On Sun, 22 Mar 1998, George Toft wrote:
> > If a modem were a hard drive, that would be correct. But it's not.
>
> In the dark ages from whence I came, the serial card could buffer 16
> bytes and a hard drive 256 bytes. Even with these numbers in a
> single-tasking DOS, I saw the above performance on 286's.
Nevertheless, the fact remains that a hard drive and a modem are extremely
different types of hardware and this is what accounts for the varying
performance.
The problem with a modem is not the amount of CPU time which must be spent
hauling the data in and out of the serial port, but the fact that a serial
port requires very low latency times. A hard drive (and other fast
devices such as network cards) perform "block transfers". The data is
placed in a DMA area and read directly out of RAM into the hard drive
controller, which can deal with it at whatever time it wants to. A serial
port on the other hand, has more or less no control over how fast the data
comes in. If the computer does not respond to the interrupt, the serial
port has no place to put the data and will lose it.
Because of their character-at-a-time nature, serial ports tend to signal a
lot of interrupts. A hard drive can signal an interrupt, transfer several
K of data, and go back to sleep. This has the side effect of meaning that
if something "important" happens and pre-empts the hard drive, the hard
drive is less likely to be doing something at that time. Also, if the
hard drive needs to be serviced and the system is busy, it's not the end
of the world. The disk spins around a couple of times and it will still
be there when the system is ready to attend to it. A serial port who does
not receive CPU time will be forced to throw its data away. Serial ports
must signal interrupts more or less constantly and need to have every one
of them serviced correctly. The burden is much greater.
This problem is particularly acute on a multitasking system such as linux,
where several devices may all be signalling interrupts at once. The OS
must decide which interrupts get the most priority - and unfortunately
serial ports have a fairly low priority. A program which can resolve this
is "irqtune." It can be found at http://shell5.ba.best.com/~cae/irqtune.
Under DOS, you have only one program running on the system. When you are
running your terminal software, the network card and the disk drive are by
definition not going to be doing anything unless the running program
specifically asks for it. When it is ready to access the disk, it can
send a command to the remote site to tell it to stop sending data. A
linux application has no such foreknowledge of when the system will become
busy, and therefore cannot warn the remote site ahead of time.
> > Second, the CPU is doing vastly different things when it runs a PPP
> > connection vs. reading from a disk. There's a lot to be done in a TCP
That's true. Running TCP/IP is roughly equivalent in CPU load to running
a Zmodem file transfer, and the requirements are significantly increased
if you are trying to use STAC compression (which you should never do).
Fortunately, the kernel is smart enough to know that hardware interrupts
have a higher priority than unscrambling network packets, which in turn
has a higher priority than the application layer. And even a 386sx/16 is
fast enough to keep up with the demands of the TCP/IP stack (at least one
running over a 28.8 modem). But it does reduce the overall system
performance (somewhat).
In case of the system running completely out of CPU then some packets must
be dropped. The kernel automagically knows when the TCP/IP stack is
"getting behind" and is swamping the system without much chance of
"catching up" and will discard packets rather than allow the system to
slow to a crawl. This is fairly common running ethernet sniffers,
especially if you're doing something resource-intensive with them like
trying to dump them all to the screen on a busy network. Sometimes you
can inadvertently create a packet storm this way - suppose you have
tcpdump look up the names of the hosts to which the traffic is being
sent/received, rather than displaying their IP addresses. If your
nameserver is on the same interface you are sniffing, you will end up
sniffing your own DNS packets and then making more calls to the DNS server
to resolve the IP address of the server to which you are sending the DNS
packets.
> Aahhh - Being new to Linux I'm sure I misspoke. When I was deep in
> the DOS world, we had no problems with high-speed modems and NICs on 286
> and 8088's. I see that Linux has far more to do than just listen to
The high-speed NIC's and modems on those 286's and 8088's are probably not
all that high speed. 8088's typically had token ring or NE1000 cards,
with a smattering of WD8003's and 3C501's mixed in for good measure. All
of these 8-bit cards could never keep up with a fully loaded network;
fortunately, they were very rarely used in promiscuous mode and so
basically didn't have to. As for modems I never saw anything faster than
2400 baud attached to an 8088, and rarely any faster than 9600 on a 286.
(a couple of exceptions for 14.4's running on BBS's in the last of the
olden days).
> My gut feeling, considering the extreme talent that went into making
> Linux, is even a lowly 386 should be able to keep up with a 28.8 modem.
Really it can. My 386DX/25 will drop some characters in minicom when its
serial port is running at 56Kbps. Since it is over a null modem cable,
the 56Kbps connection is continuous, rather than intermittent such as you
would have with a modem whose compression ratios fluctuate. It can keep
up with this for 4-5 seconds and then will garble the data. I have not
attempted to enhance this with IRQtune because the link is not used much
and rarely runs at full power. Of course, this was a 25MHz 386. A 16MHz
386 might have some more trouble with such speeds, but then, a 28.8 modem
will not generate so much throughput as that either.
Don't try this with your 128K ISDN link, though. :)
A 28.8 modem will very rarely exceed 56Kbps of throughput (that would
equal about 6K/sec, and when was the last time you got that much
throughput on any modem PPP connection?) and will certainly never do so
for any length of time. Don't worry too much about it.
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
