Does anyone have ballpark numbers to share w/ single-thread nfs performance? Going from a 4500 running solaris 2.8 to a 760 and I'm capping out around 22mbit/s for single copies -- this hold pretty consistent w/ tcp and udp mounts (both w/ rsize=32768). This is across a WAN, but RTT is only ~16ms. Running multiple parallel copies will bump throughput to ~80mb/s.. Is this about right, or are there magic knobs I'm missing?
Thanks.
On Fri, Oct 31, 2003 at 05:06:11PM -0800, atticus@satanic.org wrote:
Does anyone have ballpark numbers to share w/ single-thread nfs performance? Going from a 4500 running solaris 2.8 to a 760 and I'm capping out around 22mbit/s for single copies -- this hold pretty consistent w/ tcp and udp mounts (both w/ rsize=32768). This is across a WAN, but RTT is only ~16ms. Running multiple parallel copies will bump throughput to ~80mb/s.. Is this about right, or are there magic knobs I'm missing?
32768 bytes / 16ms ~ 16Mbit/s. So that's about what you can expect.
Greetings,
Is this about right, or are there magic knobs I'm missing?
32768 bytes / 16ms ~ 16Mbit/s. So that's about what you can expect.
Good point, hadn't occured to me that NFS's behavior would still restrict BW*delay product for UDP. Does anyone have pointers on large windows over NFS?
Though the filer would appear to do wscale'ing on snapmirror connections, its not for NFS. Also seems that NFS stack on the Solaris side ignores tcp_*_hiwat and decides on a 32k window on its own. Can't find any information to this effect on NOW, but hoping someone who's delved into this has insight to share..
thanks.
On Mon, Nov 03, 2003 at 12:50:21PM -0800, atticus@satanic.org wrote:
Though the filer would appear to do wscale'ing on snapmirror connections, its not for NFS.
That is different. I had snapmirror transfers running at more than 20MByte/s (160Mbit/s) over a local GigE and at ~100Mbit/s over a WAN tunnel (the tunnel routers had only FastEthernet connections, so it might have been faster).
Greetings,
-
atticus＠satanic.org -
Michael van Elst