romain@pyramid.pyramid.com (Romain Kang) (11/20/89)
If you're going to have a BIG uucp site, it is even cleverer to use the terminal server to connect to directly to the uucp TCP port (if the server allows it). This works quite well if your uucp supports incoming TCP connections, since it bypasses the tty + (rlogind or telnetd) + context switch overhead entirely. If you want to see the performance hit from the latter two terms, see John LoVerso's article (7705@xenna.Xylogics.COM). In some variants of uucp, you'll need to list the incoming connections with the IP address of your terminal server to satisfy some weak authentication requirements. In 4.3, you would say something like: pyrnj Never TCP uucp server03.pyramid.com Incoming uucp will still want to run 'g' protocol, since that's still the most reliable way to move data over dialups. 'f' is the only other reasonable alternative, but there are other weak links in a terminal server scheme which make flow control dicey. Naturally, you can't gracefully dial out without RS-232 (i.e., tty) control... The potential disadvantage that I see is that the pkcget() stall code in 4.3 uucp or the VMIN termio setting in HDB aren't applicable to non-tty descriptors like sockets, which may make the kernel schedule uucico more frequently than optimal. In other words, uucico could spin on reads that only return a few characters at a time, rather than pulling in (nearly) complete 'g' packets on each read. However, direct connection to the uucp TCP port is a clear winner on fast dialups. I don't have the figures around anymore, but when rutgers made "/stream" mode available on their Cisco, pyrnj saw instantaneous character rates (as reported by sar) rise from about 1100 to 1900 bytes/second. Now, if rutgers could only keep both of their TrailBlazers healthy... -- "Eggheads unite! You have nothing to lose but your yolks!" -Adlai Stevenson
chris@mimsy.umd.edu (Chris Torek) (11/20/89)
In article <91705@pyramid.pyramid.com> romain@pyramid.pyramid.com (Romain Kang) writes: >[`log in' on the tcp uucp port, and then run the g protocol.] >The potential disadvantage that I see is that the pkcget() stall code >in 4.3 uucp or the VMIN termio setting in HDB aren't applicable to >non-tty descriptors like sockets .... My stall code would work if you somehow set linebaudrate. The VMIN code will fail since a TCP connection is not a tty, but my code just does a select on no file descriptors. Incidentally, someone really ought to try tweaking the 1/10th second `guess' I used for the initial `delay since we last got here', now that UUCP is generally run on something other than a VAX 11/780 with Able DH/DM devices (which is where I tested it). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
gnb@bby.oz (Gregory N. Bond) (11/20/89)
In article <91705@pyramid.pyramid.com> romain@pyramid.pyramid.com (Romain Kang) writes:
The potential disadvantage that I see is that the pkcget() stall code
in 4.3 uucp or the VMIN termio setting in HDB aren't applicable to
non-tty descriptors like sockets, which may make the kernel schedule
uucico more frequently than optimal. In other words, uucico could
spin on reads that only return a few characters at a time, rather
than pulling in (nearly) complete 'g' packets on each read.
Except that, at least in our Bridge CS-100 terminal server, you can
specify a buffer size, and (up to, depending on timeouts) that many
characters get buffered up and sent in one TCP packet. Thus the read
on the socket gets a buffer full.
A second advantage is that our terminal server does RTS-CTS flow
control with the blazer, and is happy doing 19,200baud, that the SunOs
3.5 driver can't. Given an 8-bit datapath and protocols to take
advantage of it, that is a big win.
We found that, using the terminal server, the NNdaemon (the moral
equivalent of uucico for the networking software mainly used in
Australia) dropped from >50% CPU to < 0.5%, while the speed increased
from 600bytes/sec to >800bytes/sec.
Greg.
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnb