Packet loss, any ideas why?

[Wing man]

Normally I have a good connection when I play Continuum but the past week I have noticed I am dropped from DD games due to High Packet Loss. I read a few other threads and did a Trace.

Please advise me if you see anything that could explain it.

Thanks in advance. I use Avast Anti Virus, Spywareblaster, Adaware, and regularly clean my PC and keep it running smooth.

 

Trace results:

http://i8.tinypic.com/24orax4.jpg

[»SOS]

Trace looks completely normal. Could not be any better - you have 0% packetloss (those two big numbers are measurement defects).

 

Can you try another computer on the same connection?

 

Strange network problems are caused by the network card in many cases.

[Wing man]

Thanks for the reply, seems ok now.....

[»Admiral Kirk]

That kind of trace should be impossible ^^. You cant have a _lower_ latency to a host that is after a host with higher latency in terms of hops... The fact that it jumps from to 10 says to me that that program doesnt test very well, either that or the hosts give low priority to ICMP traffic and greater priority to p!@#$%^&*-through traffic, in which case trace is totaly useless. Might also expain the ploss on the trace that might not show up in actual game play.

[Bargeld]

The way that all 'ongoing' traces function allows it to happen. It doesn't trace to the destination and then take hop times from there. It determines the path during the initial stages of starting the trace, then I queries each IP address along the way, one at a time.

 

So if you happen to have a moment of network traffic at an earlier hop, you can get an ms ping. The latency clears up and the next hop reports back normally, at 10 ms.

 

 

Client -> Hop 1 (10 ms)

Client -> Hop 2 (10 ms)

Client -> Hop 3 ( ms - cuz there was some network traffic while sending to this IP)

Client -> Hop 4 (10 ms - the temporary network traffic has subsided and therefore doesnt impact this ping)

Client -> Hop 5 (10 ms)

etc.

Then it repeats.

 

This is why, when you watch a trace from the main menu of Continuum, the time it takes to update each hop, as it progresses, takes longer than a single ping to the destination. The time it takes to update each hop should be about the same as the latency to that hop (which it reports) + the latency of the return trip (which isn't reported) + processing time.

[»SOS]

Although a much higher average over 410 cycles is still higher. Of course, this can simply be attributed to the router in question having some weird reply behaviour. But yeah, perfectly normal in any case

[»Admiral Kirk]

Yes I understand how cyclic pings work... However, in order to send the ICMP data to a host thats further down stream (hops forward) it must go through all previous hops to get thier. Now note the Min numbers.. The smallest ping at hop 6 is the smallest ping at hop 7 is 10. That is to say that a ping send to hop 6 has never come back with in less than 80ms... However, it seams that a hop has gotten back from hop 7 in 10ms at some point. In order for that to legitimitly happen (as in no traffic shaping involved). Either thier would have had to have been a _very_ short momentary lack of lag allowing the ping to hop 7 to traverse hop 6 in less than 10ms and then said reduction in lag would have to never happen when sending icmp packets to hop 6. Or the routers do packet shaping and give directed icmp packets lower priority but p!@#$%^&*-through packets normal priority. At any rate, its all academic

[»SOS]

My god. Enter key, man!