Could you try to run top or htop and look at the CPU load? I could imagine that
the fixes dnsmasq might have some CPU spikes that simply leave not enough
cycles for the traffic shaper?
Best Regards
Sebastian
> On Jan 22, 2021, at 22:25, Jonathan Foulkes <[email protected]> wrote:
>
> I figure there should be no inter-dependencies there, but the side-effect of
> the new dnsmasq is pretty serious.
>
> I did not install .6, I only performed an opkg update of the dnamasq package
> itself. So kernal is the same in my case.
>
> But others running a full .6 build report similar QoS issues.
>
> I regressed back to .4 and all is good on the QoS front, waiting until a new
> drop of dnsmasq before trying again.
>
> - Jonathan
>
>> On Jan 22, 2021, at 4:15 PM, Toke Høiland-Jørgensen <[email protected]> wrote:
>>
>> Jonathan Foulkes <[email protected]> writes:
>>
>>> I installed the updated package on a 19.07.4 box running cake, and QoS
>>> performance went down the tubes.
>>> Last night it locked up completely while attempting to stream.
>>>
>>> See the PingPlots others have posted to this forum thread, mine look
>>> similar, went from constant sub 50ms to very spiky, then some loss, loss
>>> increasing, and if high traffic, lock-up.
>>> https://forum.openwrt.org/t/security-advisory-2021-01-19-1-dnsmasq-multiple-vulnerabilities/85903/39
>>>
>>> load is low, sirq is low, so box does not seem stressed.
>>>
>>> Any reason Cake would be sensitive to a dnsmasq bug?
>>
>> No, not really. I mean, dnsmasq could be sending some traffic that
>> interferes with stuff? Or it could be a kernel regression - the release
>> did bump the kernel version as well...
>>
>> -Toke
>
> _______________________________________________
> Bloat mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
