Messages in this thread | | | Date | Fri, 16 Oct 1998 21:36:30 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: 921Kbps on Linux: is it possible ?!?! |
| |
Date: Fri, 16 Oct 1998 11:33:30 +0200 From: Pavel Machek <pavel@atrey.karlin.mff.cuni.cz>
BTW When adding 921Kbps, add 1500000bps, too, they are supported by NS PC87338 chip. (Expect patch soon, it already works for me.)
I can add 921 Kbps, since that seems to be pretty standard --- it's double 460800 bps, or 921600 bpd. Above that, though, there isn't much standardization, as near as I can tell. Some clock rates/divisor combinations will give you 1500000 bps; others will give you 1563000 bps.
This is why the bitmask approach is really kludgy. What I'd like to do is replace it with BSD-style input baud and output baud fields in struct termios. However, this requires making a libc interface change, which can be made less painful with glibc and symbol versioning. However, that is clearly a post-2.2 thing to worry about.
So I'd rather not add every single possible high-speed baud rate at this point, unless there really is "subtantial and credible evidence" that these baud rates will actually get used. We can add a few, for the sake of certain boards that really want the high-speed baudrates. 921kbps is fine, but for the rest, it's likely that many of these will be highly board specific. It also mean that programs that want to support these high-speed non-standard speeds will have to have a large number of entries in their tables to map strings to their BXXXXXX values.
Earlier someone quipped that saying people won't use these high speed items is like saying that 640k will never be too much memory. I don't actually think this is a valid analogy. 32k of memory was plenty of memory on a PDP-8, and the march of technology did not mean putting more memory on a PDP-8; the processor itself was completely replaced with something more modern. So it may very well be with serial interfaces; you can already find USB modems in the stores, and IEEE Firewire is just much, much better suited for high-speed data transfer.
First of all, given the RS-232 specs, there are real distinct limitations as you go to the higher speeds. The original RS-232C specification specified a maximum speed of 20kbps before noise, signal degredation, etc. would become a problem; the original RS-232 specification didn't support anything faster than 20,000 baud. Of course, the original RS-232 spec also said that the maximal cable length was 50ft., and what has happened over the years is that we've used faster baud rates with shorter cables that are very heavily shielded. But the faster you go, the shorter the cable has to be and the better quality it had better be. So at the hardware level, anything above 115200 bps starts requiring very careful attention to cabling issues. Even at speeds as "low" as 230400, I've found that cables can be the reason why things don't work. You can't be using long, cheesy cables! At 921kbps, while I haven't tried it myself, I'd surprised if cables longer than 3ft worked at those speeds without seeing data corruption.
So sure, we can add support for faster speeds, but I still stand by my statement that I suspect very, very few people will be using speeds greater than 230400. Aside from serial boards wanting to boast that they can do high speeds (and some of the ones who claim they can that I've tested really can't --- but it's not a problem because most people will never notice), there simply much in the way of hardware peripherals that use the higher speeds. I've seen a very few modems that support 230400, but that's about it. And if you're doing computer-to-computer data transfers, why are you using a serial line? Use Ethernet instead; it's way faster, and that's what it's designed for.
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |