NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/dcom/modems/13074

Internet Message Format | 1992-09-08 | 8.3 KB

Path: sparky!uunet!sun-barr!ames!data.nas.nasa.gov!taligent!apple!ntg!dplatt
From: [e-mail] (Dave Platt)
Newsgroups: comp.dcom.modems
Subject: Re: Optimizing Telebits.
Message-ID: <[e-mail]>
Date: 7 Sep 92 18:20:13 GMT
References: <[e-mail]>
Organization: New Technologies Group, Inc.  Palo Alto CA
Lines: 159

>1)  Someone from Telebit once told me that in order to use UUCP
>spoofing you had to have MNP enabled.

I believe that this is true for spoofing under V.32 modulation, but not
for spoofing under PEP.  The Telebit V.32-capable modems use a vendor-
specific extension to MNP to signal each other that spoofing is to be
enabled.

PEP has its own form of error control and modem-to-modem
"administrative" signalling, which takes the place of MNP when this
modulation is being used.

>                                     This seems sort of wierd to me
>considering that you have to have it turned off when the non-Telebit
>world calls you or ye ole g protocol will not like life very much.  Is
>this correct?  Is it silly to have S111=30 when MNP is disabled?  If I
>have to enable it for the Telebit world, how can I deal with it being
>enabled with the non-Telebit world?

For outbound calls, just turn it on/off as part of the dialer sequence.
For inbound calls, you'd probably have to arrange to have the _caller_
enable or disable MNP at her end when placing the call.

>2)  When my WorldBlazer is chugging away and seems to be moving at a
>good clip using PEP, it suddenly will stop and just sit there doing
>absolutely nothing for between 8 and 10 seconds.  Then the transfers
>start up again.  I've seen uucico say that a bad packet was received
>at that point so I'm sure that is what is causing it.  But why does it
>take so long to start back up?  Why does it even stop in the first
>place?  You would think that the side receiving the bad packet would
>just immediately send back a message asking the other end to retransmit.
>What can I do about this incredibly long delay.

The uucp 'g' protocol definition is somewhat ambiguous about what the
receiving end "should" do when it receives a bad packet.  Either of two
behaviors is permitted:

-  Send back a NAK immediately.

-  Drop the packet on the floor without ACKing or NAKing it.  The sender
   will eventually time out and retransmit the packet.

According to Jamie Hanrahan's excellent paper on the 'g' protocol, most
vendor-supplied uucp implementations do the latter.  Unfortunately, the
sender-timeout period is relatively long (8-10 seconds, as you say), and
this causes the entire session to stall for quite a while.

Some of the third-party uucp packages use the "NAK immediately"
approach.  uupc 3.0 for the Macintosh and UUPC/Extended for DOS do so,
as does Taylor uucp for Unix (at least, that's how I read the code).
These packages will recover much more quickly from a bad packet than
standard SunOS uucico will.

So... you could try installing Taylor uucp on your system - it would
recover from these bad-packet errors more quickly.

As a workaround for your current uucp package, you could try _reducing_
your serial port speed.  If you're using a machine which has a "slow,
dumb" UART, it may be dropping characters during periods of rapid data
flow or heavy interrupt load.  Reducing the serial port speed may
actually increase your throughput, by cutting back the number of errors.
Our SparcStation-1, for example, drops characters occasionally when I
run the serial ports at 38400 bps ("Silo overflow") and stalls the 'g'
protocol;  it doesn't drop characters at 19200 bps.  One of our neighbor
sites can run at 9600 bps without errors, but suffers from heavy packet
loss when they run at 19200 bps.

You might also want to try a different serial cable... you might just
possibly have a marginal cable which is occasionally corrupting
characters.

>3)  I'm using SVR4 and I've tried to manipulate the window and packet
>sizes without any apparent differences.  I've heard that you can
>change the window size and not the packet size for the g protocol and
>that you can change both for the G protocol.

This is incorrect.  The 'g' protocol is capable of supporting windows up
to 7 packets, and packets of up to 4k (I think) bytes.

However, many _implementations_ of 'g' have hardwired limits which are
much smaller than this.  Some older versions can run only g3/64.  Some
newer ones can run 7/64 without difficulty, and can _send_ 128-byte
packets but aren't able to receive them (e.g. SunOS, ULTRIX).  Both
SunOS and ULTRIX versions misbehave _very_ badly if you ask them to send
you 256-byte packets... they either send malformed packets or dump core.

From all I've heard, the 'G' protocol never really needed to exist... it
doesn't handle above and beyond the design limits of the original 'g'
protocol.  My best guess is to why it exists, is as a way of signalling
that the implementation is _really_ capable of handling large-packet
negotiation properly (unlike the common implementations of 'g' which
will barf badly if you ask them to send large packets, and can't parse
packets which are either longer or shorter than 64 bytes).

>4)  And last - this is just a little pet peeve.  For some reason these
>WorldBlazers think they need to retrain when they lose the modem on
>the other side.  The other end will cut off the connection and the
>WB's CD light starts blinking like it is retraining.  How can I stop
>this from happening?  I wan't the damn thing to hang up and not wait
>10 seconds while it figures out the line has been dropped.  I've seen
>no other Telebits do this and it is aggravating to have this one do
>it.

That's pretty much in the nature of V.32, I believe.  V.32 uses a single
carrier frequency, with adaptive echo cancellation.  It's not terribly
easy for a V.32 modem to tell (quickly) that its peer at the other end
has disconnected, since it continues to "hear" the carrier signal come
back (its own carrier, delayed and mixed).  If the modem is more quick
to hang up when carrier is actually dropped, it will probably also be
more prone to disconnect prematurely if there's a burst of noise on the
line.

According to an article from Ed Morin:

# If you want to diddle with the retrain threshold, you can use S404.  The
# default value is (I think) 11 and the higher the number the more
# sensitive your modem will be to retraining.  You must be in debug mode
# to read/write this register.  For example:
#
#     AT~D1S404=20D0
#
# I tried this to take care of a problem with my WB locking onto a dial
# tone thinking it was a carrier, but it didn't cure the problem - it only
# made it less frequent.  Of course, higher numbers made the problem even
# less frequent, but introduced other problems - such as frequent
# retraining during a connection which wasn't an acceptable tradeoff...

You might want to try fiddling with this register... possibly setting it
to zero (which might completely disable retraining - I haven't tried).

If you establishing a connection which uses V.42 error control, you
_may_ find that this permits a more graceful disconnection.  V.42
includes a "Hey, I'm about to hang up, please tear down the connection"
signal, and some V.42-equipped modems (not all) will send this, and some
will honor it.

>I've often wondered what undocumented registers the Telebits have in
>them to improve performance and how they work.  Does anyone have such
>a listing or know how I can get it?

Try AT~D1&V to get a list of the current values of the "undocumented"
registers.  I don't know what they mean, unfortunately.  Greg... can you
help satisfy our curiosities?

>Wheh!  That was a long one.  Anyway, I'd appreciate any help with this
>as more sites are interested in getting newsfeeds and I'm starting to
>run out of time during the day to get everything transferred.  It's
>not due lack of time per se, but really in these  ineffecient
>transfers.  Thanks.

I've had very good results running g7/64 and g7/128 over a V.32
connection without g-protocol spoofing.  Adding V.42 error control
sometimes helps, sometimes hurts... usually it helps more than it hurts
(I see throughputs of up to 1000 characters/second on large files).

--
Dave Platt                                                VOICE: [phone]
              Domain: [e-mail]      UUCP: ...netcomsv!ntg!dplatt
 USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303