[erlang-patches] SNMP erlNodeReductions defined too narrow

[Tobias Schlager]

Hi,

I've created a new patch. Since I wanted to give the branch a more describtive name, the previous branch 'snmp_fix_node_reduction_type' can be dropped. After looking into the snmp and os_mon application it seems to me that the otp_mibs application is the only application facing this kind of overflow problems. The os_mon application does already handle large values nicely, e.g. by masking memory-related values to the desired 32bit type ranges.

This patch updates all applicable MIB objects of the OTP-MIB to 64bit based types. This affects the objects erlNodeReductions, erlNodeInBytes, erlNodeOutBytes as well as the MilliSeconds based objects erlNodeRunTime and erlNodeWallClock. Additionally, the patch checks and trims the values before inserting them into the node's shadow table. I've chosen to 'reset' (modulo operation) counter based values and simply limit other integer based values. The patch does also remove trailing whitespace from the edited files and fixes some date-related warnings in the MIB files (returned by 'smilint').

git fetch https://github.com/schlagert/otp.git otp_mibs_fix_type_overflows

https://github.com/schlagert/otp/compare/erlang:maint...otp_mibs_fix_type_overflows
https://github.com/schlagert/otp/compare/erlang:maint...otp_mibs_fix_type_overflows.patch

Regards
Tobias

________________________________________
Von: Stefan Zegenhagen [stefan.zegenhagen@REDACTED]
Gesendet: Montag, 15. Juli 2013 16:47
An: Tobias Schlager
Cc: erlang-patches@REDACTED
Betreff: Re: AW: [erlang-patches] SNMP erlNodeReductions defined too narrow

Hi Tobias,

> However, I think extending this and probably some other values to a
> wider type is actually a good thing because providing a value that
> typically overflows within a few hours is quite meaningless. I would
> like to make another patch that actually fixes the problem but I'm not
> sure what the desired behaviour would be for a counter. Should it
> always reflect the highest valid value when overflowing or should it
> start over?

I only know this for network counters. Here the desired behaviour is
that the counter starts again from zero. If someone wants to get
accurate numbers from the device, he has to poll those counters in
regular intervals to detect overflows. The minimum time (in which the
counter can overflow) can easily be calculated from the link speed
(10/100/1000 MBit) here.

This behaviour sounds reasonable for other counters as well, especially
when there's no counter-reset MIB object.

Kind regards,

--
Dr. Stefan Zegenhagen

arcutronix GmbH
Garbsener Landstr. 10
30419 Hannover
Germany

Tel:   +49 511 277-2734
Fax:   +49 511 277-2709
Email: stefan.zegenhagen@REDACTED
Web:   www.arcutronix.com

*Synchronize the Ethernet*

General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer -
Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht
Hannover; Ust-Id: DE257551767.

Please consider the environment before printing this message.