Quite simply a 'netio -s' on one computer, and a 'netio -u
192.168.1.whichever' on the other. I was monitoring with 'vmstat 1'
for hardware stuff and bmon to see the actual speed and had a ssh
open.
The things I've been fiddling with recently to see if it'd make a difference:
- Renicing of ksoftirqc to anything between -5 and -17, I don't
remember exactly.
- Disabling tcp window scaling. I read somewhere that that may help
throughhput, but it may be a stupid move.
- Some barely thought about (I did read the following:
http://lists.samba.org/archive/samba/2003-December/077198.html)
window memory buffer size changes, with a 'so that that at least won't
be a bottleneck' angle:
--------------------
echo 400000 > /proc/sys/net/core/wmem_default
echo 512000 > /proc/sys/net/core/wmem_max
echo 400000 > /proc/sys/net/core/rmem_default
echo 512000 > /proc/sys/net/core/rmem_max
echo 98304 512000 640000 > /proc/sys/net/ipv4/tcp_mem
echo 98304 512000 640000 > /proc/sys/net/ipv4/tcp_wmem
echo 98304 512000 640000 > /proc/sys/net/ipv4/tcp_rmem
echo 98304 512000 640000 > /proc/sys/net/ipv4/tcp_mem
-----------
It seems that windows (in which I have jumbo frames on) doesn' quite
need as many interrupts, although I'm not sure that was for the same
speed, as I had another kernel panic (attached, this one has a small
visible trace). I was running the windows version of netio as a
server, and doing a client test with udp.
--Bart Alewijnse
panic3.gif
Description: GIF image
|
