Unexpected behavior when running parallel while loop on quad core

[Aristocrate]

Hi crossrulz,

I read it in the USRP documentation again a few minutes ago. Queues are apropriate when exchanging data among threads.

I've put all operation in a single loop. It works fine still I try to transmit a 5M bandwidth signal there occurs a buffer underflow.

The read speeds from drive is limited to 125MB/s in contrast to a 1GB/s for transmission between USRP and host computer. That's another argument for choosing Producer/consumer architecture.

The wait time I refer to in my comment is the time at wich the USRP start to generate data. Upt to tha time the device buffer is filled.

welll both loop works parallely when USRP generate a timestamp Error. for it no longer process any data at its input.

Solving the timestamp error will certainly resolve the problem.

The LabVIEW 11 version of the VI is attached to this post

[crossrulz]

---

@Aristocrate wrote:

The read speeds from drive is limited to 125MB/s in contrast to a 1GB/s for transmission between USRP and host computer. That's another argument for choosing Producer/consumer architecture. 

---

But the producer is way slower than the consumer.  That is your problem.  You should just queue up as much as you can from the file read and just let the USRP do its thing.

[Aristocrate]

Hi crosscrulz,

I could solve the problem by properly arranging synchronisation VIs into my program. Both loops can now works parallely (with normal while-loops).

Now, I face the same isssue reported here

That's due to discrepancy between read speed from hard drive and transmission speed to USRP.

Thanks for your support

[MarcoMauri]

Hi!

did you try reading an array of clusters from your file instead of a single element?

I think this could increase reading speed...

Marco

[Aristocrate]

Hi Marco,

the CDB WDT does not allow for reading a single element; you will always read and Array. The size of Array you read from hard drive is inherent to the chunks size from record process. Therefore, setting again the size of bytes to be read at the read from binary vi, results in an array of cluster, which is not compatible to TX vi unless you convert the array back to single elements  

[MarcoMauri]

---

[...]. Therefore, setting again the size of bytes to be read at the read from binary vi, results in an array of cluster, which is not compatible to TX vi unless you convert the array back to single elements  

---

 If you are limited by the producer loop, I think you can get a little bit faster by reading the array of clusters and converting it back to single elements before TX vi. This is just a way to reduce the number of times you access the HD.

Regards,

Marco