By "speed" we really mean the "data flow rate" but almost everybody incorrectly calls it speed. The speed is measured in bits/sec (or baud). Speed is set using the "stty" command or by a program which uses the serial port. See Stty
The top speed of 115.2k has been the standard speed since the mid 1990's. By the year 2000, many serial ports supported higher speeds but Linux seldom used them due to lack of drivers. These high-speed ports by default only support 115.2k and must have special software to enable the higher speeds. Today (2001) almost all new serial ports support speeds of 230.4k and 460.8k. Some also support 921.6k. Unfortunately, to get these speeds you need to compile the kernel with a special patch and it seems the patch doesn't support the 2.4 kernels yet.
For internal modems, only a minority of them advertise that they support speeds of over 115.2k for their built-in serial ports. Will shsmod support these ??
The patch to support high-speed is called shsmod (Super High Speed). There are both Windows and Linux versions of this patch. See http://www.devdrv.com/shsmod. For Linux, much of the documentation is only in Japanese. There is also a module for the VIA VT82C686 chip www.kati.fi/viahss/.
Here's a list of commonly used divisors and their corresponding speeds (assuming a maximum speed of 115,200): 1 (115.2k), 2 (57.6k), 3 (38.4k), 6 (19.2k), 12 (9.6k), 24 (4.8k), 48 (2.4k), 96 (1.2k), etc. The serial driver sets the speed in the hardware by sending the hardware only a "divisor" (a positive integer). This "divisor" divides the maximum speed of the hardware resulting in a slower speed (except a divisor of 1 obviously tells the hardware to run at maximum speed).
Normally, if you specify a speed of 115.2k (in your communication program or by stty) then the serial driver sets the port hardware to divisor 1 which obviously sets the highest speed. If you happen to have hardware with a maximum speed of say 230.4k, then specifying 115.2k will result in divisor 1 and will actually give you 230.4k. This is double the speed that you set. In fact, for any speed you set, the actual speed will be double. If you had hardware that could run at 460.8k then the actual speed would be quadruple what you set.
To correct this accounting (but not always fix the problem) you
may use "setserial" to change the baud_base to the actual maximal
speed of your port such as 230.4k. Then if you set the speed (by your
application or by stty) to 230.4k, a divisor of 1 will be used and
you'll get the same speed as you set. PROBLEM: stty and many
communication programs (as of mid 1999) still have 115.2k as their
maximum speed setting and will not let you set 230.4k, etc. So in
these cases one solution is not to change anything with setserial
but mentally keep in mind that the actual speed is always double what
you set.
There's another work-around which is not much better. To use it you
set the baud_base (with setserial) to the maximal speed of your
hardware. This corrects the accounting so that if you set say 115.2k
you actually get 115.2k. Now you still have to figure out how to set
the highest speed if your communication program (or the like) will not
let you do it. Fortunately, setserial has a way to do this: use the
"spd_cust" parameter with "divisor 1". Then when you set the speed to
38400 in a communication program, the divisor will be set to 1 in the
port and it will operate at maximum speed. For example:
setserial /dev/ttyS2 spd_cust baud_base 230400 divisor 1
Don't try using "divisor" for any other purpose other than the special
use illustrated above (with spd_cust).
If there are two or more high speeds that you want to use that your communication program can't set, then it's not quite as easy as above. But the same principles apply. You could just keep the default baud_base and understand that when you set a speed you are really only setting a divisor. So your actual speed will always be your maximum speed divided by whatever divisor is set by the serial driver. See How speed is set in hardware: the divisor and baud_base
Note that the baud_base setting is usually much lower than the frequency of the crystal oscillator in the hardware since the crystal frequency is often divided by 16 in the hardware to get the actual top speed. The reason the crystal frequency needs to be higher is so that this high crystal speed can be used to take a number of samples of each bit to determine if it's a 1 or a 0.
If you are seeing slow throughput and serial port overruns on a
system with (E)IDE disk drives, you can get hdparm. This
is a utility that can modify (E)IDE parameters, including unmasking
other IRQs during a disk IRQ. This will improve responsiveness
and will help eliminate overruns. Be sure to read the man page very
carefully, since some drive/controller combinations don't like this
and may corrupt the filesystem.
Also have a look at a utility called irqtune that will change
the IRQ priority of a device, for example the serial port that your
modem is on. This may improve the serial throughput on your system.
The irqtune FAQ is at
http://www.best.com/~cae/irqtune