/*
* Copyright 2018 <+YOU OR YOUR COMPANY+>.
*
* This is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3, or (at your option)
* any later version.
*
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this software; see the file COPYING. If not, write to
* the Free Software Foundation, Inc., 51 Franklin Street,
* Boston, MA 02110-1301, USA.
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include <gnuradio/io_signature.h>
#include "trigger_pipe_samples_impl.h"
namespace gr {
namespace prediction_cpp {
trigger_pipe_samples::sptr
trigger_pipe_samples::make(int num_pipe)
{
return gnuradio::get_initial_sptr
(new trigger_pipe_samples_impl(num_pipe));
}
/*
* The private constructor
*/
trigger_pipe_samples_impl::trigger_pipe_samples_impl(int num_pipe)
: gr::block("trigger_pipe_samples",
gr::io_signature::make2(2, 2, sizeof(float), sizeof(gr_complex)),
gr::io_signature::make2(2, 2, sizeof(float), sizeof(gr_complex))),
d_num_pipe(num_pipe)
{}
/*
* Our virtual destructor.
*/
trigger_pipe_samples_impl::~trigger_pipe_samples_impl()
{
}
void
trigger_pipe_samples_impl::forecast (int noutput_items, gr_vector_int &ninput_items_required)
{
unsigned ninputs = ninput_items_required.size ();
for(unsigned i = 0; i < ninputs; i++)
ninput_items_required[i] = noutput_items;
}
int
trigger_pipe_samples_impl::general_work (int noutput_items,
gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const float *in_trigger = (const float *) input_items[0];
const gr_complex *in_sig = (const gr_complex*) input_items[1];
float *out_trigger = (float *) output_items[0];
gr_complex *out_sig = (gr_complex *) output_items[1];
// Do <+signal processing+>
int i = 0;
int out_pos = 0;
while(i<noutput_items-d_num_pipe)
{
if (in_trigger[i] == 1)
{
for(int j=0; j<d_num_pipe; j++)
{
out_trigger[out_pos+j] = in_trigger[i+j];
out_sig[out_pos+j] = in_sig[i+j];
}
i+=d_num_pipe;
out_pos+=d_num_pipe;
}
else
i+=1;
}
// Tell runtime system how many input items we consumed on
// each input stream.
consume_each(i);
// Tell runtime system how many output items we produced.
return out_pos;
}
} /* namespace prediction_cpp */
} /* namespace gr */
Hi Marcus,
Thanks. I think it was just that ~18MSps is too much for my PC. After writing a cpp block for detecting the trigger and piping some samples, the cpu utilization jumped up to +90% on all cores, and I can now support 6.25MSps x 3 streams. But not much more. For some reason I expected that my cpu could handle the full 1Gbps connection.
The CPU is an older (Sandy Bridge/gen-2) i7@3.40GHz 4 cores, running on Ubuntu 16. Memory wasn't an issue, as the memory usage for the flow hovers around 100MB, with ~10GB to spare.
The ethernet connection is able support higher sampling rates(8Msps x 3 streams) with direct USRP source to null sink connections. So the ethernet/network should be fine.
I've attached screenshots of my flowgraphs, and some code for the blocks I use.
Only concern now is if its harmful to have 90%-100% cpu utilization for an hour or so.
Thanks,
AB
Sent: Tuesday, March 27, 2018 4:39:10 AM
To: discuss-gnuradio@gnu.org; Bakshi, Arjun
Subject: Re: [Discuss-gnuradio] Dropping samples "D" when CPU at 60%
again, we'd need to get a holistic view of what you're doing. All we
can do is speculate wildly based on your description.
> Is it just that the block I've written is not efficient enough? I
would expect higher CPU utilization in that case.
Possibly. Don't know. You tell us nothing about your block, especially
no code.
Please be more precise when asking, give your code, give actual
throughput benchmark, give us hardware information (which I've asked of
you before, but you never delivered). It's actually not easy to ask a
good question, but you really need to get better at it!
Fair warning: a sum rate of 18.75MS/s is really not that little. It's
absolutely possible you have shoddy network hardware or drivers that
just can't deal with that much data. Again, pure speculation, since you
tell us nothing about your hardware, or your OS, or anything about the
environment you're working in.
All that we can say is: something in your overall system, be it
hardware, your CPU, your RAM, your software or anything else, doesn't
work as you want it to.
Best regards,
Marcus
On Sat, 2018-03-24 at 19:30 +0000, Bakshi, Arjun wrote:
> Hi all,
>
> I have written a block in python to detect and decode some packet transmissions. I've noticed that when I have 3 rx streams running at 6.25Msps (total network traffic is 75MB/s), the host starts dropping samples after a while. The CPU utilization does not exceed 60%, and the Ethernet isn't being saturated. I've increased buffer sizes (net.core.w/rmem_max) to the largest values possible
>
> A 'D' in the console means that the host isn't consuming samples fast enough.
>
> Is it just that the block I've written is not efficient enough? I would expect higher CPU utilization in that case.
>
> I think the most expensive thing I'm doing is looking at each sample in a stream of floats to find where the values goes above a threshold. This part is in my block, and triggers the decoding logic, which is in the same block.
>
> I don't know how to do this more efficiently. I'm thinking of re-writing it in C++, but I don't know how much better it'll get.
>
> Thank you,
>
> AB
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
| lists.gnu.org Discuss-gnuradio -- GNU Radio, the Free & Open-Source Toolkit for Software Radio About Discuss-gnuradio |
No comments:
Post a Comment