From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1IrzNy-0006H5-Mp for garchives@archives.gentoo.org; Tue, 13 Nov 2007 17:17:15 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lADHG3Yx018942; Tue, 13 Nov 2007 17:16:03 GMT Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lADHBn9W014447 for ; Tue, 13 Nov 2007 17:11:49 GMT Received: by nf-out-0910.google.com with SMTP id f5so1642195nfh for ; Tue, 13 Nov 2007 09:11:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=+B5m1p3DqZy2fgnEXX8HmOMMKkoioQGz0jkTNrH0HF4=; b=X7WtcRkn5szrFHS7WVGq9iU+L9WLLS6iGvL+lzcFHM79pW+w16xBLD4ZHkeXdkWjmIOZDY4JA+lBFr2EWizqayIaQYn2Au9qinB5SyNjxpVhY608JdhqKGc5+mtsmi7c8HRQK8BAjnCl/5cZ3Lv13KuzC15FqjLMFzAqZx8Xtwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=sEJQoqXdZSE6dKXKU5XbOruYZ9dG061LBKJORxctmzw7DGjBId8A2NFcoCKbtneZB2c2WOo7jqO/C0sskZdDWZUcAZYsVnrSQlzW0dd4+jifbs7+Uve+B92yy5CQnBEO1oSseKIAp86z0EcUvBZPLP4Gj11OGGgkr+qJftj5Ui4= Received: by 10.78.37.7 with SMTP id k7mr6948898huk.1194973908778; Tue, 13 Nov 2007 09:11:48 -0800 (PST) Received: by 10.78.132.17 with HTTP; Tue, 13 Nov 2007 09:11:48 -0800 (PST) Message-ID: <642958cc0711130911p7e74c2b7s887024121cc3f692@mail.gmail.com> Date: Tue, 13 Nov 2007 12:11:48 -0500 From: "Mark Shields" To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] {OT} Cable latency & Skype In-Reply-To: <200711131415.20954.michaelkintzios@gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_933_3242607.1194973908745" References: <49bf44f10711121559n648285a6y2a84655b8a4bc942@mail.gmail.com> <642958cc0711130545x18ddd449jb84cb8e149d0639f@mail.gmail.com> <200711131415.20954.michaelkintzios@gmail.com> X-Archives-Salt: 16c9926a-7af3-4d8c-b82b-e713d4cd5562 X-Archives-Hash: 41dfc50ddfd0383c94aecf886ce32d7e ------=_Part_933_3242607.1194973908745 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Nov 13, 2007 9:15 AM, Mick wrote: > On Tuesday 13 November 2007, Mark Shields wrote: > > On Nov 12, 2007 6:59 PM, Grant 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@gentoo.org 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 ------=_Part_933_3242607.1194973908745 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Nov 13, 2007 9:15 AM, Mick <michaelkintzios@gmail.com> wrote:
=
On Tuesday 13 November 2007, Mark Shi= elds wrote:
> On Nov 12, 2007 6:59 PM, Grant <emailgrant@gmail.com> 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 n= etwork.
> > Has anyone else noticed this and had success "fix= ing" it?  I'm using a
> > Gentoo router so I can try= just about anything.
> >
> > - Grant
> > --
> > gentoo-user@gentoo.org mailing list
&= gt;
> I work for as a cable modem technician.  The first thing t= o 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 (up= stream 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 t= o check for
> latency/packet loss.  Also ask them to check the c= ircuits/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 (altho= ugh
> Comcast just blows off high latency on pings as the result of d= ropping 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 switc= hes?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
HOST: lappy                 &nb= sp;     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 &nb= sp;18.3  17.1  19.5   0.7
 11. 194.74.77.222        =         0.0%    15   18.1  17.1 &n= bsp;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 &n= bsp; 0.9
 13. t2c1-p4-0-0.us-nyc.eu.bt.net  0.0%    15 &n= bsp;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. <= a href=3D"http://tbr1.n54ny.ip.att.net" target=3D"_blank">tbr1.n54ny.ip.att= .net         0.0%    15  133.2 133.8= 131.2 135.4   1.4
 16.=20 cr2.n54ny.ip.att.= net          0.0%    15  135.2 = 133.5 131.6 135.7   1.3
 17. cr2.wswdc.ip.att.net       &nbs= p;   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   &nbs= p;     0.0%    15  132.2 134.1 130.0 159.4   = 7.1
 21.=20 12.124.64.62   &= nbsp;             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
&nb= sp;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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Note some of these are being dropped in = the UK, rather than by Comcast.
--
Regards,
Mick
<= /div>
I would like to mention that while I am not a cable modem field te= ch, 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 issu= e and not just the ICMP packets being given lower priority/dropped.  T= he packet loss could also be that hop/ISP dropping the packet because it de= tected what it might consider "too many pings" (flood protection,= I assume).  I've seen Comcast drop on a 3rd hop before. &nbs= p;  In the case of ICMP packets having lower priority, it's best t= o 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 pro= blem somewhere along the line, and you can continue with further testing su= ch as traceroutes, speed tests, and individually pinging possible problemat= ic 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=20 speedtest.net).

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

--
- Mark Shields ------=_Part_933_3242607.1194973908745-- -- gentoo-user@gentoo.org mailing list