[erlang-patches] SNMP erlNodeReductions defined too narrow

[Björn-Egil Dahlberg]

On 2013-07-16 12:23, Tobias Schlager wrote:
> 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
Thank you. I've fetched this branch and replaced the previous one in pu. 
It is cooking.

I've also reassigned it to the protocol team for review. This might take 
some time since most otp people are on vacation.

Thank you! Regards,
Björn-Egil

>
> 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.
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
>
>