Re: Aw: Re: Re: [PATCH] vnstat: Update to 1.18

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 4482 bytes --]

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 <Bernhard.Bitsch(a)gmx.de> wrote:
> 
> 
> 
>> Gesendet: Freitag, 23. März 2018 um 16:54 Uhr
>> Von: "Michael Tremer" <michael.tremer(a)ipfire.org>
>> An: "Bernhard Bitsch" <Bernhard.Bitsch(a)gmx.de>, "IPFire Development" <development(a)lists.ipfire.org>
>> 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" <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
>>>> 
>>>> 
>>>>> Gesendet: Mittwoch, 21. März 2018 um 18:38 Uhr
>>>>> Von: "Matthias Fischer" <matthias.fischer(a)ipfire.org> 
>>>>> An: "Michael Tremer" <michael.tremer(a)ipfire.org>, "IPFire: Development-
>>>>> List" <development(a)lists.ipfire.org>
>>>>> 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