Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!newsfeed.ksu.ksu.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!sdd.hp.com!ihnp4.ucsd.edu!network.ucsd.edu!keyhole.ucsd.edu!not-for-mail From: eld@keyhole.ucsd.edu (Eric Dorman) Newsgroups: comp.unix.bsd Subject: Re: BSD for the Sun386i Date: 13 May 1994 17:40:46 -0700 Organization: MPL of SIO at UCSD Lines: 39 Sender: eld@mpl.ucsd.edu Message-ID: <2r16me$363@keyhole.ucsd.edu> References: <2qcljn$gqt@norm.eng.gtefsd.com> <ho4MM7o.dysonj@delphi.com> <2qk8uf$kok@panix2.panix.com> <Boyt076.dysonj@delphi.com> NNTP-Posting-Host: keyhole.ucsd.edu Hi all. >> >>Uh...almost, at best. >> >>Can we say, "sio and hacks on the tty code", kids? >> >>There, I knew we could. > >Yes, FreeBSD uses ring-buffers instead of clists -- can we say theoretically >faster... I thought you could... [deleted] >BTW, sorry, for the smart-alecky response. I personally would prefer >that we (FreeBSD) used clists, but we dont. I would rather throw away >an unmeasurable performance advantage for compatibility. But thats the >breaks!!! >John >dyson@implode.root.com Many moons ago (85?) we had some Intel Multibus I 80286 boxes running Xenix 3.0. We used them to do simple editing and playback of seismic data recorded on 4-track reel-to-reel tape. When playing back, the data came out at (i forget) I think 8x real time, which worked out to be about 19100bits/sec sustained rate. The Intel machines were able to pickup the stream without dropping a bit and have some umpf left over. Heh Then Intel, in its infinite wisdom, replaced the clist system with 256byte ring buffers. Now we could *barely* able to keep up with the stream; doing anything caused the ring buffer to fill up and data got lost. Awwwwwwwwww! Editing serial data was a *real* pain; searching for sync words, hacking bits back in, updating time. ARGH! Moral: Not all applications are (were :) ) created equal. Eric Dorman eld@mpl.ucsd.edu eric@siodept.ucsd.edu