On 08/14/2017 08:27 PM, Jason W Zheng via USRP-users wrote:

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.

COuld you try reverting to UHD 3.10.2 and see if that changes things? Just got this hint from engineering.


    // 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

_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to