Bug #43543 for Net-SNMP: Could TIMEOUT_MINIMUM be less than 1.0s?

Mon Feb 23 12:46:29 2009 andy [...] nowwireless.com - Ticket created

Subject:	Could TIMEOUT_MINIMUM be less than 1.0s?
Date:	Mon, 23 Feb 2009 17:46:09 +0000
To:	bug-net-snmp [...] rt.cpan.org
From:	Andy Buchanan <andy [...] nowwireless.com>

Message body is not shown because sender requested not to inline it.

Dear Net::SNMP maintainers, Thank you for your very useful module. I am using it via POE::Component::SNMP. I am just wondering why there is a minimum limit of 1.0s on the timeout in Net::SNMP::Transport. I have a program which is sending a SNMP request once every second, and when the device is unreachable, and a timeout is occuring, the overheads in POE are causing a time-leak which makes the responses come back later and later (about 2ms in each second). I was contemplating writing a workaround using additional alarms, but thought I would look through the Net::SNMP code and see if this problem could be fixed at source. I made the following change and it seems to have resolved my problem: ### Net/SNMP/Transport.pm.patch ### 80c80 < sub TIMEOUT_MINIMUM() { 1.0 } --- Show quoted text

> sub TIMEOUT_MINIMUM() { 0.1 }

Would you consider implementing this patch in the main distribution? There doesn't seem to be any issue with it and it seems to work as expected, with sub-second timeouts happening fine. I have attached my test code. Regards, -- Andy Buchanan

Wed Aug 26 11:08:32 2009 dtown [...] cpan.org - Correspondence added 10 min

Andy, I would be hesitant to lower the minimum timeout value. The module schedules an error handler to cancel the request using that value. A sub-second timeout does not seem reasonable if you start to include network latency. I am not familiar with POE or the details of the adaption of Net::SNMP. The POE::Component::SNMP documentation does seem to indicate there might be issues with timeouts: "Multiple requests to a particular instance are processed in FIFO order, including retries (-retries defaults to 1). This means that if you have multiple pending responses, and one automatically attempts retry for whatever reason, the retry request will "go to the end of the line" behind any other pending requests." Have you contacted the author of POE::Component::SNMP with this issue of a "time-leak"? -David On Mon Feb 23 12:46:29 2009, andy@nowwireless.com wrote: Show quoted text

> Dear Net::SNMP maintainers, > > Thank you for your very useful module. I am using it via > POE::Component::SNMP. > > I am just wondering why there is a minimum limit of 1.0s on the timeout in > Net::SNMP::Transport. I have a program which is sending a SNMP request

once Show quoted text

> every second, and when the device is unreachable, and a timeout is

occuring, Show quoted text

> the overheads in POE are causing a time-leak which makes the responses

come Show quoted text

> back later and later (about 2ms in each second). > > I was contemplating writing a workaround using additional alarms, but > thought I would look through the Net::SNMP code and see if this problem > could be fixed at source. I made the following change and it seems to have > resolved my problem: > > ### Net/SNMP/Transport.pm.patch ### > 80c80 > < sub TIMEOUT_MINIMUM() { 1.0 } > ---

> > sub TIMEOUT_MINIMUM() { 0.1 }

> > Would you consider implementing this patch in the main distribution? There > doesn't seem to be any issue with it and it seems to work as expected,

with Show quoted text

> sub-second timeouts happening fine. I have attached my test code. > > Regards, >

Wed Aug 26 11:08:34 2009 The RT System itself - Status changed from 'new' to 'open'

Wed Aug 26 11:08:35 2009 dtown [...] cpan.org - Status changed from 'open' to 'stalled'

Wed Aug 26 11:08:39 2009 dtown [...] cpan.org - Given to DTOWN

Mon Aug 31 16:25:26 2009 dtown [...] cpan.org - Correspondence added 2 min

The default value of 1.0 second for TIMEOUT_MINIMUM is reasonable. This value will not be changed.

Mon Aug 31 16:25:27 2009 The RT System itself - Status changed from 'stalled' to 'open'

Mon Aug 31 16:25:28 2009 dtown [...] cpan.org - Status changed from 'open' to 'rejected'