Date: Wed, 17 Nov 2004 19:57:27 -0500 From: Chuck Swiger <cswiger@mac.com> To: "Wilkinson, Alex" <alex.wilkinson@dsto.defence.gov.au> Cc: freebsd-current@freebsd.org Subject: Re: serious networking (em) performance (ggate and NFS) problem Message-ID: <419BF377.9090800@mac.com> In-Reply-To: <20041118002741.GC66483@squash.dsto.defence.gov.au> References: <200411172357.47735.Emanuel.Strobl@gmx.net> <419BE654.6020705@mac.com> <20041118002741.GC66483@squash.dsto.defence.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Wilkinson, Alex wrote:
> ping only tests latency *not* throughput. So it is not really a good test.
You can utilize a decent amount of a 100Mbs link via ping:
42-sec# time ping -q -c 10240 -i 0.00001 -s 1004 cube
PING cube.local (192.168.1.6): 1004 data bytes
--- cube.local ping statistics ---
10240 packets transmitted, 10240 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.455/0.793/4.491/0.418 ms
1.48s real 0.05s user 0.60s system 43%
...which works out to about 7MB/s. Hmph. I should have mentioned in my
previous message that that one ought to do something like:
sysctl -w net.inet.icmp.icmplim=10000 # or zero, maybe?
...as well, or else ping will be limited to some ~250 pps. It would be
interesting for Emanuel to try ping -s with a bigger value suitable to fill
jumbo frames.
--
-Chuck
PS: I just tested several varieties of ping until I got a:
ping: sendto: No buffer space available
...so I perhaps I need do some additional tuning, myself. :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?419BF377.9090800>