OK.... I have my test running. I decreased the timeo.noop_out_timeout and interval to 10 (actually raised the interval to 10 and lowered the timeout). /var/log/messages is growing pretty quickly with all of this data. But it should last a few hours.. same is true for the tcpdumps.
I'll keep you in the loop. On Jan 19, 2011, at 3:32 PM, Mike Christie wrote: > On 01/19/2011 01:13 PM, Joe Hoot wrote: >> Ok. A couple of new questions regarding this: >> >> Here are my currently settings: >> >> #node.session.timeo.replacement_timeout = 120 >> node.session.timeo.replacement_timeout = 15 >> node.conn[0].timeo.login_timeout = 15 >> node.conn[0].timeo.logout_timeout = 15 >> node.conn[0].timeo.noop_out_interval = 5 >> node.conn[0].timeo.noop_out_timeout = 15 >> node.session.err_timeo.lu_reset_timeout = 20 >> # To control how many commands the session will queue set >> # node.session.cmds_max to an integer between 2 and 2048 that is also >> # a power of 2. The default is 128. >> node.session.cmds_max = 128 >> # To control the device's queue depth set node.session.queue_depth >> # to a value between 1 and 1024. The default is 32. >> node.session.queue_depth = 32 >> >> QUESTIONS: >> ========== >> >> 1) *noop_out_timeout* - I found that if I raise my noop_out_timeout to 15 >> secs, I'm not seeing nearly as many (actually I haven't seen any timeouts >> for the last hour that I've been testing). Should I previously had this set >> to 10. In the network world, it just seems that 15 seconds is a really >> really long time to actually wait for a noop ping response (I'm relating >> this to ICMP pings, but still...). Is it common for users to set the >> noop_out_timeout this high? >> > > Hey, > > I am sick, so I will try to answer this one now and answer the others > tomorrow (going to go back to sleep now). > > I think 5 secs is actually a longish timeout. Is this problem easy to > replicate and can you do some testing? Could you turn on all debugging? > > If this is a RHEL 5 based kernel then it would be > > echo 1 > /sys/module/libiscsi2/paramters/debug_libiscsi > echo 1 > /sys/module/libiscsi_tcp/paramters/debug_libiscsi_tcp > echo 1 > /sys/module/iscsi_tcp/paramters/iscsi_tcp > > This ends up printing around 5 lines for every IO, so there will be lots of > info in /var/log/messages. So if you have to run a test for hours then this > might be a problem. If you can recreate the problem quickly this would log > info would be helpful so we can see if we are getting responses to other IO > or of maybe there is a complete stall for a while. > > If you can also get tcpdump at the same time it would be helpful so we can > see if the network layer is sending data. Something like > > tcpdump -i $ETHX -w iscsi.out > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
