"Linux Gazette...making Linux just a little more fun!"

The Answer Guy

By James T. Dennis, tag@lists.linuxgazette.net
Starshine Technical Services, http://www.starshine.org/

Modem Connect Speed

From James R. Ebright on 15 Jul 1998 in the comp.unix.questions newsgroup

Dear Answer Guy,

I have a question that I can't seem to find any refernce to in any of the regular documentation, (though I must admit, I only searched for about an hour this time, and sporadically over the last month or so).

How can you tell the connection speed that a modem auto-negotiates when dialing an ISP? My system log (/var/log/messages in RH5.1) does tell me the line speed I have set in the chat script, but I would like to know the connect speed as well (56K, 33.6, etc). I know this info must be available somewhere/somehow.

I've gotten questions like this before and I never did find an answer. Indeed I actually beg the question itself.

My problem with the question amounts to a couple of rhetorical questions in return:

Who cares?

What are you going to do based on this metric?

At first these questions may seem hostile. But they aren't intended in that sense. There are both practical and philosophical aspects to this.

Are you going to return the modem to your vendor or retailer if it doesn't "live up to" some speed?

Are you going to switch to a different ISP if their connect speed is better than your current average?

Are you going to force the phone company to pull new wire to your home, resplice their cables, or replace equipment in their CO based on these results?

You used the term "info" --- the "info must be available somewhere" --- but what is the real informational content of this number. Let's say you connect at 49000 bps --- your effective throughput is likely to vary throughout the duration of each call. The factors involved may be quite different but they all have one thing in common --- they are probably not anything you can effectively do anything about.

Certainly you can do metrics on latency and throughput by running scripts between two hosts (after synchronizing their clocks). That could give you highly accurate data.

I personally still question the informational content of that data.

So, I'm going to sound like a curmudgeon and say:

I don't know how to get that data, and I don't care to spend more time trying to find out.

... However, I'll forward this for publication in this months LG --- and I'll forward any responses back to you. (To respect your privacy we normally don't publish your e-mail addresses in LG. That does result in a bit of extra work on my part --- but I don't mind).

On an academic level I'm curious what answers and suggestions we'll see. I'll be curious where this number comes from and what it "means."

On a practical level I try to configure my systems and my work habits so I just don't have to care if my modem is working at 28.8, 33.6, 14.4 or whatever.

If you search the Answer Guy archives on the terms "modem" or "benchmark and you'll probably also find some other choice comments I've made about the marketing claims of modem vendors (and CPU vendors for that matter).

I have similar opinions about most claims of "speed" as a feature.

>-------------------------------------------------
#!/bin/bash


cd /etc/sysconfig/network-scripts
./ifup-ppp ifcfg-ppp0 &
-------------------------------------------------

>-------------------------------------------------
#!/bin/bash


cd /etc/sysconfig/network-scripts
./ifdown-ppp ifcfg-ppp0 &
-------------------------------------------------

I don't think these have anything to do with how fast or slow your modems are. If you want to reduce the amount of traffic that flows over these lines while running PPP --- run a caching named/etc/resolv.conf to the localhost address: 127.0.0.1) and a copy of Squid or Apache's cache proxy and configure your browsers to use this WWW cache.

James R. Ebright
IT Professional, CoastalNet

Sorry if I sound grumpy on this issue.

Your frustration with slow modems seems palpable --- and the great backward regulatory morass that is our telecommunications infrastructure doesn't leave you (or me) many alternatives.

(Cable modems are currently a pipe dream in my area).

Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 31 August 1998

	backup	uidgid	connect	95slow	badblock	trident	sound
	kernel	solprint	idescsi	distrib	modem	NDS	rpm
	guy	maildns	memleak	multihead	cdr