Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!agate!bionet!csd4.milw.wisc.edu!nic.MR.NET!hal!cwjcc!neoucom!wtm
From: wtm@neoucom.UUCP (Bill Mayhew)
Newsgroups: comp.dcom.modems
Subject: Re: TB+ jerky transmission
Summary: Consequence of PEP mode
Message-ID: <1470@neoucom.UUCP>
Date: 20 Jan 89 00:13:24 GMT
References: <2760@skivs.UUCP>
Organization: Northeastern Ohio Universities College of Medicine
Lines: 65


There is some irregularity in the rate of transmission rate when a
long burst of data begins in PEP mode.  I am pretty sure this is a
consequence of the fairness scheme built into the version 4.0 and
above firmware to enhnace interactive response.

Remember that PEP is a half duplex protocol that is only active in
one direction at a time on the data link.  That means that if the
host echoes back waht you type, that any keystrokes you enter must
be buffered in the modem while the host is echoing.

Under normal high speed sustained transfer, the Trailblazer will
transmit data in packes of 2000 bits (including CRC bytes + sync)
over a good circuit.  Over a poor circuit, the number of bits in
the packet will be less but the time required to send will still be
the same.  The modem will attempt to assemble the outgoing packets
into groups of 12.  The goup of 12 packes is ~1630 mS.  A
calibration tone burst of 136 mS is preended to the outgoing packet
set.  Oveall, this means a delay of about 1.75 SECONDS elapsing
before a turnaround is possible for echoing when a fast data stream
is coming in from the host end.  When the data link is idle, the
packet length is reduced to 22 mS.  The short packets allow 15
exchanges per second (~7.5 char/sec typing rate with echo).

What you are seeing in the screen repaint is a low data density
mode a first where the modem is sending you a a batch of small
packets that are 22 mS long, in anticipation that this
might actually be echoing from an interactive session.  Once the
data stream from the host fills the modem buffer to a low water
mark, it figures it had better switch over to the long packet burst
mode to prevent overrunning the buffer.  ...so you see about a 1.75
second delay after a seris of n short packets are sent in
succession.  I'm not sure exactly what n is.  Seems to be about 80.
This is a compromise to keep the echo delay down to 136 mS instead
of 1.75 seconds while in intereactive mode.

Probably for interactive use with screen repaints, it would be nice
to have an S register that would allow you to lock into short
bursts so you wouldn't see that unesthetic pause when repainting
the screen.  It isn't really all THAT annoying, is it?  It is still
faster than a repaint at a lower baud rate.  Alas, for the moment,
there is no S register for setting this.  The mode always switches
at whatever the preprogrammed magic number for the buffer low water
mark is.

Note that firmware before 4.x didn't support the fast turnaround
mode, and the echo delay was always long.  Glad they fixed it.

One possible thing you could do is to connect at 2400 baud, rather
than PEP for intereactive editing sessions.  The repaints would be
a little slower, but you woun't notice any difference whilst
typing.  A decnet editor shouln't have to do that many full screen
updates if you aren't jumping all over the file.

Fortunately, the uucp and kermit protocol spoofing do a good job at
keeping the link fully in use.

The above information is extracted from Telebit's "Fastlane
Software Developer's Guide" dated 5/86 (no document number),
"Trailblazer Installer's Guide" part # 900025-01 rev P3, and my
personal observation of the modem's behavior.

--Bill
  wtm@impulse.UUCP
  ...!lll-winken!scooter!neoucom!impulse!wtm