Article View: comp.protocols.ppp
Article #358A pox on all modem manufacturers! (a.k.a. monitoring line quality)
From: Greg Earle - Sun JPL on-site Sof...
Date: Tue, 09 Jun 1992 09:34
Date: Tue, 09 Jun 1992 09:34
81 lines
5494 bytes
5494 bytes
Once upon a time, I was seriously considering purchasing the ZyXEL 1496 modem
with the nice front-panel LCD display. Now I can think of a good reason for
it:
V.32bis modems have the ability to do fallback (and fall-forward, if they're
good and the Gods are willing (-: ) to 12000 baud (and then to 9600 as well?).
I believe that, in the case of (to use an example) a re-train where fallback
(or fall-forward) occurs, on a (e.g.) Telebit T3000, the CD LED will flash to
indicate that the re-train/fall{back,forward} is occuring.
Two things I noticed:
(1) Is there any way to determine if a fallback/fall-forward occurred? In
other words, do V.32bis modems ever do a re-train without a fallback/fwd?
Or, to put it another way, if I see my T3000 CD light flash, does it always
mean a fallback/fall-forward is occcurring?
(2) The REAL crux of this posting:
This "everything is an S register" mentality has GOT to stop, modem mfgrs!
My T3000's have 3 main purposes (in order of importance):
- PPP
- Using "tip" between two Sun UNIX (SunOS) systems
- UUCP
Now, consider this: Telebit provides 3 read-only S registers - S70, S72 and
S78 (Transmit Modulation Rate, Receive Modulation Rate, and Line Quality,
respectively) to determine the state of the connection. Great, eh? But:
(a) poseur:2:51 % sudo strings /usr/bin/tip | egrep ^AT
ATDT
ATV0Q0E0L1X0S2=255S12=255
BSD "tip" explicitly turns off the Escape S register, so you can't do
"tip remotehost" and then escape out to check the speed/quality if you
see a retrain! You have to tip to the port, and make sure that S2 and
S12 are properly set, and manually dial the number. That, or else adb
your "tip" binary to turn this off.
(b) When using PPP, everything is sent as an IP (or UDP) packet inside PPP
framing, so you can't simply shove (say) '+++' out the port - and even
if you could, you couldn't ask the modem to return the speed/quality
info anyway!
I live a measly 12 miles away from JPL, and dial in over what *should* be
pretty good phone lines. Yet I always see several re-trains during the course
of any non-trivial on-line session, and as a matter of fact, my last session
ended in a re-train that terminated with the modem dropping the connection :-(
Every time this happens, I think the same thing - "Uh oh, a retrain" - and I
think, "Will it recover? Will it drop the line? Oh, whew - it recovered. But
now, what speed am I talking at? What's my line quality now? Isn't it likely
to drop the line next time a retrain happens, if the line quality is low?"
Using "tip" or running a PPP link, I simply *can't* get this information out
of the modem anyway/anyhow. And I think that's stupid. I can appreciate that
not every modem manufacturer can convert to fancy LCD displays like ZyXEL's.
But c'mon, folks - let's get this read-only S register stuff out of there,
and into some form of visual feedback mechanism where I can *see* what the
state of my connection is. (For example, the T3000 has a "HS" High Speed and
"CD" Carrier Detect red LED. If a fallback occurs to 12000 baud, how about
changing the "HS" LED to blue or green?!? And if the line quality drops below
some value - the manual mentions "below 30/100 is bad, above 50 to 100 is good"
then change the "CD" LED to some other color, to indicate that line quality
is marginal and to be prepared for the consequences.)
The notion that important connect information is only available via being able
to access a set of read-only S registers is an anachronism of the "Modems are
always used for outgoing interactive terminal sessions" (where it can be easy
to send the escape sequence in-line) era. Enough already.
[ Off soapbox. Flames extinguished. I feel better now. (-: ]
--
______ ,__,~~, \
/ / \ ______________________________________________________________ ` ~^ \ _|
/ "Who would have ever believed that I could include an ASCII \ ()^()---|/@) \ picture of myself in my .signature file!" ___ / /_ )'
\______________________________________________________,' \_\__ | . / | `-' \___, / \ Greg Earle earle@poseur.JPL.NASA.GOV \`
Technical Details
Message-ID:
<1992Jun9.093422.15901@elroy.jpl.nasa.gov>Path:
arc1-ca.pugleaf.net!sparky!uunet!think.com!sdd.hp.com!elroy.jpl.nasa.gov!poseur.JPL.NASA.GOV!earleShow Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10beba,3761f9f3b1d479fa,start X-Google-Attributes: gid10beba,public X-Google-Thread: fa2d8,3761f9f3b1d479fa,start X-Google-Attributes: gidfa2d8,public X-Google-Thread: 103eaf,3761f9f3b1d479fa,start X-Google-Attributes: gid103eaf,public X-Google-ArrivalTime: 1992-06-08 21:39:28 PST Newsgroups: comp.protocols.ppp,comp.dcom.modems,biz.comp.telebit Path: arc1-ca.pugleaf.net!sparky!uunet!think.com!sdd.hp.com!elroy.jpl.nasa.gov!poseur.JPL.NASA.GOV!earle From: earle@poseur.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support) Subject: A pox on all modem manufacturers! (a.k.a. monitoring line quality) Message-ID: <1992Jun9.093422.15901@elroy.jpl.nasa.gov> Followup-To: comp.dcom.modems Keywords: Fallback PPP tip Sender: news@elroy.jpl.nasa.gov (Usenet) Nntp-Posting-Host: poseur.jpl.nasa.gov Organization: Sun Microsystems - JPL on-site Software Support Date: Tue, 9 Jun 1992 09:34:22 GMT Lines: 81