Corubba Smith <corubba@xxxxxx> wrote: > In polling mode during normal operation, as well as in event mode with > hashtable when an overrun occurs, the hashtable is fully re-synced > against conntrack. When removing flows from the hashtable that are no > longer in conntrack, there is no way to get the actual end timestamp of > the flow from conntrack because it is already gone. Since the last > conntrack data in the hashtable for these flows will never contain an > end timestamp in this case, set_timestamp_from_ct() will always fall > back to using the current time, aka when the plugin determines that the > flow disappeared from conntrack. That is only an approximation, but > should be good enough; and certainly more accurate than no end timestamp > at all. Makes sense to me, I'll apply it later today unless there are objections.
