What can cause a read of a Fieldpoint channel to execute slowly?

[WayneS]

I have written a DLL that uses MeasurementStudio to communicate with an ethernet FP module. A simple read takes about 2 - 3 msec when called from a simple test app (written in C or C++ or LV). However, when I try to use my DLL in a more complicate app (multi-threaded, running at Window's highest priority, with different threads assigned to different priorities), I find that the call that is reading channel data takes over 500 msec. Does anyone have any ideas on what can be going on here? Is there some limitation where my app may be interfering with DataSocket server by running threads at a high priority?

Thanks in advance.

Wayne

[Chris Matthews]

Yes, definately. DataSocket uses multiple threads internally. If you are setting threads to high priority, you will take away almost all of the CPU time from the other threads unless the high priority threads are sleeping (Sleep function). You have to be extremely careful with thread priorities. Usually, any high priority thread should be implementing some internal sleep to make sure other thread's get time to execute. Thread priority is almost definately the cause for the time delay you are seeing.

Best Regards,

Chris Matthews
National Instruments

[WayneS]

Chris,

It seems a bit more complicated than a simple matter of threads using up all of the CPU time.

While my app that gives me a 500 msec read time on a channel is running, I can also launch a simpler (single-threaded) app that calls the same DLL (mapped into its own address space, of course). That simple app takes about 2-3 msec for a read.

I have also tried dropping the process priority level of my multi-threaded app from real-time to normal, with no effect.

I have checked out my CPU usage with the windows task manager (Win 2k). The CPU usage is only in the 20 - 30% range while my multi-threaded app is running. This seems pretty acceptable to me.

Is there something going on behind the scenes in DataSocket that I should be aware of?

Way
ne

[Chris Matthews]

No, not really. DataSocket uses separate threads to monitor for activity and post messages. These are all normal priority threads so even one high priority thread in your application will take precedence over them. If you have a high priority thread in your program that is not sleeping at all, it could block the other normal threads even if the CPU isn't completely used, especially if the process priority is lowered. Try getting a debug utility that will show you the CPU usage per thread. There is one called TaskInfo2000 you can get from download.com that would work. If you want NI to look at the problem, you can contact our tech support via http://www.ni.com/ask.

Chris

[TonyH]

Wayne,

Here are two ideas:

(1) In Windows 2000, Microsoft introduced a new "application booster" algorithm that appears to re-prioritize your threads for you and seems to give precedence to maintaining UI responsiveness over all else. I would try turning application boosting off by going to Control Panel>>System Properties, selecting the "Advanced" tab, choosing "Performance Options", then choosing "Background Services" under "Optimize performance for:". This will turn off the application booster and keep threads and processes at their initially assigned priorities. This setting doesn't "boost" background processes, it just refrains from boosting foreground applications (at least as far as I know).

(2) One potential "behind the scenes" Da
taSocket issue is that DataSocket is an apartment-threaded COM server and, as such, it relies on using the Windows message handling system. If you are doing anything that might obstruct the message pump in the thread that created the DataSocket object, such as running a long function in that thread, blocking it, lowering its priority, or otherwise keeping the message pump from running, then it will impact DataSocket performance as well.

Hope that helps.

Tony
NI - Measurement Studio

[WayneS]

Tony,

Thanks for the suggestions. I already have priority boosting switched off as you suggested in your first idea.

Your second idea may be getting to the heart of the matter. I guess I am not sure of the details of what may be happening here. The thread that creates the DataSocket object is not processing windows messages. Because the app is not expected to receive many messages (except, maybe WM_DESTROY), I don't worry about keeping the message pump running at all times. In fact, the main thread (which runs the message pump) of the app gets put to sleep at times while it waits for other threads to do their thing. Do I need to always keep a message pump running? If so, does it need to be at a higher priority than the thread t
hat is making the DataSocket calls? How many messages must be processed each time my app reads a channel?

Wayne

[TonyH]

Wayne,

I almost forgot you are using FieldPoint. In this case, the DataSocket objects are getting called in a separate thread that is dedicated to FieldPoint communication. It is possible that by boosting the priority of other threads you are preventing this dedicated thread from running. Have you tried running your program with all threads set to normal priority, but with the process priority raised.

Also, FieldPoint is not particularly high speed and applications running at normal priorities should be able to keep up in most cases. Are you doing some other sort of data acquisition or analysis in your program or analyzing that requires the incremental performance gains that you might get by changing thread priorities?


Tony
NI - Measurement Studio