On Mon, 26 Aug 1996, Philippe Troin wrote: > Test I was done on a 2.0.14 kernel with a 100kb nul file (dd > if=/dev/zero...) > Test II was done on a 2.0.14 kernel with irqtune and a 100kb nul file. > Test III was done on a 2.0.15 kernel with a 100kb nul file. > Test IV was done on a 2.0.15 kernel with irqtune and a 100kb nul file. > Test V was done on a 2.0.15 kernel with a 100kb random file. > Test VI was done on a 2.0.15 kernel with irqtune and a 100kb random > file.
> I II III IV V VI > Count Time Rate Time Rate Time Rate Time Rate Time Rate Time Rate > ---------------------------------------------------------------------- > Avg. 59.17 1.7 36.66 2.7 58.53 1.7 34.60 2.9 57.09 1.7 26.93 3.7 > Dev. 10.32 5.18 9.15 6.31 11.58 0.05 > > The figures are quite clear. Irqtune really improves my serial > performances, even with kernel 2.0.15 (see previous messages, 2.0.15 > included a patch which might have helped serial performance). > What I don't understand is why a file consisting of zeros only do not > get the same transfer rate as a random file. If I understand your data, you're saying you get a much faster transfer rate with the random file over the all-zeros file, right? This is very bizarre. The random file and a file consisting of all zeros should *not* get the same transfer rate on any modern modem which does hardware compression (most do). The all zeros file should get a much faster transfer rate than the random file. The reason is that it is not possible to compress a random file so the best transfer rate possible would be the line speed (28.8 kbs for a 28.8 modem). A file of all zeros is easily compressible so you should do much better (theoretically 115200 kbs for a 28.8 modem which does hardware compression but in practice probably much less). Are you sure your numbers are right? If so, perhaps you're still getting overruns even with irqtune, but now much less. But the all-zeros file is getting transferred so fast (because of the compression) that it is seeing many more overruns than the random file and correcting the overruns is slower than just transferring the file at the slower rate that the random file is being transfered at. > I suspect an obscure PPP problem. I suspect you're right. Have you set up PPP to use hardware flow control? Have you enabled hardware flow control with your modem init string (it may be the default anyway)? Are you setting the port speed to 115200? Another possibility is that your 16550A UART is not what it claims to be. With a non-buffered (8250) UART, I've seen this kind of behavior of faster transfers actually becoming slower because of the overruns. I suspect that irqtune would have much more of an impact on that type of UART as well. You might want to try using a communications program like minicom and see what kind of transfer rates you get there. This might help isolate whether it's really a serial problem or a PPP problem. Gerry
