Traffic Sensor Reporting way off (like %40)

Dear AndrewG

If you have a 32 bit counter, it is advised to use smaller intervals to avoid having multiple overflows in a single scanning interval.

The traffic bandwidth is computed as volume over time. Reports can use longer interval than the raw data. If you use longer intervals, the lower bandwidth is correct. If you have 1000 Mbit/s for a minute and then nine minutes no traffic, the average traffic for a 10 minute interval is 100 Mbit/s.

Thanks Arne,

This was really what I was heading towards. Can PRTG check its a 32 bit counter, and check the speed of the interface. Based on those 2 numbers "force" a scan interval.

For example, the 32 bit counter is used to store OCTETS (that's BYTES not bits), that is a limit of 4 billion, the link runs at 1Gbits/s. That is 125MBytes/s.

So, 4 Billion divided by 125 Million is 32. in short, that's 32 seconds I can go without an overflow happening.

In short, PRTG should not allow a 1Gbit/s link to be scanned at an interval bigger than 32 seconds. This means that PRTG could be reporting massively incorrect numbers.

Another solution would be to allow an interval of what ever, but have the scan check the value, wait 30 seconds (based on my example), and check again, this would guarantee never to pass an overflow point.

Anyway, i hope this can be taken both as a suggestion for Paessler, and advise to fellow PRTG users.

Dear AndrewG

Using 30 second intervals fills the harddrive fast. We want to give the user the flexibility, for example if they know that they only have moderate traffic, to use longer intervals.

The SNMP options in PRTG allow overflow handling which can correct for one overflow per interval. Sadly, the Windows SNMP implementation does not offer 64 bit counters.