On 09/11/2023 09:45, Swannick, Matthew (FP) - IC via USRP-users wrote:
Hi,
I have previously sent the same message via e-mail so please discard
one of the messages.
I am performing testing of transmit streaming using Ettus SDRs and
encountering underruns, which I would like to eliminate.
I believe the problem is related to the rate at which samples are
being read from the storage or host OS scheduling (rather than
configuration of the Ettus itself), but was wondering whether you may
still have some suggestions please.
I am doing the following:
·5 * Ettus B205mini SDRs are connected to a Linux based host computer
via 5 independent USB 3.0 connections.
·The host is simultaneously streaming samples to each of the 5 SDRs.
·The samples are being streamed from 5 different sample files, one
file for each SDR.
·The sample files are stored on a fast SSD on the host.
·The SDRs are transmitting at different sample rates (between 20MHz
and 55MHz).
·The code being run by the host is based on the Ettus example program
- tx_samples_from_file.cpp, but has been enhanced to run 5 separate
transmit streamers simultaneously.
The problem:
·For debug purposes the streaming code running on the host measures
the time taken to read each buffer of samples from the SSD.
·Some of the times taken to perform a read can be quite high – a few
1000us. This causes the underruns.
·The average time to read a buffer is much smaller than this - just a
few us. So the vast majority of reads are fast enough and do not underrun.
·There is a large variety in the buffer read times - I would like the
buffer read times to be consistent, which should eliminate the underruns.
·The measurements show that the SSD/USB/host CPU, etc, are
fundamentally fast enough, but some individual reads of the sample
buffer can be slow.
·I believe I can fix this in software via a queuing system to counter
the variations in read times, but would prefer to find a root cause
and if possible fix the source of the high read times.
I was wondering whether Ettus could have encountered this sort of
thing before and whether there are any suggestions please?
Hopefully the description makes sense, please let me know if any
further information would be useful.
Many thanks
Matthew Swannick
CONFIDENTIALITY NOTICE: This email and any attachments are for the
sole use of the intended recipient and may contain material that is
proprietary, confidential, privileged or otherwise legally protected
or restricted under applicable laws. Any review, disclosure,
distributing or other use without expressed permission of the sender
is strictly prohibited. If you are not the intended recipient, please
contact the sender and delete all copies without reading, printing, or
saving.
L3Harris Technologies UK Limited is a private company registered in
England with the company number 11111631 whose registered office is at
100 New Bridge Street, London, United Kingdom, EC4V 6JA.
For information on our Privacy & Cookie Policies, please visit our
website: https://www.l3harris.com/en-gb/privacy-policy
_______________________________________________
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-le...@lists.ettus.com
You might spend some time studying Linux performance tuning with respect
to file I/O:
https://www.yugabyte.com/blog/linux-performance-tuning-memory-disk-io/
And likely dozens of other articles like it.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
