On 7 Dec 2009 at 11:20, Mike Christie wrote: > 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
No, I mean if the network is dead (#1), sending nop's doesn't help. If the target is dead (#2), TCP will time out anyway. I'm unsure about #3: You want to check a guaranteed round-trip time (which is the nop timeout). But what can you really do if the nop times out? You can notice that the network doesn't guarante your expectations. Re-establishing a connection won't make the network faster, I'm afraid. But can't you get that (timestamps) piggy- backed on TCP anyway? > 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 > nop/ping? I basically meant this: If the network "fills", the TCP sending window will shrink, and if the network is doing well, the window will widen (that's the overload control). If the receiver is not ready to accept data, the window size will be zero (that's flow control). Now if the network is "tight", sending a NOP over the same TCP connection may not have the desired effect. So NOPs just answer the question "are you still alive over there?", but it does not answer the question "how fast are you" in all the cases. Maybe on a switched LAN things are all different from what I describe... Regards, Ulrich -- 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 open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
