implement support bandwidth autodetect. #42
Comments
|
How much effort to implement? Seems like a worthwhile issue/request to look at. I am open to your thoughts on this, but looks like it might address some of the users questions around speedtests etc. |
|
With the autorate-ingress option, it is not necessary to inform DL / UP rates. It is a solution for environments with bandwidth fluctuation, prioritizing navigation, reducing latency and congestion. Cake is excellent for this situation. |
|
The script needs to ignore the request to report DL / UP rate. autorate-ingress besteffort ack-filter |
|
Tests must be done on a LAN client with iperf and Wireshark. You should not use websites for testing |
I don't think that is the ideal case. https://man7.org/linux/man-pages/man8/tc-cake.8.html#SHAPER_PARAMETERS
It reads like the bandwidth parameter sets the maximum rate and autorate-ingress then shapes the bandwidth to a value lower then that rate. edit: Thus the correct setting of the bandwidth parameter has no negative effect on the operation of autorate-ingress. /end edit I also believe given that autorate-ingress "cannot estimate the bandwidth of links downstream of itself", is very good reason to maintain bandwidth parameters. The network in Australia has a very strict bandwidth policer, and a significantly better experience is obtained by applying rate limits within the home environment**. **edit: rather then allowing the network policer to bandwidth limit the upload stream. /end edit. If I read the documentation correctly, autorate-ingress would be unable to determine that the bandwidth of the upstream link is being limited by the network policer, in and of itself, and thus requires the assistance of bandwidth parameter. |
|
It's not the case. Continuing the other options, with the definition of the bandwidth rate |
Would it hurt to get both scenarios tested? |
|
I have an LTE 40/10 connection. |
|
fd81ba3 |
|
@maghuro Please test and debug changes locally before committing to the repo. I also suggest using a editing client that supports ShellCheck (atom/notepad++) to avoid basic coding mistakes (your past 5 commits have failed), not to mention commit names like "deeeeeeeerp" are very unprofessional in a group project. Using a web browser to write code is also a terrible idea. |
I agree, we need to build more structure towards stable releases - I would love if @Adamm00 is the "Release Manager" so to speak for versioning/changelogs if you are up for it. If your preferred approach is for forks, local tests etc. I am also ok, but don't mind as formal develop branch if it makes sense. Let's get consensus, however master branch stability should be first since we are past v1 and we have more users adopting the add-on thanks to everyone's work! Thoughts from everyone appreciated. I am also learning a lot as this project unfolds - thanks to you all. |
|
@ttgapers - FULLY support your comment above ... it is CRUCIAL to control commits to the Master and/or Mainline Branch. Another add-on to Asus-Merlin routers descended into chaos before being rescued by one of the "Part of the Furniture" experts. It would be a tragedy if Cake-QOS had to endure the same fate. NIP it in the bud NOW ... pretty please. I'm no coder - nor do I have any Github config knowledge - but surely you can shutdown commits to the Master with a VERY select few who can commit there - with the rest putting in Pull Requests ... or whatever. |
|
Hello guys, that's the reason I created a branch specifically for that implementation. I don't want to mess with master branch. I'm no good at this, I'm not a coder either, I'm just a guy who have some ideas and want to try to help the best I can. But it is clear I'm no good doing it :) So I'll close this issue, please delete the branch I've created, and I'm going off. Thank you guys for letting me in, and thanks for your fantastic work! Really you're the best!! |
|
Oh and if you guys want to implement this, let me say that autorate-ingress works pretty well and it detects pretty well your current bandwidth. To implement it, my suggestion is that when user enters auto on download and upload, you have to hardcode autorate-ingress on extra options. And you should separate download and upload options as I did on this dork implementation. Because used may want to have a fixed bandwidth in download for example, and autorate-ingress on upload. Regarding unlimited, user have to enter 0 and you should separate also both options. |
Might as well just have a webserver serving compiled binaries, yes? Which IMO, is the entire point of branching. To collaborate with others regarding unpolished code. There is much to be learned through error. A closed source, paid for software this is not. Seeing the above statement from people who've pushed more then one "hotfix" to the main branch these last days.......
All valid statements, and a wise man once said "exaggeratedly "friendly" (in that fashion) or useful, pick one". However..... To directly point out the commit failings (your past 5 commits have failed) of others, and in the context of the rest of your post, not only is that not exaggeratedly friendly, it is not even useful. And I think we can all agree that if something is not useful, it may not have to be "exaggeratedly" friendly, but it should at least be respectful. Did I mention something already about hotfixes! Cake works extremely well for me. Thankyou everyone for the development effort. Watching the collaboration so far, without a defined project manager and people being granted commit access relatively easily, has been interesting and refreshing. Thankyou again. |
|
I tested the auto-bandwith branch. Functional. We still need to polish the code. |
I treat every project as if I were being paid to do so, take pride in your work. I like to think users can be confident that any scripts I am involved with are of the highest quality. What isn't high quality is pushing 25+ one line commits in 24 hours and not even using a text editor or git client to review your work before committing the changes, let alone testing them locally. I'm sorry but its just lazy, and if I were a user monitoring this repo's commit log I would have 0 confidence running code from it. I hate to be blunt and for anyone to feel like I am singling them out, but this is the exact reason open source projects have commit guidelines and reject low quality commits. If any person with commit access can't put that minimal effort into their content, they should not be committing. |
|
Now as for the topic on hand. I read the manpage much like @Audionut in regards to the fact a "guideline" up/down value should also be specified with the autorate-ingress option
|
|
There are several ways to express yourself. I work as a professor and university researcher. I take advantage of all knowledge and organize it in proportion to the level of knowledge. I admire @Adamm00 work a lot, like the others. I believe that it is necessary to curate decisions, with a hierarchy of knowledge. It is necessary to welcome everyone. The idea @maghuro of creating separate branches is a good one. As Adamm has greater knowledge in FW and scripting, he will analyze and confirm if useful and feasible. |
|
Hi Everyone, I just posted in the forums but this may help: I've been testing (as I remembered reading the information somewhere) and all that is needed to implement unlimited bandwidth is to change the validation for the bandwidth values so that they accept 0 (zero) - this is taken by cake as unlimited. We can then add autorate-ingress in the extra options if required. I manually edited my cake-qos.cfg to the following Generated By Cake - Do Not Manually EditJun 27 11:47:36############################################## Installerdlspeed="0" ############################################## CakeQOS-Merlin - v1.0.0: Running... |
|
You can get the same result adding "unlimited" to your extra options field as it will take priority;
|
@maghuro - I hope you do not just "go off", cause I am sure like others here do believe your contributions are super important. Let's just get the structure back - where the key is, we don't develop in master. For the entire team - @Adamm00 would like/prefer local development/testing, and I am also ok if this means a formal develop branch for collaborative development/testing prior to pushing to master. If that works let's formalize it and work in sync. I love what we have built here, but as the Dos Equis says we don't do...which is "When I do test I do it in Production" 👎 Trust we will see you @maghuro |
Exactly the goal of the "Release Manager" role assuming @Adamm00 would like to assume it, I am ok due to his rigor around quality control on what gets to Master.... |
As I said... Adamm said me once, and absolutely right, to not "test" things in master. I made mistakes? Yes I made. My builds failed? Yes they failed. As I said I'm not a pro and most of the code I write is in a testing way. I'm learning shell by doing mistakes and correct them. And as no one wanted to write this bandwithd auto detect, I tried by myself. It wasn't by laziness that I haven't tested it. It is because I'm not phisically at home right now and I didn't want to test it because something could get wrong and I was unable to manually reboot my router. Sorry to do this way. From now one, Everytime I want to contribute, I'll only open a pull request for you to evaluate and correct my noobness mistakes. I'm not mad, I've just lost the excitement I had with this :) Sorry. |
|
@maghuro thanks for the work, effort and most importantly good intentions and passion :) |
Agreed, but laziness borne from enthusiasm and excitement. It's not laziness in the sense of slob that lacks enthusiasm and excitement. And while again, your statements are correct in the literal sense, one should be careful of over-damping enthusiasm through criticism. Open source projects need people willing to get their hands dirty with code. We live in a society where majority expect to be force feed on the effort of others. I speak from the experience as someone who has dampened the enthusiasm of potential significant contributors in open source projects, and driven those contributors away. :(
Yes, this exactly. Perhaps, as encouragement, there could be a middle-ground. Branches are free range for the developer of said branch, but in order to commit to the main branch, the commits must follow standard, and thus need to be re-written to the appropriate standard before committed to the main branch. Re-writing code gets old, quickly. Learn to do it right the first time :) |
Its not about being sorry, take it as constructive criticism and grow from it. Everyone has to start somewhere, my main point is everyone (myself included) should be doing things the right way, not taking shortcuts at the expense of QA. Test locally first, everything on the repo including dev branches should be 100% personally tested at the time of writing and working to the authors knowledge. Measure twice, cut once. If you are not home to test the code yourself, then don't push it until you are home and its ready. There is no need to rush things, the script will still be here tomorrow and the next day to contribute to, there isn't a race on who can commit something first. The next big thing is using a proper workflow. Download Notepad++/ Atom / VSCode and the corresponding shellcheck plugin, this plugin alone will alert you to 99% of easily avoidable mistakes and detail the reasons why you should avoid such mistakes. Another major piece of software is your git client, there is no reason not to download Github Desktop (or similar software) to manage your changes. By doing this you also have the ability to diff your changes before pushing them so you can review and correct any obvious mistakes. And there you have it, the right way to contribute to a group open source project, not the easy or fast way. Invest in yourself so users can be confident of your work. |
|
I'm using Notepad++ and Github desktop. Can you help me installing the proper shellcheck plugin? I've searched and didn't find it nor know how to install it. Thanks. |
|
That's the spirit @maghuro - your enthusiasm and pushing forward your ideas have been most welcome ... the project is now on track to formalise the commit process - which is all that was needed so accuracy and reliability of the code can be maintained. There is a great deal to learn from the experts here - so I'm pleased you are taking the messages to heart but not allowing yourself to be offended. |
|
https://github.com/koalaman/shellcheck#in-your-editor I guess notepad++ actually isn't supported, so Atom or VSCode would be your best bet.
Then start using it from now on 😉 All your commits so far have been from the Github website from what I can tell. |
|
I am learning too and going to adapt to the "standards" that @Adamm00 just laid out. I was used to Notepad2 with Github Desktop, but moving to Atom/VS Code with the plugins.... So in summary:
And there you have it, the right way to contribute to a group open source project, not the easy or fast way. Invest in yourself so users can be confident of your work. I'll be ensuring I do adhere and do correct me as I also learn the way of the Jedis here :) Happy to see you @maghuro and @jkychn Back on topic....sorry :p |
|
Added in #52 |
Needs testing.
SHAPER PARAMETERS
autorate-ingress
[3] --> Queue Priority | [diffserv4]
[4] --> Extra Options | [ack-filter-aggressive]
The text was updated successfully, but these errors were encountered: