What I see though is this:
The bottom graph shows blue (download) rate rising from 450 to about 600 Mbps, while your utilization (top graph) goes into the 75% range... so 600 * 0.75 = 450Mbps you have clearly received on your ethernet port upwards of 400Mbps of packets!
(or... our script thinks so! perhaps we have a bug @_FailSafe could we be having a bug where we think the amount of time that's passed is way smaller than the actual amount of time, so we estimate bandwidths as WAY too high?)
WoW it's impressive, I have never seen 200 or 400 or even 600 mb displayed during a thousand Speedtest, fastcom, waveform etc. .. never .. I am a little lost .. this may explain during all my wireshark catches i get according to my observation of huge amount of tcp .. possible?
Can you try changing out the ethernet cable between your ISP router and your OpenWrt router as well as the ethernet cable between your OpenWrt router and your desktop computer? Get brand new ones out of the wrapper or something... and try again?
I assure you his cat7 rj45 cables came out of the box on September 16, 2021.
I am not immune that they are defective despite being careful but they are 4 months old
I will have to go to bed it is 5:00 am .. when I wake up, I am going to repeat the exact same test with the same values but with a more powerful router, I will drag the files into the same folder .. Daniel I think that you are close to finding the reason for this latency, your analytical discovery is more than coherent it explains and justifies a lot of things .. if I really have such high peaks in bandwidth then that explains why I have this latency .. in short it's as if I was saturating the line to the limit of suffocation during its fractional peaks .. a bit as if I was DDOS ..
@segal_72 I suggest that you try the speed test at https://fast.com/
It's run by NetFlix and they put servers in the core networks of many ISPs.
NetFlix do this to help Netflix's customers get better streaming rates and to help the ISPs reduce their IP transit charges (and really to stop the ISPs from lobbying to get NetFlix to make direct payments to the ISPs).
What that means is that you might get a better measure of the capacity of your connection as compared with some of the other speedtest providers.
@CharlesJC the fast.com speed test is excellent, but also the waveform bufferbloat test uses content delivery networks for the transfer, and also should be very fast, but here is his speed test result:
48.5 down 24.6 Mbps up
Yet the ethernet clearly sees 400+Mbps of packets coming in, and @segal_72 constantly complains that he has horrible lag in all his games. Yet I don't see evidence of actual delays... this is the first time we've seen evidence of an actual anomaly... It's very weird kind though.
1 Like
I regularly use fastcom because it is the only one that allows me to see my loaded latency
@dlakelan agree that Waveform is great and I use it daily as part of our testing.
Results do vary by ISP and how connected they are to the internet core of their country. I consistently get reports of 25% better download speeds with Fast as compared with Waveform. YMMV
Either way, it just doesn't make sense that his Ethernet port sees 400Mbps of inbound packets but the download speed tests show 50-60Mbps download speed.
1 Like
if we subtract a zero from the values, we find my initial flow rates .. which could suggest a possible bug ..
1 Like
Speculating here...
Is it possible that the 400 is a momentary peak, while the 60 is the sustained throughput?
It seems though that it can sustain this for several seconds at least as the upward pressure causes the autorate to push the ceiling upwards.
@segal_72 I know you need to get to bed, but tomorrow can you do a tcpdump on your eth1 during a speed test for a few seconds, I want to see what it captures.
a lot of times when testing dslreports i get a bufferbloat at the very start of the test and at the end of the test, I guess this is normal, but I wanted to clarify it.
yes of course with pleasure, can you tell me again the necessary command line?
tcpdump -i eth1 -w /tmp/output.pcap
1 Like
Another piece of speculation...
Could the asymmetry between upload and download the problem? The speed tests rely on back-pressure too (even if the messages are UDP rather than TCP). As the upload speed is so constrained, might the speedtest provider be backing off on the download because of the large delays on the upload side?
The weird thing is that his ethernet port is receiving 400+Mbps of packets, but his desktop computer is only receiving ~60Mbps of real throughput, where are the other 85% of the packets?? it makes me think he's receiving packets for some other ISP subscriber which make no sense to the router and so it's dropping them or something like that (like maybe duplicate packets? maybe every packet is duplicated 4 or 5 times?)
