What exactly do you want to vectorize? Best regards, Marcus
On 09.09.2017 12:44, David via USRP-users wrote: > > Thx for the info. > > Do you think there would be any mileage in using the GPU for that, it > should vectorise quite well? > > I' know nothing about the GPU, only done some simple Cuda stuff, maybe > theres OpenCL support? > > > On 08/09/17 16:51, mle...@ripnet.com wrote: >> >> I've run a simple interferometer application with a B210 on an XU4, >> with two channels at 15Msps. >> >> >> >> >> >> >> >> On 2017-09-08 11:23, David wrote: >> >>> Thanks Marcus, >>> >>> so doing ... >>> >>> benchmark_rate --args "num_recv_frames=512" --rx_rate 40e6 >>> >>> no overruns (got a couple with 256). >>> >>> I'm just trying to get a feel of what is possible with this processor, >>> >>> Cheers >>> Dave >>> >>> >>> >>> >>> On 08/09/17 15:58, mle...@ripnet.com wrote: >>>> >>>> I've found that altering num_recv_frames in the device args to be >>>> helpful on XU4--try 128 or 256 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 2017-09-08 10:34, David via USRP-users wrote: >>>> >>>>> Just tried out a USB3 powered hub, to power the b200. >>>>> >>>>> The XU4 wouldn't boot powered from the hub (2A max), but powered >>>>> from it's own supply (4A) and the B200mini powered from the hub >>>>> all seems OK, no device errors, fscks on reboot, etc. :-) :-) >>>>> >>>>> So, using "benchmark_rate --rx_rate 40e6", I get no dropped samples :-). >>>>> >>>>> Using uhd_fft at 10MHz rate results in just a few overruns over >>>>> several minutes, it's marginal... >>>>> >>>>> Now I can move on to do some real stuff... >>>>> >>>>> Kind regards, >>>>> Dave >>>>> >>>>> >>>>> On 04/09/17 18:21, David wrote: >>>>>> So after a reboot of my main Ubuntu PC... >>>>>> >>>>>> It's now recognised, so doing... >>>>>> >>>>>> # fsck /dev/sdd2 >>>>>> fsck from util-linux 2.27.1 >>>>>> e2fsck 1.42.13 (17-May-2015) >>>>>> rootfs was not cleanly unmounted, check forced. >>>>>> Pass 1: Checking inodes, blocks, and sizes >>>>>> Pass 2: Checking directory structure >>>>>> Pass 3: Checking directory connectivity >>>>>> Pass 4: Checking reference counts >>>>>> Pass 5: Checking group summary information >>>>>> rootfs: 124553/237568 files (0.4% non-contiguous), 783269/920192 blocks >>>>>> # fsck /dev/sdd1 >>>>>> fsck from util-linux 2.27.1 >>>>>> fsck.fat 3.0.28 (2015-05-16) >>>>>> 0x25: Dirty bit is set. Fs was not properly unmounted and some >>>>>> data may be corrupt. >>>>>> 1) Remove dirty bit >>>>>> 2) No action >>>>>> ? 1 >>>>>> Perform changes ? (y/n) y >>>>>> /dev/sdd1: 7 files, 5028/65399 clusters >>>>>> >>>>>> Then put it back into the XU4, and it reboots OK. So there is >>>>>> more than one issue here? >>>>>> >>>>>> Sorry for the commentary/verboseness, but I've been at this for a >>>>>> while now... >>>>>> >>>>>> Kind Regards, >>>>>> >>>>>> Dave >>>>>> >>>>>> >>>>>> On 02/09/17 22:02, Nate Temple wrote: >>>>>>> Hi Dave, >>>>>>> >>>>>>> This is certainly an interesting issue. I suspect the core of >>>>>>> the issue may be power draw on the USB interface during boot. >>>>>>> One of the common issues with the XU4 that I've seen reported is >>>>>>> that the USB3 ports do not provide USB3 spec power levels. >>>>>>> >>>>>>> Using a powered USB3 hub may resolve the issue. >>>>>>> >>>>>>> Another option would be a Y power cable such as this >>>>>>> http://www.ebay.com/itm/262045046196 which would allow you to >>>>>>> use an external power adapter to feed power to the USRP. >>>>>>> >>>>>>> Another test you could try -- Try using the USB2 on the XU4. >>>>>>> Does it result in the same boot up problems? >>>>>>> >>>>>>> I have a early rev 0.1 20151201 XU4 that I often use paired with >>>>>>> a B205mini and have not seen any issue such as this. >>>>>>> >>>>>>> Regards, >>>>>>> Nate Temple >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Sep 2, 2017, at 1:44 AM, David via USRP-users >>>>>>>> <usrp-users@lists.ettus.com >>>>>>>> <mailto:usrp-users@lists.ettus.com>> wrote: >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I'm trying to get XU4 and B200mini to work together, but having >>>>>>>> a serious issue: the SD card gets trashed! >>>>>>>> >>>>>>>> I'm using Ubuntu 16.04 image from the Odroid site, kernel >>>>>>>> 4.9.28-38, and latest GIT clone of UHD (as of two weeks ago). >>>>>>>> Two uSD cards I had are now totally trashed. I'm on my last >>>>>>>> card. They seem to get totally trashed after I run uhd-fft a >>>>>>>> few times. >>>>>>>> >>>>>>>> The main symptom is that if the B200mini is connected and I >>>>>>>> reboot, an fsck is done every time, and also has the effect of >>>>>>>> continually rebooting, and continually corrupting the card. >>>>>>>> >>>>>>>> Unplug the B200mini and all is fine (after a couple of fscks). >>>>>>>> I managed to work out that if I remove the udev rule that >>>>>>>> starts up UHD (uhd-usrp.rules) I am also able to reboot with no >>>>>>>> issues. So a driver issue? >>>>>>>> >>>>>>>> Without the udev rule I get the following, which I'm assuming >>>>>>>> is normal?: >>>>>>>> >>>>>>>> [ 24.555119] usb 3-1.1: device descriptor read/64, error -110 >>>>>>>> [ 29.995114] usb 3-1.1: device descriptor read/64, error -110 >>>>>>>> [ 45.675119] usb 3-1.1: device descriptor read/64, error -110 >>>>>>>> [ 56.685085] usb 3-1.1: device not accepting address 5, error -62 >>>>>>>> [ 67.565082] usb 3-1.1: device not accepting address 6, error -62 >>>>>>>> [ 67.569976] usb 3-1-port1: unable to enumerate USB device >>>>>>>> >>>>>>>> Hope you can help, thanks, >>>>>>>> >>>>>>>> Dave. >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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
