Gesendet: Freitag, 23. März 2018 um 16:54 Uhr Von: "Michael Tremer" michael.tremer@ipfire.org An: "Bernhard Bitsch" Bernhard.Bitsch@gmx.de, "IPFire Development" development@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@gmx.de An: "Matthias Fischer" matthias.fischer@ipfire.org Cc: "IPFire: Development-List" development@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@ipfire.org An: "Michael Tremer" michael.tremer@ipfire.org, "IPFire: Development- List" development@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