grr@cbmvax.UUCP (George Robbins) (07/22/89)
Sigh...
At first glance, it looks like the ability to do high-speed protocol
based file transfers through an incoming Terminal Server/LAT port is
screwed up even worse than before.
Up thru 2.2, everything worked fine
With 3.0, Kermit and Xmodem broke. (medium blocks, toy protocols)
With 3.1, uucp is broke too. (small blocks, rugged protocol)
It smells like somebody decided on what was a "reasonable" amount of
data to come in via a LAT transaction, and when presented with "bursts"
of data, it gets tossed or somebody gets confused.
I'm a bit at a loss as to how to better define the problem, but I
intend to see if I can escalate it thru the support people this
time. Last time I mentioned this, I recieve a number of "me too"
messages, so I'll try to keep people posted.
--
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)grr@cbmvax.UUCP (George Robbins) (07/22/89)
In article <7399@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > Sigh... > > At first glance, it looks like the ability to do high-speed protocol > based file transfers through an incoming Terminal Server/LAT port is > screwed up even worse than before. Some first level debugging has turned up the following problem: In version of Ultrix prior to 3.1, doing a "stty raw" or the equivalent stty/ioctl calls would automatically switch your terminal server session to "passall" mode for the duration of the period raw mode was set. After applying the Ultrix 3.1 update, this no longer happens; making "binary" transfers thru terminal server ports fail due to such things as "flow control" characters and server local/forward switch characters. I would expect this would also screw up gnu emacs users of the flavor that believe that control/s has something to do with searching, though I haven't investigated this... Example: (make sure you're using "sh", /usr/new/csh mucks with tty modes!) With Ultrix 3.0 (and previous): <show sessions doesn't show passall> $ stty raw <show session shows passall> $ stty sane <show sessions doesn't show passall> With Ultrix 3.0 (and previous): <show sessions doesn't show passall> $ stty raw <show sessions doesn't show passall> this is wrongo! $ stty sane <show sessions doesn't show passall> Whatever problems that caused Ultrix 3.0 LAT suport to not work with Kermit/Xmodem/etc. may still be there, I'll have to try some testing after manually doing a "set session passall" on the terminal server and see what else fails. -- 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)
trier@freja.diku.dk (Jens Trier Rasmussen) (07/24/89)
The problem with Ultrix 3.1 and the LAT software not setting the terminal port to PASSALL is a known problem within DEC. A rumor says that they are working on getting the fix into the next release Cheers Jens Trier Rasmussen
grr@cbmvax.UUCP (George Robbins) (07/24/89)
In article <7402@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > In article <7399@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > > Sigh... *** FLASH *** A kindly DECperson informs me there is a 3.1 patch tape that fixes this and other problems... Excuse me while I dial up the Support Center... -- 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)
grr@cbmvax.UUCP (George Robbins) (07/25/89)
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... > > *** FLASH *** > > A kindly DECperson informs me there is a 3.1 patch tape that fixes > this and other problems... In article <4692@freja.diku.dk> trier@freja.diku.dk (Jens Trier Rasmussen) writes: > The problem with Ultrix 3.1 and the LAT software not setting the terminal > port to PASSALL is a known problem within DEC. > > A rumor says that they are working on getting the fix into the next > release *** UN-FLASH *** Well, I spent a bunch of time talking with the Support Center today, and the news is both confusing and depressing... 1) Colorado Support Center (responsible for LAT) does not have an Ultrix 3.1 patch tape, or at least doesn't admit to it. 2) They do seem to admit that there is a problem. 3) They have to commune with Ultrix engineering to review the status of 3.1 LAT problems. They aren't really up to speed on 3.1 yet. 4) They do have some fresh (6/89) patches for 3.0 LAT. These may fix some of the outstanding LAT problems, but aren't applicable to 3.1. 5) Don't try it, especially if your system takes a long time to fsck disks and whatnot after a mid-day patch/crash attempt. 6) Upgrading to Ultrix 3.1 _will_not_ make your LAT problems go away. I'm waiting for a call back from the support center in "the next day or so"... The current status seems to be that if you are using LAT for any kind of file transfers or EMACS with control/s type key bindings, you should be vary cautious about upgrading to 3.1. It breaks things and your users will be very unhappy. If you plan to stay with 3.0 for any length of time, you should consider contacting CSC and obtaining a new 3.0 patch tape with the new LAT patches. There may be some new DECnet/Ultrix stuff too. (DECnet != LAT). Workarounds: Telling your emacs users to do a "SET SESSION PASSALL" command on their server port helps, but may not work for uucp/kermit or where dynamic control is really needed. Summary of Ultrix _3.0_ LAT patches: lat_hic.c: Allow multiple opens on the same reverse lat tty lat_scl1.c: Fix stty commands/modes pass8, istrip, tandem vs server modes lta.c: Truncated printouts on slow reverse LAT printers lat_conn.c: LAT printers (printcap) may fail if more than one ethernet I/F direct.c: Limitation of only 5/6 ttys for each of multiple LAT services ....till next time.... -- 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)
art@dinorah.wustl.edu (Arthur B. Smith) (07/25/89)
In article <7412@cbmvax.UUCP>, grr@cbmvax.UUCP (George Robbins) writes: > > *** FLASH *** > > A kindly DECperson informs me there is a 3.1 patch tape that fixes > this and other problems... > Unbelievable (or would be if it weren't DEC)! There's already a patch tape for a system that we haven't received. DEC claims that 3.1 has been shipping for over a month. So when do we, the loyal customers, get 3.1? Maybe they could ship it with the patches installed? NAAAAH. That would make too much sense. sigh. art smith (art@dinorah.wustl.edu, ...!uunet!wucs1!dinorah!art)
grr@cbmvax.UUCP (George Robbins) (07/27/89)
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)