Did you try HZ=1000 instead of the default? When do you actually need to use nathelper-rtsp nowdays?
1 Like
I tried HZ=250 and did not see any difference compared to the default 100. But I did not test 1000 Hz, as I don't quite see how the timer interrupts would affect packet-driven QoS. As discussed in the SQM development forum, it looks the culprit is HTB qdisc which seems to dislike the dual-core with arm-cortex.
I am not using nathelper-rtsp myself, but I was asked to add that to my WNDR3700 build earlier and I have kept it in the recipe. It is so difficult to add kmods afterwards to private builds, so I have just kept it along in case somebody needs it.
"Software Rate Limiting
Use of HTB to rate limit connections to a given speed is to be preferred, as HTB buffers up one, and only one packet. Note that HTB is timer based; default Linux kernels are often compiled with HZ=250 (or even lower), causing burstyness and non-uniform delivery of packets; building your kernels at HZ=1000 will reduce this effect. Very important also is that your kernel have support for hi resolution timers (hpet or better)."
https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel/
This is also recommended on BSD's, FWIW
1 Like
Thanks for digging that up. That sounds rather clear.
I tested with 1000HZ kernel and it has no significant impact, although there may be a marginal improvement. With 90/8 limits I get 85/7.6 with cake and 80/7.8 with simple, so the gap remains quite large. That is roughly the same that I got with the normal 100HZ after the first HTB performance patch. There are quite a lot of HTB performance patches in kernel 4.8, so I guess that I have to live with this until kernel 4.8 gets here.
Since you have a rather fast connection I don't think you'll see much of a difference, it's more crucial on slow DSL/Cable connections. I haven't done any real measurements but as far as perception goes I'd say that connections appears to be more consistent in terms of speed.
I will note that this advice is from May 2014 - 2 1/2 years ago. I know that a lot has changed in this time: but haven't followed it carefully enough to know whether it would make a difference.
I have posted a note on the Bloat mailing list to ask if it's still relevant.
I uploaded a new build that has an older version of the "upstream thermal driver" adapted to ipq8065. It is still work in progress, but seems to work. More discussion about that thermal statistics driver at Supporting thermal sensors on ipq806x
the thermal driver got successfully backported from upstream Linux 4.9 and the PR 533 has been updated with it, but the PR 533 has not yet got pulled in. My build includes now the commits from PR533
https://github.com/lede-project/source/pull/533
EDIT:
PR533 has been accepted and the source code is included in the main LEDE repo.
Nothing build-specific, but nice to see that the router properly adjusted for the leap second 
[91901.925431] Clock: inserting leap second 23:59:60 UTCNote: the newest version lede-r2750-18152e71d8-20170104-musl1116 has been compiled with musl clib 1.1.16 that is not yet the default (and not yet used by the buildbot). So, no add-on packages can be installed to lede-r2750-18152e71d8-20170104-musl1116
Hello!
I love your builds I am using them for my wndr3700 and wndr3800.
I have just ordered new device. Zyxel NBG6817, do you think you could include it to your builds? It seems to be the same hardware just eMMC flash different which is 4gb on Zyxel.
Sorry but no. I only build for devices that I have, so that I can test the builds.
1 Like
I understand. I was building long time ago on Openwrt and Then there was Arokh and you (actually arokh was before me). so I quit building my builds 
but seems like I will have to start building myself again 
If you like my build, you can easily copy my config and build scripts and just change the device.
I publish a script that easily creates my build environment and patches. I use it myself 3-4 times a year to move to new Ubuntu etc.
I will definitely try at least. Can you please point me to the exact direction? where is the script and how to set it up? I would start setting up the environment already. Router should come tomorrow around 18:00 CET and I would already try without even checking the stock firmware if i am ready by then.
Script is included in each build's directory. You need the script plus the patches for that build, also in the same directory.
Link to advice is on message #2 of this thread...
2 Likes
12:12 <mmhorda> anywone knows why stunnel doesn't work by the way? Error relocating /usr/bin/stunnel: COMP_zlib: symbol not found 12:13 <mmhorda> ehmm. not sure. I used @hnyman build
That's apparently when you start stunnel (#lede-dev)
My build does not contain the stunnel package...