lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (04/29/88)
I would like to get uucp to run much faster, both over modems and DATAKIT (TM) VCS. 9600 baud just ain't enough! Does anyone have any suggestions for how to do it? I recall an article in UNIX/World magazine that discussed speeding up uucp over modems. There wasn't enough info in the article for me to make a change. Did anyone else see the article and figure out what to do? Thanks, -- Larry Cipriani, AT&T Network Systems and Ohio State University Domain: lvc@tut.cis.ohio-state.edu Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (weird but right)
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (04/30/88)
In article <11913@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: | I would like to get uucp to run much faster, both over modems | and DATAKIT (TM) VCS. 9600 baud just ain't enough! Does anyone | have any suggestions for how to do it? are you batching? Are you compressing? Is your # of buffers high enough? (like 7?) These are the easy ones... -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
haugj@pigs.UUCP (John F. Haugh II) (04/30/88)
In article <11913@tut.cis.ohio-state.edu>, lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: > I would like to get uucp to run much faster, both over modems > and DATAKIT (TM) VCS. 9600 baud just ain't enough! Does anyone > have any suggestions for how to do it? the one i keep wanting to see is have uucp fork into a master and slave on both ends of the wire. then, set up a message passing system of some sort between the two halves so that the slave requests the master to send acks for the packets it receives. thoughts? - john. -- The Beach Bum Big "D" Home for Wayward Hackers UUCP: ...!ihnp4!killer!rpp386!jfh jfh@rpp386.uucp :DOMAIN "You are in a twisty little maze of UUCP connections, all alike" -- fortune
bob@cloud9.UUCP (Bob Toxen) (04/30/88)
In article <11913@tut.cis.ohio-state.edu>, lvc@tut.cis.ohio-state.edu > (Lawrence V. Cipriani) writes: > I would like to get uucp to run much faster, both over modems > and DATAKIT (TM) VCS. 9600 baud just ain't enough! [How?] > > [An] article in UNIX/World magazine that discussed speeding > up uucp over modems. [They didn't tell how.] > > Thanks, > Larry Cipriani, AT&T Network Systems and Ohio State University > Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (weird but right) First the obvious. Ensure that your system AND THE UTTER (sic) system can pump characters this fast. Many systems cannot pump bytes at more than 4800 baud (480 chars/sec). The G protocol, which is the UUCP default, sends out 64 character packets. It sends out a few (eight, I believe) and then these have to be sent out (sometimes over a satellite), the other system has to read it, compute checksums, send out an ACK packet, and the first system has to read it before another packet can be sent out. At high baud rates (and expecially over ethernet and the like) this will kill performance. Hack your own protocol that sends out much larger packets. Remember, the G protocol was in the days of 300 baud modems. Remember also, that the tty line is in raw mode. On V7 and (I think) BSD systems the reading program is woken up on each character. This is very expensive to performance (and CPU utilization). The System V (and III) tty driver was modified to allow buffering of characters read, even in raw mode. Hack this into your V7/BSD system. If you have a non-System V UUCP on your SV system that fails to take advantage of this feature it should be enhanced. The folks Down Under modified their UUCP to send and receive simultaneously, effectively doubling the bandwidth. Well, I didn't say it was easy. -- Bob Toxen {ucbvax!ihnp4,harvard,cloud9!es}!anvil!cavu!bob Stratus Computer, Marlboro, MA Pilot to Copilot: What's a mountain goat doing way up here in a cloud bank?
guy@gorodish.Sun.COM (Guy Harris) (04/30/88)
> First the obvious. Ensure that your system AND THE UTTER (sic) system > can pump characters this fast. Many systems cannot pump bytes at more > than 4800 baud (480 chars/sec). More importantly, ensure that both systems can *receive* characters this fast. It's a lot easier to send them at 9600 baud than to receive them at that rate in most systems. > At high baud rates (and expecially over ethernet and the like) this will > kill performance. Some, anyway. At 19200 baud, I've seen 1742 characters per second, based on the values reported in SYSLOG, and at 38400 baud I've seen 3435 characters per second. The "g" protocol may noticeably cut performance, but it certainly doesn't kill it. It appears to cause about a 10-15% hit here. > Hack your own protocol that sends out much larger packets. If you're doing it over Ethernet or Datakit, please don't hack your own protocol; run atop some reliable flow-controlled protocol such as TCP/IP or whatever Datakit provides in that arena, and either use the "t" protocol from 4.3BSD's UUCP or the "e" protocol from Honey Danber. (Unfortunately, the two are slightly incompatible, so both sides need to have "t" or "e". Both sides also need to know how to establish a UUCP connection over the protocol in question; in the 4.3BSD UUCP, at least, it's not done by faking up a login.) The "t" and "e" protocols just send a file size indication followed by the data from the file; they don't do any flow control or error correction/retransmission of their own. Over a protocol such as TCP/IP, this is the way to go. (Why duplicate the work that TCP/IP already does?) > Remember also, that the tty line is in raw mode. On V7 and (I think) > BSD systems the reading program is woken up on each character. This > is very expensive to performance (and CPU utilization). Yes, BSD systems tend to do this. However, if you have a reasonable level of input siloing in the tty driver, it will tend not to put characters on the input queue one at a time, but will put them there in larger groups, say 14 characters on the average. This provides a major performance win without any changes to UUCP. > The System V (and III) tty driver was modified to allow buffering of > characters read, even in raw mode. Hack this into your V7/BSD system. > If you have a non-System V UUCP on your SV system that fails to take > advantage of this feature it should be enhanced. As Honey DanBer cranks the VMIN up to 64 under some circumstances, this could conceivably reduce the CPU overhead even more. I can't find the S5R2 source anywhere, so I don't know what it does here; the 4.3BSD UUCP, when compiled for a system with the S3/S5 tty driver, appears to be set up to do the same.