1 |
On Nov 13, 2007 9:15 AM, Mick <michaelkintzios@×××××.com> wrote: |
2 |
|
3 |
> On Tuesday 13 November 2007, Mark Shields wrote: |
4 |
> > On Nov 12, 2007 6:59 PM, Grant <emailgrant@×××××.com> wrote: |
5 |
> > > I just switched from DSL to cable and I'm noticing a significant delay |
6 |
> > > when using Skype, even when nothing else is happening on my network. |
7 |
> > > Has anyone else noticed this and had success "fixing" it? I'm using a |
8 |
> > > Gentoo router so I can try just about anything. |
9 |
> > > |
10 |
> > > - Grant |
11 |
> > > -- |
12 |
> > > gentoo-user@g.o mailing list |
13 |
> > |
14 |
> > I work for as a cable modem technician. The first thing to check for |
15 |
> when |
16 |
> > you're having cable internet problems is the modem. Call up tech |
17 |
> support |
18 |
> > and ask them to check the signals on the modem (upstream power, |
19 |
> downstream |
20 |
> > rcv, downstream SNR, upstream SNR, headend receive) and make sure |
21 |
> they're |
22 |
> > in range. Also ask them to ping and (if available) rf ping to check for |
23 |
> > latency/packet loss. Also ask them to check the circuits/backbone. |
24 |
> Also, |
25 |
> > can you reproduce this latency in the form of a ping/traceroute? This |
26 |
> will |
27 |
> > go a long way with ISPs in determining where the problem is (although |
28 |
> > Comcast just blows off high latency on pings as the result of dropping |
29 |
> them |
30 |
> > due to lower priority). |
31 |
> |
32 |
> Interesting to hear this. The OP will no doubt have a different |
33 |
> traceroute to |
34 |
> show the ISP, but does the comment on dropping pings explain the % loss |
35 |
> shown |
36 |
> below in certain hops, or is it just a matter of overloaded switches? |
37 |
> ========================================================================== |
38 |
> HOST: lappy Loss% Snt Last Avg Best Wrst |
39 |
> StDev |
40 |
> 5. 217.41.177.66 0.0% 15 17.9 18.0 15.7 22.8 |
41 |
> 1.7 |
42 |
> 6. 217.41.177.134 6.7% 15 21.0 17.5 15.7 21.0 |
43 |
> 1.5 |
44 |
> 7. 217.41.177.54 0.0% 15 17.0 16.6 15.1 20.7 |
45 |
> 1.4 |
46 |
> 8. 217.47.166.106 0.0% 15 16.0 16.9 15.3 18.9 |
47 |
> 1.1 |
48 |
> 9. core1-pos5-2.faraday.ukcore. 0.0% 15 17.0 45.3 15.2 192.3 |
49 |
> 52.7 |
50 |
> 10. core1-pos0-15-0-10.ilford.uk 0.0% 15 18.9 18.3 17.1 19.5 |
51 |
> 0.7 |
52 |
> 11. 194.74.77.222 0.0% 15 18.1 17.1 15.5 19.1 |
53 |
> 1.0 |
54 |
> 12. t2c1-ge14-0-0.uk-ilf.eu.bt.n 6.7% 15 17.9 17.3 15.7 19.1 |
55 |
> 0.9 |
56 |
> 13. t2c1-p4-0-0.us-nyc.eu.bt.net 0.0% 15 107.3 108.1 106.1 109.7 |
57 |
> 1.1 |
58 |
> 14. 12.116.102.17 0.0% 15 108.3 107.9 105.5 110.0 |
59 |
> 1.3 |
60 |
> 15. tbr1.n54ny.ip.att.net 0.0% 15 133.2 133.8 131.2 135.4 |
61 |
> 1.4 |
62 |
> 16. cr2.n54ny.ip.att.net 0.0% 15 135.2 133.5 131.6 135.7 |
63 |
> 1.3 |
64 |
> 17. cr2.wswdc.ip.att.net 0.0% 15 132.2 132.9 131.3 134.7 |
65 |
> 1.1 |
66 |
> 18. cr1.attga.ip.att.net 0.0% 15 134.2 133.6 132.1 135.7 |
67 |
> 1.2 |
68 |
> 19. tbr2.attga.ip.att.net 0.0% 15 135.2 134.0 132.0 136.2 |
69 |
> 1.3 |
70 |
> 20. gar4.attga.ip.att.net 0.0% 15 132.2 134.1 130.0 159.4 |
71 |
> 7.1 |
72 |
> 21. 12.124.64.62 20.0% 15 140.2 138.6 137.0 140.4 |
73 |
> 1.1 |
74 |
> 22. te-9-1-ur01.south.tn.knox.co 6.7% 15 141.2 140.4 138.1 141.5 |
75 |
> 1.0 |
76 |
> 23. te-8-3-ur02.west.tn.knox.com 0.0% 15 141.2 140.3 139.1 141.2 |
77 |
> 0.6 |
78 |
> 24. ge-1-46-ur01.west.tn.knox.co 0.0% 15 138.2 138.6 137.8 140.6 |
79 |
> 0.9 |
80 |
> ========================================================================== |
81 |
> |
82 |
> Note some of these are being dropped in the UK, rather than by Comcast. |
83 |
> -- |
84 |
> Regards, |
85 |
> Mick |
86 |
> |
87 |
|
88 |
I would like to mention that while I am not a cable modem field tech, I do |
89 |
work in an escalated dept (Tier II). That said, most of the time when you |
90 |
see packet loss/high latency at one hop, you'll see it at the sequential |
91 |
hops after that if it's a true packet loss/latency issue and not just the |
92 |
ICMP packets being given lower priority/dropped. The packet loss could also |
93 |
be that hop/ISP dropping the packet because it detected what it might |
94 |
consider "too many pings" (flood protection, I assume). I've seen Comcast |
95 |
drop on a 3rd hop before. In the case of ICMP packets having lower |
96 |
priority, it's best to just ping the host you're trying to get to then go |
97 |
from there - like an average of 100 sequential pings, for example. |
98 |
Generally speaking, if a basic ping such as this returns latency/packet |
99 |
loss, there's a problem somewhere along the line, and you can continue with |
100 |
further testing such as traceroutes, speed tests, and individually pinging |
101 |
possible problematic hops. Concerning Comcast, I called them once and |
102 |
complained about latency; they rebutted with the fact ICMP packets have a |
103 |
lower priority on their network. |
104 |
|
105 |
That doesn't make any sense to me, though. If they're having to drop ICMP |
106 |
packets, what does that say about the capacity of the network? Regardless, |
107 |
the best way to test for packet loss is to run a speed test. If your speeds |
108 |
are decently consistent and what you pay for (or close to it), then packet |
109 |
loss isn't an issue (I recommend speedtest.net). |
110 |
|
111 |
One last thing: this thread is way off-topic. I suggest we take this to |
112 |
another forum or just e-mail off this mailing list if we wish to continue. |
113 |
|
114 |
-- |
115 |
- Mark Shields |