Re: {OT} Cable latency & Skype

1 msg	Re: [Pyqwt-users] Modification of the coordinat...
5 msg	Netvanta router will not read Gentoo MAC address
24 msg	7. Configuring the Kernel
5 msg	dev-libs/apr-0.9.12 pulled back by revdep-rebuild
2 msg	gentoo as a baseline to build a secure server O...
18 msg	'free -m' under x86_64
4 msg	portage rsync error
4 msg	Gentoo dedicated servers
4 msg	Konqueror background has light and dark stripes
8 msg	portage update problems due to sane-backends
15 msg	problems with clipboard separation
9 msg	VERY OFF TOPIC - change sparse data to daily data
9 msg	Partition tale recovery
4 msg	Problem with hdparm and SATA-controller
3 msg	Return of packages.gentoo.org?
5 msg	how to detect the throughput in the lan?
2 msg	Apollon problem (only gnutella works)
3 msg	LTSP sound and readme.
1 msg	mouse freeze

{OT} Cable latency & Skype
\ Grant (12 Nov 2007)
. \ Mick (13 Nov 2007)
. \ Mark Shields (13 Nov 2007)
. . \ Mick (13 Nov 2007)
. . . \ Mark Shields (13 Nov 2007)

Subject:	Re: {OT} Cable latency & Skype
Group:	Gentoo-user
From:	Mark Shields
Date:	13 Nov 2007

On Nov 13, 2007 9:15 AM, Mick <michaelkintzios> wrote:

> On Tuesday 13 November 2007, Mark Shields wrote:
> > On Nov 12, 2007 6:59 PM, Grant <emailgrant> wrote:
> > > I just switched from DSL to cable and I'm noticing a significant delay
> > > when using Skype, even when nothing else is happening on my network.
> > > Has anyone else noticed this and had success "fixing" it? I'm using a
> > > Gentoo router so I can try just about anything.
> > >
> > > - Grant
> > > --
> > > gentoo-user mailing list
> >
> > I work for as a cable modem technician. The first thing to check for
> when
> > you're having cable internet problems is the modem. Call up tech
> support
> > and ask them to check the signals on the modem (upstream power,
> downstream
> > rcv, downstream SNR, upstream SNR, headend receive) and make sure
> they're
> > in range. Also ask them to ping and (if available) rf ping to check for
> > latency/packet loss. Also ask them to check the circuits/backbone.
> Also,
> > can you reproduce this latency in the form of a ping/traceroute? This
> will
> > go a long way with ISPs in determining where the problem is (although
> > Comcast just blows off high latency on pings as the result of dropping
> them
> > due to lower priority).
>
> Interesting to hear this. The OP will no doubt have a different
> traceroute to
> show the ISP, but does the comment on dropping pings explain the % loss
> shown
> below in certain hops, or is it just a matter of overloaded switches?
> ==========================================================================
> HOST: lappy Loss% Snt Last Avg Best Wrst
> StDev
> 5. 217.41.177.66 0.0% 15 17.9 18.0 15.7 22.8
> 1.7
> 6. 217.41.177.134 6.7% 15 21.0 17.5 15.7 21.0
> 1.5
> 7. 217.41.177.54 0.0% 15 17.0 16.6 15.1 20.7
> 1.4
> 8. 217.47.166.106 0.0% 15 16.0 16.9 15.3 18.9
> 1.1
> 9. core1-pos5-2.faraday.ukcore. 0.0% 15 17.0 45.3 15.2 192.3
> 52.7
> 10. core1-pos0-15-0-10.ilford.uk 0.0% 15 18.9 18.3 17.1 19.5
> 0.7
> 11. 194.74.77.222 0.0% 15 18.1 17.1 15.5 19.1
> 1.0
> 12. t2c1-ge14-0-0.uk-ilf.eu.bt.n 6.7% 15 17.9 17.3 15.7 19.1
> 0.9
> 13. t2c1-p4-0-0.us-nyc.eu.bt.net 0.0% 15 107.3 108.1 106.1 109.7
> 1.1
> 14. 12.116.102.17 0.0% 15 108.3 107.9 105.5 110.0
> 1.3
> 15. tbr1.n54ny.ip.att.net 0.0% 15 133.2 133.8 131.2 135.4
> 1.4
> 16. cr2.n54ny.ip.att.net 0.0% 15 135.2 133.5 131.6 135.7
> 1.3
> 17. cr2.wswdc.ip.att.net 0.0% 15 132.2 132.9 131.3 134.7
> 1.1
> 18. cr1.attga.ip.att.net 0.0% 15 134.2 133.6 132.1 135.7
> 1.2
> 19. tbr2.attga.ip.att.net 0.0% 15 135.2 134.0 132.0 136.2
> 1.3
> 20. gar4.attga.ip.att.net 0.0% 15 132.2 134.1 130.0 159.4
> 7.1
> 21. 12.124.64.62 20.0% 15 140.2 138.6 137.0 140.4
> 1.1
> 22. te-9-1-ur01.south.tn.knox.co 6.7% 15 141.2 140.4 138.1 141.5
> 1.0
> 23. te-8-3-ur02.west.tn.knox.com 0.0% 15 141.2 140.3 139.1 141.2
> 0.6
> 24. ge-1-46-ur01.west.tn.knox.co 0.0% 15 138.2 138.6 137.8 140.6
> 0.9
> ==========================================================================
>
> Note some of these are being dropped in the UK, rather than by Comcast.
> --
> Regards,
> Mick
>

I would like to mention that while I am not a cable modem field tech, I do
work in an escalated dept (Tier II). That said, most of the time when you
see packet loss/high latency at one hop, you'll see it at the sequential
hops after that if it's a true packet loss/latency issue and not just the
ICMP packets being given lower priority/dropped. The packet loss could also
be that hop/ISP dropping the packet because it detected what it might
consider "too many pings" (flood protection, I assume). I've seen Comcast
drop on a 3rd hop before. In the case of ICMP packets having lower
priority, it's best to just ping the host you're trying to get to then go
from there - like an average of 100 sequential pings, for example.
Generally speaking, if a basic ping such as this returns latency/packet
loss, there's a problem somewhere along the line, and you can continue with
further testing such as traceroutes, speed tests, and individually pinging
possible problematic hops. Concerning Comcast, I called them once and
complained about latency; they rebutted with the fact ICMP packets have a
lower priority on their network.

That doesn't make any sense to me, though. If they're having to drop ICMP
packets, what does that say about the capacity of the network? Regardless,
the best way to test for packet loss is to run a speed test. If your speeds
are decently consistent and what you pay for (or close to it), then packet
loss isn't an issue (I recommend speedtest.net).

One last thing: this thread is way off-topic. I suggest we take this to
another forum or just e-mail off this mailing list if we wish to continue.

--
- Mark Shields