mds@gbnet.net (mark) writes:
What I'm thinking of is that AFAICR tcp_xmit_hiwat and tcp_recv_hiwat are set to 8192 (bytes) and the equivalent *lowat's to 2048. This is
We're using this on our 2x400 MHz E450's and we see ~60MB/s using switched gigabit.
ndd -set /dev/ge adv_1000fdx_cap 1 ndd -set /dev/ge adv_1000hdx_cap 0 ndd -set /dev/ge adv_1000autoneg_cap 0 ndd -set /dev/ge adv_pauseTX 0 ndd -set /dev/ge adv_pauseRX 0 ndd -set /dev/tcp tcp_recv_hiwat 262144 ndd -set /dev/tcp tcp_xmit_hiwat 262144 ndd -set /dev/tcp tcp_xmit_lowat 2048 ndd -set /dev/tcp tcp_wscale_always 1 ndd -set /dev/tcp tcp_tstamp_always 1 ndd -set /dev/tcp tcp_rexmit_interval_max 60000
Note these are dedicated backup servers, so the very high tcp_X_hiwait may not be appropriate if you're not doing lots of bulk data transfer.
The tcp_tstamp_always is a big win.
Darrell
On 5 Jan 2000, Darrell Fuhriman wrote:
ndd -set /dev/tcp tcp_wscale_always 1 ndd -set /dev/tcp tcp_tstamp_always 1
Ah, interesting... I never considered whether DOT's stack supported the RFC1323 TCP extensions, but that might be part of the reason why my FreeBSD desktop (which turns on 1323 and 1644 by default) always seems to outrun much more expensive Sparc servers for network throughput, and with a lower CPU hit.
Do you find that with 2 x 400-MHz CPU's that you have enough cycles to stream 600 Mbps off the gigabit ethernet and sustain high throughput to your tape drives?
-
Brian Tao -
Darrell Fuhriman -
tkaczma＠gryf.net