vergoh / vnstat

vnStat - a network traffic monitor for Linux and BSD

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Strange estimations

kroese opened this issue · comments

I don't understand how the estimations are calculated, see for example this:

enp0s3 since 2022-06-17

          rx:  5.63 GiB      tx:  5.46 GiB      total:  11.08 GiB

   monthly
                     rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
       2022-06      5.63 GiB |    5.46 GiB |   11.08 GiB |   66.99 kbit/s
     ------------------------+-------------+-------------+---------------
     estimated     10.26 GiB |    9.95 GiB |   20.21 GiB |

   daily
                     rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
         today      5.63 GiB |    5.46 GiB |   11.08 GiB |    2.46 Mbit/s
     ------------------------+-------------+-------------+---------------
     estimated     12.56 GiB |   12.18 GiB |   24.74 GiB |

It estimates the daily amount higher than the monthly one?

The estimate is essentially telling you how much traffic you'd end up having seen in the given time period if the rest of the remaining period would still continue at the same average rate as currently seen. As your average rate for the current month is much lower than the average rate for the current day, it's sometime possible for the daily estimate to show a higher estimate for the day than for the month. If you'd then keep up with the current daily rate for the rest of the month, the estimate for the monthly date would eventually catch up or possibly even overshoot if you'd then suddenly stop transferring data for the rest of the month.

Estimates are intentionally left out for hourly and 5 minute time periods since those have often far more variance in the average rate and such estimates would likely just be confusing instead of being useful.

Yes, but how can my average rate for the month be lower than for the day? This is after starting from a clean database.

The implementation (at least in the current versions) isn't aware of when the time period really started and is always assuming it's the first possible second of that time period. As a result, the estimate for June in your case is likely to be lower than it should since the traffic for the beginning of the month hasn't been seen.

Okay, that makes sense.

Let's keep this issue open since there are clearly things that could be improved and the data for doing that already exists. For the "daily" time period this issue is likely to go rather often unnoticed, it's more likely to get noticed for "monthly" and it's visible far too long for "yearly" (-y) depending on when the monitoring was started.

Wow, great work!