Return to BSD News archive
Xref: sserve comp.os.linux.development:18627 comp.os.linux.misc:28741 comp.os.386bsd.questions:14218 comp.os.386bsd.misc:3954 sci.electronics:83206 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!uunet!usc!howland.reston.ans.net!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!athena.mit.edu!tytso From: tytso@athena.mit.edu (Theodore Y. Ts'o) Newsgroups: comp.os.linux.development,comp.os.linux.misc,comp.os.386bsd.questions,comp.os.386bsd.misc,sci.electronics Subject: Re: 16550 detection Date: 2 Nov 1994 16:39:33 GMT Organization: Massachusetts Institute of Technology Lines: 56 Message-ID: <TYTSO.94Nov2113942@dcl.mit.edu> References: <CMETZ.94Oct30051603@itchy.inner.net> <SRA.94Oct30162124@rurha-pente.epilogue.com> <CMETZ.94Oct30192816@itchy.inner.net> <CyIzxz.97A@cuug.ab.ca> <TYTSO.94Oct31162517@dcl.mit.edu> <MICHAELV.94Oct31211019@MindBender.HeadCandy.com> <TYTSO.94Nov1182557@dcl.mit.edu> <MICHAELV.94Nov1215132@MindBender.HeadCandy.com> NNTP-Posting-Host: dcl.mit.edu In-reply-to: michaelv@MindBender.HeadCandy.com's message of 02 Nov 1994 03:51:30 GMT 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. >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 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). 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