From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Aw: Re: [PATCH] vnstat: Update to 1.18
Date: Fri, 23 Mar 2018 14:54:41 +0000
Message-ID: <1521816881.556038.16.camel@ipfire.org>
In-Reply-To:
 <trinity-608dd9fd-edbe-4fc9-ae64-0624640fe3cc-1521808769881@3c-app-gmx-bs53>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4703418792845605690=="
List-Id: <development.lists.ipfire.org>

--===============4703418792845605690==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

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" <Bernhard.Bitsch(a)gmx.de>
> > An: "Matthias Fischer" <matthias.fischer(a)ipfire.org>
> > Cc: "IPFire: Development-List" <development(a)lists.ipfire.org>
> > 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" <matthias.fischer(a)ipfire.org>=20
> > > An: "Michael Tremer" <michael.tremer(a)ipfire.org>, "IPFire: Developmen=
t-
> > > List" <development(a)lists.ipfire.org>
> > > 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 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 associa=
ted
> 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 proba=
bly
comment more. If I remember correctly, the daemon wasn't available when we
adopted vnstat.

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.

>=20
> Best,
> Bernhard
>=20

-Michael

--===============4703418792845605690==--