total traffic rollover in graph? error in total?

johnpoz

I haven't even looked to see if this is in redmine or not yet.. Curious if anyone else has noticed this?

So the table shows sane numbers - but when you hover your mouse over a month.. The values shown seem like they rolled over a counter or something?

Seeing it on all interfaces on all rx, the graph mouseover is nonsense, while the table numbers look sane.

AndyRH

Ignoring the negative part, the number is the same, so it does not look like a rollover to me.
1684147557348/1024/1024/1024/1024=1.531...
Also, it is a number with a decimal point. No fractions of a byte since it is the smallest unit counted.

Perhaps a simple format error.

johnpoz

@AndyRH ah yeah that makes sense.. Should prob still be fixed.. So your seeing it too, it not just something with my install.

Ok it has to do with having inverse on.. If you turn that off then the mouse overs are fine.

AndyRH

@johnpoz I cannot see my firewall from work since I decided not to allow WAN management , but when I get home I will check.

johnpoz

@AndyRH I opened up a redmine for it, very low priority for sure..

https://redmine.pfsense.org/issues/15688

They have much more important things to work on I am sure.. But at least its documented for when say an update to that package is being worked on.

Sergei_Shablovsky

@johnpoz
Confirm, exactly the same

Sergei_Shablovsky

@johnpoz said in total traffic rollover in graph? error in total?:

They have much more important things to work on I am sure..

Exactly!

For example TURN ON BBR2 congestion control!!! (or QUIC) ;)

So many Years pfSense using old-fashion and not effective Cubic (that come with FreeBSD by default!
Even RIPE in their research (in 2019 if my memory not lie to me) show how BBR (even not BB2 or QUIC!) beat the all other algorithms.

Butt at least its documented for when say an update to that package is being worked on.

And this is a power of Redmine! ;)

johnpoz

@Sergei_Shablovsky Thanks for the confirmation. Yeah I took a quick fast look at the code.. And it seems the math that says when to convert it to a new SI looks like if >= 1000 to determine if needs to move up the scale etc... And the inverse or neg number doesn't trigger that..

Not really a big deal to be sure - just bit of an eye sore.. is all.