The daemon has the disadvantage of static configuration of all interfaces. This isn’t an information leak. It is a bug in the device driver of that NIC and therefore I don’t think that the solution is to play around with vnstat. The solution is to fix that driver. -Michael > On 28 Mar 2018, at 12:55, Bernhard Bitsch wrote: > > > >> Gesendet: Freitag, 23. März 2018 um 16:54 Uhr >> Von: "Michael Tremer" >> An: "Bernhard Bitsch" , "IPFire Development" >> Betreff: Re: Aw: Re: [PATCH] vnstat: Update to 1.18 >> >> On Fri, 2018-03-23 at 13:39 +0100, Bernhard Bitsch wrote: >>>> Gesendet: Mittwoch, 21. März 2018 um 20:30 Uhr >>>> Von: "Bernhard Bitsch" >>>> An: "Matthias Fischer" >>>> Cc: "IPFire: Development-List" >>>> Betreff: Aw: Re: [PATCH] vnstat: Update to 1.18 >>>> >>>> >>>>> Gesendet: Mittwoch, 21. März 2018 um 18:38 Uhr >>>>> Von: "Matthias Fischer" >>>>> An: "Michael Tremer" , "IPFire: Development- >>>>> List" >>>>> Betreff: Re: [PATCH] vnstat: Update to 1.18 >>>>> >>>>>> >>>>>> P.S. I did not appreciate that comment of that forum user about this >>>>>> bug. Bugs >>>>>> happen. If he doesn't like it, he can take lots of €€€€ into his hand >>>>>> and pay >>>>>> other people to get their bugs. >>>>> >>>>> Me too. But I tried to be patient, took a deep breath and tried to keep >>>>> calm and ~professional. Wasn't easy. Besides, I don't think this is >>>>> really a "bug". 'vnstat' can handle his speed and download rates with no >>>>> problems. It just happened that they were a bit too much for the >>>>> standard config - in *his* case. >>>>> >>>>> Best, >>>>> Matthias >>>>> >>>>> >>>> >>>> Hi, >>>> >>>> just my opinion ( I've investigated now a bit about this "problem" ;) ) >>>> The "solution" isn't really that. The changed parameter is only used by >>>> vnstatd, which isn't used in IPFire. I can't imagine what did the remedy. >>>> We don't know exactly his configuration. Therefore I gave him some hints to >>>> help clarifying the case. >>>> If he doesn't answer, just forget his unqualified comment. >>>> >>>> Best, >>>> Bernhard >>>> >>> >>> News about the vnstat problem. >>> Intensive PMs with Zonediver showed that the effect is caused by 32 bit byte >>> counters of the NIC. ( vnstat reads /proc/net/dev ) >>> He changed the fcrontab period for makegraphs to 3 minutes now. Amount of >>> bytes received in this period is less than 2^32. >>> >>> Remain two questions: >>> - Is this a normal behaviour for the combination of i210-T1 NIC and associated >>> driver or is this specific to his system? >> >> I cannot speak for that NIC because I do not use that anywhere. Surprised to >> hear this the first time since the i210 is also on the APU boards and it >> actually is a stripped down version of a bigger Intel NIC. >> >>> - Can we use the vnstatd daemon? This would allow to increase the vnstat >>> update frequency independent from makegraphs. >> >> I suppose we could. Arne has built this into the distribution and could probably >> comment more. If I remember correctly, the daemon wasn't available when we >> adopted vnstat. >> > That's right. >> But even collecting once a minute wouldn't be enough because with max. >> theoretical throughput of a Gigabit NIC, 2^32 bytes are transferred in 32 >> seconds. And if this is only a problem with that specific NIC, I actually >> wouldn't want to collect every 30 second on all systems. Wastes a lot of >> resources and costs a lot of write cycles on flash. >> >>> I've found a thumb rule for the maximal update period for a given bandwidth. >>> I've documented this in the forum thread. >> >>> >>> Best, >>> Bernhard >>> >> >> -Michael >> > > The default value of vnstatd are 30 seconds for UpdateInterval (short enough for 2^32 bytes on 1 GBit/s ), writes to disk is ruled by parameter SaveInterval ( default 5 minutes, which is our period from cron ). > Thus vnstatd should give a better resolution ( for some systems without information leaks! ) with similiar load as the cron based solution implemented at the moment. > > -Bernhard