Hi bobptz,
bobptz wrote:moeller0 wrote: Well, if your bandwidth is not sufficient to have two concurrent Skype sessions then don't do that then?
Maybe my wife or my children do not understand this even if I tell them 100 times.
Since in our gedankenexperiment there will b too little bandwidth for two concurrent calls, they will notice since their Skype session also is going to be crappy... But i get your point you want to have a stricter control over this...
bobptz wrote:Maybe the line is loaded already by other stuff. Maybe the line can handle couple of skype sessions if they are geographically close, but has problem if they are from another continent.
Why should this depend on the geographical distance between a call's endpoints?
bobptz wrote:Maybe the ADSL line has fluctuations and some times it has reduced bandwidth (my ADSL does).
If the fluctuations are severe the will likely make your shaper non-functional during periods of low bandwidth, in that situation sqm-scripts will not work well at all. I have he feeling you might be happier with maybe using gargoyle, which has a method to monitor the available bandwidth and set the shaper accordingly, also I believe gargoyle allows the level of detailed configuration and control you seem to want.
bobptz wrote:Why do you want to take care of torrents when everybody knows it is a hog for bandwidth and people should schedule them during off hours?
Because people don't do this reliably enough? And a number of networks are shared between users that want a reasonable fairness of bandwidth use (in times of contention), and because bit-torrent traffic can really make sqm-scripts perform worse than expected...
bobptz wrote:Because we are perfectionists and we strive for automation and excellence in the products we make.
Please speak for yourself; for me this is not about excellence but really about fixing a bad corner-case were a single misbehaving user/application can degrade the network experience for a whole segment (but unlike a DOS situation, bit-torrent by itself is not an unwanted application, so banning it is not really an option, but relying on people getting the configuration right also does not seem to work generally, sort of like in your family scenario above... ).
This is not really a manual, but rather a quick introduction to help people getting it up and running, Rich Brown wrote this great document, but its aim certainly is not to explain all the details, but rather get people to a working set-up as quickly as possible.
bobptz wrote:
moeller0 wrote:(sqm-scripts has advantages in that it works out of the box for IPv6 which qos-scripts as of 3 years ago did to (last time I looked),
I don't think I need IPv6 support (do I?). But your statement confused me. Does qos-scripts support IPv6 or not?
I do not know the current state of qos-scripts and IPv6, three years ago it did not shape IPv6 traffic at all, so say on a dual-stack link with some IPv6 traffic flowing the shaper might not have worked at all.. About today, I really do not know.
bobptz wrote:
moeller0 wrote:sqm offers link layer overhead accounting that actually works,
In English, it is more efficient in reducing bufferbloat, right?
This can be a side-effect, yes. But the man point is that without correct accounting for the link layer and the per packet overhead the shaper will not robustly work especially on an ATM-bassed link, were worst case ~50% of the link bandwidth can be wasted on quantization overhead, so either you set your shaper to 50% of the link rate or use correct link layer accounting to make sure the traffic shaper will work as expected under all circumstances...
bobptz wrote:I think it should be explained in the manual (see above) what are the features/benefits of SQM, in a way that a non-technical person understands them.
Remember when I pointed you at https://github.com/moeller0/ATM_overhead_detector ? You complained about its almost complete opaqueness and tech-babble, but this was my attempt at describing something in a way for lay-people to understand (without dumbing down on the details), so I might not be the person you actually want writing documentation... That said, if you want to contribute simple and correct text for a more detailed manual, I am sure Toke will happily include this, or it could be hosted on the openwrt wiki somewhere, just holler if you want to contribute.
bobptz wrote:A simple tutorial about all the DSCP stuff needed to fine tune it.
One of the core dies behind sqm-scripts is to come up with a traffic control system that should not need any fine-tuning You are right that a better description of the DSCP topics would be great. So may I ask you to document the steps of your journey to a working set-up, to use as a skeleton for the sqm/DSCP manual?
bobptz wrote:All the confusion in my questions could be food for thought to at least improve documentation.
So, are you volunteering your own time here to improve the documentation? In that case I will try to endorse you and help out with information, if I can. If you are thinking about volunteering my or someone else's time I am unsure how quickly the tentative documentation improvements will materialize
Ceterum censeo, you should try to perform a worst case measurement on your system first to figure out whether any DSCP magic is required at all or not, if I understand correctly we are mainly talking about theoretical short-comings you want fixed, not really confirmed practical ones... You know what they say, "if it is not broken, do not fix it". There are enough sqm related items on my todo list that fix real observable issues that I am not actively soliciting for more ideas how to spend my spare time
Best Regards
M.