Date: Fri, 05 Jul 1996 15:40:54 -0400 From: "Jacob M. Parnas" <jparnas@jparnas.cybercom.net> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: stesin@elvisti.kiev.ua, Kevin_Swanson@blacksmith.com, hardware@freebsd.org, bsdi-users@bsdi.com Subject: Re: muliport boards - building a PPP dialup server Message-ID: <199607051940.PAA02847@jparnas.cybercom.net> In-Reply-To: Your message of Sun, 30 Jun 1996 01:06:38 %2B0930. <199606291536.BAA21513@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199606291536.BAA21513@genesis.atrad.adelaide.edu.au>you write: >Jacob M. Parnas stands accused of saying: >> >> Thanks for the information. But as I said in a recent message, the new TI >> chip can go over 900Kbaud/sec. This isn't so fast. Its 1/10th the speed >> of old ethernet and 1/100 of new 100 Mbit/sec ethernet. > >As I've already said, the 16550 will go faster. The problem is that the >programming model for the 16550 makes no provision for more divider steps, >and thus any software that wants to talk to either of these chips must be >modified to understand the higher speeds. > >Quatech do a card called the DS-100 with a pair of PC16550D's and an 18MHz >clock and a jumperable /1 /2 /5 /10 divider that will allow your to >run your 16550 ports significantly faster. > >Unfortunately, they tried to implement the card properly, and as such >we have had serious problems with the cards in fast (>486/33) machines. It shouldn't be a hard thing. Simply build a fifo which has say a 1 Megabit of memory on it (pretty cheap these days). It sends an interrupt if it goes from full to not full or another if it reaches half full. If known by the kernel not to be empty, empty it 25 times/second (if it was full at 10 MB/sec, it would be emptied in 1/80th of a second.) That's fast, cheap, and will go very fast. I'm not even hardware oriented, but can see that it wouldn't be hard or difficult to build or program, and would support very fast I/O. The reason current UARTs are always falling behind is poor design and poor forethought into the even near future. The above could be vastly improved by a hardware expert, but the technology or design ability isn't the problem. Early UARTs had 1 or 2 bytes of buffering. Of course there would be trouble. Memory is so cheap now and even ISDN with full compression (on a compressable file) is so slow even to computers 10 years ago (look at ethernet). It came standard on every Sun 3/50 or 2/50 (I think). Even 10 Mbit ethernet is 20 times faster than full ISDN with 4:1 compressable data being sent (1/2 Mbit/sec) (very rare). >Serial ports like that are intended as console ports or for debugging >the system during development. Standard network design philosphy does >not allow for compute servers to have heavy I/O. Look at the Encore >Multimax for a good example of this; lots of compute, lots of disk & >memory, but Encore built its serial I/O into a seperate box and called >it an Annex. Why do modems have to go on a seperate box if ethernet can easily and cheaply be handled within the computer (even 100Mbit/sec ethernet) or 40 MB/sec SCSI-3 systems? Again, its like DOS thinking "who would ever need over 640 Kbyte of RAM?". Poor forethought and design is the problem. >> The costs are $68 for my line install (cheaper, I think than my >> analog second line) $25-35/month telco (about same as analog) about >> $60 vs $20 for analog for unlimited usage. $.01/min/channel >> (biggest problem. In southern CA, I have a friend who doesn't the >> surcharge per minute on weekends and I think northern CA may be even >> cheaper. $400 for "modem/terminal adapter" and Unix driver. (may be >> lower in some places. > >Your americocentricity is appalling. In most of the civilised world, >ISDN is still outrageously expensive. I see. Its OK to criticize a message for being useless to people on "the other side of the pond", yet a joke the other way is unacceptable to you. >> I prefer to be able to get a contracted support policy, which I don't think >> FreeBSD has. Therefore, I'm going with BSDI. I'd rather not be down for >> a long time because of maintainer of a piece of code is on vacation for 3 >> weeks. BSDI has a paid for support contract which requires them to fix >> things promptly for not much money. > >You should try talking to Karl Denninger (or perhaps just read his posts >to the various FreeBSD lists) before you make the choice. Search for >karl@mcs.net (or just mail him and ask). I'm on this FreeBSD list and support it. Yet each OS has its pros and cons. I think the warm feeling of having a supported OS is a very big pro. Maybe you don't care. But considering a problem like 40 programmers trying to get a Microvax II to run Unix for a month due to an unexpected problem (since the Unix OS used an instruction that VMS didn't), or other bugs that pass major Q/A tests, I'd like to know that there's a company standing behind fixing problems. These bugs happen. If you care to try to fix it yourself and do your normal work, your welcome to do so. I'll take support. That also is my right. FreeBSD has some good ideas. I'm not against it. But I have to choose an OS to run and I think BSDI is a cost-efficient way to run Unix fast and has some great programmers (as well as FreeBSD) doing the work and fixing bugs, without other jobs that can't just be dropped if there's a major problem in their code. >> After being burned by it once, I've been careful since to avoid such problems. > >Your naivete' is touching. Back to the personal insults. This is where I step off. I have better things to do than act like elementary school kids trading insults. What's next? "My daddy can beat up your daddy". Jacob M. Parnas > >-- >]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ >]] Genesis Software genesis@atrad.adelaide.edu.au [[ >]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ >]] realtime instrument control (ph/fax) +61-8-267-3039 [[ >]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607051940.PAA02847>