[gentoo-amd64] Cable modem help Was: Measure network speeds between machines?

[Duncan]

Paul Hartman posted on Thu, 06 Jun 2013 15:11:59 -0500 as excerpted:

> On Thu, Jun 6, 2013 at 2:09 PM, Mark Knecht <markknecht@×××××.com>
> wrote:
>> Hi,
>>    Just taking a shot at the dark on this list before I ask something
>> in the forums. Is there a simple app (or even something at the command
>> line) that I can use to measure network throughput between two Gentoo
>> machines on my internal network?
>
> Check out net-analyzer/ttcp and net-misc/iperf

In addition to these which others mentioned, take a look at bing (NOT the 
MS search engine, "Bandwidth-PING"!).  It's probably most useful outside 
the LAN once you've decided your LAN is fine, but it can be used inside 
as well, and bing can be /quite/ useful for looking at how latency is 
affected by packet size and/or content (compressible vs. not (pseudo-
random), or you can specify the content).

What's particularly nice on the WAN side is that you specify the near and 
the far end (neither of which you have to control), and bing tells you 
the difference in speed between them.  So you can use a traceroute or the 
like to find the route taken, then focus in on segments of it.  For 
instance, you can make the near end your ISP gateway and the far end the 
last ISP hop in your city, very useful for checking if there's a problem 
router in the local ISP's equipment.

>>    Background: We sold our house & moved. Comcast talked me into
>> getting there new 'Blast' level Internet service with "speed up to
>> 50Mb/S" but darned if it isn't slower than regular Comcast ISP service
>> was a the previous house. In our house I typically got about 27Mb/S
>> download using something like www.Speakeasy.net/speedtest at a
>> measurement tool. Here I've never gotten higher than 22Mb/S. I do
>> however get much better upload speeds - about 12Mb/S instead of the
>> 5Mb/S I got at the house.
>
> I don't have Comcast but often ISPs will host a speed test server inside
> their network, so you can ensure the speeds you're seeing are not being
> limited by normal Internet slowdown issues outside of their system.

FWIW as can probably be deduced from my mail address, I'm on cox, another 
cable ISP.  Luckily for me (I happen to live in cox land, not comcast 
land), cox's internet service consistently comes out near the top in 
customer surveys, while comcast at least by reputation is rather nearer 
the bottom.  So I've always felt fortunate that I'm in cox territory, not 
comcast's, tho I guess rather obviously not everyone's experience is so 
terrible with comcast or people would be finding other alternatives.

> To take a page out of the generic ISP tech support, I would try plugging
> your computer directly into the cable modem and seeing what kind of
> speeds you get then, to eliminate any outside factors.

Absolutely.  This one was always pretty close to the first suggestion 
back when cox still had newsgroups and I hung out on them.

> If you're using your own router, I would check to ensure it is fast
> enough to handle that kind of speed. If it has Gigabit ethernet ports
> that is usually a good sign. If it only has 10/100 then you might wind
> up replacing it with something more modern.

Strongly seconded once again.

Because the router is normally doing NAPT (Network Address and Port 
Translation, aka PAT, Port Address Translation, the consumer level 
variant of the more generalized NAT, Network Address Translation) and 
often more active firewalling as well, and due to the cheap CPU and 
memory provisioning common consumer level routers have, very commonly the 
LAN/WAN thruput on a consumer level router is 50% or less the rated 
Ethernet port bandwidth.  You'll often get near full port thruput on the 
LAN side as that's typically less router CPU processing, if any 
(sometimes the LAN side is simply an unmanaged switch, with the only real 
routing and processing actually done only between the LAN/WAN 
interfaces), but LAN/WAN thruput is all too commonly 25-33% port rating.

Which means that a typical 100 Mb "fast ethernet" router will commonly 
top off at between 25-30 Mbit in real life.  Thus, certainly Cox *VERY* 
strongly recommends a modern router with gigabit ports for all their 
higher tier internet services, as they're typically provisioned to do a 
couple hundred Mbit minimum (can't get /too/ far below the port rating) 
LAN/WAN thruput, while as I said it's VERY common to have 100 Mbit "fast 
ethernet" port routers top out at 25-30 Mbit.


Meanwhile, I know a bit about cable modems from my cox newsgroup days as 
well.  What brand and model modem do you have, and are you renting it or 
did you purchase?  I'm personally quite partial to the Motorola Surf 
Board brand modems, as they tend to be reliably high quality, and to 
expose more troubleshooting information on the customer side if they know 
where to look.  Other brand modems /can/ be as good, but the Motorola 
surf boards have seemed to have been consistently good quality (and as I 
said to expose more trouble shooting info to the customer) from the first 
dialup uplink cable modem models many years ago thru to the latest 
DOCSIS-3.x rated sb6xxx series.

In your web browser, try going to http://192.168.100.1 (this assumes a 
stand-alone modem, a combined modem/router /may/ expose the same 
information differently, I'm not sure as I've never had one).  On any 
DOCSIS certified modem, this should be the modem's internal web server 
troubleshooting interface (assuming comcast doesn't disable it entirely, 
cox doesn't).  As I said above, however, some brand/model modems expose 
more information here than others, with the Motorola Surfboards being 
consistently really good.

Depending on your modem's brand and model (and on what the ISP has 
configured as restricted), the interface will differ some.  However, the 
most critical information is usually found on a signals page, or similar.

There are three critical signal-strength numbers.  In order of what tends 
to show problems first they are upstream power level, downstream power 
level, and downstream SNR (signal to noise ratio).

Upstream power level is best in the 40s dBmV, tho I've seen people report 
connections at much lower values (into the lower 30s IIRC and even one at 
27, tho I wonder how he could connect at all or maybe his firmware was 
weird and it was mis-reporting, he was having issues, tho), and depending 
on the modulation used, the numbers typically top out at 55-58.  Above 50 
means your modem is effectively having to shout to be heard properly by 
the cable head-end, to the point it's causing interference with the 
downstream signal as well, while below about 38-40 means your modem is 
whispering and even that is still coming thru painfully loud at the other 
end.

But an upstream power in the 40s is good. =:^)

Downstream power is ideally 0, and the two ends will adjust their 
transmission power levels within a range to try to keep (near) zero at 
the other end if possible, so this one doesn't go out of range as often 
as upstream power, but if it does, it definitely indicates problems.  The 
equipment is rated to work at zero +/- 15 dBmV, but from all I've seen, 
you want it between about -8 and +2 if possible -- if it gets out of that 
range you can usually still connect, but there tend to be more issues as 
the connection gets more marginal.  A positive value isn't very common 
and often indicates an additional line-amp in the line -- line-amps are 
often useful for (at least old style analog, I don't really know about 
the newer digital, tho I suspect it may be more like internet) video, but 
tend to be more problematic for internet, thus the unbalance favoring the 
negative side.  If you're better than -6, solid connection.  -8, still 
pretty good but you might have occasional temporary issues.  -10 is 
getting marginal and often means intermittent issues.  -12 or worse, 
better be worried.

Downstream SNR.  Ultimately, this is the number that really counts, the 
number that the power dynamically adjusts for to keep consistent, tho of 
course you can only see the modem's side of this one, not the number at 
the head-end.  Higher is better.  Typical good numbers are in the upper 
30s, tho down to 32 or so should be usable.  Honestly, I don't remember 
seeing this one go low too often, however, unless at least one of the 
other two were WAAYYY out, which isn't surprising, since by design the 
others adjust to try to keep this one in line, so the others will go out 
of line first.

Finally, even if your numbers are reasonable, note whether they change 
dramatically over the course of hours.  Some seasonal swing is normal -- 
colder typically better so summer is the critical time -- but if you're 
swinging 10 dBmV (or even 8, I'd actually be worried if it's more than 6) 
either upstream or downstream in a few hours and it's not due to some 
really serious weather changes, chances are good that there's a loose 
fitting or bad cable somewhere.  The reason this matters even if the 
numbers stay reasonably good is that there's a limit to the dynamic 
adjustment the equipment can make while maintaining a connection.  Thus, 
big swings often force the equipment to break the existing connection and 
renegotiate a new one with new parameters.  That's fine if it's happening 
a time or two a season, but if it's happening several times a day, it's 
irritating, since you will obviously not be able to do anything on the 
net while it's renegotiating.

So good numbers are 40s upstream power, 0 to -6 downstream power, and mid 
to upper 30s downstream SNR, without wild swings.

With upstream power often being the first to show issues, if you're 
running over 50 or under 40 there, it's quite likely to be affecting your 
speeds.  As I mentioned, even tho it's upstream, the two-way nature of 
the common TCP connection and the fact that there can be some 
interference between upstream and downstream does mean that an upstream 
power above 50, certainly above 52, can mean downstream issues as well.  
That has both my own experience and that I've seen on the cox newsgroups 
(and the general comp.dcom.xdsl and cable-modems newsgroups during the 
time I was reading them too) as well.

Lastly, on Motorola Surfboards at least, and some but not all other 
brands, there's generally a log page available that can make interesting 
reading too.  I won't cover it in nearly the detail I did the above but 
two hints for reading it: 1) At least Motorola Surfboard modems run Linux 
internally (modern versions even have an open source page with links to 
the appropriate sources, in compliance with the GPL... tho it doesn't do 
a lot of good unless you have a handy cable head-end lying around, since 
by DOCSIS standard, the firmware can only be flashed from the RFI side, 
not the Ethernet side), and thus have the same Linux/POSIX standard epoch 
time, January 1, 1970.  Thus, any log events showing as 1970 indicate the 
modem wasn't able to contact a time server since its last reset at the 
time that event occurred, so it's effectively measuring the time since 
the modem booted, before it could get a connection.  And AFAIK, times are 
in universal time, so offset from (basically) GMT, not local time.  2) 
Logged events can appear much more alarming than they actually are, and 
in fact, on some cable systems certain functions won't be used at all so 
will repeatedly timeout, unless/until the cableco decides to turn off the 
warnings entirely in the config, which it often does eventually, but not 
always right away.  If you actually lose sync, either that or modem reset 
along with a few 1970 events until it can contact a time server again, 
show up.  So if you're not seeing that very often (my log shows cox did 
something short early on June 6, but there weren't any 1970 times 
reported so it was short, and before that, the last outage was May 16, 
longer and more serious, as 1970 times reach back from then until the 
beginning of the log), nothing to worry about even if some of the logged 
events do look rather alarming.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman