- This topic has 85 replies, 4 voices, and was last updated 3 years, 3 months ago by
.
-
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.
Bufferbloat consistently at A+ is a very good indication that all is good and a lot better than what you did have previously.
Tracert CMD looks normal given your location and CloudFlare as you say, a good option for DNS .
Just have to sit back and wait for FTTP to arrive
In a completely sane world, madness is the only freedom (J.G.Ballard).
Liked by:
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
ust 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.
You have been busy ;-) – I will touch base with ASUS as I agree that vdsl2 PPPoE is 30 (ish)
but I will check with ASUS as to the ether-vlan tag of 4 bytes is not required as this is modem related and modem and router maybe treated as two separate entities?But interesting question
In a completely sane world, madness is the only freedom (J.G.Ballard).
You need to login in order to vote
‘So with my diplomatic head on’, ASUSWRT stock firmware does not support the option to allow for the changing of WAN Packet Overhead size, only ASUSWRT-Merlin does and that it what is used with the @GNUton builds.
However, I did speak with ASUS and they kindly ‘advised’, that if you opted for a @GNUton build for the DSL-AX82U then for WAN Packet Overhead with the above scenario, an increase of 4 bytes for overhead for VLAN tag is advisable.
Something new I have learnt today
In a completely sane world, madness is the only freedom (J.G.Ballard).
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
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.
That is interesting that +2 did change to +0, Waveform uses very small packets for actual line speed (synch rate) testing so this maybe why the results improved also.
Great to see the maths on this and as you say, only effects very small packets, for any one else reading this thread, next item to consider is Maximum Transmission Unit (MTU)
thoughts:
So the 80 MPU includes 4 bits for VLAN ID/tag also which is handled by your DSL-AX82U ?
Given the value for MPU was 80 for your given scenario (DSL Modem Router combo – PPPoE – VLAN ID) given Cake usage is more commonly used on Routers (not modem router combo’s) what’s your thoughts that for the MPU value for routers with similar scenario as above i.e. 80 (Your Original MPU) -4 (VLAN ID/tag) = 76 ? (router does not manage VLAN ID/tag (separate ‘bridged’ modem does) ?
Edit: read below for final thoughts on MPU
In a completely sane world, madness is the only freedom (J.G.Ballard).
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
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).
Auto padded to 64, this is most interesting and great you are kind enough to spend the time to work on this and share your findings with others, much appreciated
.’.
Summary:
Both DSL Modem/Router combos and standalone Routers require as a minimal 72 MPU (minimum packet unit) value for CAKE SQM (QoS) as a guide for BT > VDSL > PPPoE usage in the UK.Would be interesting to see what does happen if MPU is set, as you say to 50 or lower, just for testing purposes
In a completely sane world, madness is the only freedom (J.G.Ballard).
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
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!
Absolutely, the journey is just as important as the destination, but glad you have got there in the end, your hard work and time spent on this is much appreciated
In a completely sane world, madness is the only freedom (J.G.Ballard).
You need to login in order to vote
- You must be logged in to reply to this topic.