I have heard this from NetApp technicians and on this list, but The only thing I found on the NetApp web page search was a reference to a switch that would overflow the buffer when translating from gigabit ethernet to fast ethernet. Someone please, point me to the bug description. We have seen the improvement, but we run GigE from client to server. None of the switches show errors or severe packet loss. The server shows packet loss, but how is that decreased by smaller read and write sizes on clients? Our switch software is supposed to be up to date. We see the problem alot and run UDP strictly, so, I need a bug number or a better description of this thing, please.
I'm not complaining, I know you are correct; it does improve performance. It's measurable and significant. When I buy new equipment, I want to pinpoint this and avoid it. When fast ethernet is faster that GigE, something is bad.
From: "Magnus Swenson" magnuss@cadence.com Edward,
Try to disable TCP over NFS and only enable UDP. Also in a switched environment 10/100/1000 BT keep the xfersizes to 8192 this has proven to improve performance (at least for us). This is a known bug on certain switches, it's also listed on now.netapp.com.
Re, Magnus Swenson
Subject: Re: Slow writes
On Fri, Feb 22, 2002 at 08:24:12AM -0800, Jim Harm wrote:
I have heard this from NetApp technicians and on this list, but The only thing I found on the NetApp web page search was a reference to a switch that would overflow the buffer when translating from gigabit ethernet to fast ethernet.
It also happens with just gigabit ethernet. There is on option for GigE flow-control, which helped us and two Catalyst 6509s somewhat. But since that's only point-to-point and not end-to-end flow control, you still get overflows if traffic passes multiple switches.
Someone please, point me to the bug description. We have seen the improvement, but we run GigE from client to server. None of the switches show errors or severe packet loss.
It is sufficient that packets get delayed randomly.
The server shows packet loss, but how is that decreased by smaller read and write sizes on clients?
If you send multiple packets in a row, the server may not have enough CPU time to process each packet. Smaller read and write sizes introduce artificial gaps which are often large enough to allow for processing.
Our switch software is supposed to be up to date. We see the problem alot and run UDP strictly, so,
What about TCP ? In our experience, the end-to-end flow control that you buy with TCP helps a lot.
We have had trouble in the past with TCP. The failover of cluster pairs would hang our Solaris equipment, because they could not pick up the session with the partner. Haven't tested other OSs because only Solaris would mount with default TCP. Haven't tested recently either.
It sounds like the real problem is just that the server is getting overloaded and drops packets requiring retransmission and that overhead is reduced by the retransmission for only 8K blocks instead of retransmission of 32K blocks.
On the flow control; why back off from full flow control when the problem seems to be that flow control is needed?
At 5:57 PM +0100 2/22/02, Michael van Elst wrote:
On Fri, Feb 22, 2002 at 08:24:12AM -0800, Jim Harm wrote:
I have heard this from NetApp technicians and on this list, but The only thing I found on the NetApp web page search was a reference to a switch that would overflow the buffer when translating from gigabit ethernet to fast ethernet.
It also happens with just gigabit ethernet. There is on option for GigE flow-control, which helped us and two Catalyst 6509s somewhat. But since that's only point-to-point and not end-to-end flow control, you still get overflows if traffic passes multiple switches.
Someone please, point me to the bug description. We have seen the improvement, but we run GigE from client to server. None of the switches show errors or severe packet loss.
It is sufficient that packets get delayed randomly.
The server shows packet loss, but how is that decreased by smaller read and write sizes on clients?
If you send multiple packets in a row, the server may not have enough CPU time to process each packet. Smaller read and write sizes introduce artificial gaps which are often large enough to allow for processing.
Our switch software is supposed to be up to date. We see the problem alot and run UDP strictly, so,
What about TCP ? In our experience, the end-to-end flow control that you buy with TCP helps a lot.
-- i.A. Michael van Elst / phone: +49 721 9652 330 Xlink - Network Information Centre / fax: +49 721 9652 349 Emmy-Noether-Strasse 9 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster@xlink.net [ KPNQwest Germany GmbH, Sitz Karlsruhe ] [ Amtsgericht Karlsruhe HRB 8161, Geschaeftsfuehrer: Michael Mueller-Berg ]
On Fri, Feb 22, 2002 at 09:57:05AM -0800, Jim Harm wrote:
We have had trouble in the past with TCP. The failover of cluster pairs would hang our Solaris equipment,
No problem here. We use F840c clusters and E420R Solaris servers running Solaris 8.
On the flow control; why back off from full flow control when the problem seems to be that flow control is needed?
I guess it is the same as with duplex autoconfiguration with FastEthernet, the automatic doesn't always work correctly.
-
Jim Harm -
Michael van Elst