Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!brutus.cs.uiuc.edu!psuvax1!rutgers!netsys!faatcrl!jimb From: jimb@faatcrl.UUCP (Jim Burwell) Newsgroups: comp.mail.uucp Subject: Re: New UUCP Protocol (was: Re: Zmodem added to UUCP) Message-ID: <1041@faatcrl.UUCP> Date: 14 Oct 89 06:15:23 GMT References: <1024@faatcrl.UUCP> <710@lakart.UUCP> <1029@faatcrl.UUCP> <688.252e37c2@simpact.com> <1032@faatcrl.UUCP> <25@van-bc.UUCP> <1035@faatcrl.UUCP> <1989Oct11.020410.27273@DSI.COM> Organization: FAA Technical Center, Atlantic City NJ Lines: 81 syd@DSI.COM (Syd Weinstein) writes: >Any multitasking O/S has an input queue length that can be exceeded if >the user task is preempted for too long and the input keeps arriving. >Unix choose 256 bytes, it could be tuned, and sometimes intelligent >I/O boards add extra buffering in addition to that 256 bytes. Hmm.. I've only had good experiances with Zmodem from our sun 3/160 to my Amiga 500 at home. Both run multi-tasking operation systems, though the Amiga isn't multi-user.. I regularly get the best CPS sending to, and recieving from our Sun. The best I get anywhere.. That includes the many PC BBSs I call, some of them running on '386s, which are faster than the 68020 in our sun 3. And the 386 is running MS-DOS, and isn't loaded down with a multi-user/tasking OS. I've never gotten above 236 CPS (2400 bps) from the PC systems.. I regularly get 238 and 239 CPS from our Sun.. >Its not that the device driver gets locked out, but that the device >driver must store the characters somewhere and it runs out of room >to store them in the buffer (CLIST) preallocated for the read. Would it be difficult to increase the buffer length to say 4K or so... That way you wouldn't have to worry about it.. What about DMA? I suppose they make serial boards which cache all the data comeing into the uart, and DMA into the system at some point... am I correct ? >Thus on a busy system, ZMODEM is bound to have problems if the >zmodem task (user level task) is preempted for longer than 256 >character times. On a lightly loaded system, its unlikely to stay >prempted for that long. Can't say I've done a Zmodem transfer with 6 users on the system while it's unbatching a load of news :-). But that kind of character level stuff usually goes pretty fast on the Sun, even when moderately loaded down.. >Also, please remember that end to end times matter, not just CPS. >Much of the time in uucp is dead time deciding which file to transfer >and acquiring permission for that transfer. With most mail files >being rather short, this is substantial. A better gain could be >in using BSMTP for mail instead of rmail. Measure the length of the >phone call for the bytes transferred, and you will see that the 8% >cps improvement might turn out to only be a 1% call time improvement, >and not worth all the extra effort. Again, long compressed batches >of news skew some numbers, but also remember that many links are limited >by the speed of the computer. Most sites running at 19200 cannot really >exchange data at that rate, but really at 1100 or 1200 cps, each character >being sent at 19200, but delays between bursts of characters slow it down. >Thus the spoofing of a Telebit actually ends up waiting for the computer >much of the time. I've always thought that mail was inefficiant too. I often wonder why mail isn't batched the same way news is, on a site level, between polls. Perhaps the UseNet gods will re-implement or upgrade mail some day... As for the 1% improvement, I doubt it would always be that low. But there are many other advantages Zmodem would give us, which have been outlined previousely in this thread. Those advantatges alone are worth the "effort" I think. We already have Zmodem in the form of rz/sz. That could be called in a number of ways, or simply included on a source level into the current uucp, unless of course, Chuck objects :-). Zmodem is a modern, robust protocol. It is the most popular protocol in the personal computer world, and it's inevitable that it will find its way into UseNet/uucp somehow. CUL, -- +------------------------------------------------+--------------------------+ | James S. Burwell | | | | "UseNet...A text network | | UUCP: | in a binary world" - Me | | ...!{ames!netsys|rutgers}!faatcrl | | | !jimb | "How do you say | | . | 'multitasking' in | | Internet: . | MS-DOSish? Network | | // jimb@faatcrl.UUCP . ** | File Server!" - Me | | // . **** | | | \\ // GEnie: Airwarior: . .** | | | \X/ JIMBURWELL Techrat . | | +------------------------------------------------+--------------------------+