Perhaps the differences in memory use are a memory leak of some kind? If you could run the same number of packets through each configuration and look at memory use, that might point somewhere.
cake - with gso-splitting - should fragment memory more than the other alternatives, as will fq_codel_fast with sce enabled. On Mon, Sep 16, 2019 at 1:00 PM Dave Taht <dave.t...@gmail.com> wrote: > > I am puzzled as to why fq_codel_fast would use more ram than fq_codel > would, was sce (gso-splotting) enabled? > > similarly, the differences between hfsc and htb are interesting. I > don't get that either. > > How many cake instances are being created? > > And for the sake of discussion, what does cake standalone consume? > > On Mon, Sep 16, 2019 at 11:22 AM Sebastian Gottschall > <s.gottsch...@newmedia-net.de> wrote: > > > > after we found out serious out of memory issues on smaller embedded devices > > (128 mb ram) we made some benchmarks with different schedulers > > with the result that cake takes a serious amount of memory. we use the out > > of tree cake module and we use it class based since we have complex methods > > of doing qos per interface, per mac addresse or even per > > I note that I often thought about having mac address functionality > might be a valuable mode for cake. > > >ip/network. so its not just simple cake on a single interface solution. we > >made some benchmarks with different schedulers. does anybody have a solution > >for making that better? > > With such complexity required I'd stick to hfsc + fq_X rather than > layer in cake. > > Understanding the model (sh -x the tc commands for, say, hfsc + > something and htb + something ) your users require, though, would be > helpful. We tried to design cake so that a jillion optimizations such > as ack prioritization, per network fq (instead per flow/per host) - > but we couldn't possibly cover all use cases in it with out more > feedback from the field. > > Still... such a big difference in memory use doesn't add up. Cake has > a larger fixed memory allocation > than fq_codel, but the rest is just packets which come from global memory. > > Can you point to a build and a couple targets we could try? I am > presently travelling (in portugal) and won't > be back online until later this week. > > > > HTB/FQ_CODEL ------- 62M > > HTB/SFQ ------- 62M > > HTB/PIE ------- 62M > > HTB/FQ_CODEL_FAST ------- 67M > > HTB/CAKE -------111M > > > > HFSC/FQ_CODEL_FAST ------- 47M > > HTB/PIE ------- 49M > > HTB/SFQ ------- 50M > > HFSC /FQ_CODEL ------- 52M > > HFSC/CAKE -------109M > > > > > > consider that the benchmark doesnt show the real values. its system overall > > and does not consider memory taken by the wireless driver for instance > > which is about 45 mb of ram for ath10k > > so this makes all even more worse unfortunatly since there is not that many > > ram left for cake. just about 70mb maybe. > > Am 08.09.2019 um 19:27 schrieb Jonathan Morton: > > > > You could also set it back to 'internet' and progressively reduce the > > bandwidth parameter, making the Cake shaper into the actual bottleneck. > > This is the correct fix for the problem, and you should notice an > > instant improvement as soon as the bandwidth parameter is correct. > > > > Hand tuning this one link is not a problem. I'm searching for a set of > > settings that will provide generally good performance across a wide range > > of devices, links, and situations. > > > > From what you've indicated so far there's nothing as effective as a correct > > bandwidth estimation if we consider the antenna (link) a black box. > > Expecting the user to input expected throughput for every link and then > > managing that information is essentially a non-starter. > > > > Radio tuning provides some improvement, but until ubiquiti starts shipping > > with Codel on non-router devices I don't think there's a good solution here. > > > > Any way to have the receiving device detect bloat and insert an ECN? > > > > That's what the qdisc itself is supposed to do. > > > > I don't think the time spent in the intermediate device is detectable at > > the kernel level but we keep track of latency for routing decisions and > > could detect bloat with some accuracy, the problem is how to respond. > > > > As long as you can detect which link the bloat is on (and in which > > direction), you can respond by reducing the bandwidth parameter on that > > half-link by a small amount. Since you have a cooperating network, > > maintaining a time standard on each node sufficient to observe one-way > > delays seems feasible, as is establishing a normal baseline latency for > > each link. > > > > The characteristics of the bandwidth parameter being too high are easy to > > observe. Not only will the one-way delay go up, but the received > > throughput in the same direction at the same time will be lower than > > configured. You might use the latter as a hint as to how far you need to > > reduce the shaped bandwidth. > > > > Deciding when and by how much to *increase* bandwidth, which is presumably > > desirable when link conditions improve, is a more difficult problem when > > the link hardware doesn't cooperate by informing you of its status. (This > > is something you could reasonably ask Ubiquiti to address.) > > > > I would assume that link characteristics will change slowly, and run an > > occasional explicit bandwidth probe to see if spare bandwidth is available. > > If that probe comes through without exhibiting bloat, *and* the link is > > otherwise loaded to capacity, then increase the shaper by an amount within > > the probe's capacity of measurement - and schedule a repeat. > > > > A suitable probe might be 100x 1500b packets paced out over a second, > > bypassing the shaper. This will occupy just over 1Mbps of bandwidth, and > > can be expected to induce 10ms of delay if injected into a saturated > > 100Mbps link. Observe the delay experienced by each packet *and* the > > quantity of other traffic that appears between them. Only if both are > > favourable can you safely open the shaper, by 1Mbps. > > > > Since wireless links can be expected to change their capacity over time, > > due to eg. weather and tree growth, this seems to be more generally useful > > than a static guess. You could deploy a new link with a conservative > > "guess" of say 10Mbps, and just probe from there. > > > > - Jonathan Morton > > _______________________________________________ > > Cake mailing list > > Cake@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cake > > > > _______________________________________________ > > Cake mailing list > > Cake@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cake > > > > -- > > Dave Täht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740 -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
