Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!yarrina.connect.com.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.ysu.edu!freenet.akron.oh.us!neoucom.edu!ns.mcs.kent.edu!usenet.ins.cwru.edu!gatech!newsfeed.internetmci.com!swrinde!sdd.hp.com!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.netbsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.solaris,comp.unix.aix
Subject: Re: ISP hardware/software choices (performance comparison)
Date: 19 Jan 1996 22:57:21 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 122
Distribution: inet
Message-ID: <4dp7kh$8v8@park.uvsc.edu>
References: <4cmopu$d35@vixen.cso.uiuc.edu> <4dbun0$j2f@park.uvsc.edu> <4dg90i$6le@mail.fwi.uva.nl> <4dh42v$rnv@park.uvsc.edu> <4djgkh$kgn@Jester.CC.MsState.Edu> <4dkqa7$27e@park.uvsc.edu> <30FEFA1F.66C9@hydra.acs.uci.edu>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.netbsd.misc:2052 comp.unix.bsd.bsdi.misc:2209 comp.unix.solaris:57863 comp.unix.aix:69199
Dan Stromberg <strombrg@hydra.acs.uci.edu> wrote:
] > It is my understanding that most of the code in the source
] > archives requires BSD interfaces and/or libraries.
]
] Most code that isn't largely dead, has been ported.
It's dead because you define it dead. 8-).
There are some major packages, like the X interfaces to GDB,
especially the ones using Motif, that don't like the SVR4
style pty interface.
The other big sticking points without a compatability environment
are terminal I/O (termio vs. termios vs. s/gtty vs. the partial
open hack for modem ports) and command interfaces for commands
used in existing shell scripts (ps -edalf vs. ps -gaxu, etc.).
At this point, the PERL nuts will point out that everything
should be written in PERL 8-)).
> > Dan Stromberg has a couple of nice points potentially in favor
> > of Solaris as an ISP platform;
[ ... ]
] We have our differences (definitely!) Terry, but that was a quite
] gracious segue.
Besides the points listed below, I was mostly thinking of
Solaris' "autoinstall" (you brought it up today in another article,
so I replied there).
] I suggested that MP could be relevant for an ISP service, if:
]
] 1) shell accounts were being provided
] 2) there were enough downstream links that it would begin to saturate a
] single CPU to feed the upstream link
] 3) the downstream links caused a high number of interrupts, and the
] CPU/OS in use had a high interrupt latency
MP for shell accounts was one point. Users might be running CPU
intensive programs, like muds/mucks/mushes/etc. without line mode
telnet support -- or option negotiation of any kind.
It really depends on what services you intend to provide.
The majority of ISP's I'm familiar with are moving toward SL/IP,
PPP access, and supply space for user WWW pages, user FTP areas,
and IMAP/POP services for a non-transient mailbox service.
For this type of thing, you put a "Livingston Portmaster" or
similar hardware on your net, and you are back to being I/O
bound instead of CPU bound.
You could argue that these guys are close to becoming NSP's
instead of ISP's, except for the BIND issues (they typcially
don't offer domain services for dialup accounts).
] Solaris' recent improvements in TCP/IP efficiency (helping with single
] CPU or MP) couldn't hurt feeding that upstream link, and I'd guess
] they'd reduce latency.
I have a real, real hard time with Streams stack implementation,
not because it isn't a good developement environment, but because
there is *inevitable* latency introduced.
This may just be my inhernet prejudice against all stack latency,
which comes from my experience with request/response architectures.
Other than interactive sessions, there is really very little
request/response (though JAVA downloads may change that a bit),
so latency isn't very user perceptible. But by the same token,
any speed over 28.8 or whatever the ISP's clients are using is
pretty imperceptible as well. In any case, the limit will be
the ISP's pipe to his NSP, and not the interface on the ISP host
machine.
] I might add: it's kind of nice having PPP bundled. I know many people
] don't use the Solaris PPP, instead going with dp - but then, hey, it's
] nice having the choice between the two.
The "best" user-to-net attachment mechanisms I have seen are:
1) Morningstar's PPP, which has all the bells and whistles
and is sold commercially for a lot of platforms
2) BSDI's mslip, which can do channel bonding to turn 2
28.8 modems into a 56k line (ftp.bsdi.com)
3) FreeBSD/etc.'s ijppp, which is a user space implementation
of PPP with all the bells and whistles.
All of these could probably be ported to Solaris (which supports
an IP tunneling device, I believe), but other than the first, I
don't think they have been.
Most bundled PPP's aren't very happy with Microsoft's illegal
option negotiations, which were rejected by the IETF.
How does Solaris' bundled PPP react to Solaris RFC 1323 support?
The typical reaction on a host where this is enabled is that the
timer causes the compression to be effectively disabled (*BSD*
recommends turning RFC 1323 support off for PPP systems where
compression is desirable).
Also, does it implement RFC 1717 (Multilink PPP)? If so, this
would be a big win, since it isn't widely implemented for the
host side of things, AFAIK.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.