Return to BSD News archive
Xref: sserve comp.os.linux.development:18542 comp.os.linux.misc:28665 comp.os.386bsd.questions:14188 comp.os.386bsd.misc:3935 sci.electronics:83099 Newsgroups: comp.os.linux.development,comp.os.linux.misc,comp.os.386bsd.questions,comp.os.386bsd.misc,sci.electronics Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!ix.netcom.com!netcom.com!jonk From: jonk@netcom.com (Jonathan Dale Kirwan) Subject: Re: 16550 detection Message-ID: <jonkCyo2Au.239@netcom.com> Followup-To: comp.os.linux.development,comp.os.linux.misc,comp.os.386bsd.questions,comp.os.386bsd.misc,sci.electronics Organization: New World Computing Services X-Newsreader: TIN [version 1.2 PL1] References: <CMETZ.94Oct30051603@itchy.inner.net> <TYTSO.94Nov2113942@dcl.mit.edu> Date: Thu, 3 Nov 1994 00:49:42 GMT Lines: 97 Theodore Y. Ts'o (tytso@athena.mit.edu) wrote: : In article <MICHAELV.94Nov1215132@MindBender.HeadCandy.com> michaelv@MindBender.HeadCandy.com (Michael L. VanLoon) writes: : >OK, fair enough. I've never seen any of these modems, but I never : >really looked hard since I only buy external modems anyway. ;-) : Yup, I generally advise people to stay far, far, away from internal : modems. I generally don't trust them. I can't agree, when discussing high-speed applications. I was an old codger regarding externals. Always liked being able to move it around easily and I liked having the lights for feedback. But when the speeds started getting up as high as they often are now, I've given up the fight. The internal units are almost always less expensive, for obvious reasons, but their main advantage is that they can support very large buffers and present a lower overall load on the CPU. I always find modem connections at 14,400 bps, and sometimes at 28,800. Often, I simply grab or send text files without bothering with "pre- compression" using ZIP of whatnot because the lines almost always come up with V.42bis (BLTZ) or MNP 10. The text just flies then, often with sustained cps rates of over 3,000 for 14,400 and 6,000 for 28,800. This means I must set the internal serial board (if using an external modem) at rates of 57.6k or better to keep up. It is hard to ask for common users to understand the need for 16550 chips (or CPU-based serial cards) in order to use a modem. Better for them to save the $10 to $15 extra charged for 16550-based boards and to spend it on a $75 14,400 bps internal modem. Even with a 16550, the 16 bytes that it buffers (even though it should interrupt in 8) only provides about 2 to 3 milliseconds of latency. The internal boards all provide enough buffer to get by, mostly. Creating an interface between the analog modem and serial-to-parallel converter is fine for slower speeds. But it is too much a burden at the higher speeds, costing more and delivering less. : >At 115200 bps (which is where the high-end modems are going these : >days, with some capable of even 230400 bps), it takes only one : >thousandth of a second to fill a 16 character FIFO. THIS is where the : >problem lies. Nobody realistically expects you to fill that entire 1k : >FIFO, but to simply use it to handle burst overruns that 16 characters : >would never be able to catch. : A V.34 modem does 28.8kbps (and you're not going to see much better than : that, I suspect, due to silly things such as Shannon's Limit); on top of : that the theoretical maximum compression, I believe, is a factor of : four, takes you to 115.2kbps. But I've never seen a modem, or disk : compression software, or any compression technique in general, that even : comes close to a factor of two using real life data. Sure, if you're : using whatever the modem marketing people use for their benchmarks : (which is probably something like an 8k block of nulls, or "The quick : brown fox...." repeated a thousand times), you can come close to the : theoertical maximum. But most of the time, you just don't get it. I do get high character rates in practice. It is a great convenience to not have to convert text, as I mentioned above. I agree it is "bursty", since such loading isn't constant. But it is nice to be able to handle the bursts, when they occur. And with internal modems costing so damn little, why do anything else. $75 isn't much to have to toss, if it goes bad or becomes obsolete. It is just a "BIC" modem, anyway. : >I agree that 1024 is more than you would need in most normal cases. : >However, that's the upper limit. 16 characters is much less than you : >need sometimes. A realistic compromise might be a 16550 with 32 or 64 : >byte FIFO. The reason 1024 is so good, is not because it's 1024, but : >because it's a usable amount more than 16. : Funny you should mention this... Startech is marketing a chip which they : call the 16C650, which is a pin-compatible replacement for the 16550A. : It has a 32 bit FIFO, and a couple of other nice features, including : an option where it handles the flow control for you (giving you : an interrupt whenever it needs to pull RTS or CTS high or low, or giving : you an interrupt when it detects a (programmable) X-ON or X-OFF : character). I use the 4-by unit from Startech. The $10 ADSP-2105 can also make a nifty serial chip, if programmed properly. It as a T1-style serial port, too, with automatic mux/demux of 24 lines. : It also comes in a 44 PLCC package which also takes care of the COM1-4 : port decoding, such that it can be connected directly to the bus without : requiring any decoding logic --- that's clearly catering towards the : integrated motherboard market. In my opinion, though what makes this : chip really interesting is the 40 pin package which is 16550A pin : compatibile. That makes for a very cheap way to upgrade a serial port : to better be able to handle faster modems. (I don't know what the : street price is for that UART, but it's got to be less than the $100 or : so that Hayes wants for its ESP card.) : The Linux serial driver should be able to take advantage of the 32 bit : receive FIFO automatically; after the 1.2 release comes out, I'm : planning on enhancing the driver to be able to take advantage of more of : the features of this very interesting chip. : - Ted