Right now, I am running a backup job over the network, its running at 1000Kbits/s - The full speed of the switch.

The switch confirms the speed, the backup program confirms the speed, and the increasing file size confirms the speed. All report the network is running at 1000Mbits/s

But PRTG (Traffic Sensor) says 400Mbit, and I sort of know why...

This type of behaviour only happens with scans at the interval of 60 seconds. If I change it down to 30 seconds then it starts to report 1000Mbits/s. If I use "Scan Now" over and over again, it reports correct too.

If I set the Interval down to 5 minutes, then it says its running about 100Mbits/s

The switch in question is a D-Link DGS-1224, but it may happen with other switches.

This is either a bug, or incompatibility. Sure it has its work around, but still hard to spot. My guess is some limit on the 32bit counter used on the switch, but maybe PRTG can detect this and advise to set the interval down so it does not misread this? False data is 100 times worse than no data at all. Happy to discuss.

Anyway, Hope this helps other people, and hope it can be investigated also.

Article Comments

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.


Mar, 2017 - Permalink

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.


Mar, 2017 - Permalink

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.


Mar, 2017 - Permalink