From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernhard Bitsch To: development@lists.ipfire.org Subject: Aw: Re: Re: Re: [PATCH] vnstat: Update to 1.18 Date: Wed, 28 Mar 2018 23:47:12 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4851024581395486291==" List-Id: --===============4851024581395486291== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable What do you mean with static configuration? As far as I've seen in the sources, the functionality of vnstatd and 'vnstat = -u' should be identical. You're right about the bug in the device driver ( which causes an information= leak ), but vnstatd can help as work-around. -Bernhard > Gesendet: Mittwoch, 28. M=C3=A4rz 2018 um 20:04 Uhr > Von: "Michael Tremer" > An: "Bernhard Bitsch" > Cc: "IPFire Development" > Betreff: Re: Aw: Re: Re: [PATCH] vnstat: Update to 1.18 > > The daemon has the disadvantage of static configuration of all interfaces. >=20 > This isn=E2=80=99t an information leak. It is a bug in the device driver of= that NIC and therefore I don=E2=80=99t think that the solution is to play ar= ound with vnstat. The solution is to fix that driver. >=20 > -Michael >=20 > > On 28 Mar 2018, at 12:55, Bernhard Bitsch wrot= e: > >=20 > >=20 > >=20 > >> Gesendet: Freitag, 23. M=C3=A4rz 2018 um 16:54 Uhr > >> Von: "Michael Tremer" > >> An: "Bernhard Bitsch" , "IPFire Development" <= development(a)lists.ipfire.org> > >> 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: Developm= ent- > >>>>> 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 ke= ep > >>>>> 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 reme= dy. > >>>> We don't know exactly his configuration. Therefore I gave him some hin= ts 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= 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. > >>>=20 > >>> Remain two questions:=20 > >>> - Is this a normal behaviour for the combination of i210-T1 NIC and ass= ociated > >>> driver or is this specific to his system? > >>=20 > >> I cannot speak for that NIC because I do not use that anywhere. Surprise= d 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 = probably > >> 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 bandw= idth. > >>> 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 eno= ugh for 2^32 bytes on 1 GBit/s ), writes to disk is ruled by parameter SaveIn= terval ( default 5 minutes, which is our period from cron ). > > Thus vnstatd should give a better resolution ( for some systems without i= nformation leaks! ) with similiar load as the cron based solution implemented= at the moment. > >=20 > > -Bernhard >=20 > --===============4851024581395486291==--