Forum Replies Created
-
It’s actually pretty ridiuclous that browsers don’t have easy bandwidh controls for stuff like this.
The easiest thing to do would be get a linux fedora torrent: https://torrent.fedoraproject.org/
The top torrent works fine and should easily do what is needed (Fedora Astronomy_KDE Live x86_64 37). It’s 4.5GB so enough time to test.
In qbittorrent go to Tools > Options > Speed
Then run waveform.
You need to login in order to vote
Yeah that’s running as expected so far. Can you run a rate limited download in say qbittorrent (set it to max 20Mbps or so) and then run another waveform as it downloads? Blizzard download also a good test:
You need to login in order to vote
You weren’t kidding about QoS being a complex subject. Another deep hole emerges…
I just decided to try downloading a Linux ISO from here in Chrome: https://ubuntu.com/download/desktop
This was with 0 throttling or anything: https://www.waveform.com/tools/bufferbloat?test-id=5276cd72-fed1-413d-80ac-bc630a04784e
Wtf… explain that. I then thought to myself maybe something is wrong with the Blizzard launcher downloader. So now I left blizzard completely unthrottled: https://www.waveform.com/tools/bufferbloat?test-id=365a5fff-e53e-46f2-b505-3deddb1f3e52
I don’t know how I failed low latency. Everything looks fine. I can only assume that the download speed is too slow to get the tick? Jitter looks more than adequate now.
Now I did what I did before… I set blizzard launcher to 20Mbps limit: https://www.waveform.com/tools/bufferbloat?test-id=7b47acc8-eede-4d03-9252-4dfb6ef4ed4d
The jitter issue came back. Now I set it to 10Mbps limit: https://www.waveform.com/tools/bufferbloat?test-id=53f75547-42bc-4708-98a1-22cfeb304b79
I got the low latency tick on the left, backs up the theory it’s about download speed. I still got the increased jitter issue.
So if I understand this correctly… you should not actually use a rate limiter on any type of traffic. It just leads to worse performance… I don’t know how but take it as you get it I guess.
Edit: Yip just checked waveform FAQ section. I did not get the tick because I was less than 10 Mbps (was at 8.31 Mbps):
So if I don’t limit anything it seems… fixed. I would still be very curious to see your results.
You need to login in order to vote
No rush on it, thanks. I think basic test would be something like have cake installed on latest gnuton then:
1: Run waveform test with nothing active to make sure latency and jitter is fine.
2: Set something to download at around 60% of your total bandwidth. Helps if it’s like 10GB+ so you have time to test.
3: Run waveform again and check latency/jitter.
Ideally step 3 waveform should show all ticks even for low latency gaming.
Liked by:
You need to login in order to vote
Sorry once again to everyone following this or finding via Google search… the plot thickens as they say. I now however have 100% values for wan packet overhead and mpu for VDSL2 PPPoE PTM (FTTC) with vlan 101 tag in UK.
I was going to just edit my above posts with the final info but hopefully people can look back and see the journey and the reasoning. I guess the point is don’t be afraid to try and experiment till things fall into place!
For wan packet overhead it is still 34 so that’s good. About mpu however:
My last post was very close… agonizingly so. I didn’t factor in a very crucial change to the ethernet frame: https://en.wikipedia.org/wiki/Ethernet_frame#Payload
The important part: “the minimum payload is 42 octets when an 802.1Q tag is present and 46 octets when absent”.
So what does this actually mean for us? Well since you actually “lose” 4 bytes in the ethernet payload by having the 101 tag, you already account for the vlan tag in the minimum amount at 64. So thus you just need to add 4 bytes for ptm transmission.
Thus the final (and will not change) number for mpu is 68. If you want to see how the Asus router page should look:
Also some extra info on why Mode should be Normal and not PTM even though we have PTM service:
If you set the PTM mode, there is an additional calculation by cake for every packet in which it accounts for the 64/65 encapsulation. It makes much more sense to just account for this in the bandwidth number you supply to cake (in theory slightly less cpu load which is great for less powerful soc). This means 98.4% (64/65).
So e.g. above screenshot if my 90% upload bandwidth number is 10 then I should supply cake with 9.84.
Now the real fun begins when you move to FTTP… there is so many different technologies I would air on the side of caution and stick to the wiki guidelines as they are actually really solid to start with. FTTP should have a 44 wan packet overhead and an 84 mpu.
Liked by:
You need to login in order to vote
So the 80 MPU includes 4 bits for VLAN ID/tag also which is handled by your DSL-AX82U ?
Correct… however when looking at stuff it gets more complicated than I originally thought.
The PPPoE header actually lives inside the ethernet payload (46-1500) so when I was doing the original calculation, I assumed this wasn’t the case. Thus the actual mpu should be 72. I was accounting for the full PPPoE when I didn’t need to.
So why 72? The minimum packet size is 64 (above post screenshot from wikipedia, if less then it gets auto padded to 64). However you still need to add 4 for ptm transmission and again this pesky vlan tag (4) – note the 64 number does not include the vlan tag in its minimum, why it’s in brackets. The PPPoE is already accounted for in the 46-1500 as stated above so no +8 (my original mistake).
Although different technologies, the above Sky user in that openwrt wiki is under the exact same constraints as us. They still had to add 4 bytes for briged-ptm transmission and 4 for the vlan tag needed by Sky. In this case there is no difference between non pppoe and pppoe mpu because of the payload.
As for second question: All the values I’ve looked at should be the same regardless of if it’s a modem+router combo or just router. I did all the reading and prep looking at pure router openwrt command line configuration of cake. If anything the DSL-AX82U should have been the one to suffer in bufferbloat tests but since it’s holding 0~1ms under load on waveform we can safely assume it’s identical.
Note: My original testing of 80 mpu didn’t show much issue because it was still a low enough packet size to not immediately show a problem and since it was still above the minimum mpu, no issue. If I had set something like 50 then it would have been more apparent. Just like they say with overhead before it was figured out, it’s always better to slightly overestimate than underestimate if you don’t know the exact number.
Liked by:
You need to login in order to vote
Good to hear. It’s getting to the limit of my understanding now but after talking with others, I kind of understand mpu.
The linux kernel (which obviously cake runs on) has to at a bare minimum keep track of a 21 byte packet (20 byte header and 1 byte payload) to function. However once you introduce layer 2 ethernet frames this packet goes to 64 at the bare minimum.
Note: The reason why 34 is correct is 6 for mac destination, 6 for mac source, 802.1q (our vlan tag) 4, ethertype of 2, FCS of 4, ptm itself is 4 (S, ck, PTM-FCS), protocol id is 2 (since pppoe authentication) and finally pppoe containing version code, session id etc of 6.
We take 80 as an mpu because vdsl2 covers the l2 ethernet frame so it can be assigned the whole minimum payload size of 46. However we still need to account for the whole actual l2 ethernet frame so our 34 + 46 = 80.
However, all of this mpu stuff can be considered a red herring. It’s nice to get close (80 does seem strong) but in reality a minimum packet size is fruitless. It would only really show with super small ACK packets. Something that isn’t really going to happen much.
I did run tests and usually I was +2 ms on waveform. Now I was able to get +0 ms on waveform so seems like something did change.
You need to login in order to vote
Just a small update on things. Maybe someone finds it useful. I did a little bit of digging into wan packet overhead and really read the cake documentation.
The number should be 34 for most FTTC connections. Reason being is that yes vdsl2 pppoe is 30 but if the ISP uses vlan tagging (e.g. BT) then you must also consider the ether-vlan tag which adds 4 bytes.
The PTM flag should also not be set (noatm). It’s better to just present cake with a slightly modified download bandwidth to account for the 64/65 octet encapsulation of ptm (0.984 of your bandwidth). This should in theory lead to less CPU strain since cake doesn’t have to adjust the accounted packet size.
I’m currently looking into MPU. From here: https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details#more_hints_tips_info
Something around 72 perhaps. Not sure of the relation between bridged-ptm and pppoe vdsl based on his info but if bridged-ptm = 22 then it makes sense that you would add 8 from the pppoe vdsl mpu (both have ether-vlan) so thus mpu should be 80. I’ll look around a little more and see if I can get any extra info.
Liked by:
You need to login in order to vote
Yeah I think it’s just some weird cmd line ping. If dslreports and waveform show A+ and fast.com shows that I have a loaded ping less than 5ms from unloaded I can’t complain. It’s leaps and bounds better than what I had. Definitely a strong purchase.
If you want to see my tracert:
I was testing some DNS providers. I was choosing based off ping. Unfortunately for me, Quad9 has an Edinburgh resolver but since BT doesn’t peer to it I’m always stuck resolving to London. I would have been able to have a like 3ms dns resolver. :(
I did like Quad9 due to the good malware blocking but it seems like I have to choose between Google and CloudFlare. Both ping at 16ms but Quad9 is at 18ms.
You need to login in order to vote
Is there any benefit to lowering from 30 to 27?
I know I’m getting pretty ridiculous right now but even with Cake I still have an issue where if I ping something in cmd like bbc.co.uk, I’ll have a ping spike for 1-2 ping responses when I go to fast.com. It’s only about 10-20ms so nothing bad but still annoying. Is this expected behaviour? The thing is it’s not too consistent. Sometimes it will happen for 1 ping and then some tries it won’t impact the ping by more than say 2ms.
Also while I’m here I got abit lost when configuring DNS:
Is this DNS over TLS needed?
You need to login in order to vote
