From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernhard Bitsch To: development@lists.ipfire.org Subject: Aw: Re: Re: [PATCH] vnstat: Update to 1.18 Date: Wed, 28 Mar 2018 13:55:07 +0200 Message-ID: In-Reply-To: <1521816881.556038.16.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9059994279799005407==" List-Id: --===============9059994279799005407== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > 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 > > 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 remed= y. > > > We don't know exactly his configuration. Therefore I gave him some hint= s 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 pro= bably > 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 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 SaveInterv= al ( default 5 minutes, which is our period from cron ). Thus vnstatd should give a better resolution ( for some systems without infor= mation leaks! ) with similiar load as the cron based solution implemented at = the moment. -Bernhard --===============9059994279799005407==--