lkml.org 
[lkml]   [1998]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.099 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site