Ross Harvey wrote:
> Hehe, I just made the existing socket code 20-30% faster simply by patching
> unpst_sendspace and unpst_recvspace in my running kernel with gdb(1),
> setting them equal to the buffer sizes used in your proposal.

On my 386DX, this helped just about 7% in lmbench bw_pipe test :(

I did some more tests using lmbench.

Once I did the tests when booted via 'boot -s' to single user,
the numbers become more consistent (previously, I tested in single user too,
but via shutdown from multiuser).  Don't ask me why :-/

On my PIII/600Mhz, the pipe bandwidth and latency seems to be same
for "old" and "new" code according to lmbench. It's like 34.9us
latency and 487 MB/sec bandwidth.  Seems likely the code speed is
not a factor here, more likely memory access speed is.

I tried on 386DX and values here are more telling - I get consistent values,
NEW_PIPE is faster about 5 times:

old pipe:	latency: ~1800 us, bandwidth: 0.75 MB/sec
NEW_PIPE:	latency: ~1148 us, bandwidth: 3.57 MB/sec
old pipe with unpst_*space bumped to 16KB:
		latency: ~1800 us, bandwidth: 0.80 MB/sec

I also tried to run several (5) instancies
of lmbench/bw_pipe, to get some numbers for paralel pipe pushing.
Again, there was no real difference between "old" and "new" pipes
on the PIII, even when I used more simultaneous bw_pipe processes (tried
7 and 10). The numbers for 386DX are like this:

old pipes(5):	0.15 MB/s
NEW_PIPE(5):	~0.76 MB/s

It would be really interesting to compare numbers on other archs.

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
NetBSD - just plain best OS! -=<>=- Got spare MCA cards or docs? Hand me them!