Newsgroups: comp.os.linux Path: sparky!uunet!usc!wupost!csus.edu!netcom.com!harp From: h...@netcom.com (Gregory O. Harp) Subject: 57.6Kbps under Linux -- some results... Message-ID: <!nwn!6h.harp@netcom.com> Date: Sat, 12 Sep 92 13:26:38 GMT Organization: Netcom - Online Communication Services (408 241-9760 guest) Lines: 69 Well, since I opened my big mouth and said that 57.6Kbps probably wasn't possible, I ended up doing some experimenting with exactly that. I'll summarize for those who don't want to read the whole thing. I can _almost_ do 57.6Kbps with my 50Mhz 486DX. I only have 16450 UARTs, so those of you with 16550A UARTs and very fast machines should be able to do it. [WARNING! Kernel-hacking ahead!] First, I had to hack the kernel serial code to handle that speed. Linux currently only supports 38.4Kbps as "shipped." BTW, I'm working with version 0.97pl4 of the code, if you want to follow along. It's a matter of modifying the table on lines 328-330 of kernel/chr_drv/serial.c. This is the baud rate divisor table. Anyway pick an entry like the value 384, which is 300bps, and change it to 2, which is the divisor for 57600bps. You might want to replace a less-common baud rate like 50 baud (the divisor to change is 2304), but most terminal software won't support that. BTW, if you really want to try it, the divisor for 115Kbaud is 1, but good luck! ;) If you want to figure it out for yourself, the formula is: divisor = 1843200 / (baud * 16) Once you rebuild the kernel (Remember to back up! Oops, am I too late? ;) ) and reboot, you should be able to tell any software that you want to use 300 baud (or whichever entry you modified) and you will actually be set up for 57.6Kbaud. Now, I tried hooking up to my Amiga 3000 at this rate. I had some success, but the file I downloaded was corrupted somewhat and I only pulled about 4K/sec out of the transfer. My next experiement was to null-modem my two serial ports together and do the following: cat </dev/ttys0 >foo2 & cat foo >/dev/ttys1 I transferred a 1430343 byte file in 4 minutes and 9 seconds, meaning I pulled 5744 bytes per second! 57.6Kbaud! Now, once again, the file was a little corrupted, but tar was able to identify it as a compressed archive and it at least made it through a hundred K or so before crapping out. I'd be really interested in seeing what a 486DX50 with 16550A UARTs on it can do. If someone out there has one (or they want to swap I/O cards with me ;) ) send me mail at h...@netcom.com and we'll talk. BTW, the reason I keep saying 16550A and not just 16550 is because a glance at the code tells me that Linux is only enabling the FIFO if the UART is the 16550A (refer to lines 265-272 of serial.c). Linus, can you tell us why you don't use the FIFO on the 16550? I've personally never used the FIFO because my projects were for 16450 UARTs, but I'm not aware of any problems. Oh well... Gotta go. Glad the weather's nice here in Dallas. Gonna be a nice afternoon for some horseriding! Later folks... Greg -- -----------------Greg-Harp----------------h...@netcom.com------------------ Love me, love my ferrets. "Break out of the mold before Or at least love my ferrets. ;) the mold sets in" -- B52's
Path: sparky!uunet!cs.utexas.edu!sun-barr!olivea!mintaka.lcs.mit.edu! bloom-picayune.mit.edu!athena.mit.edu!tytso From: ty...@athena.mit.edu (Theodore Y. Ts'o) Newsgroups: comp.os.linux Subject: Re: 57.6Kbps under Linux -- some results... Message-ID: <TYTSO.92Sep12125450@tsx-11.mit.edu> Date: 12 Sep 92 16:54:59 GMT References: <!nwn!6h.harp@netcom.com> Sender: n...@athena.mit.edu (News system) Organization: Massachusetts Institute of Technology Lines: 54 In-Reply-To: harp@netcom.com's message of Sat, 12 Sep 92 13:26:38 GMT Nntp-Posting-Host: tsx-11.mit.edu In article <!nwn!6h.h...@netcom.com> h...@netcom.com (Gregory O. Harp) writes: First, I had to hack the kernel serial code to handle that speed. Linux currently only supports 38.4Kbps as "shipped." I've been working on a heavily revised version of the serial driver, that supports more boards (including the AST FourPort boards) as well some other neat features. One of the neat features is a way to control what speed "38400" baud means when you specify it to the kernel, using setserial. You can set it to mean 38400, 57600, 115200, or "custom divsor". With custom divisor, you basically get to specify "div" in the equation baud = 1843200 / (div * 16) I'll be shipping my new serial driver to Linus soon, so look for it in a Linux release near you. Some of the other fixes which should be popular is that I've managed to use over 100k less memory in the tty drivers, which means 100k more memory for user programs. I figure that should be nice for people who have 2 or 4 meg machines. :-) BTW, the reason I keep saying 16550A and not just 16550 is because a glance at the code tells me that Linux is only enabling the FIFO if the UART is the 16550A (refer to lines 265-272 of serial.c). Linus, can you tell us why you don't use the FIFO on the 16550? I've personally never used the FIFO because my projects were for 16450 UARTs, but I'm not aware of any problems. The initial version of the 16550 which were shipped by National Semiconductor had a bug, so that their FIFO's where *not* reliable. The spec sheets from National specific state that if you have a 16550, you should not attempt to use the FIFO's. Fortunately, relatively few 16550's were actually shipped before the problem was discovered, and most of those ended up in PS/2's. These days, when people talk about 16550's, they generally mean recent versions of the chips that have the working FIFO's. These chips will be labelled: "NS16550A", "NS16550AF", "PC16550C", or "PC16550CF", (apparently PC16550CF is the most recent chip version; although I've been assured by National Semiconductor that most of the bugs which were fixed in the PC16550CF's shouldn't give me any trouble if I only have a NS16550A). In any case, because the original 16550's had such a serious bug, National thoughtfully gave us a software way of detecting whether or not the chip was one of the chips with the FIFO bug, or not. All of the more recent chips will ID themselves as a 16550A; it is only the original buggy chips that will ID themselves as a 16550. You generally don't need to worry about this. Although it might be prudent to check a serial board that you're thinking about to see whether it has one of the newer chips, it is very unlikely that if you were buying a serial board that you would actually run into one that had one of the original 16550 chips. - Ted