New ConKit (10077) eating up System resources!

[jebem]

I had a look into this issue as well.
I have just installed the Connectivity Kit on a Windows 8.1 laptop having SSD drives and a Intel i7 dual core with hyper-threading enabled processor (total of 4 "cores" on Windows).

I have no virtual calc or psychical calc connected.
As soon a I run the Connectivity Kit exe, the Connectivityit.exe process is consuming 100% of the available CPU Core resources, running in a very tight program loop.

This is a single-threaded program, so if you have a multi-core processor you will not see 100% total processor usage because Windows will schedule the process threads, one at a time, to one of the cpu cores in a round robin fashion.

To see this 100% scenario, just set CPU affinity on this Connectivityit.exe process (in task manager or in process explorer): then you will be able to see that the process consumes 100% of this core.

I have to say that this is old news. I remember to see this behavior in older program versions as well. I just don't remember which ones.

While this behavior is annoying, it is nearly harmless as long as your Processor has adequate temperature monitoring and adequate refrigeration/ventilation.
Of course the electrical power consumption will go up as well, and this is important if you are running the program on a battery powered laptop.

Basically the process is looping doing some kind of I/O control functions (not the regular data read/write I/Os), checking the file system and the registry at a very high rate, depending on how fast is your PC system.

There are plenty of tools to monitor this, starting with the MS sysinternals.
(I remember Mark Russinovich presentation at one of the Microsoft Teched in Barcelona long time ago, just after he joined Microsoft. Really enjoyed and learned from his Windows debug presentation. What an expert he is!).

This very busy looping activity generates the following metrics:
- CPU average of 57% user time (non privileged, application level);
- CPU average of 43% privileged time
- 63 I/O other Operations/sec (I/O control functions)
- 1350 Interrupts/sec
- 118 DPCs Queues/sec
All the other metrics are close to zero activity. So no I/O data access to disk, no physical or virtual memory issues, no network activity, just a very busy program loop consuming as much CPU as possible from a single core.

As I see it, scalability doesn't need this program behavior in order to cope with all the extra work to manage the maximum number of calculators connected to it.

As others have remarked, polling should not cause this heavy CPU usage behavior IF the poll rate is low enough.

What we see here is that the Windows kernel returns from the system calls but the program is calling it back all the time, hence you have 43% usage in Kernel and 57% usage inside the program itself (user time).

Probably all here knows about this one, but here it goes:
This tight loop cpu usage behavior is easy to simulate in Windows. One just needs a text editor and type something like:
@echo off
:loop
go to loop
Then save the file as test.bat, run it and set the cpu affinity for the process. We will see about 80% or more of cpu usage.

This reminds me of the good old days of MS-DOS when the Command.com was consuming 100% of the CPU only because it was idling in a really tight loop (this was a MS-DOS design feature, not a bug).
How do I know and care about this?
Well, because some VMware customers used to run MS-DOS legacy applications, we consolidated them as VM's. Then we noticed this performance issue caused by the Command.com behavior. For those interested, I used a well know 3rd party TSR, but really, one just needs to set a cpu usage limit on those legacy VM's to fix it.