* Add Gigawords to radius packets where applicable.
IMPORTANT NOTE: The ioctl() only supports 32-bit counters. In order t
obtain 64-bit counters, these are now pulled in from sysfs (it's assumed
to be mounted on /sys which I'm assuming is standard).
It is unknown whether sysfs will be available everywhere, as such, keep
the ioctl() method in place, but attempt to detect wrap-overs.
If the sysfs mechanism fails, fail back to the ioctl().
Given maximum data rates, the intervals between calling this needs to be
such that no more than 4GB (2^32) bytes are sent or received in any
given interval. Mostly important for radius plugin where data
accounting may be in effect.
Towards this, a timer interval on 25 seconds is set to force a ioctl()
poll irrespective of the rate of stats update calls. This may be
important for especially radius that needs to provide interim-update
intervals, if the interim updates is too long and the counters could
wrap-over twice in a single interval. At 25 seconds we should detect
all wraps up to an effective data rate of 1.37Gbps, which for my
purposes is adequate.
Possible downsides, 4 files are opened, read and closed every time
statistics is requested. This results in 12 system calls every single
time statistics is required, compared to 1 for the ioctl. Efficiency is
unknown, but as a rule of thumb fewer system calls are better, this is
however not a critical path in my opinion, so should not be a problem.
If required I can run a few benchmarks using gettimeofday() to measure
actual impact.
Signed-off-by: Jaco Kroon <jaco@uls.co.za>
* Use netlink if possible to obtain 64-bit stats.
This uses two system calls per round.
This should be preferred where available. It seems the RTM_GETSTATS was
only added from 2016 some point (4.7.0 as per pali), which is in my
opinion old, but given experience with certain embedded systems does
need to be supported.
projects / ppp.git / commit