2266

Yup... Keeping an eye on the actual shell output while running the Lua is.. Interesting. Was that since the beginning with your Shell. This behavior from waveform has been consistent for me throughout. I can basically sort of "trick" it to give me better results under different conditions. Actually, sometimes under load it gives me aces

This discrepancy between waveform results, and watching ping times and actions in the shell output is also why i have been reluctant to either make it a goal to pass the Waveform bufferbloat, and the amount of data it represents in various mathematical ways, and to dismiss it. it shows a lot of things, i am still trying to interpret all of it

2267

For curiosity, what do you get with 10 Mbit/s fixed CAKE?

2268

Quick experiment

usually a bit better i would say, running a slight bit of traffic right now. Just killed everything and changed rates to 10000 down and 10000 up. Normally i experience no latency increase under load with these conditions

2269

I wonder what gives you such a latency spread even when not that loaded and despite you being so close to the tower. What happens if you do this with 1800 band only?

2270

You and me both mate. Been trying to isolate things for quite a while now.

Let me give you an example of what i was talking about.

Started up the Lua... Should probably have let it settle a bit, but here it is from a cold start.
Notice my speed, decently hgh right? Compared to what it usually shows, around 50% of that.

Now check this:

Screenshot (32)
Screenshot (32)1920×1080 398 KB

a quick look at what happened with the autorate just around when waveform started the upload test, so after the download part. it basically shot up until the high 120 Mbps. Usually under daytime it would trigger the autorate algorithm, but this time it got caught fairly early, but check the pings in the shell output... interesting huh?

2271

I'd be interested to see you just use fixed CAKE @ 10 Mbit/s with LTE locked to 1800 only. Would you be able to do that?

2272

Yes, this is definitely on my to do list. isolate and look over the bands. I am very curious if this is my modem, my tower, my bands. But all of this require a methodical approach.

But I would say that these latency änomalies" doesn't scare me that much anymore. because the proof is in the pudding, and IRL i am apparently not that affected by this behaviour

2273

Yeah I'm sure @dlakelan is right and this is somewhat academic. As you say proof is in the pudding.

Your LTE connection seems to offer a pretty high bandwidth which is cool.

But I'd really love to see what happens when you lock to 1800 if only to see if your latency shows less spread and random spikes. I wonder if carrier aggregation is contributing.

2274

Totally with you there, because it may be a question of me just excluding one band (I am looking closely at the B20 at 5 Mhz, got a funny feeling) And i might see markedly different results in latency. And as such, i wouldn't suffer much from a max 10% decrease in bandwidth. either way, the data itself is interesting, and sort of related to the overall scope here. (at least in regards to LTE lines)

2275

One thing to add over the last many posts. While there is information to be gathered in general about LTE lines that might be useful and informative in regards to adaptive bandwidth and CAKE and my hogging the thread with that information. I think the most informative, for me at least, is that during testing it turned out that the most basic settings really brings out the best of the project in it's current state. When applying and testing, basic and standard SQM settings really does the trick IMHO. I have seen @moeller0 also in several other threads advocating an approach of this kind, keep it simple, it really is very sound advice to keep things simple and basic before introducing headaches of complexity and before you have a decent understanding of things in the background. It's kind of a testament to the already developed features of CAKE and piece of CAKE, at the same time as it speaks to the developers here. My respect for the work @dlakelan put in on this algorithm is increasing by the day, and i have rarely seen faster coding than what @_FailSafe and @Lochnair and @CharlesJC have put down in the recent days, way faster than it is actually possible to test :joy: And it's basically because you pulled the threads @Lynx :wink: I see that one of the inspiration sources @yelreve is also back throwing things in there... Things can only get better from here guys.

2 Likes
2276

That... yeah that is actually a bit of a challenge sometimes :sweat_smile:

To be honest just what has been accomplished by everyone participating here in the past few months is amazing, can't wait to see what we end up with : )

2 Likes
2277

I completed an update and partial re-organisation of the README. Please let us know if I missed anything out.

2 Likes
2278

The sqm-autorate project primary location has moved to https://github.com/sqm-autorate/sqm-autorate/tree/testing/lua-threads

I'm updating the installation procedures and documentation but it will take a day of two for us to sort it all out.

1 Like
2279

Gentlemen, I asked once before, but I bring it up again as that attempt to start a discussion fell by the way-side. Autorate is not a generic solution for SQM but for cake, so naming it cake-autorate would IMHO be more apt thing to do.
To be explicit, autorate will probably work out of the box if cake was set up e.g. by qosify, but will fail if sqm was used to instantiate HTB+fq_codel or anything not using cake as traffic shaper. But these are all qos set-ups that are part of sqm's default .qos script set.
It is fine to describe autorate as being fully compatible/tested with sqm's later_cake.qos or piece_of_cake.qos, but the naming should really be adjusted while that is still relatively easy IMHO.

2280

sqm is a slightly more google-able phrase than cake. Google for "cake shaper" for a problematic example.

2281

True, but does not change the fact that sqm-autorate promises something the project can not keep. And that is bad marketing as what it offers can be really helpful. To me calling it sqm-autorate overpromises and under delivers and that is an avoidable self-goal IMHO. But I am not attached much to cake-autorate and am open for other names that better describe what it does and that are google friendly...

Googling "cake autorate" actually shows a pretty relevant set of pages mostly concerned with sch_cake... (as does googling for cake-autorate)...

2282

Actually I don't think there's a strong reason the autorate code can't adjust the speed of TBF or HTB... though I haven't looked at whether such an adjustment requires tearing down the whole qdisc or can be done with a "change" command. If it requires tearing down and rebuilding, yeah, probably it won't be something we do.

2283

My curiosity got the better of me so I had to test : )

When using the simple.qos script with fq_codel this seems to work to change rate:
tc class change dev eth1 parent 1: classid 1:1 htb rate 35mbit ceil 35mbit

So the difficulty would likely be finding the right place to adjust it automagically.

2284

In simple.qos there should be 4 HTB instances with coordinated rate settings, that would need to be adjusted in a sensible sequence.... and if the shaper settings gets low the fq_codel targets and intervals need adjustments. This would be more involved than two calls to tc.

2285

Here are some graphs these are from v0.4.3.
About 24 hours quite light usage, only in the evenings more traffic.

This was my config.

config network
        option upload_interface 'eth1'
        option download_interface 'ifb4eth1'
        option upload_base_kbits '80000'
        option download_base_kbits '80000'
        option upload_min_percent '50'
        option download_min_percent '50'

config output
        option log_level 'INFO'
        option stats_file '/tmp/sqm-autorate.csv'
        option speed_hist_file '/tmp/sqm-speedhist.csv'

config advanced_settings
        option upload_delay_ms '25'
        option download_delay_ms '25'

Readme says " upload_delay_ms and download_delay_ms should be changed from the default of 15. If the logs are analysed from, say, 24 hours of operation, the vertical (green) line may be a starting point for the new values."

Can I now try to start tune these values and for example set
option upload_delay_ms '30'
option download_delay_ms '15'
I do not fully understand this :slight_smile:

Otherwise one nice feature would be that when you stop sqm-autorate service this would restore the original values to cake qdiscs.

delaydownecdf
delayupecdf
downhist

timeseries
timeseries799×1200 78.7 KB

uphist

1 Like