Realtime Graphs show wrong throughput


I think perhaps we should rewind:

Please start by explaining:

  • the speed of your Internet connection (I assume you're saying that your ISP claims you have a 132 Mbps connection)???


So your Windows machine is wrong too???

Also, BTW 132 Mbps is a rather uncommon speed...why are you under the impression your connection cannot exceed that?

(Please clarify - and I'm sure we can assist you.)

What do you mean? It says right there "Peak: 316.29 Mibit/s" -- that is more than 132Mibit/s. I am just as confused as the other person, since those values look just like they're supposed to.

1 Like

Ok so lets try again.
The raw connection speed is 224995Kbps. But you have to reduce PPPoE overhead.
Windows shows 214 Mbit/s
vnstat on OpenWRT shows 214 Mbit/s
only the OpenWRT webinterface shows a much lower value
It is about the Inbound value which shows strange values which don't line up. Average and peak are close enough to be right but the Inbound value is completly wrong.

You are paying way too much attention to the intermittent inbound-value. The spikiness of the graph and the value shown for the inbound speed is an aliasing artifact due to the interval the various values are sampled -- it's not wrong, OpenWRT just shows the very intermittent value whereas e.g. Windows averages things over a couple of samples.


The inbound is a 3-5 second snapshot....wrong compared to all 5 seconds, of course...

I'm not sure why you're doing this on purpose. But since you are...all I can simply say is - don't see a problem.

well then lets ignore the graph but there is nothing to interpret for a value like Inbound.


  • take actual total of bits downloaded over x seconds
  • divide by x

Basically, this thread boils down to OP wanting the graph sampling more frequently and averaging a few samples in sequence and showing that as the inbound value.

I haven't looked at Luci's code, but I believe it uses the rather inefficient XHR-requests to retrieve the values. To update the values more frequently, it probably should be reworked to use Websockets instead, thereby lessening the load on both ends.

1 Like

I'm not sure how that is relevant at all. There is a constant download with 214 mbit/s over minutes but the inbound value shows never over minutes there a value which is higher than 130 mbit/s. The math to make this work would have to be so bad screwed up that the total bits downloaded over x seconds are divided by the wrong x. So in this case the time over which got measured would not line up with the time divided by.

Like I said, it's aliasing caused by the frequency and timing of the samples used. I haven't looked exactly how the graphing works (and I'm not interested enough to bother, either), but imagine the system taking two samples, but the timing between those two samples and the frequency how often the samples are taken don't line up with buffering and whatnot: one sample will show different values than the other, and the graphing system just happens to end up using the smaller one. If you were to average the two samples, however, they'd show the value you're expecting.

So, it's not technically wrong, it just can be a bit misleading if you do not average things out a little in your mind.


Then I do not understand for what to have that value at all if it is wrong all the time. It hasn't shown a single right value about half a hour now so I do not understand it's purpose.

This is a known paradox of taking running and real-time samples...something similar pops its head up in quantum physics too. :wink:

I don't see that...and you'd have to ignore the OpenWrt graph in Post No. 1 to come to that opinion. Maybe you can explain why you're making arbitrary statements...or why you think the OpenWrt graph shows what you describe.


I see your download hit 303 Mbps sometimes...and dips to ~130.

(303 + 130) / 2 == 216.5


I guess you're admitting that you're ignoring the graph now. Or you didn't see:

303 > 130


Do you know the difference between a graph and a value?

Yes, and values are used to program/draw graphs...I'm not sure if you're being facetious or you really insist that you don't understand.

Perhaps you should explain what you don't understand...or maybe I didn't understand the joke?

I agree if a number never higher than 131 showed as input, that's an issue...if that helps. But I really don't know enough about your device, CPUs, etc.

Well, let's put it this way: it's perfectly useable as-is for the people who understand that there's always going to be some amount of aliasing happening with these things.

With the above in mind, I do actually understand your point and yes, it would seem to make more sense for a wider audience, if it was averaged over a couple of samples. If you wish, you could e.g. open a ticket on OpenWRT's Github-repo suggesting such an adjustment.

1 Like

I really don't understand the joke you two try to make here. I did even mark the fkn value red in the screenshots and you try to tell me something about alaising of a graph which was irrelevant from post 3.

TBH I thought you meant your ISP could not go about 132 maybe it's a language issue...I really don't think cursing was necessary. It's an honest

I sad I thought you made a joke. I also don't know how asking me about a graph and a value help your post, but OK. Maybe you didn't see:

I guess you're not reading:

I'm not making a joke. I literally just said that I do understand your point and I agree that averaging it a little would make the value make more sense to a wider audience. I do think a small adjustment to the way the value is shown would be a beneficial tweak. I still do not agree that it's wrong as it is, however.

1 Like