Ignore Virtual Cores, And Other Things

[vpshockwave]

Hey guys!

First of all, I'd like to say this is a fantastic piece of software! Good enough to convince me into buying it! I love having everything on my G15 LCD in one place!

That said, I do have a few suggestions that I think would add some useful options.

First, the ability to ignore virtual cores in the CPU Utilization reading. I can either monitor all 6 of my physical cores at once, or I can monitor the CPU as a whole, but when I monitor it as a whole, it factors in the virtual cores which are usually barely, if at all, being used. This has a detrimental effect of the CPU Utilization reading (it cuts it in half basically, thus making it inaccurate). The ability to ignore the virtual cores would make this more accurate in my opinion.

Second, polling times less than a second. I realize the polling can eat up CPU, but for those of us with the CPUs that can handle it, polling times in milliseconds would be a great addition. I would love a 500 millisecond polling rate, and I know my CPU could handle it.

Third, add the ability to drag / resize the LCD items with the mouse, rather than have to use the arrow keys or hit modify to change the length. This would make the custom LCD screens much easier to modify and create.

Thanks for the great piece of software guys! Keep it up!

[Fiery]

Thank you for the suggestions.

1) Virtual cores cannot be ignored, because it would make the CPU utilization measurement completely false. Even when the virtual cores are only working at 1-digit percentage load most of the time, such small load will still count. And with proper benchmarks and proper stress test modules (like what AIDA64 implements) it's quite easy to stress all cores -- incl. virtual ones -- to 100%. If you're bothered having your virtual cores sleeping all the time, then you may want to disable HyperThreading in the BIOS Setup

2) Less than a second polling time may be handled by your processor quite easily -- and in fact most multi-core processors could do that --, but the problem is not there. AIDA64 has a hardware monitoring module that has a set of sub-modules to handle various tasks. One of those sub-modules is for core temperature monitoring, another is for motherboard sensor chips, a third is for GPU monitoring, etc. etc. A few of those sub-modules use HID or COM (serial) port sensor devices like T-Balancer and Koolance. Such communication protocols tend to be very slow compared to other modules, which effectively means reading sensor values could last 200 to 800 msec (!), regardless of how fast CPU you have in your system. On top of that, when you have a high-end desktop system with 6 or 12 cores (1 or 2 CPU sockets), 3 or 4 GPUs (e.g. two HD6990 cards) with multiple sensor chips connected, the regular sensor readouts can also take more than 500 msec combined. Hence using a more rapid update rate could well mean a constant sensors polling or a deadlock.

3) We'll check the LCD screen drag&drop ability, IMHO it's a good idea.

Regards,

Fiery

[vpshockwave]

Thank you for the suggestions.

1) Virtual cores cannot be ignored, because it would make the CPU utilization measurement completely false. Even when the virtual cores are only working at 1-digit percentage load most of the time, such small load will still count. And with proper benchmarks and proper stress test modules (like what AIDA64 implements) it's quite easy to stress all cores -- incl. virtual ones -- to 100%. If you're bothered having your virtual cores sleeping all the time, then you may want to disable HyperThreading in the BIOS Setup

2) Less than a second polling time may be handled by your processor quite easily -- and in fact most multi-core processors could do that --, but the problem is not there. AIDA64 has a hardware monitoring module that has a set of sub-modules to handle various tasks. One of those sub-modules is for core temperature monitoring, another is for motherboard sensor chips, a third is for GPU monitoring, etc. etc. A few of those sub-modules use HID or COM (serial) port sensor devices like T-Balancer and Koolance. Such communication protocols tend to be very slow compared to other modules, which effectively means reading sensor values could last 200 to 800 msec (!), regardless of how fast CPU you have in your system. On top of that, when you have a high-end desktop system with 6 or 12 cores (1 or 2 CPU sockets), 3 or 4 GPUs (e.g. two HD6990 cards) with multiple sensor chips connected, the regular sensor readouts can also take more than 500 msec combined. Hence using a more rapid update rate could well mean a constant sensors polling or a deadlock.

3) We'll check the LCD screen drag&drop ability, IMHO it's a good idea.

Regards,

Fiery

Thanks for the quick response. I'd rather not disable HT because I know it does get used, though rarely in gaming it seems. It's just annoying see that my CPU is supposedly being used @ 30% only to check the cores and find that all physical cores are at 60-70%. I know some applications like stress testing and benchmarks can eat the hyperthreading alive, but in real world applications (outside of, say, video encoding), they seem to rarely be used in any significant way. But I do understand your point. I'm not a programmer by any means, merely a gaming enthusiast.

Keep up the good work!

[STM]

i like the idea about LCD drag&drop

that would help speed up editing things