I don't think the problem is in the metadata, unless I'm really doing it wrong.
I've tried the suggestion you put out earlier, modeling my code after the
example txrx_loopback_to_file. The first packet has a startofburst = true and
subsequent packets have the start_of_burst value and the has_time_spec value
set to false after the first transmission.
// set up TX streams and threads
std::thread tx_threads[NUM_CHANNELS];
uhd::tx_streamer::sptr tx_streams[NUM_CHANNELS];
uhd::tx_metadata_t md;
md.start_of_burst = true;
md.end_of_burst = false;
md.has_time_spec = true;
md.time_spec = uhd::time_spec_t(0.1);
for (int i = 0; i < NUM_CHANNELS; i++){
stream_args.channels = std::vector<size_t>(1,i);
tx_streams[i] = usrp->get_tx_stream(stream_args);
//start the thread
std::cout << "Starting tx thread " << i << std::endl;
tx_threads[i] = std::thread(txTask,tx_buffs[i],tx_streams[i],md);
}
///////////////////////////////////////////////////
////////the thread function////////////////////////
////////////////////////////////////////////////////
void txTask(Complex *buff, uhd::tx_streamer::sptr tx_stream, uhd::tx_metadata_t
md){
size_t num_acc_samps = 0;
struct timespec start_time;
clock_gettime(CLOCK_MONOTONIC, &start_time);
while(!stop_signal_called){
size_t samples_sent = tx_stream->send(buff,BUFF_SIZE,md);
num_acc_samps += samples_sent;
md.start_of_burst = false; //after first transmission set to false
md.has_time_spec = false; //after first transmission set to false
}
struct timespec end_time;
clock_gettime(CLOCK_MONOTONIC, &end_time);
double runtime = (end_time.tv_sec - start_time.tv_sec) +
(end_time.tv_nsec - start_time.tv_nsec ) / 1000000000.0;
std::cout << std::endl << "Sent " << num_acc_samps
<< " samples in " << runtime << "s"
<< " Throughput = " << num_acc_samps / 1e6 /runtime << " Msps"
<< std::endl;
//send a mini EOB packet
md.end_of_burst = true;
tx_stream -> send("",0,md);
printf("End transmit \n");
}
Even with the metadata fix I still get underflows when transmitting and
receiving on the same channel, no matter what the rate. If you have an X310, I
wonder if you could compile and run my code and see if you get the same result?
Thanks,
Jason
________________________________
From: The Tilla <ti...@comcast.net>
Sent: Monday, August 14, 2017 4:47:31 PM
To: Jason W Zheng; mle...@ripnet.com
Cc: usrp-users@lists.ettus.com
Subject: RE: [USRP-users] Buffer underrun issue with simultaneous transmit and
receive on the X310
I think some of the issue here as well is the tx_metadata.
For continuous streaming, the first packet ONLY should have startofburst = true…
Further packets after the first one should have startofburst = false, cuz they
really are not start of burst, they are continuations of the initial burst.
Furthermore, for continuous streaming as soon as possible, you should not
provide a timespec.
If you continually provide a timespec to each packet, it will continually try
to send them at time = 0.1, which is not what you want…
If you want to start your tx at a specific time, then similar to startofburst,
you should only provide a timespec with the first packet, all subsequent
packets should not include a timespec.
Does that make sense?
It can be a bit confusing at first, but after writing a few apps, you will be
an expert 😊
From: Jason W Zheng [mailto:jason.w.zh...@aero.org]
Sent: Monday, August 14, 2017 4:41 PM
To: ROBIN TORTORA <ti...@comcast.net>; mle...@ripnet.com
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Buffer underrun issue with simultaneous transmit and
receive on the X310
Hi Robin, Marcus
It makes no sense to me, then why changing transmit to be on its own channel
(daughtercard) would cause the program to work.
// set up TX streams and threads
std::thread tx_threads[NUM_CHANNELS];
uhd::tx_streamer::sptr tx_streams[NUM_CHANNELS];
uhd::tx_metadata_t md;
md.start_of_burst = true;
md.end_of_burst = false;
md.has_time_spec = true;
md.time_spec = uhd::time_spec_t(0.1);
for (int i = 0; i < NUM_CHANNELS; i++){
stream_args.channels = std::vector<size_t>(1,i); //changing this from i
to 1 causes it to work for unknown reasons
tx_streams[i] = usrp->get_tx_stream(stream_args);
//start the thread
std::cout << "Starting tx thread " << i << std::endl;
tx_threads[i] = std::thread(txTask,tx_buffs[i],tx_streams[i],md);
}
The relevant line is commented in the above code snippet. When I change the
channels arguments for the tx stream_args to be on it's own channel
(daughterboard) separate from the receive, the underflows go away.
@Marcus, in the code I posted, there is no coordination between the transmit
and the receive threads. This is for example purposes. The transmit and receive
buffers are independent. The transmit thread buffer is prefilled with 0's and
is constantly transmitting 0's.
________________________________
From: ROBIN TORTORA <ti...@comcast.net<mailto:ti...@comcast.net>>
Sent: Monday, August 14, 2017 1:06:20 PM
To: Jason W Zheng via USRP-users; Jason W Zheng
Subject: Re: [USRP-users] Buffer underrun issue with simultaneous transmit and
receive on the X310
Willing to bet significant money your tx thread is being put on the physical
processor that does not have your NIC card attached to it...
Then, all data must go over QPI between processors.
NUMA is not good for this.
You can experiment with affinity to make sure things are all on the same
physical processor as your NIC...
We no longer buy multi-processor boxes for issues like this, NUMA is bad...
On August 14, 2017 at 2:32 PM Jason W Zheng via USRP-users
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
I'm running on a server with 2 Intel Xeon E5-2650 v4, CPU is listed here:
https://ark.intel.com/products/91767/Intel-Xeon-Processor-E5-2650-v4-30M-Cache-2_20-GHz
The network card I'm using is the recommended Intel X520-DA2
I also have over 500 gigs of ram, so that is not an issue
I don't think my cpu or network card are the issue as when I change my code to
receive and transmit on separate channels, it works without any underflows.
________________________________
From: USRP-users
<usrp-users-boun...@lists.ettus.com<mailto:usrp-users-boun...@lists.ettus.com>>
on behalf of Jason W Zheng via USRP-users
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>>
Sent: Monday, August 14, 2017 11:27:24 AM
To: ROBIN TORTORA
Cc: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Buffer underrun issue with simultaneous transmit and
receive on the X310
How should I set the tx metadata? My application will essentially stream
continuously.
Thanks,
Jason
________________________________
From: ROBIN TORTORA <ti...@comcast.net<mailto:ti...@comcast.net>>
Sent: Monday, August 14, 2017 11:17:07 AM
To: Jason W Zheng via USRP-users; Jason W Zheng
Subject: Re: [USRP-users] Buffer underrun issue with simultaneous transmit and
receive on the X310
I dont see you setting the tx metadata object members to any values, so you are
essentially going to tx with default metadata IF there is a constructor that
initializes all the members to a consistent value...
On August 14, 2017 at 1:56 PM Jason W Zheng via USRP-users
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
Since I haven't gotten a response in a week, I thought some source code might
help. I've removed any buffer dependencies leaving just the receive thread and
transmit thread. The receive thread is constant receiving to a buffer, while
the transmit thread is constantly transmitting 0s from another buffer.
On the x310, when I receive and transmit from the same channel (same
daughterboard), I get underflows (U's on the console), no matter what the rate.
When I put receive and transmit on separate channels, the U's go away.
How do I fix my source code so I can receive and transmit from the same channel
without underflows?
Thanks,
Jason
________________________________
From: USRP-users
<usrp-users-boun...@lists.ettus.com<mailto:usrp-users-boun...@lists.ettus.com>>
on behalf of Jason W Zheng via USRP-users
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>>
Sent: Monday, August 7, 2017 1:05:05 PM
To: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>
Subject: [USRP-users] Buffer underrun issue with simultaneous transmit and
receive on the X310
Hi,
I'm building an application where I receive data from the x310, process the
data, then transmit it out. I have 3 separate threads running, one for each
task. The receive task is constantly receiving data from the x310 at 200MS/s
and putting it into a buffer. The process task takes data from the receive
buffer, processes it, and puts it into a transmit buffer. The transmit task is
constantly transmitting data from the transmit buffer at 12.5 MS/s.
I get constant underruns (U's on the console) when I try to receive and
transmit from the same channel on the x310. However, when I transmit and
receive on separate channels, underruns no longer occur. I would like to figure
out a solution to this problem as I want to processes two 200MS/s streams on 1
x310.
This problem occurs no matter the sample rates. I've tried lowering the receive
rate to 50MS/s (while transmitting 4x the data to balance things out) and there
are still constant underruns though at a lower rate. I know processing time is
not the issue as I've profiled the time it takes to process, and I have even
removed the processing task from the application altogether (receive data to a
buffer and do nothing with the data; constantly transmit 0's from the transmit
buffer) and the underruns still occur.
I'm running on UHD 3.11.0, and the x310 is is configured with basic TX/RX
daughterboards and flashed with the XG image for use over two 10 gig ethernet
links.
Thanks,
Jason
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
