NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/sys/3b1/4429

Text File | 1993-01-29 | 7.9 KB | 169 lines

Newsgroups: comp.sys.3b1
Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!unixhub!unixhub.SLAC.Stanford.EDU!kls
From: [e-mail] (Karl L. Swartz)
Subject: Re: Taylor uucp 1.4 gamma on 3B1 with TCP (long)
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Stanford Linear Accelerator Center
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 28 Jan 1993 09:19:27 GMT
Lines: 157

In article <[e-mail]> [e-mail] (DoN. Nichols) writes:
>In article <[e-mail]> [e-mail] (Karl Swartz) writes:

>O.K.  I'm just using nntp so multiple machines here in the house can
>read news from a single machine ... I don't use it as a news transport
>mechanism, just a reader extension, because my feeds are all uucp.
>Since I can't NFS mount the news spool directory on the 3B1s ...

For that use I'd defintely prefer NNTP, even if the NFS option was
available.  That's what I run here at work and given the resources
it's the only way to go.  We use NNTP for feeds, too, except for a
feed home via UUCP.  (Nice having a pair of T-1s are your *slowest*
connections to the Internet! :-) )

>and didn't want to duplicate the disk space utilization

Of course in my case there isn't much in the way of disk duplication
since the machine with the full feed shovels everything out and then
expires it within a few hours; the other machine keeps one or two
groups as long as a month.

>Perhaps you can use something like viarsh (which worked well between
>the 7300 and the Sun-3 for me.

I thought about that, and might have looked into it further.  One
concern I had was with regard to queueing, which UUCP does nicely.
Beyond that, there was the desire for Taylor UUCP for the potential
speed increase over conventional modem links.  It also has a great
advantage for mail ... read on.

>>And then there's still Smail and SMTP to deal with when I'm done with
>>news.

>Though there is a workable sendmail with the WIN/TCP software package.

I've fought with sendmail for years, and long ago achieved the same
level of proficiency with sendmail.cf that I once had with TECO
macros.  (This almost feels like an AA session!)  After all that,
I find it difficult to accept that "workable sendmail" isn't an
oxymoron.  I certainly wouldn't want to go back to sendmail in any
way shape or form from smail 3.1.  (I know of folks who swear by IDA
sendmail and it seems a great improvement, though I've never worked
with it myself.  With smail 3.1 around I don't quite see the point.)

>My major problem with it was lack of good documentation

Good sendmail documentation is definitely an oxymoron.

>and lack of a good starting sendmail.cf for *my* setup

I looked over their sendmail.cf and it was one of the more decrepit
examples I've seen.  I played with 3b1 sendmail a bit at one point
and ended up replacing their .cf entirely.  Can't recall which one I
switched to though.

In any case, any current SMTP-based solution that I'm aware of lacks
one major feature that UUCP-over-TCP buys you: one system can't poll
another one for mail.  (Yes, the protocol includes a TURN command, but
nobody seems to implement it.)  This is significant because I expect
to soon have a SLIP link to work.  In this situation a solution based
solely on SMTP might produce large mail delays unless the link is up
most of the time, or my MXes try to connect fairly regularly.

With UUCP I can poll for mail.  I can also set it up so that it tries
to connect over TCP, leaving my modems free for other work, and then
falls back to normal modem calls if the SLIP link is down.

Ok, this is getting a bit away from the problem of the two machines in
my house, but as I said there were many reasons for choosing the UUCP
solution in this particular case.

>which was multiple machines etherneted together at home, and
>everybody else is a uucp connection through uunet at present

At present ditka doesn't have a link to uunet, but does talk to 52
other systems via UUCP in addition to the one at the other end of the
BAN (Bedroom Area Network).  I'm still very interested in having UUCP
work well over modems!

>I was assuming the condition of one machine with the major disk farm,
>and smaller client machines without enough disk to really want to do
>news spooling on them.  Also, I was assuming that all news would have
>to be retained on the primary incoming machine, rather than offloading
>carefully selected portions to another machine.

I'd love to have a "major disk farm."  As it is, by pooling the
resources of the two machines, I collectively manage to provide a
minor disk farm.  Maybe closer to a petting zoo.  :-)

BTW, in part this has been a bit of an exercise to see just how much
could be extracted from a 3b1.  It's also been an effort in postponing
the inevitable until 386BSD seems reasonably stable, and then until I
had the time and money to do something about it.  As soon as I get
back from Usenix I'll be buying a 386-40 (AMD, not Intel! ;-) and will
soon have ditka moved over to that platform.

>A Sun-3 with adequate disk does a reasonable job of being a nntp
>server, as long as there is adquate memory so swapping is not to
>likely to occur.

No doubt, especially if a 3b1 can still keep up with the job.  One of
the reasons for a SPARC 2 was that we have no Sun 3s while we do have
and support SPARCs.  Also, I wanted something that would keep up with
demand for several years, while serving half-a-dozen NNTP feeds (plus
a UUCP feed or three) and potentially several dozen users reading via
NNTP.

>>Another reason for trying Taylor is that it is supposed to be quite a
>>bit more efficient in using CPU cycles than other uucps.  If this can
>>eke a bit more throughput out of the Telebits before I get 386BSD up
>>and running, great!

>That improved throughput is quite adequate reason to use it on the
>3b1, which needs all the help that it can get at high baud rates

So far I haven't looked at this much, except for some quick tests via
the null modem link.  In that case I was only looking at the protocol
negotiations.  Anyway, I may try a few tests, but probably will just
devote my efforts to 386BSD at this point.

>(the serial port drivers are a prime problem, which you will be
>bypassing by using the ethernet.

I'll be bypassing it for one of 53 links, one which carries perhaps 2%
of the total traffic.  I'll still be *very* interested if I decide
386BSD isn't quite stable enough for my needs yet!

>    I hadn't noticed these, but you are correct.  Perhaps the programs
>which I have compiled expected the declarations above to not be present in
>the header files, and so did the declarations on their own.

Or perhaps other stuff was too finely tuned to the 3b1.  I dunno.  So
far it seems best to compile network stuff with -I/usr/ethernet/include
and leave everything else to use the standard includes.  It does require
some Makefile hacking on occasion, though.

>>Eh?  I didn't know about the fixincludes script either!  Was this with
>>gcc 2.x or with 1.40?  I just checked and it isn't in the gcc 1.40
>>package I got.

>Was that the source package, or a pre-compiled one?

The latter; Andy Fyfe has explained more about this so I'll leave it
in his more capable hands.

>Anyway, you had a much firmer grasp of just what you needed and why
>than I was able to glean from your article, though that could have been a
>factor of me being too sleepy (as I am again :-)

Speaking of sleepy ... what the hell am I doing here in the terminal
room at this hour when I have a 700a wakecall?!  G'night!

--
Karl Swartz        |INet    [e-mail]
SLAC Computing Services    |       or [e-mail]
1-415/926-3630        |UUCP    uunet!lll-winken!unixhub!kls  -or-  ditka!kls
(SLAC and the US Dept. of Energy don't necessarily agree with my opinions.)