SQM for FTTH, overhead issue i guess?

Installing and Using OpenWrt Network and Wireless Configuration
21

i see, do u know the reason why i have such high pk_delay?

I wander if TCP BBR is the one messing up?

22

why is the queue for both interfaces ( directions ) set to 22000/upload?

23

You don't have super high peak delay, 300us is 0.3ms

The thing that worries me is that you burst well above the SQM configured rate. @moeller0 what could be causing that?

24

i have 30/30 Fiber thats why

1 Like
25

i have 149.5 i have seen it 400ms too

26

well this is getting carploads of hits...configured too low(high) for your use case? catching something you dont want caught?

27

i have 0 knowledge about those things and i dont use torrent... i copied the .sh file from Ultimate SQM settings: Layer_cake + DSCP marks (New Script!)

idk what that does

1 Like
28

This is for bulk data which is supposed to be ignored more or less in order to give other data low delay

29

I have seen it go like 70-80ms on Video and best performance too

The thing is its not consistent, it fluctuates very much, the performance drops very badly like 7pm to 10 pm of my time

                  Bulk  Best Effort        Video        Voice
  thresh       1375Kbit       22Mbit       11Mbit     5500Kbit
  target         13.2ms       13.0ms       13.0ms       13.0ms
  interval      260.2ms      260.0ms      260.0ms      260.0ms
  pk_delay       83.8ms        3.9ms       26.9ms        448us
  av_delay       59.9ms        958us       19.5ms         81us
  sp_delay         21us         31us         37us         20us
  backlog            0b           0b           0b           0b
  pkts           260755        26282       757764        31712
  bytes       329231946     32730735    996623836      9204057
  way_inds         5101            0       160476            5
  way_miss          127          108         2976          170
  way_cols            0            0            0            0
  drops            3851           14         1493            0
  marks               0            0            0            0
  ack_drop            0            0            0            0
  sp_flows            0            1            6            1
  bk_flows            0            0            1            0
  un_flows            0            0            0            0
  max_len          1490         1490         1490         1454
  quantum           300          671          335          300
30

Mmmh, these are microseconds so rather low...

And here everything is fine as well, with a target of 13ms, a peak of 4 ms is totally fine, and the 149.5ms in bulk are also as intended, the bulk tin really is designed for giving way to more important tins immediately.

Your bigger issue probably is the

and

at > 200ms TCP tends to not work so well anymore.The rule of thumb is 1ms RTT in fiber/copper gives you ~100Km distance (speed of light in fiber/copper tends to be ~2/3 of in vakuum). so 260 * 100 = 26000 Km, which is more than half around the world...

And that might be the other shoe, BBR, especially BBRv1 did not expect competent AQM like SQM/cake on the path, and tries to estimate a links capacity, by throwing packets into the link until the BBR-flows RTT increases above a threshold (with this threshold typically well below the 5ms of SQM's default or even the 13ms in your case). In that scenario BBR will in its probing phase send way to much data into your AQM and that will drive up queueing there. BBRv3 is said to employ a specific model to detect competent AQM along the path, but I have not tested whether it detects SQM or not.

31

@mozyes BBR is something that needs to be set on the endpoints though, some people think they can set this on the router and then the router will somehow magically change things, so unless you're using BBR on your client you aren't actually using BBR... just to clear up what can be confusing for some people.

1 Like
32

That is for the bulk tin, that is designed for traffic that does not care about latency, so from cake's perspective just fine, you actively need to mark traffic to map into the bulk tin, so I think that is acceptable, no?

33

I have bad pings in almost everything, US servers get 290+ and EU servers get 150+...
i read somewhere for people like australian, rtt 300ms is acceptable...

i guess i should remove it?

i will go back to cubic then or is there any better alternatives?

34

i see... i will change it back the...

35

Problem with the pk_delay i have seen is, its not just only bulk tin, even the best effort and video goes above 70ms, idk how much value i should expect and try to get?

36

That 26.9ms delay in the video tin is I agree a bit high. But the problem is that you have an interval of 260ms I think so the feedback control is not working well. You need to reduce that number

unless you routinely pass a lot of data through an ISP route with a lot of hops and significant delays, change rtt 260ms to rtt 100ms or even lower like maybe rtt 70ms

1 Like
37

That depends, but if you are really 260 ms away from the servers you mostly use, setting RTT to 260 seems fine, but that comes at a latency cost... see the 13ms target tells cake that delays <= 13ms are A-OK and cake will only start interfering with traffic once the delay exceeds 13ms. Now with long paths, eve if you drop a packet, there will be quite some delay until remote servers can react and so packets will pile up

38

i will lower the rtt and see

1 Like
39

It's a bit of trial and error... let us know how a lower rtt works please!

1 Like
40

i didnt know that's how cake worked, i m gonna lower rtt and see the results