Re: Irqtune: some stats (was Fix for your serial/PPP problems)
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
Reply to: