Messages in this thread | | | Date | Mon, 8 Feb 1999 06:50:01 -0500 | From | Tom Sightler <> | Subject | Slow PPP with 2.2.1 |
| |
OK, I'm looking for any help I can get with this problem. I have an old IBM PS/2 Model P70 (the portable version of the Model 70 Microchannel system) that I
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 errors.
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
remained.
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 interrupts proccessing.
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.
Thanks, Tom Sightler
- 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/
| |