bbqsystool

[DebianJoe]

Okay, attacking the system managers tool. Was really tempted to include linking to <panel.h>, but luckily...the bbq philosophy says that's a bad thing. ;)

Will report when it's close to ready for testing. It's not even close yet.


So far, it's pretty light; hitting right at 94 SLOC, with functional main menu.

[DebianJoe]

Okay, a few quick points that I have found interesting and worthy of a short discussion on the systool.

Acpi-cpufreq will work for throttling MOST CPU's as was originally in the BBQCPU tool, and with a little loop I've got it will set a governor on each cpu found in /sys/devices/cpu so that it's system-core agnostic.

Starting with kernel 3.9, the pstate power scaling driver is used automatically for modern Intel CPUs instead of the other drivers. This driver takes priority over other drivers and in fact is inbuilt as opposed to being a module. This driver is currently automatically used for Sandy Bridge and Ivy Bridge type CPUs.

I've been thinking that it makes sense to not only have some "hit or miss" options, but actually drop from the ncurses interface to allow kernel modules that are available to be listed to the user. With the total amount of things that can be set, this may confuse the hell out of some "fast-food" users. Screw them, though.

I can also set up a monitor for frequency, manually adjustable interface for CPU frequency scaling, and how often (per cycles) that the governor actually checks the CPU frequency.

For the more insane users, as long as we're using sudo, which we'll need anyhow...they might as well have the freedom to attempt to ignore BIOS set throttles on the CPU and allow an attempt to pass arguments to the processor via the Kernel. I can do this too, but it could be a VERY bad thing in some cases.

Thoughts?

[machinebacon]

system-core agnostic. <- thanks!
pstate power scaling driver <- didn't know about this
allow kernel modules to be listed <- YUM!
confuse the hell out of some <- YUP!
Screw them, though. <- YEP!

monitor for frequency
manually adjustable interface for CPU frequency scaling,
and how often (per cycles) that the governor actually checks the CPU frequency.

For the more insane users <- SIGNED!
but it could be a VERY bad thing in some cases <- Comes without warranty anyway :)

Thoughts?

Good points, especially the inbuilt power scaling driver was completely now to me (due to lack of quality time reading the kernel mailing list)
I'm absolutely okay with a verbose output/setting options or manually adjustable scaling. Those who don't know how to use it can still use the command-line governor; nobody is forced to click on a [Expert] button in which all the red buttons and knobs can be switched on and off ;)

Everything that is potentially dangerous (like overriding tresholds) should just have some kind of visual feedback. No more hand-holding - ain't nobody got time fo dat.

:)

Of course only attempt things that existing tools cannot do for us. I absolutely love those nice little things that (formerly) the /proc folder had it store (today it's /sys/devices/system and sub), so let's get these things into some visually pleasing (as in: human-readable) output.

In a word: full verbosity, plus expert mode.

[DebianJoe]

No more hand-holding - ain't nobody got time fo dat.
In a word: full verbosity, plus expert mode.

Happily moving forward wielding an axe and making exciting stuff happen.

[Titan]

How about a modification for htop to show network interface download and upload speeds next to the cpu bars?

Or maybe a simple modification to ranger that shows notifications in another ranger tab, to notify of errors and job completion?

[DebianJoe]

Modifications, such as a .diff that allows the user to modify it? I wouldn't think that htop needed that OOTB, but I could consider a plug-in...or a stand alone if there's not already a good one out there. I'd have to look into it. It certainly is worth discussion, though. I'll probably be on the systems tool for a little while, as it's a very complicated business. Still, let me know exactly what you're thinking Titan.

Unix philosophy should always be forefront, IMHO.

[bones]

How about a modification for htop to show network interface download and upload speeds next to the cpu bars?

Modifications, such as a .diff that allows the user to modify it? I wouldn't think that htop needed that OOTB, but I could consider a plug-in...or a stand alone if there's not already a good one out there. I'd have to look into it. It certainly is worth discussion, though. I'll probably be on the systems tool for a little while, as it's a very complicated business. Still, let me know exactly what you're thinking Titan.

Unix philosophy should always be forefront, IMHO.

There's some tools out there:

https://github.com/sivel/speedtest-cli

[Titan]

I was thinking more of something similar to the way the awesome WM network widget works, not a test of your broadbands maximum upload and download speed.

[bones]

I was thinking more of something similar to the way the awesome WM network widget works, not a test of your broadbands maximum upload and download speed.

Ah, gotcha. Hmm, there's probably a way to do a simple *coughcough* conky *coughcough* for that. :D

[DebianJoe]

Okay, I think I'm following you Titan.

In the meantime, for those of you who still have single core CPUs, the bbqsystool at least has basic throttling, kernel module listings, and CPU-info procs for details on what hardware you're running and what modules control it. It's nowhere near done, but it does do what it says on the box so far.

On multi-cored systems, I've yet come up with a really clean way to loop through the settings for all of them...so wait a day or so for me to finish that. If you do wish to play with the interface, though, keep in mind that you can check how it's working with "watch grep \"cpu MHz\" /proc/cpuinfo" from a shell to keep 2 second updates on the CPU speeds. I've managed to get the t43 to hold steady at 800MHz, and to stay consistently at 1.869 GHz, or to vary up and down.

deps = ncurses.h libc
install by just porting the bbqsystem.c to a directory and build with "gcc bbqsystem.c -lncurses" for now. I'll make it more user friendly later. Makefiles are bloat.

*note, initial pre-alpha...that interfaces with CPU via kernel. No warranty.

[Titan]

I was thinking more of something similar to the way the awesome WM network widget works, not a test of your broadbands maximum upload and download speed.

Ah, gotcha. Hmm, there's probably a way to do a simple *coughcough* conky *coughcough* for that. :D

IMO conky is bloat.

[DebianJoe]

IMO conky is bloat.

I agree. http://www.ex-parrot.com/pdw/iftop/...reduced bloat + what you want. Spawn one of those little floating windows and use it for iftop and htop at the same time.

[Titan]

Just tried iftop, great little tool. Well thats one less idea for you to try Joe :)

Thanks for the suggestion.

[DebianJoe]

No problem Titan. Happy networking. ;)

edit: It may be a bit longer before I get multi-core capability due to null termination issues. I went from getting the reading that I have 1 CPU core to -17834238 CPU cores...I'm going to have to rethink how I'm going to count them.

[DebianJoe]

In just a few moments, I'll push the newest systool. It now supports as many cores as it can locate.

Testing on a dual-cored system: Powersave, using grep to make sure that I'm changing stuff.


Cranking them up:


I require the user to launch as superuser (sudo), now...but it keeps me from having to perform interrupts, and for whatever reason Linux doesn't like to let just anyone go around playing with processor rates.

Edit: Uploaded. Verbose mode, better documentation, and makefile to come.

[machinebacon]

Hey Joe, I heard you shut your curses down.. ;)

Following thing happens when run in a terminal emulator:

I suppose that the term is not reset - haven't looked into the code yet (might be a refresh(); missing, no idea)
Generally, the items don't seem to clear the screen after selection:

Of course, this might be the problem of lxterm - I'll check it in a moment in tty (where it is supposed to run in the future :wink wink:)

Edit: yup - if I select the first item (in tty), it just leaves a blinking cursor at the bottom of the screen, bailing out with Ctrl-C does change the screen to what should have been printed and the app exits (of course).

[DebianJoe]

I have used urxvt without issue. I will test on lxterm to see if I can replicate it.

Wait, are you saying that it does the same thing in TTY? Running it under Elektra via tty seems to be working fine for me.

[machinebacon]

Added and edit ^^ above.

So I run the file, the menu pops up, I hit Enter. It clears the screen and shows:

Code: Select all

bbq@grill:~/bbqsystool$ ./a.out 

(basically the command I entered before)
Only after Ctrl-C it changes to

Code: Select all

Governing Settings for acpi-cpufreq.
Press a number to go set value and go to menu.
1).Conservative.
2).PowerSave.
3).On Demand
4).Performance.
bbq@grill:~/bbqsystool$ 

and bails out (due to Ctrl-C of course)

Edit: same with su - and sudo (this is in bash, no custom .profile and no .bash_profile file)
Edit 2: and the same in urxvt

[DebianJoe]

^^ Using xterm and lxterm and urxvt and tty all work for me, so let's see what's different.

You're building it using "gcc bbqsystem.c -lncurses" to link to the ncurses support, correct?
I have used it across 3 systems without seeing this so far, so please specify your lilbncurses edition.

[machinebacon]

Yes, I did build it with the ncurses link.

libncurses5:
Installed: 5.9-10

not the very newest -20, so I up it:
libncurses5:
Installed: 5.9+20130608-1

and all is well. Sorry for the wind :)