Unfortunately I don't appear to have enough hard drive space on the ssh client, I've forgotten to mention.
I'm using a Raspberrypi 4b 4gb~ (with about 60mb~ of space left on the sdcard)
I didn't need to go away this weekend, so I decided to have some OpenWrt fun...
By George, he's got it! (Apologies to Prof. Henry Higgins...) I reset my Archer C7 v2 back to factory defaults, upgraded to OpenWrt 22.03.5 r20134-5f15225c1e, configured SQM, then used the install process documented in the README. I set the interfaces and the rate limits, left logging options and number of pingers at defaults, and it worked fine. I'll submit a github issue with comments on the installation process, but...
Most importantly, cake-autorate seems to consume a small amount of CPU - when running as a service, it bursted to 100% (via htop) for a dozen seconds at startup and thereafter ran around 10-20% of the CPU. Even when running betterspeedtest.sh or speedtest.net, the CPU never got very high for very long. There were sporadic bursts of higher CPU utilization, but they didn't seem related to traffic.
NICE JOB!
1 Like
@Lynx, it seems I have somehow borked my router install and will need to set it up from scratch. Unfortunately ,this currently has higher priority than cake-autorate testing (and figuring out how to compile tsping). However that testing is still on my TODO list 
(also we move houses next week, so everything will be on hold anyway).
Question, did you actually move the different processes into different files (not sure whether you ever wanted to do so))? While it looks like busy work the consequence is that the processes in bash would be able to have meaningful names instead of all being called cake-autorate?
Alternatively, we might pass a dummy parameter to each function just containing the name so htop would report e.g.:
cake-autprate.sh monitor_pingers
cake-autprate.sh parse_pingers
Again this might already be the case...
I did not, but by default htop actually shows multiple entries for several individual processes anyway:
At the moment cake-autorate maintains a 'proc_pids' file in its run directory with the correspondence between the processes and their pids as follows:
root@OpenWrt-1:~# cat /var/run/cake-autorate/primary/proc_pids
parse_tsping_preprocessor = 32517
parse_tsping = 3482
intercept_stderr = 3355
maintain_log_file = 3381
monitor_achieved_rates = 3464
maintain_pingers = 3469
parse_tsping_pinger = 32518
Hi all
I have been running @Lynx commit d175bf9 from last weekend for the last week and cake-autorate has not crashed once. Previously, it was crashing multiple times a week but since updating, it has been working really well and had no issues. Still using your tsping binary.
CPU usage pretty good on my Linksys E8450, the lower load stats below is where cake-autorate was crashing before updating last weekend, the plot is last 2 weeks:
Off topic but a while ago I split up my cake autorate OWD plots to make them more readable, I just uploaded a new screenshot, check it out: https://github.com/bairhys/prometheus-cake-autorate-exporter
3 Likes
Well, my goal is to be able to see which 'function' is eating up how much CPU cycles from just looking at htop output....
This makes casual diagnostics easier and user reports potentially more informative.
@rb1 sweet! I'm super happy to read your report because I have been working hard to try to iron out any remaining stability issues. On my system things seem super stable now too.
@moeller0 is only requires another terminal on the side to cross reference against htop. Easily the most hungry processes are: 1) the main process; and 2) parse_tsping, which presumably relates to a mixture of the frequency of the reads and associated processing for each read.
We could cut down processing a little by switching from byte-by-byte reads to fixed-width reads. But I wouldn't know how big to set the width to. Mostly the lines are less than 250 characters, but what happens if the users set domains rather than IP addresses. Then the size could exceed 250 characters.
Any thoughts on that?
1 Like
That depends on the details, we really have records of different length and can have multiple records in the FIFO, so we expect the read to give us a full line/record, but what happens if say a 20 bute control record is followed by a 100 byte data record in the FIFO and we read 100 bytes?
So I would not go down that route....
Does this mean Lynx is gone/banned/smited?
I guess he decided to leave the forum. I still hope this is not a permanent decision....
I really hope nothing bad happened to lynx, this project has been really innovative and its been amazing so far~ I was really looking forward to the progress
Wow, that was abrupt, and apparently without any explanation, so it's hard to know why. I do hope he comes back, he's been driving a lot of interesting stuff.
Sometimes you need to step away from things like this, but I think it's no biggie to just say "hey I'm taking a break from this for a few months" rather than anonymizing his account etc.
Without rehashing the original topic, he was outspoken in this thread and decided to leave on his own. He’s been active on Github since then, but hard to maintain a community project without interacting with the community.
Gotcha. I've never been a fan of terminology wars of any kind. Hope he decides to come back.
@rb1 I felt I needed to say thanks besides the 
...
(I tried to do a full page screenshot in Firefox but somehow I'm missing something...)
1 Like
Good to see you got it going. To get the full webpage screenshot, I used "GoFullPage" chrome extension.
Just wondering, did you have Prometheus and Grafana installed before setting up the Cake-Autorate dashboard?
Yes, I did. Besides autorate, I'm already monitoring cake itself, but went on a slightly different path from this, since I had already an "exporter" that I chose to keep. But I digress...
And thanks for the tip on the chrome extension.
Nice, so if I understand correctly, you managed to get cake statistics into Prometheus? Could you describe how you set this up or have a link to a guide? When I tried getting cake into Prometheus, I think there was a cake collectd package but had trouble getting Prometheus to scrape collectd Plugin:Write Prometheus.
First a disclaimer: my router isn't running OpenWrt, but Debian (it's an x86/64 small PC)
Actually, I first tried the collectd route, but I had issues getting it working, and I was eager to see cake stats on Grafana, so I ended up using a script I used to pull cake statistics into Cacti.
It simply outputs tc qdisc in json, and runs each 10 seconds.
Then I put in place a json api to publish the stats so that Prometheus could grab them thru json-exporter.
This approach is only a workaround, but as soon as I have the time I'll try collectd again. The main issue here seems to be the api lack of robustness, which I think explains the small gaps in the graphs (see below)
1 Like
Hey @gadolf, would you be able to upload your script somewhere? Your Grafana Cake page is nice and I'm interested in setting up something similar. I like the way how you are showing the different traffic categories.