Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cbmvax!grr From: grr@cbmvax.UUCP (George Robbins) Newsgroups: comp.unix.ultrix Subject: Re: Ultrix 3.1 vs. LAT Keywords: Ultrix 3.1 LAT kermit xmodem emacs Message-ID: <7456@cbmvax.UUCP> Date: 27 Jul 89 07:26:14 GMT References: <7399@cbmvax.UUCP> <7402@cbmvax.UUCP> <7412@cbmvax.UUCP> <4692@freja.diku.dk> <7432@cbmvax.UUCP> Reply-To: grr@cbmvax.UUCP (George Robbins) Organization: Commodore Technology, West Chester, PA Lines: 78 In article <7432@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > In article <7412@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > > In article <7402@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > > > In article <7399@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > > > > Sigh... Gee, only a compeat idiot would keep responding to his own articles... Anyway, the status currently is that the Support Center is "working on" resolving the problem with Ultrix engineering. Rumor thru other paths has it that some of the latest 3.0 patches need to be reworked for the 3.1 distribution. It seems that it will be a week or two before any real fixes surface. While talking to the Support Center representative that's been handling this problem with me, it became obvious the he was actually *very* knowledgable about LAT and terminal servers in general. It seems that CSC is massivly commited to using servers and they had a lot of problems getting everything working reliably. We talked a while about LAT problems and what sort of problems seemed to have shown up in the 2.x -> 3.0 change and whether these problems might still be unresolved in 3.1 even after the (future) patches are applied. No real conclusions, but some intersting facts fell out that are worth repeating. 1) If you are using DECSA's or the like make sure you have upgraded to the LAT 3.0 software release. This fixes a number of problems that result in hangs or degraded performance after the server hasn't been rebooted in a while. Anything 2.2 or older is likely to have a lot of problems. DECserver 200's should be a current software release too, (I think it is 2.0) though this seemed to be less crucial. 2) The way servers/LAT works is that they accumulate characters and forward them every 80 milli-seconds. They wait up to a second for acknowledgement from the host before retrying. Buffers are of very finite size (~200 bytes on DS200), so that if you have network conditions resulting in long delays or retries, then you are going to see overruns on imcoming protocols that use large packets. 3) This has some consequences - protocols that use larger packet sizes or run in "blast" mode cannot be guaranteed to work under degraded network conditions at > ~200 char/sec _with_flow_control_disabled_. Large packet size Kermit and X-modem can run into problems here and something like Z-modem or sliding window protocols that always have more than one packet outstanding can lose big-time. 4) If this sort of thing is going on, then the server counters should be incrementing retrasmissions, duplicates or other errors at the same time the "overrun" erros are accumulating. 5) The 80 milli-second "circuit timer" is tuneable and it might make sense to reduce it in an environment where the server supports incoming high-speed tranfer in addition to manual input. Obviously this increases network loading and host overhead, and it's not clear it fixes anything. 6) It's also possible that other activity like incoming Trailblazer connections at 9600+ baud, may hammering the system hard enough that time spent at serial interrupt level processing to delay LAT responses. If so, then one should be unable to duplicate the problems with the modems turned off and the system lightly loaded. 7) There's still no obvious reason why LAT performance/functionality should have changed between 2.X and 3.0. The 3.0 LAT patches seem to represent fixes to things that were outright broken, rather than performance issues/parameter changes. I've dug out my old 2.2 build pack to run some A/B tests in hopes of pinning down something that works reliably under 2.2 and fails always with 3.0. This is a pain, since it seems that everybody has their own private versions of [a-z]modem plus random terminal emulators/file transfer programs on their personal systems. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)