* [gentoo-amd64] Cable modem help Was: Measure network speeds between machines?
2013-06-06 20:11 ` Paul Hartman
2013-06-06 20:28 ` Mark Knecht
@ 2013-06-07 6:48 ` Duncan
1 sibling, 0 replies; 5+ messages in thread
From: Duncan @ 2013-06-07 6:48 UTC (permalink / raw
To: gentoo-amd64
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@gmail.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
^ permalink raw reply [flat|nested] 5+ messages in thread