identical PCs, different thread speed

[Craig Leidholm]

Here's one I can't figure out. I have three identical laptops (IBM TP A21p) running my application created in LW/CVI 6. All have same memory, CPU, Win2k... I updated my application a few months ago by adding a seperate thread for a DAQ communication to an instrument across RS232. It has been working perfectly on my PC and one customer's PC for several months now. Just recently, I upgraded another customer's identical laptop and, when the application is communicating to get data from the instrument, what typically takes 3-5 seconds takes 15-30 seconds on his PC. And since this DAQ happens hundereds of times as the system does its scans, an experiment that used to take an hour now takes 4-6 hours. Moreover, he loaded the software on
another laptop in his lab and had the same problem. I went there with my laptop and the thing ran perfectly.

So I updated his PC with the newest Win2k service packs, updates its BIOS, and all the most recent drivers for the laptop, removed a few applications that might have conflicts and no improvement. I uninstalled and reinstalled my application just to make sure -- no improvement.

Short of reformatting the HDD and starting over, what can I do?

[msaxon]

I have just been investigating a similar problem. I have a data acquisition app which has three threads: one for HMI, one for data acquisition and one for data processing. During a data capture run, both the data acquisition and data processing threads are 'busy' threads - they have some Sleep(0) calls, but otherwise are busy all the time, checking to see if data is available and then processing it.

This app works fine on most PCs but one customer was having difficulty - the data acquisition thread reported that it was running out of time to do its stuff. On investigation, I found that, on my customer's PC, that particular thread was getting hardly any processing time even though all threads run at the same priority.

I found I could cure the problem by putting the b
usy threads to sleep on a regular basis for a non-zero amount of time. I used Sleep(5), because I couldn't afford to let them go to sleep for a long time.

Paradoxically, putting these non-zero Sleep() calls into the threads resulted in Windows giving them more time than they had previously.

So, I don't know if that story will help you at all but I would be interested to know if it does! Also if anyone else knows why Windows exhibits this peculiar behaviour.

--
Martin

[Craig Leidholm]

So, if these non-sero Sleep() calls resulted in more time than previously for the non-DAQ threads, did the DAQ get more time to do its stuff?

I already have my SetSleepPolicy() at the minimum to try to combat this, but that obviously didn't do the trick. I'll try the non-zero Sleep() calls in the non-DAQ threads to see if those help.

By the way, I noticed that, if I do something on the HMI while this ridiculously slow DAQ is occurring, such as select a pull-down ring control, the DAQ suddenly picks up and screams at its normal rate. But as soon as I get off of the control, it goes back to its lethargic pace. Needless to say my customer is not pleased at the moment and I'm at a loss.

Thanks for the reply.

[msaxon]

Yes, putting the Sleep(5) calls in the DAQ thread resulted in the OS giving more time to that thread. Wierd.

--
Martin

[Heinz Hoeffken]

Hi,

With respect to laptops 2 disadvantageous facts could coincidence:

a) Your measurement application enters a kind of idle state e.g. when
waiting upon measurement results coming from external instruments

b) The laptop owner has activated some operating system power management
functions to spare energy of the notebooks battery.

The SDK (subject >System Sleep Criteria< ) comments:

As long as the system determines that there is application activity,
it will not put the system or any devices into the sleeping state.
The system can detect certain activities, such as user input or network
communications. However, there are other activities that the system cannot
track. For example, a presentation application requires the screen
for
display. However, it may appear that the application is idle during the
presentation, causing the system to turn off the screen. To notify the
system that your application is busy, use the SetThreadExecutionState
function. This function prevents the system from placing the system or
any devices into the sleeping state while the application is running.

The solution could be to simply include 2 lines of code:

#include >windows.h"
SetThreadExecutionState(ES_SYSTEM_REQUIRED);

kind regards

Heinz Hoeffken