Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: re: problem with telnet v6.6-5 under vms 5.5 / Pause delay
From: bell@uwpg02.uwinnipeg.ca
Date: 2 OCT 92 09:02:42 CST
Organization: University of Winnipeg

I had the same problem, and received the following message from
Henry Miller which cleared things up, here is his msg:

Date:   12-SEP-1992 07:13
From: henrym@sacusr.mp.usbr.gov
Description: RE: Pause delay


John Sandhoff writes:

|This is the infamous telnet pause problem, which has been eradicated on
|multiple occasions but like the lowly cockroach seems to keep coming
|back (Sorry guys :-) ). It was quite pronounced for certain sites at
|6.5 and continued thru most 6.6 versions. On the plus side, the developers
|have found numerous bugs while hunting down this one. On the minus side,
|this one keeps showing up (BUT READ ON!).
|
|The workaround is to keep one finger poised over the delete key. The bug
|has something to do with the output buffer not getting flushed after a
|transmission error, and receipt of *any* character seems to flush the
|waiting output. I saw (note the tense) the problem predominantly on high
|output things, like reading mail, but it shows up anytime. Most annoying
|is after typing the username, when it never prompts for the password.
|This bug is sensitive to your site - I saw it a lot while other sites
|have never noticed it (we believe that there's a subtle wiring problem
|here that we're exploring).
|
|I've been fortunate enough to get to play with beta code. The 6.6-5 beta
|showed some problems but I never installed the final -5 code so I don't
|know if it was fixed then. I'm now using the 6.6-5A code and I *have not
|seen the problem at all*!!!
|
|6.6-5A is due out *any day now* :-). Most unfortunately, the guy that's
|really driving the code these days, Henry Miller, has been in and out
|after suffering some medical injuries. He's really put his heart and soul
|into this stuff (he even UNDERSTANDS Bliss!) and he CARES about getting
|it right. Maybe Henry is willing to release the beta pieces.. I dunno.
|I'm certain he'd rather use his time to get a real release out the door
|(do computers have doors?). The downside of releasing the pieces of new
|code, is there's no clear instructions on integrating them. It takes
|some intuition and understanding to get the pot of pieces running, and
|support becomes a nightmare if there isn't control over what pieces
|people are running.
|
	Gosh, John, you're going to make me blush.  6.6-5A will be out as soon
as we get the NFS problem resolved.  There will be new releases of serveral
pieces of other software as well.

	The bug was pretty close to what John described.  However, the root
problem was that the transmission and retransmission timers were performing
poor arithmetic on a combination of signed vrs unsigned data.  The result was
that the timer variables were going chaotic.  The data would eventually get
sent when the 20 second master timer came through and forced an ACK to be
send for connections.  In this case, the data was piggybacking the ACK!
Hitting another key would cause the connection to unhang, since it caused
a new packet to be emitted, which would push all data on the retransmission
queue out ahead of it.

John Clement writes:

|There is a second problem that the Telnet local routine can hang under CMUTEK.
|This is primarily due to memory allocation/deallocation.
|
|I realize this is not the server hangup problem, but is one that can happen.
|
|We (Henry and I) think it has been fixed.  Incidentally the code might
|be faster.  Henry is now using it and he has reported that there are no
|bugs yet.  Time will tell.
|
	John has actually been the driving force for fixing the TELNET client
and server.  However, this is a different problem from the TELNET pause,
which could be noticed on both client and server, and was due, again, to a
bug in IPACP.  Most other applications were immune because of the massive
amount of data being sent constantly, where TELNET is usually a character
at a time protocol.

|The downside is that transmission from the server to client can be slowed. The
|previous client (local machine) stored gobs of stuff in virtual memory, as it
|came in, and then sent it out to the terminal at whatever rate it could.  Now
|when the buffers are full the data will back up and eventually the server
|(remote  machine) will be forced to slow down a bit.  This may even help the
|control-c problem.  How long have you waited for the data to stop coming
|at you after control-c or control-o?  Since it is now a finite amount rather
|than a Mbyte the stop should be faster.
|
|The allocation and deallocation could get it into a mode where character
|transmission was slow, and it even included a bug where data in virtual
|memory "could" be deleted before it was written.  This bug should not
|have been encountered in practice, but it could have been if the amount of
|data grew too large.
|
|I would like to report that along with the new Telnet there will be a version
|of Rlogin.

	To get the new version, use ANONYMOUS FTP to either SACUSR, SACWMS
or SACMGR.MP.USBR.GOV.  In directory [.TEKIP] are the files TEKIP0665A.SAVE
and TEKIP0665A.SAVE_Z.  The latter is an LZCOMP'ed version of the former.
This is not at installation kit, but just a BACKUP saveset and the structure
of the saveset should make it obvious where the files go under CMUTEK_SYSROOT:.

	Please note that SACMGR is unavailable on Saturdays from 0300 to 1600,
Pacific Time.

	Due to the new IP driver and PTY drivers, you will have to reboot the
system.  The IPACP and drivers are co-dependant on each other, so you have
to load them all up and reboot.  Before you reboot, modify your INTERNET.CONFIG
file to use the 'ETHER' driver instead of 'XEDRV'.  There are still some
problems with the external driver, but the internal driver works OK.

-HWM
----------
Henry W. Miller
Assistant Systems and Network Manager
U.S. Bureau of Reclamation
Mid Pacific Region
2800 Cottage Way MP1100
Sacramento, CA 95825
(916) 978-5108 / FTS - Same as commercial
Inet:	"henrym@sacusr.mp.usbr.gov" (or "henrym@sacto.mp.usbr.gov")

"I've fallen, and I can't get up!"

-------------------------------------------------------------------
David Bell                        E-mail: BELL@UWPG02.UWinnipeg.CA
Acting Director                   V-mail: 204/786-9449
Computer Services                 S-mail: University of Winnipeg
                                          515 Portage Avenue,
                                          Winnipeg, Manitoba,
                                          Canada  R3B 2E9
-------------------------------------------------------------------

-------------------------------------------------------------------
David Bell                        E-mail: BELL@UWPG02.UWinnipeg.CA
Acting Director                   V-mail: 204/786-9449
Computer Services                 S-mail: University of Winnipeg
                                          515 Portage Avenue,
                                          Winnipeg, Manitoba,
                                          Canada  R3B 2E9
-------------------------------------------------------------------