El 02/11/09 19:43, James A. T. Rice escribió:

Dear James,

> That looks vaguely familiar, although I think mine was nop-out timeout
> (might be reported in another log file). Does it mostly happen when you do
> long sequential reads from the Infortrend unit? In my case it turned out
> to be a very low level of packet drops being caused by a cisco 2960G when
> 'mls qos' was enabled (which due to an IOS bug, didn't increment the drop
> counter). I'm not sure if the loss when 'mls qos' is enabled is by design
> as part of WRED, or a function of the port buffers being divided up into
> things smaller than optimal.
> Having TCP window scaling enabled made the problem an order of magnitude
> worse, try disabling it and seeing if you have the same problem still?
> (suggest something like dd if=/dev/sdc of=/dev/null bs=1048576 count=10 to
> see if that triggers it, assuming it was the same problem I was
> suffering).
> Every other iSCSI target I've tried recovered pretty gracefully from this,
> but not the Infortrend, I suspect their TCP retransmit algorithm needs a
> lot of love. I suspect it's pathologically broken when window scaling is
> enabled.

Disabling TCP window scaling [1] on Linux solves nop-out problem, we 
don't get more "iscsi: detected conn error" and performance improves :)

It's very strange, we have 3 Cisco 2960G in the SAN and this behavior 
only occurs in two of them, we're looking in depth this problem.

Nop-out has been solved but we still have a lot of "duplicate ACKs" in 
all machines. I will update this post with more info. James, thanks a 
lot of for the help.


[1] # echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

Santi Saez

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to