TX/RX Blinking LEDs on WRAP platform
-
Yes, Ryan is on the right path. This code is very good…
-
The c code I posted is the most efficient way of doing this. It reads the values directly from kernel memory.
You stated "Although the CPU usage page on my WRAP went up from 3% - 8% to 17% - 28%, I've not noticed any throughput issues." So I'm confused on how you state now that the GUI isn't showing any CPU change.
For testing purposes I did a comparison myself using the webgui CPU usage. Base CPU usage is 1-2%. When using your original script CPU usage is 14-18%. With the c program CPU usage is 1-3%.
I personally do not like the shell script idea. If you look in the netstat code it reads from the kernel memory to get the values it outputs to the console. Calling netstat multiple times and parsing the output with tail and awk is inefficient. For a one time deal this would be fine, but to have something running as a background process every second, this will affect system performance.
-
The c code I posted is the most efficient way of doing this. It reads the values directly from kernel memory.
You stated "Although the CPU usage page on my WRAP went up from 3% - 8% to 17% - 28%, I've not noticed any throughput issues." So I'm confused on how you state now that the GUI isn't showing any CPU change.
For testing purposes I did a comparison myself using the webgui CPU usage. Base CPU usage is 1-2%. When using your original script CPU usage is 14-18%. With the c program CPU usage is 1-3%.
I personally do not like the shell script idea. If you look in the netstat code it reads from the kernel memory to get the values it outputs to the console. Calling netstat multiple times and parsing the output with tail and awk is inefficient. For a one time deal this would be fine, but to have something running as a background process every second, this will affect system performance.
I have noticed no increases in memory or cpu capacity beyond about 700K of memory usage. Under no conditions did the binary ever go above 1%.
jdijulio: Please watch a top list, and rank by CPU usage or idle usage. Your chasing the wrong zombie here..
-
I did some benches with rsw686's program running and the max throughput was not affected by it. I vote for adding it at system>advanced with an interface selction dropdown and default it to disabled. This way you could make WLAN-Traffic visible on LED3 too ;D
Btw, Scott added some code to make LED2 on a WRAP and the ErrorLED on Soekris blink on unacknowledged alerts. This feature already can be found in the latest snapshot.
-
Btw, Scott added some code to make LED2 on a WRAP and the ErrorLED on Soekris blink on unacknowledged alerts. This feature already can be found in the latest snapshot.
This simply is w00t :D (sorry, had to throw that in)
-
The c code I posted is the most efficient way of doing this. It reads the values directly from kernel memory.
You stated "Although the CPU usage page on my WRAP went up from 3% - 8% to 17% - 28%, I've not noticed any throughput issues." So I'm confused on how you state now that the GUI isn't showing any CPU change.
For testing purposes I did a comparison myself using the webgui CPU usage. Base CPU usage is 1-2%. When using your original script CPU usage is 14-18%. With the c program CPU usage is 1-3%.
I personally do not like the shell script idea. If you look in the netstat code it reads from the kernel memory to get the values it outputs to the console. Calling netstat multiple times and parsing the output with tail and awk is inefficient. For a one time deal this would be fine, but to have something running as a background process every second, this will affect system performance.
I just re-download the binary from rsw's post and also re-ran my benchmarks on my WRAP unit. With nothing additional running (no shell script and no C program), I had a base CPU usage of between 3% and 6% in the WebGUI, and according to a 'ps aux' I had between 79% - 90% of the CPU in IDLE state.
I did two sets of tests; one while the WRAP had no traffic going through it, and one while a single wireless client was preforming a "speed test" through it.
Set 1 (No wireless clients)
–-----------------------When I used the shell script, over a period of 1 minute I had an average CPU usage of 22.5% in the WebGUI. A 'ps aux' reported 0.1% of CPU usage, and 1.0% memory usage, with a time of 0.88s. A 'ps aux' also said that I had 73.2% of the CPU in IDLE state.
When I used the C program, over a period of 1 minute I had an average CPU usage of 4.6% in the WebGUI. A 'ps aux' reported 0.0% of CPU usage, and 0.6% of memory usage, with a time of 0.08s. A 'ps aux' also said that I had 89.6% of the CPU in IDLE state.
Set 2 (One wireless client)
When I used the shell script, over a period of 35 seconds I had an average CPU usage of 35.6% in the WebGUI. A 'ps aux' reported 0.0% of CPU usage, and 1.0% memory usage, with a time of 0.50s. A 'ps aux' also said that I had 70.3% of the CPU in IDLE state.
When I used the C program, over a period of 35 seconds I had an average CPU usage of 20.6% in the WebGUI. A 'ps aux' reported 0.0% of CPU usage, and 0.6% of memory usage, with a time of 0.05s. A 'ps aux' also said that I had 80.6% of the CPU in IDLE state.
Clearly, when I tested this earlier something else must have been going on.
I (honestly) expected the C program to be faster than the shell script anyway. I wasn't trying to "put down" rsw's work or anything by my follow up post; I just wasn't seeing the same thing.
My only thought is that maybe the shell script process wasn't killed properly and was still running in the background at the time that I ran the benchmarks on the C program originally, which clearly could have skewed the results. I'm not sure, but either way, it does in fact appear that the C program preforms quite well (again, as I had hoped/expected).
Sorry to ruffle everyone's feathers...
Slightly off topic, can someone explain to me how the CPU usage on the WebGUI is calculated, compared to what I'm seeing from a generic 'ps aux' on the shell console? The numbers never seem to jive, and I'm curious if I'm just reading it wrong, or if it's calculated differently than I would expect.
Thanks everyone!
PS: Hoba - I agree that putting rsw's code into the snapshots and eventually into a stable version! It's a neat feature for folks who have hardware that support it.
-
Autoexec blinkled when the wrap boot:
create .sh file in /usr/local/etc/rc.d/ named for example blinkled.sh with this examples lines:
/bin/blinkled -i sis1 -l /dev/led/led2 (WAN)
/bin/blinkled -i sis2 -l /dev/led/led3 (OPT1)then, chmod +x /usr/local/etc/rc.d/blinkled.sh
All .sh that are in this path are exec at boot.
Saludos.
-
how do you create the .sh file?
-
Like noted above the shellscript will consume rather much cpu time. Ryans solution to this was much nicer. I wonder why we didn't follow that thought and integrated it. ;)
-
i also lost the RRD graphs after using the shell command version
-
Worked perfect for me added .sh and executes everytime with bootup and very very very little cpu usage, THANKS! I think this should def be put in the next release on the embedded image but disabled by default and added somewhere under the system menu.
