Laggy Ethernet comm to cDAQ-9185

[torekp]

I've got a cDAQ-9185 chassis with four 9477 digital output modules, connected to my computer by Ethernet, writing samples at under 3 kHz (almost 150 samples, every 50 ms).  The task keeps giving error -200292 (could not write samples, not enough space) but the real problem is that samples stop being generated.  And that happens when there is a long time (~100 ms) between just before my DAQmxWriteDigitalU32 statement (in CVI LabWindows) and just after.  It seems that the attempted write doesn't go through until it's too late.  I have "Do Not Allow Regeneration" set, for what I think are good reasons, so when all samples in the buffer have been generated, it quits.

So, I suspect that Windows and/or the Ethernet port driver are taking their sweet time.  Questions:  is there a way to have Ethernet based control without massive timing jitter?  Or is it "Abandon all hope, ye who enter"?

Would a USB-connected cDAQ chassis perform more deterministically?

[ShaunR]

150 samples @ 50ms is about 24K/s if the samples are double precision. The default TCPIP buffer in Windows is 8K IIRC and if NAGLE is on, you maybe filling the buffer too quickly. I would try U8, if you are currently using doubles, to reduce the data amount and see if the problem perists. If it resolves it, then I would try turning off NAGLE and increasing the buffer to 65K to use doubles again.

Edited February 19, 2020 by ShaunR

[smithd]

theres no such thing as determinism over standard ethernet...

I believe cdaq will automatically pack the digital lines pretty effectively, but you can just use task manager (on win10) to see the network traffic, else use resource monitor. I wouldn't suppose there is any issue with the network. In fact, I wouldn't even expect that function to be blocking for an ethernet device, but maybe it is. Does anything else happen in task manager when you see the blip? Does it still happen if directly connected?

[torekp]

Thanks guys.  I already went to direct connection from computer to cDAQ, and that seemed to lengthen the duration without this error - although it's so intermittent that it's hard to tell.  I've never heard of NAGLE before, and on reading about it, it sounds like a likely suspect.  I'll see if I can finagle something.  (Hmm, I probably shouldn't pun-ish people for answering my questions!)

Edit: Fin Nagle didn't do me any favors.  Network traffic is 416 Kbps sent, which makes sense for my data plus a relatively small header per packet.  When I watch task manager as it crashes, the fall-off of traffic is a cliff, not a blip, when error -200621 happens.  I have yet to observe another -200292, but that could show me more of a blip; it will keep writing data for about 10 more cycles before the crash.  If I can figure out how to make the graph show multiple points per second (and yet not scroll away too fast).

Edited February 20, 2020 by torekp

[torekp]

I left off an important fact about what I was doing, and apparently, doing wrong.  After DAQmxWriteDigitalU32, I was doing DAQmxGetWriteTotalSampPerChanGenerated, DAQmxGetWriteCurrWritePos, and DAQmxGetWriteSpaceAvail.  Those diagnostics told me how the problem proceeded, but they also helped cause it.  Now that I commented them out, it has run for 17 hours, whereas mean time to failure was <1 hour when the diagnostic commands were used.

Ever see the movie Mystery Men?  One of the heroes, Invisible Boy, has his super-power only when no one is looking.  My cDAQ task can do its job, as long as I don't look at it.

Edited February 21, 2020 by torekp

[pallen]

Schrodinger's Task.  😁