Oh, you should start a cmd.exe instance first... Go to the search box in the task bar, type cmd.exe, right click the search result and select "Run as administrator" (I seem to recall that otherwise hrping will not work too well). Then navigate to the directory in which ping_collector.bat is located. Then type "ping_collector.bat" (without quotes) and hit enter; after a long while it should exit and you should find the log file (e.g. ping_sweep_xDSL_Tue05032016_170032.55.txt, the Tue05032016_170032.55 part will be replaced by a string representing the date and time you started the ping-sweep).
In your case where you executed ping_collector.bat by double clicking in the explorer, I have no idea were the log file will end up at. I guess one of the windows search functions might help there? (I am not an active windows user, so I can not easily test that myself).
as long as the network was not saturated during that epoch it should not matter, but you can always re-run ping_collector.bat... Anyway I would really recommend to run it from a terminal window's command line instead of from the explorer/desktop via double clicking...
Honestly, I think you should do the next step (installing octave and run ATM_overhead_detector) and post the resulting two plots here in the thread ;). Spoiler alert, ping_sweep_xDSL_31072017_74312_22.txt contained much cleaner data, but both runs egreed that on your link there are 40 Bytes of per packet overhead.
Now depending on which qdisc and interface you use you need to specify different overheads, to keep things simpler just assume cake/piece_of_cake:
pppoe-wan: select overhead 40
ethN or ethN.N: select overhead 32
make sure to select "cake" as link layer adjustment method in the link layer tab of the sqm GUI.
That in itself is not really that significant; overestimating the overhead effectively just equal specifying a lower bandwidth. (So these two variables are not truly orthogonal/independent). I believe getting the overhead correct is a decent first step and now the next step is figuring out the permissable bandwidth for each direction. For your ingress I would recommend to stay <= 5000 (ingress shaping is a bit approximate, the more one shapes below the true bottleneck bandwidth the more effective the ingress shaper is going to be in dealing with ingress bursts, so 5500 of a 5664 sync rate truly is too little, I believe some where between 85 to 90% of the sync rate is a decent starting point, 56640.9 = 5097.6 to 56640.85 = 4814.4). Egress might actually work up to the syncrate (assuming your ISP does not use a secondary traffic shaper upstream of the DSLAM AND assuming you got the overhead accounting configured correctly).
Also, please use the dslreports tests and post the links to the results page here, the detailed results are really helpful in understanding and debugging sqm configuration issues... as well as getting the initial configuration right for a given link.
To be more explicit, I truly believe your qualification above, but for me to have a meaningful discussion about the degree of "worse-ness" I need to have some data to look at. The dslreports speedtest (when configured well) is a very nice tool as it will display a number of interesting data points about the test (especially with the high-res Bufferbloat option enabled).
Side-note, on your link I would probably only configure 4-8 streams for the upload direction as 572Kbps is really not that much and 8-16 for download (as far as I remember the test will fail if the number of streams is too high, or rather you might only get a subset of the requested streams, and in that case I recommend to change the configuration to only request a number of streams that will actually work reliably on a given link, but I digress).
Okay, the download seems acceptable right now; the upload however looks terrible. I guess I would try next with upload set to 400, just to see whether this is a ISP traffic shaping issue. Also I would try with 4 upload streams to test whether this might be just unfortunate interaction of 8 streams in tcp slow-start.
Once you have the bandwidth under control, I believe the next steps could be:
move the link layer accounting to cake itself
configure cake's per-active-internal-IP-address fairness mode, which for most users should do the right thing....
Eight (8) simultaneous upload streams seems like a lot, for a .5 m/bit connection - FYI & reference, only (3) are auto-calculated on the 1 m/bit connection here.. ( 15 / 1, (8) upload, (3) download )
Yes you are ;). Newer luci-app-sqm will default to LLA cake if cake is used as qdisc, otherwise tc_stab. But it seems your luci-app-sqm is a bit older and hence you need to manipulate the advanced options. MTU 1492 is typical when using PPPoE on an otherwise MTU 1500 link, PPPPoE overhead equals 8 bytes, but anyway the comment you referenced really only addresses the next 3 fields (and please note the tcMTU really only needs to be larger than the real MTU).
Yes that pretty much should be it.
This looks like you are set now, the configuration looks decent and the speedtest result is also reasonable for your bandwidths. Happy internetting.
First, LEDE by default connects the WAN interface on the archer_c7_v2 to eth0 (and when using a VLAN to eth0.vid). When the WAN interface is configured with the PPPoE protocol, the WAN interface will be pppoe-wan which in its turn uses eth0 as its physical interface.
Secondly, choose PPPoE as the WAN protocol on the modem (archer) and run the modem in bridge mode. On the modem just apply the settings for DSL that you would use when running it in router mode, before switching it to bridge mode. On the router use for PPPoE the authentication data that was used on the modem when it ran in router mode.
Once a modem (most of them) is started in bridge mode, it cannot be connected to over IP any more (remains only visible on layer 2 (ethernet) and vanishes from layer 3, or like many DOCSIS (cable) modems, it remains reachable at 192.168.100.1, but no traffic can be routed over that IP address). With no IP connectivity to the modem itself, often only a hard reset to factory default will restore the possibility to configure the modem.
Last, for SQM select the pppoe-wan interface as the interface. For a proper configuration of the link layer adaption and queuing dicipline, see: https://lede-project.org/docs/howto/sqm.
<img src="/uploads/def[quote="moeller0, post:75, topic:5348"]
am I suposed to try it?
Yes you are . Newer luci-app-sqm will default to LLA cake if cake is used as qdisc, otherwise tc_stab. But it seems your luci-app-sqm is a bit older and hence you need to manipulate the advanced options. MTU 1492 is typical when using PPPoE on an otherwise MTU 1500 link, PPPPoE overhead equals 8 bytes, but anyway the comment you referenced really only addresses the next 3 fields (and please note the tcMTU really only needs to be larger than the real MTU).
[/quote]
Could you say the opitimal settings for this case? By default I get this
Mmmh, since the GUI really is just a tool to modify /etc/config/sqm and "/etc/init.d/sqm [start|stop]" will iterate over all individual configurations in /etc/config/sqm it will be more efficient if you could post the output of:
cat /etc/config/sqm
tc -d qdisc
tc -s qdisc
before and after making the changes you want to know about. As is I can not really answer your question: I see what you requested in the GUI but I have no idea what version of sqm you have and how it behaves exactly, so please at least post the output of "tc -d qdisc" and "tc -s qdisc" so I can see how LLA mechanism default got interpreted by the rest of sqm-scripts.
Assuming you have the most recent version, this incantation should have resulted in cake handling the LLA instead of the more generic tc_stab method.
Hi RougueWolf, as far as I can see that looks decent. I hope this works better than what you started out with as I do not see any room for further optimizations.
. Newer luci-app-sqm will default to LLA cake if cake is used as qdisc, otherwise tc_stab. But it seems your luci-app-sqm is a bit older and hence you need to manipulate the advanced options. MTU 1492 is typical when using PPPoE on an otherwise MTU 1500 link, PPPPoE overhead equals 8 bytes, but anyway the comment you referenced really only addresses the next 3 fields (and please note the tcMTU really only needs to be larger than the real MTU).