Concept of average_calculation_time is exceptionally important in FastNetMon as correct bandwidth calculation relies on correct setting of this value.
Internally, FastNetMon uses algorithm called exponential moving average to approximate speed. This algorithm allows us to react on new traffic information way faster in compare with simple average which can provide traffic speed only after getting all the data over period.
With exponential moving average we review all new traffic information every second and re-calculate speed according to this data. This approach allows us to detect DDoS attacks way faster.
The simplest way to explain meaning of this value as time duration over which FastNetMon collects traffic data before calculating speed.
For example you use Netflow or IPFIX protocol and your router has active and inactive flow timeouts set to 30 seconds. Such flow timeouts mean that all information about traffic observed by router right now will reach FastNetMon with delay ranging between 0 and 30 seconds.
Network telemetry data may arrive in single burst (i.e. one large flow occupying all the bandwidth) or as multiple smaller flows distributed over time period of 30 seconds.
The naive approach to calculate bandwidth is to wait 30 seconds and then divide amount of transferred data by 30 seconds and as result we will receive smoothed / approximated bandwidth. That’s exactly why correct keeping of average_calculation_time value in sync with active and inactive flow timeout on router is paramount for getting accurate traffic bandwidth.
By default, average_calculation_time set to 5 seconds which may work fine for sFlow, port mirror protocols only. If you use Netflow or IPFIX you have to adjust this value to match your active and inactive flow timeouts set on router. We recommend setting average_calculation_time slightly little bit bigger then active and inactive flow timeout on router.
Such protocols as sFlow or port mirror do not have any aggregation delay as network devices export traffic information without any significant delay and in this case you may even set average_calculation_time to 1.
What will happen in case of average_calculation_time misconfiguration? You will see bandwidth which is way bigger than actual traffic in your network or way smaller then your actual traffic and bandwidth metrics will be very spiky. As consequence DDoS detection will not work as you expect and real attacks may be missed and you will definitely have false positive alerts.
Misconfiguration of average_calculation_time is one of the main root causes of bandwidth miscalculation and it’s very important to understand how it work to efficiently operate FastNetMon.
If you experience traffic calculation bandwidth issues and all configuration options are correct please check this guide.