Attempting to run the # ATM_overhead_detector @moeller0
I do not understand, would you guide me through the process, I am on WIN10. I tried to execute one in an ssh of my router then got lost lol.
Setting up the advanced options like this as well for a vdsl ptm link
First, the ATM_overhead detection only works on ATM/AAL5 encapsulated links, so ADSL. It will not give any reasonable or trustworthy results for PTM based links at all.
Secondly, please have a look inside the two ping_collector scripts, they should be pretty verbose.
Thirdly, the ping log file these scripts generate can easily exceed multiple megabytes, and hence can be dangerous to run on your typical flash and RAM starved router, so I would recommend to run this script on a host computer inside your network. since you are using Windows, please install harping and have a look at ping_collector.bat, or install the Linux subsystem for Windows and then try ping_collector.sh. In any case, first read the contents of the selected ping_vollector script.
Gourtly, good luck! And let me know if anything is left questionable after reading the scripts....
downloaded hr ping>installed
downlaoded pingcollector.bat>moved to hr ping folder
ran cmd as admin>ran command in cmd C:\Users\User\Downloads\hrping-v507\ping_collector.bat
All it did was ping for 2 hours so yeah lol I don't think I did it right. I have a ptm link connecting through pppoe VDSL2
I am trying to achieve optimization as displayed here:
https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details
At the bottom of the page under section:
## MORE HINTS & TIPS & INFO
How I use CAKE to control bufferbloat and fair share my Internet connection on Openwrt.
CAKE has been my go to solution to bufferbloat for years, not just because of solving bufferbloat but also for fairer sharing of my link. Whilst CAKE has some sensible defaults there are a few extra options & tweaks that can improve things further.
There are these scripts: egress: 19950 diffserv4 dual-srchost bridged-ptm ether-vlan nat mpu 72 ack-filter ingress 78000 diffserv4 dual-dsthost bridged-ptm ether-vlan nat ingress
which are added to: Advanced option string to pass to the egress queueing disciplines; no error checking, use very carefully.
We will just say egress because I have 2 sqm instances which are configured as such
config queue 'eth1'
option ingress_ecn 'ECN'
option itarget 'auto'
option etarget 'auto'
option debug_logging '0'
option verbosity '5'
option qdisc 'cake'
option qdisc_advanced '1'
option squash_dscp '1'
option squash_ingress '1'
option qdisc_really_really_advanced '1'
option linklayer 'ethernet'
option overhead '27'
option enabled '1'
option interface 'pppoe-wan'
option upload '6000'
option download '0'
option script 'layer_cake.qos'
option egress_ecn 'NOECN'
option eqdisc_opts 'diffserv3 nat dual-srchost ack-filter mpu 64'
config queue
option debug_logging '0'
option verbosity '5'
option squash_dscp '1'
option squash_ingress '1'
option enabled '1'
option interface 'br-lan'
option download '0'
option upload '30000'
option qdisc 'cake'
option script 'layer_cake.qos'
option qdisc_advanced '1'
option egress_ecn 'ECN'
option qdisc_really_really_advanced '1'
option itarget 'auto'
option etarget 'auto'
option linklayer 'ethernet'
option overhead '27'
option ingress_ecn 'NOECN'
option eqdisc_opts 'diffserv3 nat dual-srchost ack-filter mpu 64'
So my next questions are concerns with advanced tweaking I would say. Most importantly ack-filter - will this command be functional ingress and egress and function properly in both instances?
The next question has to do with option eqdisc_opts
I looked into some past posts which show mpu 64 (docsis post). But there are others which change this to mpu 72(vdsl2 post). So yeah just basically what mpu does and where it should be set for vdsl2 pppoe.
The section also mentions bridged-ptm ether-vlan - now I do not use vlan but I believe because I am "authenticating" as my ISP likes to call it through a xDSL modem drawing an ip from their systems and dialing in to the pppoe with my OpenWRT x86 router does this mean I am bridged-ptm and I should include something like this in the option eqdisc_opts
Also where can the other commands for option eqdisc_opts be found?
One last thing, under section
Show Advanced Linklayer Options, (only needed if MTU > 1500). Advanced options will only be used as long as this box is checked.
I have it set as such, should I be changing any of the variables here?
Thank you Sir!
Please, stop right there, the thing is ATM_overhead_detector for a reason. the detection method absolutely requires ATM/AAL5 encapsulation, since it works by detecting the RTT steps induced by ATM celling. It will not give you anything reliable for PTM based links unfortunately...
So you will need to find another way to figure out the minimum per packet overhead your ISP requires.
Instead of using the mpu keyword here, you could just expand the advanced link layer options and set mpu there, but it will have the same effect....
ack-filter should technically work for both directions, but it really only makes sense in the internet upload direction, for the download direction the packets already passed the bottleneck. But please test whether ack-filtering is helpful at all on your link, do not just enable it because you can, it has some mild potential side-effects.
It tells the link layer adjustments what will be the minimum packet size, that is if you send a hypothetical packet with one Byte of header & payload, if you package that as an ethernet frame it will be >= 64 bytes on the wire (the ethernet payload is ~ >= 46 bytes, if you sent a single Byte there will be 45 bytes of padding). PTM uses ethernet framing (including the FCS) and adds at least 4 bytes PTM overhead, so that the mpu will be >= 64+4 = 68. If you expect a VLAN tag you should add another 4 bytes resulting in the observed 72.
Only your ISP will know that no amount of reading in the tea leafs here in the forum is going to indicate whether your ISP uses a VLAN tag or not (or maybe even two).
As I said above, you could use the mpu field to pass the mpu to cake instead of going via the qdisc_opts fields, but it will have the same result.
@warchief, asymptotically for large packets (1500 bytes or so) errors in packet size calcs are only on the order of 10/1500 ~ 0.7% which is far below the errors in your speedtest results... now for packets of say 200 bytes like a VoIP packet you might be talking 10/200~5% which is significant... so the best bet when in doubt is to overestimate the overhead by 10 or 15 bytes. this results in a conservative estimate of bandwidth utilized by small packet flows. So in your case just take the best estimate you have and add 10 bytes...
This is my current modem config and I believe they did place a vlan on it because when I attempt to connect the link on an openreach xdsl modem it will not connect, I suspect it has something to do with a checkbox in the settings the newer zyxel may have which the openreach I aquired from europe may not. There is literally one check box that the zyxel has and the openreach does not and I can't draw an ip4 from the ISP and the ISP set it up specifically for my link to lock me out.
I had issues with the link going down and having to ask for them to remotely reauthenticate and they ended up sticking this vlan setting in and now I can't connect but before I was fine.
not quite sure what is going on but in that configuration you definitely have a VLAN tag 299 and priority 3. However it's not in bridge mode, so it would be expected to most likely strip the VLAN for the port your router is connected to (ie. the VLAN tag is on the WAN side, not the LAN side). I can't guarantee that, but it's unusual for consumer devices to present VLAN tags to consumer equipment.
I think the issue I ran into was I tried to bridge that particular PTM connection but it wouldn't because it takes off the vlan tag and expects the router pppoe dial in to set up the vlan? At the time I didn't know and I don't really have access to them to test. Same deal with my openreach router I couldn't get it to bridge because the vlan wasn't able to set or something. So I had to basically leave it at stock and let the underlying bridge PTM connection setup take over. The modem does come from the ISP with 3 default connections set up to establish the link.
On MGT-PTM, but according to the screenshot below most traffic is carried by PPPOE-PTM, so VLAN299 might not be important for reaching the internet, no? This smells to me a bit like MGT-PTM is a link the ISP uses to get into the modem from their side (something similar to TR-069 https://www.broadband-forum.org/technical/download/TR-069.pdf), unless PPPOE-PTM is an interface in which the ISP's modem acts as router, I would concentrate on that first.
BTW, the same is true for the mpu as well, if in doubt, rather overestimate.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.
