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.
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.
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.
This is a known paradox of taking running and real-time samples...something similar pops its head up in quantum physics too.
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.
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.
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.
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.