I noticed that Chaos Calmer is somewhat slower compared to Barrier Breaker.
On WR1043NDv1 the LuCi interface values, memory free, packets send, no of connections, takes a long time to load up on the web interface compared to barrier breaker, performance is also slower by a lot. Anyone having the same issue or it is just me?

I noticed that with each version increase more and more daemon appears and start listening on sockets by default.
For Barrier Breaker to Chaos Calmer the new "Star" is RPCD.
I mean I am all for new features but we are all running it on resource constraint devices so a balance need to be struck btw performance and features.

PS : on the Default LUCI Page, Memory statistic is missing one section Barrier Breaker has 4 while Chaos Calmer has only 3

(Last edited by alphasparc on 23 Nov 2015, 03:13)

+1
too much eye candy in luci interfaces i think it could be done with bare html

I have seen the same slowness in Luci GUI, but it has not always been that way. CC trunk used to update the Luci front page's dynamic contents rather quickly until maybe June(?). Since the summer I have sometimes noticed the slowness in the initial update of the dynamic fields. I have not bothered to investigate which change triggered the slowness :-(

Just a guess:  the reason might be in the uhttpd web server daemon, not in the Luci itself.

(Last edited by hnyman on 19 Aug 2015, 11:02)

32 MB RAM device make no fun today just the kernel eat ~35% RAM

Hmm maybe this is why the DGN3500 I tried out seemed so slow. I thought it was related to slow flash (as noted in some old mailing list posts and tickets). But maybe it is CC-RC3? Has this been reported to the devs? This would be really important to fix before the final, especially since the web GUI is what makes the first impression here!

hnyman, yes, I never saw it in the circa mid-May build (or earlier CCs) I had been using until I recently updated to one from late July, so it could certainly have begun in late-May/early June.

It's going to be tough to report--if it hasn't been already--since it's not consistently slow. I haven't quite figured out when it is/isn't.

I tried to debug Luci a bit and filed a ticket to document findings: https://github.com/openwrt/luci/issues/459

Is this solved in Chaos Calmer or it didn't exist?

I actually upgraded to CC today; having previously used alphasparc's patched BB (which has the conntrack cache fix). When I connect directly to the internet, I get 300Mbit (I have a fast connection). Through the router, it was around ~260Mbit on BB. After upgrading to CC however, the speed it way worse - it's like 160-190Mbit.

I only get about 66% sirq, 33% idle. What gives? Why is it slow even though my CPU is not as busy? I tried disabling whatever I could but the speed didn't get any better. I will go back to BB if I can't get CC to take full advantage of my connection.

Oh, I have a WDR3600.

It's hard to tell by the Subject alone, but this thread is just about the UI.

Oops... my bad.

I don't think so, unless it was fixed near the very end (I'm still using a build about a month before final).

Has anyone tried DD (trunk)?

If CC isn't solved I don't think DD is either.

luci in trunk from yesterday (r47551) works pretty good for me, even more responsive than r46672

No one bothered to backport to CC?
Come on CC is supposed to be stable and this IS A BUG.

The slowness is caused by a keepalive bug in uhttpd, fixed ~7 weeks ago by r47161 in trunk and r47162 in CC.
Issue has been tracked in ticket #20607 and #20661.

A workaround is disabling keep alive:

uci set uhttpd.main.http_keepalive=0
uci commit uhttpd
/etc/init.d/uhttpd restart

Thanks for the links and workaround, but I'm a little confused by how a fix was made for CC. I'm guessing that this means source code only and applies to those who compile their own builds. It does not apply to those who just go to the site and download the latest released version, right (that's still a 46767 build with unchanged older dates)?

This brings up an interesting point: with only one or two stable-branch releases coming per year, how do fairly serious issues like the above get addressed for the majority, who I assume don't compile their own builds?

Yes. So far the fix is only in the source code for self-compilation.

There are about 50 different platforms, so compiling even one updated package for all platforms is quite an effort. Devs have selectively done that after some key security-related fixes, but not generally.

Personally I wish that there would be a maintenance release 15.05.1 in the near future, as there have been quite a lot of fixes since the 15.05 release.

For my understanding: Buildbots are constantly building trunk images.
What is the big effort behind building updated 15.05 images?

Just curious...

Also, who can make the call on 15.05.1? Would be great to have it include the updated atheros firmware and ath10k package for affected routers.

No wonder the problem still persisted when I downloaded the latest CC...so it isn't the latest.

I solved similar issue disabling uhttp http_keepalive.
option http_keepalive '0'

(Last edited by oferreiro on 19 Dec 2017, 21:32)