Ulrich Windl wrote:
> On 1 Dec 2009 at 14:57, Erez Zilber wrote:
>> Maintain a list of nop-out PDUs that almost timed out.
>> With this information, you can understand and debug the
>> whole system: you can check your target and see what caused
>> it to be so slow on that specific time, you can see if your
>> network was very busy during that time etc.
> Hi!
> Having studied TCP overload protection and flow control mechanisms recently, 
> I 
> wondered if a look at the TCP window sizes could be a indicator equivalent to 
> timed-out nops. My idea is: Why implement something, if it's possibly already 
> there for free.

The problem with the nop timeout code is that it detects:

1 If the target is not reachable because something wrong is in the network.
2 If the target is dead.
3 If the network layer is not sending/receiving data fast enough (within 
the nop timeout).

#3 is a problem because we do not know if it is not sending/receiving 
data quickly because of #1 or #2 or just because we are trying to 
process more data than the network can handle within the nop timeout value.

Do you thing we should we be trying to send iscsi pdus with data 
segments that are smaller than the window size or some other value or 
something like that?  Or is there a way to get the time it is taking for 
tcp packets, and could we use that to automatically determine the nop 
value? Should we just send a network ping and forget doing the iscsi 


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

Reply via email to