Packet loss every night, intermittent

L

Leno

Expert Member
Joined
May 15, 2005
Messages
2,396
Reaction score
767
Location
UK & PE
Every night while browsing the www it all comes crawling to a stop

running a ping clearly shows bad packet loss

eg:


64 bytes from 168.210.2.2: icmp_seq=31 ttl=57 time=67.180 ms
64 bytes from 168.210.2.2: icmp_seq=32 ttl=57 time=67.126 ms
Request timeout for icmp_seq 33
Request timeout for icmp_seq 34
64 bytes from 168.210.2.2: icmp_seq=35 ttl=57 time=70.438 ms
64 bytes from 168.210.2.2: icmp_seq=36 ttl=57 time=60.141 ms
64 bytes from 168.210.2.2: icmp_seq=37 ttl=57 time=73.978 ms
64 bytes from 168.210.2.2: icmp_seq=38 ttl=57 time=72.203 ms
Request timeout for icmp_seq 39
64 bytes from 168.210.2.2: icmp_seq=40 ttl=57 time=65.103 ms
64 bytes from 168.210.2.2: icmp_seq=41 ttl=57 time=67.619 ms
Request timeout for icmp_seq 42
64 bytes from 168.210.2.2: icmp_seq=43 ttl=57 time=64.469 ms
Request timeout for icmp_seq 44
64 bytes from 168.210.2.2: icmp_seq=45 ttl=57 time=60.002 ms
64 bytes from 168.210.2.2: icmp_seq=46 ttl=57 time=58.692 ms
Request timeout for icmp_seq 47
Request timeout for icmp_seq 48
64 bytes from 168.210.2.2: icmp_seq=49 ttl=57 time=57.036 ms
64 bytes from 168.210.2.2: icmp_seq=50 ttl=57 time=60.258 ms
64 bytes from 168.210.2.2: icmp_seq=51 ttl=57 time=69.612 ms
Request timeout for icmp_seq 52
Request timeout for icmp_seq 53
64 bytes from 168.210.2.2: icmp_seq=54 ttl=57 time=57.522 ms
64 bytes from 168.210.2.2: icmp_seq=55 ttl=57 time=54.816 ms
Request timeout for icmp_seq 56
Request timeout for icmp_seq 57
64 bytes from 168.210.2.2: icmp_seq=58 ttl=57 time=70.247 ms
64 bytes from 168.210.2.2: icmp_seq=59 ttl=57 time=67.355 ms
Request timeout for icmp_seq 60
Request timeout for icmp_seq 61
Request timeout for icmp_seq 62
64 bytes from 168.210.2.2: icmp_seq=63 ttl=57 time=63.989 ms
64 bytes from 168.210.2.2: icmp_seq=64 ttl=57 time=66.695 ms
Request timeout for icmp_seq 65
Request timeout for icmp_seq 66
64 bytes from 168.210.2.2: icmp_seq=67 ttl=57 time=82.428 ms
Request timeout for icmp_seq 68
64 bytes from 168.210.2.2: icmp_seq=69 ttl=57 time=53.657 ms
64 bytes from 168.210.2.2: icmp_seq=70 ttl=57 time=52.494 ms
Request timeout for icmp_seq 71
64 bytes from 168.210.2.2: icmp_seq=72 ttl=57 time=61.935 ms
64 bytes from 168.210.2.2: icmp_seq=73 ttl=57 time=71.325 ms
Request timeout for icmp_seq 74
64 bytes from 168.210.2.2: icmp_seq=75 ttl=57 time=61.353 ms
64 bytes from 168.210.2.2: icmp_seq=76 ttl=57 time=69.347 ms


few secs before working fine:

64 bytes from 168.210.2.2: icmp_seq=0 ttl=57 time=71.552 ms
64 bytes from 168.210.2.2: icmp_seq=1 ttl=57 time=61.757 ms
64 bytes from 168.210.2.2: icmp_seq=2 ttl=57 time=76.990 ms
64 bytes from 168.210.2.2: icmp_seq=3 ttl=57 time=59.531 ms
64 bytes from 168.210.2.2: icmp_seq=4 ttl=57 time=64.434 ms
64 bytes from 168.210.2.2: icmp_seq=5 ttl=57 time=63.116 ms
64 bytes from 168.210.2.2: icmp_seq=6 ttl=57 time=74.583 ms
64 bytes from 168.210.2.2: icmp_seq=7 ttl=57 time=75.212 ms
64 bytes from 168.210.2.2: icmp_seq=8 ttl=57 time=74.413 ms
64 bytes from 168.210.2.2: icmp_seq=9 ttl=57 time=64.002 ms
64 bytes from 168.210.2.2: icmp_seq=10 ttl=57 time=62.684 ms
64 bytes from 168.210.2.2: icmp_seq=11 ttl=57 time=78.275 ms
64 bytes from 168.210.2.2: icmp_seq=12 ttl=57 time=65.459 ms
64 bytes from 168.210.2.2: icmp_seq=13 ttl=57 time=77.283 ms
64 bytes from 168.210.2.2: icmp_seq=14 ttl=57 time=76.456 ms
64 bytes from 168.210.2.2: icmp_seq=15 ttl=57 time=83.089 ms
64 bytes from 168.210.2.2: icmp_seq=16 ttl=57 time=81.273 ms
64 bytes from 168.210.2.2: icmp_seq=17 ttl=57 time=79.320 ms
64 bytes from 168.210.2.2: icmp_seq=18 ttl=57 time=64.661 ms
64 bytes from 168.210.2.2: icmp_seq=19 ttl=57 time=69.393 ms
64 bytes from 168.210.2.2: icmp_seq=20 ttl=57 time=67.466 ms
64 bytes from 168.210.2.2: icmp_seq=21 ttl=57 time=57.721 ms
64 bytes from 168.210.2.2: icmp_seq=22 ttl=57 time=51.886 ms
64 bytes from 168.210.2.2: icmp_seq=23 ttl=57 time=60.805 ms
64 bytes from 168.210.2.2: icmp_seq=24 ttl=57 time=60.295 ms

Then cycle repeats itself

My line stats dont seem to change during the packet loss, but here they are


ADSL Link Downstream Upstream
Connection Speed 6143 kbps 639 kbps
Line Attenuation 39.5 db 17.0 db
Noise Margin 14.25 db 10.0 db

ISP: barebones (IS reseller)
 
Havent noticed it yet on the weekend, will keep an eye on it
 
Windows PCs have poor clocks, and are incapable of measuring with a resolution of a millisecond.
The route displayed is only the outward route taken by the probes. It is impossible to infer by what route the replies came back.
Modern routers give priority to real data packets, and very low priority to returning TTL-exceeded ICMP packets. So RTTs on intermediate routers can be anomalously high
The speed of light in fibre or copper cables adds significantly to the RTTs on long hops.
Large RTTs do not necessarily mean poor performance. The TCP pacing algorithms are quite capable of maintaining optimal traffic volume over very long paths, provided your TCP Receive Window (RWIN) is large enough
The Receive Window must be of size in bytes at least equal to the product of your rated download speed in bytes per second (512 kbps = 64000 bytes per second) times the RTT on the path in seconds.
Small RTTs do not necessarily mean good performance. It is possible for a path to give low RTTs even when it is close to saturation, or suffering packet loss.
Some routers by design do not respond to traceroute queries.
Some corporates block all traceroute queries at their firewall.


Noise Margin 14.25 db 10.0 db
Click to expand...
should be 30 dB or higher: the higher the better. As the SNR decreases below 30 dB, performance will steadily decrease, and errors will increase.
 
Last edited:
dadiggle:
You're right about the higher SNR is, the better, but not about 30dB being the threshold.

Anything above 12dB with ADSL is acceptable, as it would provide you with a stable ADSL connection and no errors whatsoever, unless something is interfering.

It's only once you're below like 8dB that you'll start noticing a performance decrease, in which case the router will disconnect & try to sync at a lower speed.
 
dadiggle said:
Windows PCs have poor clocks, and are incapable of measuring with a resolution of a millisecond.
The route displayed is only the outward route taken by the probes. It is impossible to infer by what route the replies came back.
Modern routers give priority to real data packets, and very low priority to returning TTL-exceeded ICMP packets. So RTTs on intermediate routers can be anomalously high
The speed of light in fibre or copper cables adds significantly to the RTTs on long hops.
Large RTTs do not necessarily mean poor performance. The TCP pacing algorithms are quite capable of maintaining optimal traffic volume over very long paths, provided your TCP Receive Window (RWIN) is large enough
The Receive Window must be of size in bytes at least equal to the product of your rated download speed in bytes per second (512 kbps = 64000 bytes per second) times the RTT on the path in seconds.
Small RTTs do not necessarily mean good performance. It is possible for a path to give low RTTs even when it is close to saturation, or suffering packet loss.
Some routers by design do not respond to traceroute queries.
Some corporates block all traceroute queries at their firewall.
Click to expand...
Nice copy and paste job dadiggle, I'm giving you an 'F'.
http://homepage.ntlworld.com/robin.d.h.walker/cmtips/traceroute.html
 
Aha so you're the guy who is littering our streets with all those packets!

GETTIM!
 
murpheys law i havent had a problem since i posted original post

but thats what i thought the last time i stopped for a while

there is a slight tic on the line (approx every 500ms), I suspect the alarm modem is messaging with it
but the noise is there all the time aparently even when the line works peachy (could even be the telephone)

I only discovered the noise now as I never use the landline :twisted:
 
Leno said:
murpheys law i havent had a problem since i posted original post

but thats what i thought the last time i stopped for a while

there is a slight tic on the line (approx every 500ms), I suspect the alarm modem is messaging with it
but the noise is there all the time aparently even when the line works peachy (could even be the telephone)

I only discovered the noise now as I never use the landline :twisted:
Click to expand...

PS if you wondering why i dont unplug the alarm, wonderful ATLAS hard wired it into my telephone plug....
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X