[erlang-patches] SNMP erlNodeReductions defined too narrow

[Björn-Egil Dahlberg]

First off, big thanks for the test suite! =)

I'm far from a snmp and mib expert but i guess it could be an issue with 
type changes in the mib?

The patch has been reviewed and approved but I'm putting this on the R17 
track, the next major release, because of potential incompatibilities.
I'm letting it cook in r17-branch, unless tests start failing it will be 
merged.

// Björn-Egil

On 2013-07-16 15:19, Björn-Egil Dahlberg wrote:
> 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
>>
>>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
>
>