NC_OP_START and NC_OP_STOP purpose

Question

I don't understand well the purpose of ncAction with NC_OP_START and NC_OP_STOP on a network interface object and I have no PCI-CAN available at the moment to test it.
Is it correct to say that the processor of a stopped board will accept the new frames written to the write queue with ncWrite but will delay the actual transmssion until a NC_OP_START is issued ?
I must send 18 frames over the CAN bus but the thread that calls ncWrite is interrupted by other threads of equal or higher priority and I end up with some unacceptable delay in the flow. May I issue a NC_OP_STOP then fill the write queue and issue a NC_OP_START and expect the frames to be sent without interruption by the board ?

Answer 1

Hello B2k,
The difference is 50s but I should have mentionned that those 50s are lost over 4096 stop/start cycles and each cycle places 18 frames in the write queue between the stop and the start. I open no CAN object and the whole process is performed at the network interface object level. The computer is a P3 at 850MHz.
I believe that a part of the delay may be due to the time it takes to write the frames on the queue. Without the stop/start action, (I guess) the first frame is sent on the bus immediately and the next frames follow as fast as possible. But when the board is stopped it must wait until it is started (i.e. all the 18 frames have been written) to send the first frame.
The driver may be faster with one board, but i
t is definitely slower when using four boards each driven by a separate thread. There is no document I could find to explain the changes between the versions, but I understand NI applied several patches to prevent some crashes in a heavily multi-threaded environment. One possibility could be they prevent concurent threads from running the driver at the same time to avoid reentrancy conflicts. I observe now that the CPU usage is around 60% when it used to stick at 100% with v2.1.2 and the process is a little bit slower (it went from 82s to 90s).