use at home for a dial-on-demand proxy. It's been used for this role for about
two years and has run Linux kernel from as early as 1.1.59.
I have been running a patched up version of 2.0.36 with portfw and ipchains and
of course the MCA (Microchannel) patches and PPP-2.3.5 ppp compiled in.
Using this setup with my USR 56K modem I consistently get transfers of
compressed file of 4.9-5.2Kps, however, when running kernel 2.2.1 my speeds are
lowered by about 40% (3.5Kps typical).
While I don't really have any true pressing need to upgrade this machine to 2.2,
I thought it would be nice to run the first stable kernel with built-in support
for microchannel, instead of the patched up 2.0 stuff. Now I'm doing everything
I can think of to figure out why the PPP is so slow, and I'm looking for
guidance. Here the lowdown so far:
The P70 was originally a 386/20Mhz machine. This one has been upgraded with a
Cyrix Cx486DRx2/40Mhz and runs about like a 486/33 (Bogomips 15.7). I'm using
the built in serial port which is a 16550A.
The symptom is slow PPP with quite a few FRAME errors reported on the ppp0
interface. Under 2.0.36 performance was always great and never reported any
My first testing basically involved compiling a very stripped down kernel with
no firewalling, etc to add overhead to the tcp/ppp communications chain,
tweaking all the PPPD settings, disabling all compressing on the link, using
irqtune, killing all backgroud proccesses, etc. I could improve things
slightly, but nothing major.
I then patched in the ppp.c from the PPP-2.3.5 package into the 2.2.1 kernel so
that I would be running the same ppp version on 2.0.36 as on 2.2.1. The problem
Since I was now running the same ppp code on both kernel and the problem
remained the same I began to suspect the serial routines were running slower in
the new kernel
I then began to play with the 16550 receive fifo FCR_TRIGGER value in serial.c.
I changed this from the default of 8, to the other options of 1,4, and 14.
could notice no difference with 4 or 14, and with 1 my frame errors went up
significantly (as expected).
I then decided to begin to go back through the 2.1.x kernels and see if I could
pinpoint when the problem was introduced. I think (although I'm still testing)
that the problem was introduced between 2.1.100 and 2.1.102. Kernel 2.1.100
seems to work correctly, 2.1.101 doesn't seem quite right (I'm going to compile
another one clean just to make sure), and the in 2.1.102 things go bad.
Interestly 2.1.102 is when IPCHAINS replaced the old ipfwadm. Now this
shouldn't affect much here because I'm compiling without firewalling options
enabled for this testing, and even if I did enable chains, I'm using the
IPCHAINS patch on my 2.0.36 kernel. The other things that were changed seemed
to involve IRQ handling. Some seemed to be related to edge and level triggered
I found this suspect since the microchannel machines use level triggered
interrupts instead of the more common edge triggered stuff in the ISA world,
unfortunately I'm understand lille about the linux irq stuff and I'm learning
it from scratch. Does anyone out there who is more familiar with the linux irq
handling think that this could be related to the problem?
I'm also looking for any other sugestions as to what could be causing this
problem (in case I'm really off base now). Any help or guidance of ways to
troubleshoot this would be appreciated.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/