Software utility for Sagers! - Page 13

Yes, using the Scroll lock LED might be a more portable way for such tasks. However, I have to see if it will be a more general solution or just something I will use on my Clevo notebook.

Related to the programming languages, I'am flexible here among some of them. Usually I'am doing most stuff nowadays in C# and Java, but for more response time critical and hardware related apps I would perhaps use C/C++ instead. - Usually I wanted to make it just for fun with C# here (using VS.Net 2003 or C#B), since it would be a good test example in order to see how capable C# would be for such custom apps. - But maybe C++ would be better suited from a performance point of view. Beside this, it would give me a chance to try out the Borland C++BuilderX Ent IDE which I have and never installed, tried out or used so far (shame on me...).

Ok folks, I've just found another way of working with the Sager 8890/Clevo D800P LEDs... - However, maybe this is more interesting for Henrik from a UI design point of view (?).

Those who are Sager 8890 owners or just interested in some sort of mini demo (...well, things are just at their very early beginnings and so this demo doesn't actually do much at all...) might give it a try if they like. - But please NOTE that you will need at least to have the Microsoft .NET Framework Version 1.1 Redistributable Package installed, in order to run this demo app under Windows 2000 or Windows XP (in case you don't already have this preinstalled), otherwise you can't run this demo app.

The Microsoft .NET Framework Version 1.1 Redistributable Package is available here:

http://www.microsoft.com/downloads/d...displaylang=en


The D800P demo app I initially talked about can be downloaded from here:

http://www.kyrsoft.com/temp/d800simu.zip


Greets

krobotkin

what does the demo show?

Momentary the demo just shows up an 8890 image app where you can:

- turn on/off the simulated computer via it's power button, when it's turned on the green LED should flash on

- use the simulated computers email button to start your default email client, the email LED should start to blink orange now...

- use the web button, to start your default web browser and let it visit this PcTorque Sager forum...

- use the above right "Reboot" button to simulate a sort of Windows reboot...

- and finally use the "Quit" button to quit the whole simulation app


If I find enough free spare time, I will turn it into a custom 8890 EmailMonitor (similar to the email tool supplied with the Sagers/Clevos) or some other system status info like app. - If Henrik likes, we can also host the temp monitoring and fan setup stuff on something like this for the 8890 notebook line...

WOW Excellent app Henrik.
My fan usually kicks in at 55C and shuts off at 45C using your MaxFan I run it for about 10 minutes and got it down to 36C.
Why does the CPU underclock when you run off batteries?
It drops from 3.23Ghz to 2.56GHZ.

Henrik, please read.

Go to Start>Control Panel>Power Options. You can change it there.

And Henrik, is there any way to accurately view what my CPU is clocked at when using your BatterySaver app? MobleMeter's measurement jumps around all over the place. It'd be nice to know when I do my "underclock and see how long the battery lasts" tests.

Vilken kille!

Bra Henrik. Sätt Sverige på Kartan på det här forumet också jag håller på försöka köpa en SAGER 8790s

Yes I speak Swedish and so does Henrik

/WarOrc

DOes it work on the 8790?

Hey does this cool app work on the 8790?

Thanks,
Sean

actually believe its gotta be done in ur bios. Disable to underclock function when you first start it up. I checked my power settings and its not listed, might be different for you though

I'm pretty sure I saw a list of options for when running off the batter. Not totally sure though as I'm at work.

EDIT: Just got home and you're right. My bad. I was thinking about the 'turning off stuff' options.

Since I'am too lazy to code this up in some higher prog language (like C/C++/C# etc.) you can use another trivial scripting way for showing this up.

Save the following windows script in a text file and name it ..let's say.. "processor.vbs" or something like that (make sure you give the file an ".vbs" extension):

--------- start cutting out here -------

--------- end of cutting out -------

Now you can start that vbs-file from your windows desktop or explorer via a double click and inspect your actual CPU clock speed. This little script should pop up dialog window which shows you the relevant clock speed datas. - I've leaved out some of the other 20 CPU datas which can be shown up here too.


To obtain the current CPU temperature, as it might be setup inside the win ACPI driver tables for the Clevos, try out the following (again save the contents to some "temp.vbs" file etc.):


---------- start of cut out here -----------

-------------- end of cut out --------------

BTW, I haven't tested those things on a Clevo notebook so far, since I'am actually not at home, but usually the above scripting stuff should work. For the ACPI based current temperature script, I believe that this is just a boring static value inside the ACPI tables which doesn't get updated by the Win OS so far (at least I think so...). In other words, this shown up value will maybe never differ when you repeatedly call that temp.vbs script again and again.

Greets

krobotkin

Awesome, thanks Krobotkin. The CPU one works here at work (dual amd processors), but the temp one does not. I'll let you know when I get home and try these out on my 8890

Pyrobob, the TEMP one will only work for ACPI based platforms, e.g. mostly notebooks based ones, since most desktops use other mbios sensoring ways here. - However, as I mentioned before the ACPI temperature itself can be retrieved from Windows WMI functions, but there is one big problem in this MS WMI implementation, namely the temperature does not update at all. It will be updated only when the system (notebook) is rebooted or resumed from standby state, or when the temperature gets very high. - So far I haven't found out if there is some way to force the Windows OS to update/refresh it's thermal CPU data settings via WMI ACPI scripting functions.

It seems, this behavior is by MS design, e.g. if the OS does not need to know the change of temperature, the change of temperature isn't notified to the OS, and the OS does not try to read the latest temperature. While the temperature is cool enough, the OS does not need to know the event and the WMI temperature is not updated.

Related to the processor clockings, I'll also have some better script solutions which also take multiple/dual processors etc. into account and which also work network wide (they can remotely access other machines). Those other scripts UI presentations are also much better, since they reuse some borrowed IE browser window for information showup and they are capable to update their contents periodically. Beside that, these offer to showup/hide the individual listed data entries.

If there is some general interest for some other monitoring or inspection WSH/WMI scripts, like showing up hdd, memory, bios, video, process... etc. datas, which everybody can easily customize and run himself, let me know and I then maybe post some of them here.

thats cool man. didn't know that i could program stuff like that... the temp one keeps giving me the same readings though "61 C-141 F" even while running MaxFan. any ideas why? thats for the help robot

I volunteer to test it on an 8790 when you get round to added that functionality.

zach, according to his last post,, try this

run maxfan. CLose the program but dont stop it. Meaning dont hit auto, just the x

reboot the machine then run his program. See what the temp says then

Krobotkin, that cpu code you gave me... does it check for the current clock speed? Because I ran it and it showed accurately my speed (3000). Then I ran Henrik's batterysaver app and ran it again and it hadn't changed. One or the other program isn't doing it's job.

Hmm, I've used a derivate of that clock speed script on my D800 and when I run the notebook on battery and start the script, it shows for my 3.4 GHz CPU a clock speed of 28xx, which seems to be correct for the CPU clock speed when on battery mode, since the FSB gets down on bat mode so that the CPU just runs as a 2.8 GHz one.

I don't know how Hendrik's app is working, e.g. if his app clocks down the CPU's FSB or the like and if yes, if it also notifies the OS about any FSB and thus finally clock changes (?). - All the WMI (Windows Management Instrumentation) scripting functionality I've used is based on standard Windows capabilities, e.g. there is nothing special I've added to the base routines or the like and so it relies on Windows WMI detection and update features itself.

Best you try that out together with some other trusted app, which is capable to showup the real actual clock speeds via direct hardware addressing (maybe CPUZ, Sandra or Aida etc.) and then compare these with the scripting results.

I believe that Windows doesn't get any updated/refreshed data values and so the initial value it has during startup will be preserved and always shown up, no matter how often you restart the script, it will always show up the initial value. - That's one of the bad things about the Windows Management Instrumentation implementation together with their ACPI communication. So far I haven't found any way to tell the Windows OS to update and request the actual underlayed hardware thermal values via some WMI methods. I'am actually even not sure if it is possible with WMI alone to get such refreshes...

I know from the MobileMeter author that he once too discovered this MS WMI pitfalls and thus he has programmed (after a lot of tryouts and errors) some sort of direct low level ACPI driver access for his MM program. Of course programming some direct driver access hooking in C/C++ etc. is much more complicated and difficult than using the windows scripting host capabilities together with the predefined WMI structures.

Generally the best way to solve this would be the way Hendrik will hopefully take, e.g. reading out the sensor datas directly straight from the hardware smbus, even that is by no means a trivial task and so hard to find out all the hidden secrets.

Another TIP from me for those who don't use MobileMeter so far for reading out the temperature values would be try out the actual hmonitor version. AFAIK, the actual hmonitor implementation should support the Clevo/Sager Hitachi H8 processors too and thus might be capable of reading out the actual temps directly from the hardware! - See: http://www.hmonitor.com/

hmonitor only read cpu temp for the 8890. It also reads a temp ~4-5 degrees higher than mobmeter displays. Dont know why. But the functionality of that program seems really neat. I wish it worked