Network rate incorrect, depended on refresh interval.

[MarekKnapek]

Brief description of your issue

Network total rate column in process list and total rate in column in network list says network rate, but in reality they display bytes in interval, not rate. This is no problem in case of one second refresh interval. But it is problem in case of other refresh intervals.

Steps to reproduce (optional)

• Start some network process, that has constant amount of network traffic. Such as RDP session, or internet radio, or some kind of video streaming, or Total Commander copy operation between two computers over SMB or FTP with bandwidth limiter enabled.
• Start System Informer.
• In process list, add the network total rate column.
• Observe the network rate of your app.
• In network list, add total rate column.
• Observe the network rate of your app.
• The two numbers agree with each other.
• All this happened with the default one second refresh interval.
• Now change the refresh interval to two seconds, or ten seconds.

Expected behavior (optional)

The network rate of your application is the same, regardless of refresh interval. If it was 1 MB/s it is still 1 MB/s.

Actual behavior (optional)

The network rate of your application is now 2x or 10x times the reality. If it was 1 MB/s before, it is 2 MB/s or 10 MB/s now. That is a bug. The program says rate, but displays data amount since last refresh instead. Resource Monitor (perfmon.exe) confirms that the application under test actually did not change amount of data transferred as reaction to changing refresh interval in System Informer.

Environment (optional)

System Informer Version: 3.0.7310 (bc98048)
Windows Server 2022, x64, 10.0.20348.2031.

[MarekKnapek]

OK, there is big miscommunication. Process Hacker displays "rate" and "MB/s", this is different form "data in interval" or "data since last update" and "MB". In your car example with 1s refresh interval: There are there are 20 m per refresh interval and there are 20 m since last update and there are 20 m per second being travelled, this is where we agree with each other. In case of 2s refresh interval: There are now 40 m per refresh interval, or 40 m since last update being travelled, yes, this is correct. But there are still 20 m per second travelled no matter the refresh interval. The word "per" in English means "to divide by". So 40 meters travelled per 2 seconds means speed (or rate) of 20 m/s, it still means 40 m since last update.

when it does finally update you've uploaded 20MB not 10 and showing 20 is correct.

10 or 20 or what? Units matters! Showing 20 MB downloaded since last update is indeed correct. Showing 20 MB downloaded per refresh interval is indeed correct. Showing 20 MB/s downloaded is incorrect, this is where we don't understand each other.

The vehicle is going 5M during the first second and 15M during the next second but you've configured 2 second interval? and we're showing 40M which is correct?

By my math 5 m + 15 m is equal to 20 m. Where does the 40 m value comes from? Correct is to show 20 m since last update, or 20 m per update interval, or 10 m/s.

I expected this is exactly what the "bytes in interval" and "bytes per second" columns are for. This is what I suggested to be added back in 2011 at http://processhacker.sourceforge.net/forums/viewtopic.php?f=14&t=346 and now when I'm developing a network application, I noticed it is broken.

Marek

[MarekKnapek]

Added by commit number c25ae6a 12 years ago.

[jxy-s]

I think you both are right here. There is an improvement we can make to ExtendedTools.

Before I go further. I need to remind us this fact - In most circumstances System Informer is an external observer to activity on the system. We are not inline nor are we probing specific activity to take a measurement. And as with most things in computation there are tradeoffs between the accuracy and performance.

Calculation of any rate can be estimated independent of the period between measurements. And as the period of measurement approaches infinity, your calculation becomes more accurate (you might know this as the derivative). To perform this calculation you need two things. The difference in measured information and the difference in time between those measurements. With these two things you can adjust to represent the rate of change in terms of any related period unit (in this case time, milliseconds to seconds). This approach is taken all over computation, you might be familiar thinking of this in terms of game engines where activity is updated each "game tick" but must account for "delta time" in their computation.

The commit you linked (c25ae6a) does this. As does the code on master. It could be improved as it assumes the update interval is the period, which may not always be the case. In reality I think we should be capturing the delta time instead of relying on the configured update interval. This would give us a more accurate estimation. We already do this in the main binary for many of the other calculations. Said practically, this rate will be inaccurate if you manually refresh (e.g. using F5) outside of the update interval.

[dmex]

Fixed in latest canary build

[MarekKnapek]

Not fixed yet. Version System Informer 3.2.25045.1011 (8a2756fe) Canary. Steps to reproduce: Add network total rate column to the main Processes tab. Have refresh interval set to 1 s. Listen to internet radio. Observe that the player's rate is oscillating between 2 - 5 kB/s. Change refresh interval to 10 s. Observe that the player's rate is 43 kB/s. This is wrong. In reality the network transfer rate (number of bytes transferred per second) did not change at all. What changed is number of bytes transferred per refresh interval (43 kB per 10 s), but the rate is still 4.3 kB per 1 s, just as before refresh interval change.