jmm@skivs.UUCP (Joel M. Miller) (01/17/89)
This has probably been asked and answered before, but ...
I use a TB+ in PEP mode on a VT100-emulating terminal. Screen refreshes are
always "jerky": they begin with a short burst of a few dozen characters, a
brief but annoying pause, another slightly longer burst, another pause, and
then the rest of the screen fills smoothly and quickly. The problem is
especially annoying when screen-editing, since most transmissions are
short and so composed almost entirely of bursts and pauses.
I've tried various combinations of protocols, compression or not, interface
speeds, etc, and nothing helps. Is this behavior intrinsic to PEP; is there
something I can do about it?
--
Joel M Miller; Smith-Kettlewell Eye Research Foundation
2232 Webster St; San Francisco CA 94115; 415/561-1703
UUCP: {uunet,pacbell}!skivs!jmmwtm@neoucom.UUCP (Bill Mayhew) (01/20/89)
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
roe@unibase.UUCP (Roe Peterson) (01/21/89)
From article <2760@skivs.UUCP>, by jmm@skivs.UUCP (Joel M. Miller): > This has probably been asked and answered before, but ... > > I use a TB+ in PEP mode on a VT100-emulating terminal. Screen refreshes are > always "jerky": they begin with a short burst of a few dozen characters, a > brief but annoying pause, another slightly longer burst, another pause, > then the rest of the screen fills smoothly and quickly. This is normal. I'm not just exactly sure why it happens, but I do know that the total time to refresh a screen is still very reasonable in comparison to other modems on the market, and absolutely blows away 2400 baud. (It may be a function of the ping-pong going on between the modems.) There is nothing you can do to change it. -- Roe Peterson uunet!attcan!utgpu!tmsoft!mcl!unibase!roe
muller@munnari.oz (Paul Muller) (01/25/89)
Why not do a bit of quick math to work out what a suitable low water mark should be, dynamically? That would allow you to do something like say editing where you may hit one or two keys, then get a pageful of data (scroll page), there you would like a low 'low water mark', or where you are typing a lot and little else, where a higher 'low water mark' could be used. I can't see why it should be much harder to do than implement a suitable S register, it would also save much netmoise over what an optimum setting for that particular S register should be (just ask any MS-DOSer what the best buffer size is while in a crowded room full of other MS-DOS junkies, get out of the way quickly!) . The Trailblazer had a 68000 in it last I looked, must have some spare juice to run a little math...... Paul "If you can just tell me what your opinion looks like...." Me