KamenG
March 4th, 2004, 05:51 PM
I have a modular software product that consists of multiple components written in different languages: LabVIEW, C/API, C++/MFC. Modification of the LabVIEW code is not an option at this time so adding functionality is limited to small modifications of the C-code and writing plug-ins in VC++. The plug-in that I'm currently working on uses UDP/IP (thorugh the MFC AsyncSocket) to communicate with a real-time target. The process runs in Real-Time priority class yet when the labVIEW front end (which runs in Normal priority) starts taking a lot of CPU cycles (20-50% and more according to TaskManager) the communication is starting to suffer - serious latencies are incurred.
At this time my belief is that the stock Windows TCP/IP stack is buffering the datagrams to allow the front end its extensive use of the CPU. The latter doesn't really need the cycles since it mainly provides a user interface, which is not critical but I have no idea how to change that short of using a real-time extension with its own TCP/IP stack and API (like VenturCom's RTX).
Any thoughts on what I can look into to identify the culprit with certainty and then to improve the response? Thanks in advance.
Kamen
At this time my belief is that the stock Windows TCP/IP stack is buffering the datagrams to allow the front end its extensive use of the CPU. The latter doesn't really need the cycles since it mainly provides a user interface, which is not critical but I have no idea how to change that short of using a real-time extension with its own TCP/IP stack and API (like VenturCom's RTX).
Any thoughts on what I can look into to identify the culprit with certainty and then to improve the response? Thanks in advance.
Kamen