Open SvenRoederer opened 6 years ago
Since there is no documentation about the package it's hard to guess.
There has to be some kind of traffic control otherwise the connection will be synchronous to the lowest common speed. Basically it's fast forward for ack-packages and avoiding congestion, the rest is just stuff for special purposes like telephony, stream and others. tc contains all sorts of classes, discs and algorithms, which is nice for academic research but probably not necessary to do a functioning traffic control.
I think there is less than a few ppl who are interested in indepth understanding of tc and even fewer in doing so on a router.
Having been written or introduced by @NeoRaider and in use on a broader scale at gluon I think we should give it a try. How do u know if it is lightweight, from name?
@bobster-galore - you know it's lightweight by looking at the source: Just a single, 300-line file: https://github.com/freifunk-gluon/packages/blob/master/net/simple-tc/src/simple-tc.c - and it depends (apart from the default libs) only on libnl-tiny, that we use as well.
It only sets input/output rate, no special handling for ACK, congestion, etc.. To see, how that behaves in real life, it might be quicker to run tests, than digging into kernel packet scheduler (do bulk bidirectional data transfer on a single socket, as well as on separate sockets, together with a slow client on a different connection). Or ask someone, who has already done that.
That package looks very interesting IMO.
Ah, it uses token bucket filter (tbf), which will take care of congestion etc. We should give it a try!
package added to SAm0815_experimental builds
How can we test it? I can imagine to put it on a router and do a simple test, just downloading a big file while uploading a big file. When both operate on the given bandwidth it is nice otherwise if it is slowing down download speed to upload speed it is not. What do u think?
This might work, just give it a try and then we will see.
Ok, did a quick test with Freifunk Berlin 2018-alpha 6f46d18 on cpe210 v1.1
First I was downloading recent Ubuntu desktop and uploading Ubuntu desktop to the router:/dev/null after the test router. up- and download where quite different.
I put the alpha to the cpe.
While downloading recent Ubuntu desktop I send a 20MB email since I could not reach the other router (probably the first test was not concurrent on the same way since the connection was thru wireless and olsr).
I watched traffic by vnstat -l -i
I'm somehow irritated, did u do anything else beside including it to the build? E.g. default settings or some findoutandsetitrihgt-magic? Or is it only living in the system? If this is the case I did the wrong test.
the package was just enabled to be build, no configuration was done at all. I think /etc/config/simple-tc needs to be configured
So far I can say that my previous test didn't test simple-tc. Now I installed it by opkg update & opkg install simple-tc. I configured /etc/config/simple-tc like that:
# Example config
config interface 'ffuplink'
option enabled '1'
option ifname 'ffuplink'
option limit_egress '1000' # 1000 Kbit/s
option limit_ingress '5000' # 5000 Kbit/s
Then I set /etc/config/qos enabled=0. After restart qos is still in autostart, simple-tc is not and there is no used ffuplink in that experimental notunnel.
simple-tc ffuplink 5000 1000 gives invalid interface: ffuplink surprisingly it's not called at startup.
To me it seems that there is more to be done 4 using it. My first thoughts concerned only luci-stuff and variables in uci, think it's more.
I just found this in Gluon: https://github.com/freifunk-gluon/packages/tree/master/net/simple-tc
Do you think it's a lightweight alternative to the current qos script?