darryl@lemuria.UUCP (Darryl P. Wagoner) (11/13/89)
I am looking to put together a uucp site and would like to use a SPARCstation 330 as the system. But the 330 doesn't seem to support the ALM-2, so I thought about using an ethernet terminal server. Does anyone know how well a terminal server will work for uucp traffic? Also any recommendations would be helpful. Most of the traffic will be at 2400 baud or less and very little real user dial in. Does Sun require a 20 user license for a system that will only be doing uucp if you buy a ALM-2 board? -- Darryl Wagoner (home) darryl@lemuria.uucp Shecora Associates, Inc; OS/2, Just say No! Nashua,NH (w) 603-623-3330 (h) 603-465-7130 UUCP: ubbs-nh!lemuria!dpw
mikulska@odin.ucsd.edu (Margaret Mikulska) (11/15/89)
In article <1243@lemuria.UUCP> darryl@lemuria.UUCP (Darryl P. Wagoner) writes: >I am looking to put together a uucp site and would like to use a >SPARCstation 330 as the system. But the 330 doesn't seem to support >the ALM-2 ... > It what sense "doesn't support" ? They sell it for mono, GX, and TC SPARC/330. It's not sold for CXP and GXP systems, but my guess is that the latter two systems require all three 9U slots available for graphics hardware, and Sun ALM-2 is also 9U, so there is simply no room for an ALM-2 board. However, some third-party vendors begin to sell 6U size ALM-2 for SPARC/330. Margaret Mikulska mem@inls1.ucsd.edu ucsd!inls1!mem
prc@erbe.se (Robert Claeson) (11/19/89)
First, I want to make everyone reading this aware of that we're selling the stuff mentioned in this article, so I guess I'm kind of biased. Anyway, darryl@lemuria.UUCP (Darryl P. Wagoner) writes: > I am looking to put together a uucp site and would like to use a > SPARCstation 330 as the system. But the 330 doesn't seem to support > the ALM-2, so I thought about using an ethernet terminal server. > Does anyone know how well a terminal server will work for uucp traffic? We've been using Annex II terminal servers from Xylogics, Inc. and Encore Computer Corp. for uucp traffic for the last 3-or-so years. I have still to encounter any problems, once you get the stuff configured correctly for your application. BTW, we use V.32 modems which talks at 38.4 Kbps to the server regardless of what the current line speed is. Just make sure that the remote site disables xon/xoff flow control before rlogin'ing to the host. The chat script that we use to give out to remote sites goes something like (with Annex security enabled for dial-in ports): sername:--sername: Uremote ssword: abcdef nnex: stty\siflow\snone\soflow\snone nnex: rlogin\shost ogin: Uremote ssword: xyz As I said, we haven't had any problems with doing this since we first tried it 3 years ago. -- Robert Claeson E-mail: rclaeson@erbe.se ERBE DATA AB
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!gnbneil@cpd.com (Neil Gorsuch) (11/20/89)
In article <1243@lemuria.UUCP> darryl@lemuria.UUCP (Darryl P. Wagoner) writes: >I am looking to put together a uucp site and would like to use a >SPARCstation 330 as the system. But the 330 doesn't seem to support >the ALM-2, so I thought about using an ethernet terminal server. >Does anyone know how well a terminal server will work for uucp traffic? >Most of the traffic will be at 2400 baud or less and very little >real user dial in. First, let me mention my bias on this subject, since we just released the product that I am about to mention. Why not use a desktop Sparcstation, and put more serial ports on it using the standard tty driver already supplied? Sounds impossible, you say 8-) ? Aside from a card cage, there isn't much difference between a desktop Sparcstation and a Sparcstation 330. We are now selling serial and parallel ports on the SCSI bus, in groups of 8 serial and 1 parallel port per "box" (each box uses 1 SCSI address). All the modem control signals are supported on every serial port. The desktop sparcstation is much cheaper, enough cheaper that if you want more MIPS, just add 1 or 2 more as diskless clients of the first. You'll beat the server configuration on MIPS and $s that way. The desktops can have up to 64 Mbytes each of memory, if that's a worry, and you can put 10.5 mS average seek time disks on the SCSI bus. Using the SCSI bus for the serial ports is nice because there is much more bandwidth on the SCSI bus than the ethernet (5 Mbytes/S as opposed to 10 Mbits/S). There is much more serial throughput available in our box than you need in the application you described. The input response is excellent, almost like having ALMs, certainly more than adequate for uucp traffic. If you're stuck on buying an expensive card cage, put in a SCSI interface and add a few of our boxes, and you'll still have better performance for lower $'s than thernet serial boxes. You won't quite approach ALM performance, but the difference is very small and the last time I looked, ALM-2 prices were much higher than the $'s for our boxes. For more information, contact me by email or call (800)433-6784. -- Neil Gorsuch INTERNET: neil@cpd.com UUCP: uunet!zardoz!neil MAIL: 1209 E. Warner, Santa Ana, CA, USA, 92705 PHONE: +1 714 546 1100 Uninet, a division of Custom Product Design, Inc. FAX: +1 714 546 3726 AKA: root, security-request, uuasc-request, postmaster, usenet, news