[Tech] Need help with the Internet at the Mentone ("slow" ... latency? and/or connectivity?)
Christian Einfeldt
einfeldt at gmail.com
Tue Jun 28 23:40:56 PDT 2016
Thanks, Michael! I am going to chew on this for a while. :-)
On Tue, Jun 28, 2016 at 7:06 PM, Michael Paoli <
Michael.Paoli at cal.berkeley.edu> wrote:
> You might want to start with closest hop router.
> It's likely default. Can find that with the ip command.
> If that command isn't on (your mere mortal user) PATH,
> it's typically in /sbin or /usr/sbin, so could use absolute
> (starts with /) path to the program instead (e.g. prepend ip
> with /sbin/ or /usr/sbin/). So e.g. I find from my example
> host:
> $ ip r s
> default via 198.144.194.233 dev br0
> 192.168.55.0/24 dev br0 proto kernel scope link src 192.168.55.1
> 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
> 198.144.194.232/29 dev br0 proto kernel scope link src 198.144.194.235
> $
> So, most notable there, would be the IP that shows in the
> default route:
> 198.144.194.233
> Interestingly/oddly that command didn't show my IPv6 bits, but that
> may not matter for your setup. Anyway, giving option to just show
> the IPv6, I have:
> $ ip -6 r s
> 2001:470:66:76f::1 dev he-ipv6 metric 1024
> 2001:470:66:76f::/64 dev he-ipv6 proto kernel metric 256
> fe80::/64 dev br0 proto kernel metric 256
> fe80::/64 dev he-ipv6 proto kernel metric 256
> fe80::/64 dev vnet0 proto kernel metric 256
> default via 2001:470:66:76f::1 dev he-ipv6 metric 1024
> $
> ... so in that case, for the IPv6 portion, default router IP:
> 2001:470:66:76f::1
>
> Anyway, should be able to ping your default router IP(s),
> ping(1) for IPv4, ping6 for IPv6, e.g.:
> $ ping -n -c 5 198.144.194.233
> PING 198.144.194.233 (198.144.194.233) 56(84) bytes of data.
> 64 bytes from 198.144.194.233: icmp_seq=1 ttl=255 time=29.3 ms
> 64 bytes from 198.144.194.233: icmp_seq=2 ttl=255 time=10.6 ms
> 64 bytes from 198.144.194.233: icmp_seq=3 ttl=255 time=11.2 ms
> 64 bytes from 198.144.194.233: icmp_seq=4 ttl=255 time=11.3 ms
> 64 bytes from 198.144.194.233: icmp_seq=5 ttl=255 time=12.1 ms
>
> --- 198.144.194.233 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4003ms
> rtt min/avg/max/mdev = 10.676/14.960/29.305/7.188 ms
> $
> and for IPv6:
> $ ping6 -n -c 5 2001:470:66:76f::1
> PING 2001:470:66:76f::1(2001:470:66:76f::1) 56 data bytes
> 64 bytes from 2001:470:66:76f::1: icmp_seq=1 ttl=64 time=15.0 ms
> 64 bytes from 2001:470:66:76f::1: icmp_seq=2 ttl=64 time=15.4 ms
> 64 bytes from 2001:470:66:76f::1: icmp_seq=3 ttl=64 time=15.0 ms
> 64 bytes from 2001:470:66:76f::1: icmp_seq=4 ttl=64 time=15.1 ms
> 64 bytes from 2001:470:66:76f::1: icmp_seq=5 ttl=64 time=14.2 ms
>
> --- 2001:470:66:76f::1 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4005ms
> rtt min/avg/max/mdev = 14.216/14.971/15.440/0.426 ms
> $
>
> You may also be able to isolate issues with traceroute, e.g. using
> TCP with traceroute (need to be superuser ("root") to do this, so
> sudo or as root, so, e.g.:
> $ dig -t A www.google.com. +short
> 172.217.1.228
> $ sudo traceroute -n -T -p 443 172.217.1.228
> traceroute to 172.217.1.228 (172.217.1.228), 30 hops max, 60 byte packets
> 1 198.144.194.233 10.857 ms 12.343 ms 14.765 ms
> 2 216.131.94.209 16.936 ms 19.052 ms *
> 3 * * 173.205.60.193 21.125 ms
> 4 89.149.180.42 30.564 ms * 141.136.106.206 33.101 ms
> 5 199.229.230.134 37.055 ms 37.975 ms 41.609 ms
> 6 216.239.49.168 42.531 ms 34.588 ms 39.405 ms
> 7 64.233.174.91 46.842 ms 49.246 ms 209.85.246.38 53.627 ms
> 8 64.233.174.204 65.770 ms 58.009 ms 57.582 ms
> 9 209.85.248.124 55.769 ms 64.233.174.191 56.836 ms 55.163 ms
> 10 * * *
> 11 172.217.1.228 43.975 ms 42.202 ms 37.240 ms
> $
>
>
> From: "Christian Einfeldt" <einfeldt at gmail.com>
>> Subject: Re: [Tech] Need help with the Internet at the Mentone ("slow"
>> ... latency? and/or connectivity?)
>> Date: Tue, 28 Jun 2016 11:01:07 -0700
>>
>
> Hi Mike,
>>
>> How do I get the IP address for the switch? Googling doesn't seem to be
>> helping me here, I just be asking the wrong question?
>>
>> The speedtest does work on that machine from home using the same machine
>> and the same ethernet cable. Thanks!
>>
>> On Tue, Jun 28, 2016 at 8:05 AM, Michael Rojas <
>> ledworldwide.solutions at gmail.com> wrote:
>>
>> Hi Christian,
>>>
>>> It looks like you are experiencing heavy packet loss from the lobby. My
>>> next step would be to ping a switch or server on the local network from
>>> the
>>> lobby to try and narrow down where the problem lies (bad switch/router
>>> config, bad cable ...?)
>>>
>>> Why the speed test didn't work from the basement is a mystery though. Is
>>> the speedtest working from another location (from home)?
>>>
>>> -Mike Rojas-
>>>
>>>
>>>
>>> On Fri, Jun 24, 2016 at 11:46 PM, Christian Einfeldt <einfeldt at gmail.com
>>> >
>>> wrote:
>>>
>>> Hi, Thanks for your thoughts, Michael.
>>>>
>>>> On Fri, Jun 24, 2016 at 1:44 PM, Michael Paoli <
>>>> Michael.Paoli at cal.berkeley.edu> wrote:
>>>>
>>>> Sounds like you've got latency issue, not necessarily bandwidth
>>>>> issue(s). The very long times on ping to Google would
>>>>> reflect latency issues. It's not uncommon for ISPs to support
>>>>> large buffering - this gives 'em a slight edge in most typical
>>>>> bandwidth tests ... and the cost of latency - as/when the
>>>>> bandwidth is quite saturated, buffers fill, and hence latency
>>>>> can be quite to even exceedingly high. This can then trigger various
>>>>> errors, such as DNS timeouts - which might well be why your
>>>>> "speed tests" failed - but can't really tell from the limited output
>>>>> that check provided (the CLI tool may have options for more details,
>>>>> and/or one may use additional diagnostics to check what's happening
>>>>> when the speed test is attempted - which may then make clear why the
>>>>> test is failing). Shared usage of bandwidth can be an issue, e.g.
>>>>> multiple computers, etc., and single "pipe" of some fixed limited
>>>>> bandwidth to Internet. If one machine is hogging it all, or even
>>>>> multiple are together trying to use all the bandwidth, that will
>>>>> make it "slow" for them, and anything else attempting to share that
>>>>> bandwidth.
>>>>>
>>>>> Anyway, realized and understand that bandwidth (speed), and latency
>>>>> (how long does the trip take) are not the same thing. Either may
>>>>> be perceived as "slow", depending upon the nature of the usage.
>>>>>
>>>>> If, as you mention, you're having problems even doing the updates,
>>>>> it's likely either issues with latency causing issues with DNS,
>>>>> and/or more general connectivity issues (which may also be caused
>>>>> by latency issues). "Slow" - as in low bandwidth, will not
>>>>> in-and-of-itself break "speed"tests or getting updates on-line ...
>>>>> were it only a bandwidth issue, things would just take longer ...
>>>>> possibly *much* longer.
>>>>>
>>>>> From: "Christian Einfeldt" <einfeldt at gmail.com>
>>>>>
>>>>>> Subject: [Tech] Need help with the Internet at the Mentone
>>>>>> Date: Fri, 24 Jun 2016 11:50:55 -0700
>>>>>>
>>>>>>
>>>>> Hi,
>>>>>
>>>>>>
>>>>>> Here are my questions:
>>>>>>
>>>>>> 1. Why did my speed tests fail in this situation?
>>>>>> 2. Are the ping speeds normal for this situation?
>>>>>> 3. What diagnostic tests can I run to isolate the slowness on this
>>>>>> system?
>>>>>>
>>>>>> As most people on this list know, Partimus is volunteering for a low
>>>>>> income
>>>>>> housing shelter in here in SF. I have put in some quality legacy
>>>>>> Lubuntu
>>>>>> machines in the lobby for the residents to use. These machines all
>>>>>> have
>>>>>> Intel Core 2 duo chips with 2 GB of RAM and are running Lubuntu 14.04.
>>>>>> I
>>>>>> use a similar machine at home, and have no problems with it. This
>>>>>> email is
>>>>>> being written on such a machine at one of the other two homeless
>>>>>> shelters.
>>>>>> The residents routinely use these machines to watch YouTube video and
>>>>>> use
>>>>>> LibreOffice, etc., all without issue. The machines are proven good.
>>>>>>
>>>>>> This is the third shelter to which we have given machines. They don't
>>>>>> have
>>>>>> a budget for either the equipment or the tech support for these
>>>>>> machines.
>>>>>>
>>>>>> Two of the three shelters have good speed on the Internet that goes to
>>>>>> the
>>>>>> machines. (The shelters provide the Internet service).
>>>>>>
>>>>>> However, the third shelter, called the Mentone, has slow Internet
>>>>>> speeds in
>>>>>> the lobby. I am not able to even do anything as basic as run sudo
>>>>>> apt-get
>>>>>> update, as the machine chokes on downloading the updates.
>>>>>>
>>>>>> The wiring is put in place by a company I will call the Maintenance
>>>>>> Group
>>>>>> (MG). I have called both the MG and the ISP. Both of them claim that
>>>>>> they
>>>>>> have no problems. The ISP says that they are providing the usual 2
>>>>>> Mbit /
>>>>>> second that we expect here in the US for a configuration like this.
>>>>>> The MG
>>>>>> says that they have run a test on the wiring from the server to the
>>>>>> lobby,
>>>>>> and are not seeing any problems.
>>>>>>
>>>>>> The ISP is a good company that does not hate GNU-Linux.
>>>>>>
>>>>>> The ISP asked me to give them a speed test directly from the switch,
>>>>>> which
>>>>>> is located in the basement. So I ran speed tests in the basement and
>>>>>> in
>>>>>> the lobby, and was unable to get the speed test to work. Speed test
>>>>>> has
>>>>>> worked on this machine before. Here are the two results:
>>>>>>
>>>>>> Lobby, where the Lubuntu machine is to be located:
>>>>>>
>>>>>> cje at cje-ultralap440:~$ speedtest-cli
>>>>>>
>>>>>> Retrieving speedtest.net configuration...
>>>>>>
>>>>>> Could not retrieve speedtest.net configuration: timed out
>>>>>>
>>>>>> cje at cje-ultralap440:~$ ifconfig
>>>>>>
>>>>>> eth0 Link encap:Ethernet HWaddr 20:1a:06:04:64:42
>>>>>> inet addr:172.16.2.121
>>>>>>
>>>>>> basement, directly from the switch:
>>>>>>
>>>>>> cje at cje-ultralap440:~$ speedtest-cli
>>>>>>
>>>>>> Retrieving speedtest.net configuration...
>>>>>>
>>>>>> Could not retrieve speedtest.net configuration: timed out
>>>>>>
>>>>>> cje at cje-ultralap440:~$
>>>>>>
>>>>>> *My first question: *I am not sure why this speed test failed. Does
>>>>>> anyone know?
>>>>>>
>>>>>> Since I couldn't run speedtest, I pinged google instead. Here are the
>>>>>> results from the lobby:
>>>>>>
>>>>>> cje at cje-ultralap440:~$ ping www.google.com
>>>>>>
>>>>>> PING www.google.com (216.58.192.4) 56(84) bytes of data.
>>>>>>
>>>>>> 64 bytes from nuq04s29-in-f4.1e100.net (216.58.192.4): icmp_seq=1
>>>>>> ttl=52
>>>>>> time=8.24 ms
>>>>>>
>>>>>> 64 bytes from nuq04s29-in-f4.1e100.net (216.58.192.4): icmp_seq=2
>>>>>> ttl=52
>>>>>> time=7.31 ms
>>>>>> <snip>
>>>>>>
>>>>>> --- www.google.com ping statistics ---
>>>>>>
>>>>>> 16 packets transmitted, 12 received, 25% packet loss, time 15037ms
>>>>>>
>>>>>> rtt min/avg/max/mdev = 6.962/7.497/8.198/0.366 ms
>>>>>>
>>>>>> Here is the test from the basement:
>>>>>>
>>>>>> cje at cje-ultralap440:~$ ping www.google.com
>>>>>>
>>>>>> PING www.google.com (216.58.192.4) 56(84) bytes of data.
>>>>>>
>>>>>> 64 bytes from nuq04s29-in-f4.1e100.net (216.58.192.4): icmp_seq=1
>>>>>> ttl=52
>>>>>> time=8.24 ms
>>>>>>
>>>>>> 64 bytes from nuq04s29-in-f4.1e100.net (216.58.192.4): icmp_seq=2
>>>>>> ttl=52
>>>>>> time=7.31 ms
>>>>>> <snip>
>>>>>>
>>>>>> --- www.google.com ping statistics ---
>>>>>>
>>>>>> 11 packets transmitted, 11 received, 0% packet loss, time 10015ms
>>>>>>
>>>>>> rtt min/avg/max/mdev = 7.022/7.816/8.519/0.451 ms
>>>>>>
>>>>>> cje at cje-ultralap440:~$
>>>>>>
>>>>>> *My second question*: Are these ping speeds normal?
>>>>>>
>>>>>> My third question: What can I do to find the problem with the system?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> --
>>>>>> Christian Einfeldt
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Christian Einfeldt
>>>>
>>>> _______________________________________________
>>>> Tech mailing list
>>>> Tech at lists.partimus.org
>>>> http://lists.partimus.org/listinfo.cgi/tech-partimus.org
>>>>
>>>>
>>>>
>>>
>>
>> --
>> Christian Einfeldt
>>
>>
>
>
--
Christian Einfeldt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.partimus.org/pipermail/tech-partimus.org/attachments/20160628/59b5a659/attachment-0001.htm>
More information about the Tech
mailing list