Re: Irqtune: some stats (was Fix for your serial/PPP problems)
On Mon, 26 Aug 1996, Gerry Jensen wrote:
> 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).
Just at a guess (and I don't know ppp internals that well), it
might be PPP escaping the zero as a control character. If the
software had to handle the escape sequence for "N thousand"
nulls, it might bog it down a bit, and those escape sequences
might themselves take up more space, as they often do. Really,
though, I can't see that accounting for the difference on a
modem that does compression. The compression should be more of
a factor than escaping every character even, assuming it IS a
compressed link.
I don't know if PPP even escapes nulls.
(clip)
>
> Gerry
__kmb203@psu.edu_______________Debian/GNU__1.1___Linux__2.0.14___
... although "AI" research had centered on the idea of creating
thousands of lines of LISP code which would then somehow become
intelligent ... meanwhile in the darkness, the "EMACS" grew and
grew, unrecognized even by the AI community, fifty, one hundred
times the size of other text editors. In retrospect the general
lack of suspicion is [perhaps] the most convincing proof ....
-- "Why they didn't see it coming", New Brittanica 2136
Reply to: