The main reason for my choice is mobility, need this stuff being available when traveling :) Dual boot on the surface was at least a few years ago a PITA, and MS tended to kill the bootloader with updates. Don't know it this is better nowadays.
Ralph, dk5ras.
> -----Original Message-----
> From: Discuss-gnuradio [mailto:discuss-gnuradio-
> bounces+ralph=schmid.xxx@gnu.org] On Behalf Of Müller, Marcus (CEL)
> Sent: Tuesday, February 20, 2018 3:36 PM
> To: Discuss-gnuradio@gnu.org; rell320@gmail.com
> Subject: Re: [Discuss-gnuradio] Performance Issues
>
> Hello Tellrell,
>
> first observation: Step away from Ubuntu 14.04, if possible. Its compilers aren't
> really as cool as they could be (there's been a lot of performance improvement
> in both GCC and Clang in the last four years), and you do care about
> performance.
> Also, Ubuntu 14.04 won't be around for much longer, so if this is a new
> application, switching to the next LTS is probably a good idea (by the way, I've
> not been able to find significant performance regressions in simulation-only
> GNU Radio flow graphs due to KPTI fixes, i.e. meltdown fixes).
>
> Then: Virtualizers are getting better every day; whether that makes them the
> best choice for SDR is something that I can't generally answer. Fact is that USB3
> handthrough to VMs is known to be rather flaky, so if you're using a USRP B2xx,
> then native is most likely the way to go.
> If you're using a high-end network card, and a good hypervisor, chances are
> you can actually have a virtualized dedicated network card in the VM (if that is
> the case, you probably know yourself, because you'd have configured your VM
> to be "owner" of part of your network card).
>
> What you should most definitely not do is have a "NAT" networking solution
> between your VM and your Host – that way, every UDP packet for a network-
> attached USRP would have to go through a packet analyzer/rewriter, and that's
> going to eat CPU.
>
> I don't know what your CustomBlock does, but if it not a hier_blopck, Python is
> really not the thing you want for highest performance. Also, to avoid the
> vec2stream, make your block consume vectors instead of single samples; the
> complex_to_magnitude_squared block can be configured to directly work on
> vectors, too!
>
> Generally, you'll find that most guys on here are happy running a modern Linux
> on their machines. Setting up a Fedora 27 that boots alternatively to the pre-
> installed windows took about 15 minutes on my new laptop, but it's definitely
> not the first installation of that I did, so calculate let's say 30 minutes. That's
> actually something that you might just want to try out. After that, it was really
> just a matter of "sudo dnf update -y; dnf install -y gnuradio" to be up and
> running a halfway recent GNU Radio. On debian unstable or testing, you'd get
> something even more recent.
>
> Best regards,
> Marcus
>
> On Tue, 2018-02-20 at 08:48 -0500, Tellrell White wrote:
> > Hello Guys
> > Currently I'm running a flow graph that looks like the following:
> >
> > UHD Source -> Stream2Vec -> FFT -> Vec2Stream -> Com2Mag^2 ->
> > CustomBlock(Python)
> >
> > I'm running this block inside of a virtual machine running ubuntu 14.04 LTS.
> The host machine runs Windows with an Intel Core i7-4700 MQ processor
> running at 2.4GHZ with 8GB of RAM.
> >
> > Running the flow graph shown above in the VM is a struggle resulting in
> freezing after a few seconds so my question is would it better to go another
> route for performance, either, by installing UHD and Gnu Radio on the host
> machine running windows or using another machine and dual booting and
> installing linux, GNU Radio, and UHD for this application?
> >
> > Regards
> > Tellrell White
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment