Suggestion: Smaller graph sampling period and lower startup priority

Hi!

1/ Could you implement an option in a future update of the Networx software that allows users to modify the sampling period of real-time internet traffic in the graph? I love very short sampling... as 0.25s or 0.5s for example.

2/ Could you also optimize the impact of networx.exe on Windows startup and make it as low as possible? Currently its impact is high instead of being medium or low (my CPU is a Ryzen 9 3900X...), even if I don't choose to display the graph at startup.

Thank you for your answer! Your software is really great!!

Thank you for your feedback.

The current design of the network monitor is based on a 1-second sampling rate, where the number of bytes sent and received is measured over that second, and the bandwidth usage is displayed in Mbps. The graph then updates with a new data point (line) every second, representing the bandwidth for that entire second.

If we were to introduce a 0.5s or 0.25s sampling rate, several issues arise:

• The current graph updates every second with a single data point representing the average Mbps over that second.
  If we sample at 0.5s or 0.25s intervals, the graph would need to either update more frequently (which it isn't designed to do) or average multiple smaller intervals into a single second, potentially leading to confusing or misleading representations of the data.
• The graph is designed to show one line per second.
  To accommodate 0.5s or 0.25s sampling, the graph would need to change its update rate to reflect these smaller intervals. This would either make the graph too cluttered (if updated twice or four times per second) or require averaging the smaller intervals, which defeats the purpose of finer sampling.
• Mbps (Megabits per second) inherently assumes a full second for the rate calculation.
  Sampling at 0.5s or 0.25s and then converting to Mbps could cause confusion, as the calculated value would represent a much shorter time period, making the Mbps less intuitive and possibly inaccurate.

Given these factors, the current 1-second sampling rate is optimal for accurate and clear representation of the bandwidth usage in Mbps, and for maintaining the clarity of the graph. Adjusting the sampling rate to 0.5s or 0.25s would compromise the accuracy and readability of the data.

Regarding the second issue, it's a good point. We've made adjustments to the app to reduce its thread priority to a low value, which should lower the startup impact to medium or low. Please download and try the new build. However, as we are not certain how frequently Windows updates the startup impact rating, it may take some time before you see the improvement.

Thank you for your extremely quick response and the solutions you provided. I have clearly understood the rational aspect of the points you raised in 1/, 2/ and 3/, namely that if we were to modify the sampling period on the abscissa axis, we should normally and logically modify the unit of measurement on the ordinate axis (Mbits or MBytes) so that the sampling becomes consistent.

One of the reasons I'm asking this question is that visualizing traffic as a graph in real-time with a particularly short sampling period (and with appropriate colors as Networx offers) helps to fight against malware and other PUPs whose goal is to leak user confidential data to the outside world at a frantic pace. Without a short sampling period, the damage can be more severe.

Thank you anyway for the involvement of your developers in your application.

We understand your concern about the importance of a short sampling period for real-time traffic monitoring, especially in situations where quick action is needed.

Perhaps what you are noticing is that NetWorx uses 5-second averaging by default, which might make it seem like there's no immediate reaction.

There are two hidden settings in NetWorx that can help make the graph and upload/download readings more responsive: Smooth Graph and Mean Samples.

To achieve a more immediate reaction, you can set Smooth Graph to False, and Mean Samples to 0.

You're a genius, I didn't know these hidden parameters!

By using polygons in my kind of graph, it fully runs each 1 second, and the sampling is displayed each 1 second with your parameters. In the same time, it runs when I don't modify the parameters, the sampling is also displayed each 1 second.
The problem comes from when the sampling and the graph are displayed with columns and bars. With this kind of graphics display, it runs when I don't modify the hidden parameters (and it's displayed each 5 seconds); and it doesn't run when I apply the hidden parameters when columns and bars are recognized by the system.

I prefer the sampling represented and displayed by columns and bars graphics, it's more visual to prevent the user from a malware threat. With an only polygon kind of graphics, the representation of the sampling is more accurate by using pixels, but it's not as fully visual as a squared area like columns and bars graphics parameters.

The reason the 'Columns' (bars) graph type doesn't work for you now is because when you change the Mean samples parameter to 0 or 1, there is no more averaging, so the columns can't be shown. This type of graph always uses averaging, by design.

If you'd like to have thicker bars visually moving at a faster rate so that any unexpected usage spikes can be easily seen, we've just added a new hidden setting that allows you to control it. It's called Graph line step and can be set to any number between 1 and 10.

Roughly speaking, it's the size of each logical bar in pixels, so if you set it to a higher number, and choose 'Histogram' as your graph type, you will see a shorter time period on the graph, but with thicker lines.

Please download the new build, set your graph to 'Histogram' and change 'Graph line step' in the hidden settings. This also affects 'Polyline' and 'Columns', so feel free to experiment with it.

I downloaded the last version of the app. Histogram is perfect, polygons also perfect (because I can see the sampling every 1 second). Columns are bad like the last version of the app (because we see the sampling every 5 seconds, not every one second like histogram or polygons, this is the reason why columns are bad in sampling rate). A good point for columns: when I set the "Graph line step" to 1, it's more beautiful than when I set the parameter to 10. Graph line step to 1 is the best settings for the appearance of the graph.

Also, I checked the impact of the app on Windows startup. It's "high" like the last version, and not medium or low as I would want to have for my startup computer.

What I would like for columns graph, the first thing and the most important, is the same rate sampling as histogram and polygons graphs (1s). Now, with these settings on the new app, I'm using the histogram graph instead of columns graph. In a view to keep columns graph, I want the columns graph more reactive and more reactive in the sampling rate like histogram or polygons graph.

The big bars in notification area of my taskbar at the right of the graph is needed for me to see how reactive the system is, not because it's more beautiful, but because I see most quickly how the system runs with the data transferred to outside (uploaded data). Because the big bars get 1s reaction like histogram graph or polygons graph sampling rate.

The "high impact" designation from Windows likely doesn't measure or update that metric frequently. As Microsoft explains, "high impact" simply means the app uses more than 1 second of CPU time or more than 3 MB of disk space at startup. This designation doesn't necessarily indicate any system slowdown or performance penalty.

We are glad to hear that the histogram and polyline graphs are perfect.

The column chart is designed to show averaged values over N seconds, which is intended for users who prefer fewer animations and are okay with the chart being N seconds behind real-time. It won't function correctly if you have 0 or 1 samples, because with 0 or 1 samples there would simply be nothing to average. It needs a minimum of 2.

If you want a real-time chart that resembles columns, we recommend using the Histogram mode and setting the graph line step to 10 or so. This will result in a histogram with ticks that are roughly (depending on your display PPI) 10 pixels wide, which should give it a bar chart appearance: