From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Aw: Re: Re: [PATCH] vnstat: Update to 1.18 Date: Wed, 28 Mar 2018 19:04:29 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1826493819981145286==" List-Id: --===============1826493819981145286== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The daemon has the disadvantage of static configuration of all interfaces. This isn=E2=80=99t an information leak. It is a bug in the device driver of t= hat NIC and therefore I don=E2=80=99t think that the solution is to play arou= nd with vnstat. The solution is to fix that driver. -Michael > On 28 Mar 2018, at 12:55, Bernhard Bitsch wrote: >=20 >=20 >=20 >> Gesendet: Freitag, 23. M=C3=A4rz 2018 um 16:54 Uhr >> Von: "Michael Tremer" >> An: "Bernhard Bitsch" , "IPFire Development" >> Betreff: Re: Aw: Re: [PATCH] vnstat: Update to 1.18 >>=20 >> On Fri, 2018-03-23 at 13:39 +0100, Bernhard Bitsch wrote: >>>> Gesendet: Mittwoch, 21. M=C3=A4rz 2018 um 20:30 Uhr >>>> Von: "Bernhard Bitsch" >>>> An: "Matthias Fischer" >>>> Cc: "IPFire: Development-List" >>>> Betreff: Aw: Re: [PATCH] vnstat: Update to 1.18 >>>>=20 >>>>=20 >>>>> Gesendet: Mittwoch, 21. M=C3=A4rz 2018 um 18:38 Uhr >>>>> Von: "Matthias Fischer" =20 >>>>> An: "Michael Tremer" , "IPFire: Developmen= t- >>>>> List" >>>>> Betreff: Re: [PATCH] vnstat: Update to 1.18 >>>>>=20 >>>>>>=20 >>>>>> 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 =E2=82=AC=E2=82=AC= =E2=82=AC=E2=82=AC into his hand >>>>>> and pay >>>>>> other people to get their bugs. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Best, >>>>> Matthias >>>>>=20 >>>>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>> 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. >>>>=20 >>>> Best, >>>> Bernhard >>>>=20 >>>=20 >>> News about the vnstat problem. >>> Intensive PMs with Zonediver showed that the effect is caused by 32 bit b= yte >>> 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. >>>=20 >>> Remain two questions:=20 >>> - Is this a normal behaviour for the combination of i210-T1 NIC and assoc= iated >>> driver or is this specific to his system? >>=20 >> 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. >>=20 >>> - Can we use the vnstatd daemon? This would allow to increase the vnstat >>> update frequency independent from makegraphs. >>=20 >> I suppose we could. Arne has built this into the distribution and could pr= obably >> comment more. If I remember correctly, the daemon wasn't available when we >> adopted vnstat. >>=20 > 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. >>=20 >>> I've found a thumb rule for the maximal update period for a given bandwid= th. >>> I've documented this in the forum thread. >>=20 >>>=20 >>> Best, >>> Bernhard >>>=20 >>=20 >> -Michael >>=20 >=20 > The default value of vnstatd are 30 seconds for UpdateInterval (short enoug= h for 2^32 bytes on 1 GBit/s ), writes to disk is ruled by parameter SaveInte= rval ( default 5 minutes, which is our period from cron ). > Thus vnstatd should give a better resolution ( for some systems without inf= ormation leaks! ) with similiar load as the cron based solution implemented a= t the moment. >=20 > -Bernhard --===============1826493819981145286==--