Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Queueing Timed Commands (Jacob Gilbert)
2. Re: USRP B210 Overflow (Garver, Paul W)
3. Re: USRP B210 Overflow (Piotr Krysik)
4. Re: Queueing Timed Commands (Ian Buckley)
5. Re: Queueing Timed Commands (Jacob Gilbert)
6. Re: Queueing Timed Commands ([email protected])
7. Re: Queueing Timed Commands (Jacob Gilbert)
8. Re: USRP B210 Overflow (Piotr Krysik)
9. Re: Queueing Timed Commands ([email protected])
10. Re: Queueing Timed Commands (Ian Buckley)
11. MSK Modulation Examples (Yin, Charles - 0665 - MITLL)
12. How to add interrupts on E310's Linux system (Weidong Wang)
13. Re: USRP B210 Overflow (Piotr Krysik)
14. Re: Queueing Timed Commands (Jacob Gilbert)
15. monitor with E310/312 (john liu)
16. Re: monitor with E310/312 (Philip Balister)
17. Re: monitor with E310/312 (john liu)
18. Re: Queueing Timed Commands (Marcus M?ller)
19. Re: USRP B210 Overflow (Marcus M?ller)
20. Re: USRP B210 Overflow (Marcus M?ller)
21. new E310 image won't boot on E312 (Jason Matusiak)
22. Re: new E310 image won't boot on E312 ([email protected])
23. Macports Patch File (Mark Napier)
24. Re: new E310 image won't boot on E312 (Jason Matusiak)
25. Re: new E310 image won't boot on E312 (Philip Balister)
26. Re: USRP B210 Overflow (Piotr Krysik)
27. Re: [Discuss-gnuradio] Macports Patch File (Michael Dickens)
----------------------------------------------------------------------
Message: 1
Date: Tue, 5 Jul 2016 10:26:04 -0600
From: Jacob Gilbert <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Queueing Timed Commands
Message-ID:
<cac52akdkfyu_qwxqaliowyxxzz-epethrnmzagfy24j1ui0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am having trouble queueing multiple timed commands up for a USRP source,
in this case the next several frequencies for a fast hopping FHSS
transmitter. I understand there is a 16 command deep queue on the USRP,
but something is causing an inability to queue up commands.
Rather than attempt explain what I've tried, I attached an example
flowgraph of the behavior. Modifying the variables at the top gives a
better perspective of the issue:
PREQUEUE_TUNES: Setting this will attempt to queue up the retunes before
starting the FG. No matter which way commands are tuned, the behavior
appears to be the same.
INITIAL_DELAY: This confuses me, but if set to a value larger than 0.01
seconds will allow two commands to queue up as expected. If it is very
small (eg: < 0.001 s) no commands queue as expected.
DELAY_BETWEEN_RETUNES: does not appear to have any effect but included due
to the oddness of the initial delay.
I have also observed this blocking behavior with a C++ block that works in
a similar way. This behavior was observed with a B200 mini, and I can try
to test other USRPs when I have access to them if this is suspected to be
specific to the B200mini.
My question then is: Is this the desired/expected behavior? If so what is
the point of the command queue. If not, am I doing something wrong and how
can I achieve the same result in the correct way?
Thanks,
Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160705/f3d74c4f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: timed_retune_test.py
Type: text/x-python-script
Size: 3605 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160705/f3d74c4f/attachment-0001.py>
------------------------------
Message: 2
Date: Tue, 5 Jul 2016 17:05:44 +0000
From: "Garver, Paul W" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B210 Overflow
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
I can easily record for 10 minutes with the B210 at 25 MSPS on a single Samsung
Evo 840 mSSD without dropping samples on an XFS-formatted partition. See last
year?s GRCON (GRCON2015) for details:
Specifically, you may be interested in the specrec (Linux-only) command-line
tool in gr-analysis [2].
I might point out that the file meta sink block in gnuradio is fairly
inefficient in how it writes metadata to disk as it does a fair bit of seeking.
If you need metadata with the files, you will probably get poor performance
using file meta sink and GNURadio. In our systems with metadata, uhd_rx_cfile
can only do 10 MSPS, whereas specrec can go up to 25 MSPS for an improvement of
15 MSPS.
Hope this helps.
[1] http://www.trondeau.com/grcon15-presentations#wednesday_Lincoln_Synchronized
[2] https://github.com/garverp/gr-analysis
From: Jeremy Hershberger
<[email protected]<mailto:[email protected]>>
Subject: Re: [USRP-users] USRP B210 Overflow
Date: July 4, 2016 at 4:49:10 PM EDT
To: Piotr Krysik <[email protected]<mailto:[email protected]>>
Cc: usrp-users <[email protected]<mailto:[email protected]>>
I have had success streaming from a B210 (2 channel RX, 16-bit, 25MS/s) to a
RAM disk. I have also had success writing smaller files to the RAM disk (maybe
a second or two of data) and then moving those files in a separate background
process to an SSD. By pulling data out of the RAM drive at a rate that is
slightly less than data flows in, I can capture for a longer total duration.
The performance would depend greatly on the speed at which your host can move
data from RAM to disk, but by changing the size of the temporary files in RAM
you should be able to extend your capture duration significantly.
On Mon, Jul 4, 2016 at 10:33 AM, Piotr Krysik via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
W dniu 04.07.2016 o 14:45, Piotr Krysik via USRP-users pisze:
> W dniu 17.06.2016 o 19:28, Marcus D. Leech via USRP-users pisze:
>> On 06/17/2016 01:07 PM, Marcus M?ller via USRP-users wrote:
>>> Hi Xuesong,
>>>
>>> I was just told I misread your email. I'd like to apologize for that!
>>>
>>>> 3) There will DEFINITELY be overruns (in less than 2 minutes) when
>>>> streaming data to a file even with sampling rate of 5 MHz:
>>>> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
>>>> --wirefmt=sc16 --duration=600
>>> Ooops, you're doing 5MS/s here.
>>> Ok, that's only 20MB/s, and now everything is comparable to the N210
>>> case.
>>> This is actually not typical; let's do a quick benchmark with dd:
>>>
>>> yes | dd of=/home/marcus/Desktop/test.bin bs=512 count=$((4*600 * 5 * 10**6
>>> / 512)) conv=fsync
>>>
>>> to try and write data in roughly the same granularity as
>>> rx_samples_to_file does by default for a B210 connected using USB3
>>> with the same amount of data.
>>>
>>> Could you also copy&paste the full output of rx_samples_to_file? That
>>> could be very helpful.
>>>
>>> I'm still pretty sure the problem is storage here ? my suspicion is
>>> that the write buffer of your operating system fills up with the 12GB
>>> of data coming in from the USRP, and then suddenly, the OS has to
>>> start throttling the USRP, because it can't write data to the SSD
>>> fast enough - possibly partly because filesystem access is everything
>>> but CPU-free.
>>>
>>> Are you planning on using GNU Radio? If you want to do that anyway,
>>> something like:
>>>
>>> UHD USRP Source ---> File Sink
>>>
>>> would probably work better than the rx_samples_to_file example,
>>> because GNU Radio is inherently multi-threaded. If you're using the
>>> GNU Radio companion, the USRP Source block has an "advanced options"
>>> tab, where you can set a larger minimum output buffer; try something
>>> like 10**7, which will give you a couple Megabytes of buffering
>>> already, which might already compensate for the non-uniform write
>>> speeds of a storage device.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>> Also try increasing num_recv_frames in the device argument--up to 128
>> or so.
>>
> Hi Xuesong,
>
> There is a genuine problem with streaming from B210 to a disk. No amount
> of computer resources, optimizations and trying different streaming
> applications solved the problem for me (rx_sample_to_file is just an
> example provided with the driver so it might not be the best application).
>
> For all others who are trying to help - if you can stream from B210 to a
> disk on your side at the sample rate of at least 10MHz (single channel,
> 16bit) and save about 10 minutes of such stream to disk without an
> overflow - please share:
> -what is a configuration of a computer on which you achieved that
> (motherboard, processor, memory, disk),
> -what application did you use.
>
> Until someone proves otherwise (at sample rates >=10MSamp/s), it is
> officially not possible to stream from USRP B210 to a disk without
> transmission problems.
>
>
Hi all again,
One little tip: streaming to a ramdisk works without problems with
overflows. If I need to make a short recording (single minutes as amount
of RAM is usually quite limited) with USRP B210 I'm using a ramdisc
created with command like this:
sudo mount -t tmpfs -o size=10000m tmpfs /path/to/ramdisc/directory
where 10000m is size of the ramdisc in mega-bytes.
Streaming to a real disc from B210 doesn't work without problems - until
someone figures out what is the problem/bottleneck.
Best Regards,
Piotr Krysik
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
From: Marcus M?ller <[email protected]<mailto:[email protected]>>
Subject: Re: [USRP-users] USRP B210 Overflow
Date: July 4, 2016 at 5:16:47 PM EDT
To: <[email protected]<mailto:[email protected]>>
I can also recommend doing two things:
1. Multi-thread your receiver, so that the thread calling recv() isn't blocked
for the duration of write()ing things to storage. Also, now you're not
inherently pushing one core to a high clock speed. The rx_samples_to_file
example is really really really just an example of how to set up a multi_usrp
object, get the rx_streamer and call recv(), nothing to use as reference when
building high-rate receivers.
2. Using something with a large buffering when writing to storage, as storage
rates and latencies are totally unpredictable.
In fact, using GNU Radio you can get both at once: Just connect your USRP
source to a file sink. GNU Radio blocks run each in their own thread, and the
output/input connection is actually a ring buffer; you can increase the size of
that in the "advanced" tab of the USRP source, by increasing the minimum output
buffer size to something relatively large; I tend to use values 512*2**20
(==512MB) because RAM is cheap :)
If you don't want to use GNU Radio, I can dig up a rather naively implemented
multi-thread-receiver that I wrote a while ago. It worked pretty well at high
rates, and does nothing but allocate a bunch of
"samples_per_packet*bytes_per_sample" sized buffers, puts them in a "ready to
use" queue, let's a thread running recv() fill them one by one, push them into
a "ready to write" queue, from which a storage IO thread takes them and writes
their content to a file, then pushes them back to the "ready to use" queue. The
design was really bad (buffers aren't inherently allocated contiguously in
memory, so we're potentially losing memory bandwidth unnecessarily), but using
enough buffers, one can completely hide the fact that storage is highly
non-deterministic and that handling storage IO might interfere with the amount
of CPU the OS has available for handling USB traffic.
Best regards,
Marcus
On 04.07.2016 22:49, Jeremy Hershberger via USRP-users wrote:
I have had success streaming from a B210 (2 channel RX, 16-bit, 25MS/s) to a
RAM disk. I have also had success writing smaller files to the RAM disk (maybe
a second or two of data) and then moving those files in a separate background
process to an SSD. By pulling data out of the RAM drive at a rate that is
slightly less than data flows in, I can capture for a longer total duration.
The performance would depend greatly on the speed at which your host can move
data from RAM to disk, but by changing the size of the temporary files in RAM
you should be able to extend your capture duration significantly.
On Mon, Jul 4, 2016 at 10:33 AM, Piotr Krysik via USRP-users
<<mailto:[email protected]>[email protected]<mailto:[email protected]>>
wrote:
W dniu 04.07.2016 o 14:45, Piotr Krysik via USRP-users pisze:
> W dniu 17.06.2016 o 19:28, Marcus D. Leech via USRP-users pisze:
>> On 06/17/2016 01:07 PM, Marcus M?ller via USRP-users wrote:
>>> Hi Xuesong,
>>>
>>> I was just told I misread your email. I'd like to apologize for that!
>>>
>>>> 3) There will DEFINITELY be overruns (in less than 2 minutes) when
>>>> streaming data to a file even with sampling rate of 5 MHz:
>>>> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
>>>> --wirefmt=sc16 --duration=600
>>> Ooops, you're doing 5MS/s here.
>>> Ok, that's only 20MB/s, and now everything is comparable to the N210
>>> case.
>>> This is actually not typical; let's do a quick benchmark with dd:
>>>
>>> yes | dd of=/home/marcus/Desktop/test.bin bs=512 count=$((4*600 * 5 * 10**6
>>> / 512)) conv=fsync
>>>
>>> to try and write data in roughly the same granularity as
>>> rx_samples_to_file does by default for a B210 connected using USB3
>>> with the same amount of data.
>>>
>>> Could you also copy&paste the full output of rx_samples_to_file? That
>>> could be very helpful.
>>>
>>> I'm still pretty sure the problem is storage here ? my suspicion is
>>> that the write buffer of your operating system fills up with the 12GB
>>> of data coming in from the USRP, and then suddenly, the OS has to
>>> start throttling the USRP, because it can't write data to the SSD
>>> fast enough - possibly partly because filesystem access is everything
>>> but CPU-free.
>>>
>>> Are you planning on using GNU Radio? If you want to do that anyway,
>>> something like:
>>>
>>> UHD USRP Source ---> File Sink
>>>
>>> would probably work better than the rx_samples_to_file example,
>>> because GNU Radio is inherently multi-threaded. If you're using the
>>> GNU Radio companion, the USRP Source block has an "advanced options"
>>> tab, where you can set a larger minimum output buffer; try something
>>> like 10**7, which will give you a couple Megabytes of buffering
>>> already, which might already compensate for the non-uniform write
>>> speeds of a storage device.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>> Also try increasing num_recv_frames in the device argument--up to 128
>> or so.
>>
> Hi Xuesong,
>
> There is a genuine problem with streaming from B210 to a disk. No amount
> of computer resources, optimizations and trying different streaming
> applications solved the problem for me (rx_sample_to_file is just an
> example provided with the driver so it might not be the best application).
>
> For all others who are trying to help - if you can stream from B210 to a
> disk on your side at the sample rate of at least 10MHz (single channel,
> 16bit) and save about 10 minutes of such stream to disk without an
> overflow - please share:
> -what is a configuration of a computer on which you achieved that
> (motherboard, processor, memory, disk),
> -what application did you use.
>
> Until someone proves otherwise (at sample rates >=10MSamp/s), it is
> officially not possible to stream from USRP B210 to a disk without
> transmission problems.
>
>
Hi all again,
One little tip: streaming to a ramdisk works without problems with
overflows. If I need to make a short recording (single minutes as amount
of RAM is usually quite limited) with USRP B210 I'm using a ramdisc
created with command like this:
sudo mount -t tmpfs -o size=10000m tmpfs /path/to/ramdisc/directory
where 10000m is size of the ramdisc in mega-bytes.
Streaming to a real disc from B210 doesn't work without problems - until
someone figures out what is the problem/bottleneck.
Best Regards,
Piotr Krysik
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160705/accf58f1/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 5 Jul 2016 19:22:59 +0200
From: Piotr Krysik <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 Overflow
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi all,
If after what I said on the list (or privately ;) ) on some occasions
about USRP B210 you have a feeling that I'm only complaining about the
performance of the device, while not trying to help myself, maybe this
post will convince you that this impression is far from the truth.
I've just tested the optimization mentioned by Marcus (increasing Min
Output Buffer value in the Advanced tab to some high number - in my case
100000000) in the previous post, together with the previous optimization
(I've set value of Device Arguments to "num_recv_frames=1024") and I got
20 minutes of continuous recording (no overflows) with sample rate 25MHz
(two channels with 16 bit samples). So it is much higher stream of data
stored to disk (5x) than the minimum mentioned by me previously.
Actually, this is maximum possible to get from B210 with 2 RX channels
and 16bit sampling and it WORKS (at least for 20 minutes during which I
tested it - probably more is possible).
However, I'm not writing this to tell you that it works for me. I want
to share the solution, so others can use it and improve it. The system I
used for the recording is following:
-Dell Latitude E6330, CPU Intel(R) Core(TM) i7-3540M CPU @ 3.00GHz, 16GB
(2x8GB) RAM,
-SSD disk used for storing the recording: Samsung SSD 850 EVO 1TB,
-system: Ubuntu 16.04 with GNU Radio and UHD installed from packages
provided with distribution.
The gnuradio-companion application that I used is shown on the
print-screen and the GRC file is also attached.
Best Regards,
Piotr Krysik
W dniu 04.07.2016 o 23:16, Marcus M?ller via USRP-users pisze:
>
> I can also recommend doing two things:
>
> 1. Multi-thread your receiver, so that the thread calling recv() isn't
> blocked for the duration of write()ing things to storage. Also, now
> you're not inherently pushing one core to a high clock speed. The
> rx_samples_to_file example is really really really just an example of
> how to set up a multi_usrp object, get the rx_streamer and call
> recv(), nothing to use as reference when building high-rate receivers.
>
> 2. Using something with a large buffering when writing to storage, as
> storage rates and latencies are totally unpredictable.
>
> In fact, using GNU Radio you can get both at once: Just connect your
> USRP source to a file sink. GNU Radio blocks run each in their own
> thread, and the output/input connection is actually a ring buffer; you
> can increase the size of that in the "advanced" tab of the USRP
> source, by increasing the minimum output buffer size to something
> relatively large; I tend to use values 512*2**20 (==512MB) because RAM
> is cheap :)
>
> If you don't want to use GNU Radio, I can dig up a rather naively
> implemented multi-thread-receiver that I wrote a while ago. It worked
> pretty well at high rates, and does nothing but allocate a bunch of
> "samples_per_packet*bytes_per_sample" sized buffers, puts them in a
> "ready to use" queue, let's a thread running recv() fill them one by
> one, push them into a "ready to write" queue, from which a storage IO
> thread takes them and writes their content to a file, then pushes them
> back to the "ready to use" queue. The design was really bad (buffers
> aren't inherently allocated contiguously in memory, so we're
> potentially losing memory bandwidth unnecessarily), but using enough
> buffers, one can completely hide the fact that storage is highly
> non-deterministic and that handling storage IO might interfere with
> the amount of CPU the OS has available for handling USB traffic.
>
> Best regards,
>
> Marcus
>
> On 04.07.2016 22:49, Jeremy Hershberger via USRP-users wrote:
>> I have had success streaming from a B210 (2 channel RX, 16-bit,
>> 25MS/s) to a RAM disk. I have also had success writing smaller files
>> to the RAM disk (maybe a second or two of data) and then moving those
>> files in a separate background process to an SSD. By pulling data
>> out of the RAM drive at a rate that is slightly less than data flows
>> in, I can capture for a longer total duration. The performance would
>> depend greatly on the speed at which your host can move data from RAM
>> to disk, but by changing the size of the temporary files in RAM you
>> should be able to extend your capture duration significantly.
>>
>> On Mon, Jul 4, 2016 at 10:33 AM, Piotr Krysik via USRP-users
>> <[email protected]> wrote:
>>
>> W dniu 04.07.2016 o 14:45, Piotr Krysik via USRP-users pisze:
>> > W dniu 17.06.2016 o 19:28, Marcus D. Leech via USRP-users pisze:
>> >> On 06/17/2016 01:07 PM, Marcus M?ller via USRP-users wrote:
>> >>> Hi Xuesong,
>> >>>
>> >>> I was just told I misread your email. I'd like to apologize
>> for that!
>> >>>
>> >>>> 3) There will DEFINITELY be overruns (in less than 2
>> minutes) when
>> >>>> streaming data to a file even with sampling rate of 5 MHz:
>> >>>> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
>> >>>> --wirefmt=sc16 --duration=600
>> >>> Ooops, you're doing 5MS/s here.
>> >>> Ok, that's only 20MB/s, and now everything is comparable to
>> the N210
>> >>> case.
>> >>> This is actually not typical; let's do a quick benchmark with dd:
>> >>>
>> >>> yes | dd of=/home/marcus/Desktop/test.bin bs=512
>> count=$((4*600 * 5 * 10**6 / 512)) conv=fsync
>> >>>
>> >>> to try and write data in roughly the same granularity as
>> >>> rx_samples_to_file does by default for a B210 connected using
>> USB3
>> >>> with the same amount of data.
>> >>>
>> >>> Could you also copy&paste the full output of
>> rx_samples_to_file? That
>> >>> could be very helpful.
>> >>>
>> >>> I'm still pretty sure the problem is storage here ? my
>> suspicion is
>> >>> that the write buffer of your operating system fills up with
>> the 12GB
>> >>> of data coming in from the USRP, and then suddenly, the OS has to
>> >>> start throttling the USRP, because it can't write data to the SSD
>> >>> fast enough - possibly partly because filesystem access is
>> everything
>> >>> but CPU-free.
>> >>>
>> >>> Are you planning on using GNU Radio? If you want to do that
>> anyway,
>> >>> something like:
>> >>>
>> >>> UHD USRP Source ---> File Sink
>> >>>
>> >>> would probably work better than the rx_samples_to_file example,
>> >>> because GNU Radio is inherently multi-threaded. If you're
>> using the
>> >>> GNU Radio companion, the USRP Source block has an "advanced
>> options"
>> >>> tab, where you can set a larger minimum output buffer; try
>> something
>> >>> like 10**7, which will give you a couple Megabytes of buffering
>> >>> already, which might already compensate for the non-uniform write
>> >>> speeds of a storage device.
>> >>>
>> >>> Best regards,
>> >>> Marcus
>> >>>
>> >>>
>> >> Also try increasing num_recv_frames in the device argument--up to 128
>> >> or so.
>> >>
>> > Hi Xuesong,
>> >
>> > There is a genuine problem with streaming from B210 to a disk.
>> No amount
>> > of computer resources, optimizations and trying different streaming
>> > applications solved the problem for me (rx_sample_to_file is
>> just an
>> > example provided with the driver so it might not be the best
>> application).
>> >
>> > For all others who are trying to help - if you can stream from
>> B210 to a
>> > disk on your side at the sample rate of at least 10MHz (single
>> channel,
>> > 16bit) and save about 10 minutes of such stream to disk without an
>> > overflow - please share:
>> > -what is a configuration of a computer on which you achieved that
>> > (motherboard, processor, memory, disk),
>> > -what application did you use.
>> >
>> > Until someone proves otherwise (at sample rates >=10MSamp/s), it is
>> > officially not possible to stream from USRP B210 to a disk without
>> > transmission problems.
>> >
>> >
>> Hi all again,
>>
>> One little tip: streaming to a ramdisk works without problems with
>> overflows. If I need to make a short recording (single minutes as
>> amount
>> of RAM is usually quite limited) with USRP B210 I'm using a ramdisc
>> created with command like this:
>>
>> sudo mount -t tmpfs -o size=10000m tmpfs /path/to/ramdisc/directory
>>
>> where 10000m is size of the ramdisc in mega-bytes.
>>
>> Streaming to a real disc from B210 doesn't work without problems
>> - until
>> someone figures out what is the problem/bottleneck.
>>
>> Best Regards,
>> Piotr Krysik
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: recorder.png
Type: image/png
Size: 105279 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160705/c23d05e4/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: recorder.grc
Type: application/gnuradio-grc
Size: 34465 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160705/c23d05e4/attachment-0001.grc>
------------------------------
Message: 4
Date: Tue, 5 Jul 2016 10:29:53 -0700
From: Ian Buckley <[email protected]>
To: Jacob Gilbert <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Queueing Timed Commands
Message-ID:
<CAM_0ocHO0zWnu+6GNcpfKapNWTyDeVRfnrvvH2yA=ql2ivj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Jacob, this is an off the cuff comment, I haven't the time to look at your
example but one thing that might bring greater understanding.
When we talk about command queue depth, it's in terms of a simple bus
transaction=1 cmd-queue entry. Retuning some of the USRP front ends might
well take a fair number of SPI transactions initiated with bus
transactions.
BTW when I say "bus transaction" I mean a simple "PEEK/POKE memory map"
style operation.
Now specific to B200mini, unless there has been a very recent FPGA change
then retuning operations that reprogram the RF synthesizers are not
available as timed commands, they always complete best effort
asynchronously. If you supply a time then I suspect (knowning how the H/W
is designed) that it is just ignored.
-Ian
On Tue, Jul 5, 2016 at 9:26 AM, Jacob Gilbert via USRP-users <
[email protected]> wrote:
> I am having trouble queueing multiple timed commands up for a USRP source,
> in this case the next several frequencies for a fast hopping FHSS
> transmitter. I understand there is a 16 command deep queue on the USRP,
> but something is causing an inability to queue up commands.
>
> Rather than attempt explain what I've tried, I attached an example
> flowgraph of the behavior. Modifying the variables at the top gives a
> better perspective of the issue:
>
> PREQUEUE_TUNES: Setting this will attempt to queue up the retunes before
> starting the FG. No matter which way commands are tuned, the behavior
> appears to be the same.
> INITIAL_DELAY: This confuses me, but if set to a value larger than 0.01
> seconds will allow two commands to queue up as expected. If it is very
> small (eg: < 0.001 s) no commands queue as expected.
> DELAY_BETWEEN_RETUNES: does not appear to have any effect but included due
> to the oddness of the initial delay.
>
> I have also observed this blocking behavior with a C++ block that works in
> a similar way. This behavior was observed with a B200 mini, and I can try
> to test other USRPs when I have access to them if this is suspected to be
> specific to the B200mini.
>
> My question then is: Is this the desired/expected behavior? If so what is
> the point of the command queue. If not, am I doing something wrong and how
> can I achieve the same result in the correct way?
>
> Thanks,
> Jacob
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160705/a473d7f8/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 5 Jul 2016 11:45:53 -0600
From: Jacob Gilbert <[email protected]>
To: Ian Buckley <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Queueing Timed Commands
Message-ID:
<cac52akaaykdkjoacy57cdtuy330a+m04qdbfomxrjw9r+vi...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Ian,
Thanks for the reply - I should have mentioned that to get around the
936x-based lack of timed commands, I am only CORDIC tuning (verified in
output) - do you happen to know many bus transactions would this be?
Somewhat related, is there a list of commands that can be timed for various
USRP models?
Jacob
On Tue, Jul 5, 2016 at 11:29 AM, Ian Buckley <[email protected]> wrote:
> Jacob, this is an off the cuff comment, I haven't the time to look at your
> example but one thing that might bring greater understanding.
> When we talk about command queue depth, it's in terms of a simple bus
> transaction=1 cmd-queue entry. Retuning some of the USRP front ends might
> well take a fair number of SPI transactions initiated with bus
> transactions.
> BTW when I say "bus transaction" I mean a simple "PEEK/POKE memory map"
> style operation.
>
> Now specific to B200mini, unless there has been a very recent FPGA change
> then retuning operations that reprogram the RF synthesizers are not
> available as timed commands, they always complete best effort
> asynchronously. If you supply a time then I suspect (knowning how the H/W
> is designed) that it is just ignored.
> -Ian
>
>
>
> On Tue, Jul 5, 2016 at 9:26 AM, Jacob Gilbert via USRP-users <
> [email protected]> wrote:
>
>> I am having trouble queueing multiple timed commands up for a USRP
>> source, in this case the next several frequencies for a fast hopping FHSS
>> transmitter. I understand there is a 16 command deep queue on the USRP,
>> but something is causing an inability to queue up commands.
>>
>> Rather than attempt explain what I've tried, I attached an example
>> flowgraph of the behavior. Modifying the variables at the top gives a
>> better perspective of the issue:
>>
>> PREQUEUE_TUNES: Setting this will attempt to queue up the retunes before
>> starting the FG. No matter which way commands are tuned, the behavior
>> appears to be the same.
>> INITIAL_DELAY: This confuses me, but if set to a value larger than 0.01
>> seconds will allow two commands to queue up as expected. If it is very
>> small (eg: < 0.001 s) no commands queue as expected.
>> DELAY_BETWEEN_RETUNES: does not appear to have any effect but included
>> due to the oddness of the initial delay.
>>
>> I have also observed this blocking behavior with a C++ block that works
>> in a similar way. This behavior was observed with a B200 mini, and I can
>> try to test other USRPs when I have access to them if this is suspected to
>> be specific to the B200mini.
>>
>> My question then is: Is this the desired/expected behavior? If so what is
>> the point of the command queue. If not, am I doing something wrong and how
>> can I achieve the same result in the correct way?
>>
>> Thanks,
>> Jacob
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160705/0ff760e9/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 05 Jul 2016 14:08:36 -0400
From: [email protected]
To: Jacob Gilbert <[email protected]>
Cc: Ian Buckley <[email protected]>, [email protected]
Subject: Re: [USRP-users] Queueing Timed Commands
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Timed tuning is supported on N2xx and X3xx only.
For platforms that support timed tuning, phase-reset is impiemented on:
WBX (with residual 180 deg ambiguity)
SBX
UBX
On 2016-07-05 13:45, Jacob Gilbert via USRP-users wrote:
> Ian,
>
> Thanks for the reply - I should have mentioned that to get around the
> 936x-based lack of timed commands, I am only CORDIC tuning (verified in
> output) - do you happen to know many bus transactions would this be?
>
> Somewhat related, is there a list of commands that can be timed for various
> USRP models?
>
> Jacob
>
> On Tue, Jul 5, 2016 at 11:29 AM, Ian Buckley <[email protected]> wrote:
>
> Jacob, this is an off the cuff comment, I haven't the time to look at your
> example but one thing that might bring greater understanding.
> When we talk about command queue depth, it's in terms of a simple bus
> transaction=1 cmd-queue entry. Retuning some of the USRP front ends might
> well take a fair number of SPI transactions initiated with bus transactions.
> BTW when I say "bus transaction" I mean a simple "PEEK/POKE memory map" style
> operation.
>
> Now specific to B200mini, unless there has been a very recent FPGA change
> then retuning operations that reprogram the RF synthesizers are not available
> as timed commands, they always complete best effort asynchronously. If you
> supply a time then I suspect (knowning how the H/W is designed) that it is
> just ignored.
> -Ian
>
> On Tue, Jul 5, 2016 at 9:26 AM, Jacob Gilbert via USRP-users
> <[email protected]> wrote:
>
> I am having trouble queueing multiple timed commands up for a USRP source, in
> this case the next several frequencies for a fast hopping FHSS transmitter. I
> understand there is a 16 command deep queue on the USRP, but something is
> causing an inability to queue up commands.
>
> Rather than attempt explain what I've tried, I attached an example flowgraph
> of the behavior. Modifying the variables at the top gives a better
> perspective of the issue:
>
> PREQUEUE_TUNES: Setting this will attempt to queue up the retunes before
> starting the FG. No matter which way commands are tuned, the behavior appears
> to be the same.
> INITIAL_DELAY: This confuses me, but if set to a value larger than 0.01
> seconds will allow two commands to queue up as expected. If it is very small
> (eg: < 0.001 s) no commands queue as expected.
> DELAY_BETWEEN_RETUNES: does not appear to have any effect but included due to
> the oddness of the initial delay.
>
> I have also observed this blocking behavior with a C++ block that works in a
> similar way. This behavior was observed with a B200 mini, and I can try to
> test other USRPs when I have access to them if this is suspected to be
> specific to the B200mini.
>
> My question then is: Is this the desired/expected behavior? If so what is the
> point of the command queue. If not, am I doing something wrong and how can I
> achieve the same result in the correct way?
>
> Thanks,
> Jacob _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160705/54885919/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 5 Jul 2016 12:18:43 -0600
From: Jacob Gilbert <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: Ian Buckley <[email protected]>, [email protected]
Subject: Re: [USRP-users] Queueing Timed Commands
Message-ID:
<cac52akbbdwpufvp8ddqb-u7gdzzhg2ufbpbzp24b9t3stox...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I was under the impression the B2xx supported timed commands for FPGA only
operations such as CORDIC tuning based on previous conversations with
Ettus, and my example shows this partially working. Is this not correct?
Jacob
On Jul 5, 2016 13:08, <[email protected]> wrote:
> Timed tuning is supported on N2xx and X3xx only.
>
> For platforms that support timed tuning, phase-reset is impiemented on:
>
> WBX (with residual 180 deg ambiguity)
>
> SBX
>
> UBX
>
>
>
>
>
>
> On 2016-07-05 13:45, Jacob Gilbert via USRP-users wrote:
>
> Ian,
>
> Thanks for the reply - I should have mentioned that to get around the
> 936x-based lack of timed commands, I am only CORDIC tuning (verified in
> output) - do you happen to know many bus transactions would this be?
>
> Somewhat related, is there a list of commands that can be timed for
> various USRP models?
>
> Jacob
>
> On Tue, Jul 5, 2016 at 11:29 AM, Ian Buckley <[email protected]> wrote:
>
>> Jacob, this is an off the cuff comment, I haven't the time to look at
>> your example but one thing that might bring greater understanding.
>> When we talk about command queue depth, it's in terms of a simple bus
>> transaction=1 cmd-queue entry. Retuning some of the USRP front ends might
>> well take a fair number of SPI transactions initiated with bus
>> transactions.
>> BTW when I say "bus transaction" I mean a simple "PEEK/POKE memory map"
>> style operation.
>>
>> Now specific to B200mini, unless there has been a very recent FPGA change
>> then retuning operations that reprogram the RF synthesizers are not
>> available as timed commands, they always complete best effort
>> asynchronously. If you supply a time then I suspect (knowning how the H/W
>> is designed) that it is just ignored.
>> -Ian
>>
>>
>>
>> On Tue, Jul 5, 2016 at 9:26 AM, Jacob Gilbert via USRP-users <
>> [email protected]> wrote:
>>
>>> I am having trouble queueing multiple timed commands up for a USRP
>>> source, in this case the next several frequencies for a fast hopping FHSS
>>> transmitter. I understand there is a 16 command deep queue on the USRP,
>>> but something is causing an inability to queue up commands.
>>>
>>> Rather than attempt explain what I've tried, I attached an example
>>> flowgraph of the behavior. Modifying the variables at the top gives a
>>> better perspective of the issue:
>>>
>>> PREQUEUE_TUNES: Setting this will attempt to queue up the retunes before
>>> starting the FG. No matter which way commands are tuned, the behavior
>>> appears to be the same.
>>> INITIAL_DELAY: This confuses me, but if set to a value larger than 0.01
>>> seconds will allow two commands to queue up as expected. If it is very
>>> small (eg: < 0.001 s) no commands queue as expected.
>>> DELAY_BETWEEN_RETUNES: does not appear to have any effect but included
>>> due to the oddness of the initial delay.
>>>
>>> I have also observed this blocking behavior with a C++ block that works
>>> in a similar way. This behavior was observed with a B200 mini, and I can
>>> try to test other USRPs when I have access to them if this is suspected to
>>> be specific to the B200mini.
>>>
>>> My question then is: Is this the desired/expected behavior? If so what
>>> is the point of the command queue. If not, am I doing something wrong and
>>> how can I achieve the same result in the correct way?
>>>
>>> Thanks,
>>> Jacob
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160705/25f875d0/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 5 Jul 2016 20:22:30 +0200
From: Piotr Krysik <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 Overflow
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
One more thing: power saving should be turned off. I'm using
indicator-cpufreq for this.
Best Regards,
Piotr Krysik
W dniu 05.07.2016 o 19:22, Piotr Krysik via USRP-users pisze:
> Hi all,
>
> If after what I said on the list (or privately ;) ) on some occasions
> about USRP B210 you have a feeling that I'm only complaining about the
> performance of the device, while not trying to help myself, maybe this
> post will convince you that this impression is far from the truth.
>
> I've just tested the optimization mentioned by Marcus (increasing Min
> Output Buffer value in the Advanced tab to some high number - in my case
> 100000000) in the previous post, together with the previous optimization
> (I've set value of Device Arguments to "num_recv_frames=1024") and I got
> 20 minutes of continuous recording (no overflows) with sample rate 25MHz
> (two channels with 16 bit samples). So it is much higher stream of data
> stored to disk (5x) than the minimum mentioned by me previously.
> Actually, this is maximum possible to get from B210 with 2 RX channels
> and 16bit sampling and it WORKS (at least for 20 minutes during which I
> tested it - probably more is possible).
>
> However, I'm not writing this to tell you that it works for me. I want
> to share the solution, so others can use it and improve it. The system I
> used for the recording is following:
> -Dell Latitude E6330, CPU Intel(R) Core(TM) i7-3540M CPU @ 3.00GHz, 16GB
> (2x8GB) RAM,
> -SSD disk used for storing the recording: Samsung SSD 850 EVO 1TB,
> -system: Ubuntu 16.04 with GNU Radio and UHD installed from packages
> provided with distribution.
>
> The gnuradio-companion application that I used is shown on the
> print-screen and the GRC file is also attached.
>
> Best Regards,
> Piotr Krysik
>
> W dniu 04.07.2016 o 23:16, Marcus M?ller via USRP-users pisze:
>> I can also recommend doing two things:
>>
>> 1. Multi-thread your receiver, so that the thread calling recv() isn't
>> blocked for the duration of write()ing things to storage. Also, now
>> you're not inherently pushing one core to a high clock speed. The
>> rx_samples_to_file example is really really really just an example of
>> how to set up a multi_usrp object, get the rx_streamer and call
>> recv(), nothing to use as reference when building high-rate receivers.
>>
>> 2. Using something with a large buffering when writing to storage, as
>> storage rates and latencies are totally unpredictable.
>>
>> In fact, using GNU Radio you can get both at once: Just connect your
>> USRP source to a file sink. GNU Radio blocks run each in their own
>> thread, and the output/input connection is actually a ring buffer; you
>> can increase the size of that in the "advanced" tab of the USRP
>> source, by increasing the minimum output buffer size to something
>> relatively large; I tend to use values 512*2**20 (==512MB) because RAM
>> is cheap :)
>>
>> If you don't want to use GNU Radio, I can dig up a rather naively
>> implemented multi-thread-receiver that I wrote a while ago. It worked
>> pretty well at high rates, and does nothing but allocate a bunch of
>> "samples_per_packet*bytes_per_sample" sized buffers, puts them in a
>> "ready to use" queue, let's a thread running recv() fill them one by
>> one, push them into a "ready to write" queue, from which a storage IO
>> thread takes them and writes their content to a file, then pushes them
>> back to the "ready to use" queue. The design was really bad (buffers
>> aren't inherently allocated contiguously in memory, so we're
>> potentially losing memory bandwidth unnecessarily), but using enough
>> buffers, one can completely hide the fact that storage is highly
>> non-deterministic and that handling storage IO might interfere with
>> the amount of CPU the OS has available for handling USB traffic.
>>
>> Best regards,
>>
>> Marcus
------------------------------
Message: 9
Date: Tue, 05 Jul 2016 14:24:17 -0400
From: [email protected]
To: Jacob Gilbert <[email protected]>
Cc: Ian Buckley <[email protected]>, [email protected]
Subject: Re: [USRP-users] Queueing Timed Commands
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I should have explictly said "Timed RF-front-end tuning".
On 2016-07-05 14:18, Jacob Gilbert wrote:
> I was under the impression the B2xx supported timed commands for FPGA only
> operations such as CORDIC tuning based on previous conversations with Ettus,
> and my example shows this partially working. Is this not correct?
>
> Jacob
>
> On Jul 5, 2016 13:08, <[email protected]> wrote:
>
> Timed tuning is supported on N2xx and X3xx only.
>
> For platforms that support timed tuning, phase-reset is impiemented on:
>
> WBX (with residual 180 deg ambiguity)
>
> SBX
>
> UBX
>
> On 2016-07-05 13:45, Jacob Gilbert via USRP-users wrote:
> Ian,
>
> Thanks for the reply - I should have mentioned that to get around the
> 936x-based lack of timed commands, I am only CORDIC tuning (verified in
> output) - do you happen to know many bus transactions would this be?
>
> Somewhat related, is there a list of commands that can be timed for various
> USRP models?
>
> Jacob
>
> On Tue, Jul 5, 2016 at 11:29 AM, Ian Buckley <[email protected]> wrote:
>
> Jacob, this is an off the cuff comment, I haven't the time to look at your
> example but one thing that might bring greater understanding.
> When we talk about command queue depth, it's in terms of a simple bus
> transaction=1 cmd-queue entry. Retuning some of the USRP front ends might
> well take a fair number of SPI transactions initiated with bus transactions.
> BTW when I say "bus transaction" I mean a simple "PEEK/POKE memory map" style
> operation.
>
> Now specific to B200mini, unless there has been a very recent FPGA change
> then retuning operations that reprogram the RF synthesizers are not available
> as timed commands, they always complete best effort asynchronously. If you
> supply a time then I suspect (knowning how the H/W is designed) that it is
> just ignored.
> -Ian
>
> On Tue, Jul 5, 2016 at 9:26 AM, Jacob Gilbert via USRP-users
> <[email protected]> wrote:
>
> I am having trouble queueing multiple timed commands up for a USRP source, in
> this case the next several frequencies for a fast hopping FHSS transmitter. I
> understand there is a 16 command deep queue on the USRP, but something is
> causing an inability to queue up commands.
>
> Rather than attempt explain what I've tried, I attached an example flowgraph
> of the behavior. Modifying the variables at the top gives a better
> perspective of the issue:
>
> PREQUEUE_TUNES: Setting this will attempt to queue up the retunes before
> starting the FG. No matter which way commands are tuned, the behavior appears
> to be the same.
> INITIAL_DELAY: This confuses me, but if set to a value larger than 0.01
> seconds will allow two commands to queue up as expected. If it is very small
> (eg: < 0.001 s) no commands queue as expected.
> DELAY_BETWEEN_RETUNES: does not appear to have any effect but included due to
> the oddness of the initial delay.
>
> I have also observed this blocking behavior with a C++ block that works in a
> similar way. This behavior was observed with a B200 mini, and I can try to
> test other USRPs when I have access to them if this is suspected to be
> specific to the B200mini.
>
> My question then is: Is this the desired/expected behavior? If so what is the
> point of the command queue. If not, am I doing something wrong and how can I
> achieve the same result in the correct way?
>
> Thanks,
> Jacob _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160705/4118ae47/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 5 Jul 2016 11:30:30 -0700
From: Ian Buckley <[email protected]>
To: Jacob Gilbert <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Queueing Timed Commands
Message-ID:
<CAM_0ocH2ZjJQuOXF0p5nUVS0MwhYFrV-6PvsT9wp=-SQpz=s...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Jacob,
A CORDIC retune is a single 32bit write transaction, so that would be
efficient in terms of cmd-q usage. Other operations that change state in
the radio would share this queue. Typically (after initial config) that
would include operations such as starting and stopping RX/TX and RF switch
configuration changes. The command queue is also probably 32 entries on any
B2xx style device.
I'll let one of the Ettus team respond to your more involved question in
detail but generically, its the AD936x based products that lack timed
operations related to (RF) radio interactions. Daughter board based USRP's
should offer timed operations for pretty much all commands.
-Ian
On Tue, Jul 5, 2016 at 10:45 AM, Jacob Gilbert <[email protected]>
wrote:
> Ian,
>
> Thanks for the reply - I should have mentioned that to get around the
> 936x-based lack of timed commands, I am only CORDIC tuning (verified in
> output) - do you happen to know many bus transactions would this be?
>
> Somewhat related, is there a list of commands that can be timed for
> various USRP models?
>
> Jacob
>
> On Tue, Jul 5, 2016 at 11:29 AM, Ian Buckley <[email protected]> wrote:
>
>> Jacob, this is an off the cuff comment, I haven't the time to look at
>> your example but one thing that might bring greater understanding.
>> When we talk about command queue depth, it's in terms of a simple bus
>> transaction=1 cmd-queue entry. Retuning some of the USRP front ends might
>> well take a fair number of SPI transactions initiated with bus
>> transactions.
>> BTW when I say "bus transaction" I mean a simple "PEEK/POKE memory map"
>> style operation.
>>
>> Now specific to B200mini, unless there has been a very recent FPGA change
>> then retuning operations that reprogram the RF synthesizers are not
>> available as timed commands, they always complete best effort
>> asynchronously. If you supply a time then I suspect (knowning how the H/W
>> is designed) that it is just ignored.
>> -Ian
>>
>>
>>
>> On Tue, Jul 5, 2016 at 9:26 AM, Jacob Gilbert via USRP-users <
>> [email protected]> wrote:
>>
>>> I am having trouble queueing multiple timed commands up for a USRP
>>> source, in this case the next several frequencies for a fast hopping FHSS
>>> transmitter. I understand there is a 16 command deep queue on the USRP,
>>> but something is causing an inability to queue up commands.
>>>
>>> Rather than attempt explain what I've tried, I attached an example
>>> flowgraph of the behavior. Modifying the variables at the top gives a
>>> better perspective of the issue:
>>>
>>> PREQUEUE_TUNES: Setting this will attempt to queue up the retunes before
>>> starting the FG. No matter which way commands are tuned, the behavior
>>> appears to be the same.
>>> INITIAL_DELAY: This confuses me, but if set to a value larger than 0.01
>>> seconds will allow two commands to queue up as expected. If it is very
>>> small (eg: < 0.001 s) no commands queue as expected.
>>> DELAY_BETWEEN_RETUNES: does not appear to have any effect but included
>>> due to the oddness of the initial delay.
>>>
>>> I have also observed this blocking behavior with a C++ block that works
>>> in a similar way. This behavior was observed with a B200 mini, and I can
>>> try to test other USRPs when I have access to them if this is suspected to
>>> be specific to the B200mini.
>>>
>>> My question then is: Is this the desired/expected behavior? If so what
>>> is the point of the command queue. If not, am I doing something wrong and
>>> how can I achieve the same result in the correct way?
>>>
>>> Thanks,
>>> Jacob
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160705/550e366a/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 5 Jul 2016 18:30:33 +0000
From: "Yin, Charles - 0665 - MITLL" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] MSK Modulation Examples
Message-ID:
<13657fc12b4974458e83264543702551069...@lle2k10-mbx02.mitll.ad.local>
Content-Type: text/plain; charset="us-ascii"
Neel and Jonathan,
Thank you for your help, I was able to get RFNoC working on my machine finally.
I am still fairly new with developing programs in Verilog and I was wondering
if there were some examples that I can look at with creating MSK modulation for
GNU Radio. If not, is there any general development tutorials that I can look
at? Thanks!
Charles Yin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160705/d3b1b248/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 5 Jul 2016 19:52:05 +0000
From: Weidong Wang <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] How to add interrupts on E310's Linux system
Message-ID:
<bl2pr03mb4667fb870651e5619fd1e16f0...@bl2pr03mb466.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I want to create a simple CE using RFNOC to generate an interrupt and send it
to the ARM cpu.
1. Could I add this interrupt signal directly to the signal "IRQ_F2P" in e310.v?
In e310.v line 415, we have :
// Misc interrupts, GPIO, clk
.IRQ_F2P({12'h0, pmu_irq, button_release_irq, button_press_irq,
stream_irq}),
2. How could I add it in linux system? I fond some topics about it for the
regular linux systems, but it seems not useful for the system on E310.
Regards,
Weidong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160705/cab76260/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 5 Jul 2016 22:23:20 +0200
From: Piotr Krysik <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 Overflow
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Paul,
The gr-analysis looks like a set of great tools to manipulate data
captured with USRPs.
Regarding efficiency GNU Radio - I've just posted three hours ago a
gnuradio-companion application that stores 20 minutes of 50MSamp/s
stream to a SSD disk (longer recordings are also possible, I don't know
if there is some limit other than size of the disk). This was without
meta-data. But now I connected unbuffered File Meta Sinks with detached
meta-data and the result is the same - it works.
Generally I haven't had yet a situation where the problems with storing
the data to disk was GNU Radio's fault. Maybe imperfect configuration of
UHD and GNU Radio (this was the problem in this case).
Best Regards,
Piotr
W dniu 05.07.2016 o 19:05, Garver, Paul W via USRP-users pisze:
> I can easily record for 10 minutes with the B210 at 25 MSPS on a
> single Samsung Evo 840 mSSD without dropping samples on an
> XFS-formatted partition. See last year?s GRCON (GRCON2015) for details:
>
>
> Specifically, you may be interested in the specrec (Linux-only)
> command-line tool in gr-analysis [2].
>
> I might point out that the file meta sink block in gnuradio is fairly
> inefficient in how it writes metadata to disk as it does a fair bit of
> seeking. If you need metadata with the files, you will probably get
> poor performance using file meta sink and GNURadio. In our systems
> with metadata, uhd_rx_cfile can only do 10 MSPS, whereas specrec can
> go up to 25 MSPS for an improvement of 15 MSPS.
>
> Hope this helps.
>
> [1]
> http://www.trondeau.com/grcon15-presentations#wednesday_Lincoln_Synchronized
> [2] https://github.com/garverp/gr-analysis
>> *From: *Jeremy Hershberger <[email protected]
>> <mailto:[email protected]>>
>> *Subject: **Re: [USRP-users] USRP B210 Overflow*
>> *Date: *July 4, 2016 at 4:49:10 PM EDT
>> *To: *Piotr Krysik <[email protected] <mailto:[email protected]>>
>> *Cc: *usrp-users <[email protected]
>> <mailto:[email protected]>>
>>
>>
>> I have had success streaming from a B210 (2 channel RX, 16-bit,
>> 25MS/s) to a RAM disk. I have also had success writing smaller files
>> to the RAM disk (maybe a second or two of data) and then moving those
>> files in a separate background process to an SSD. By pulling data
>> out of the RAM drive at a rate that is slightly less than data flows
>> in, I can capture for a longer total duration. The performance would
>> depend greatly on the speed at which your host can move data from RAM
>> to disk, but by changing the size of the temporary files in RAM you
>> should be able to extend your capture duration significantly.
>>
>> On Mon, Jul 4, 2016 at 10:33 AM, Piotr Krysik via
>> USRP-users <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> W dniu 04.07.2016 o 14:45, Piotr Krysik via USRP-users pisze:
>> > W dniu 17.06.2016 o 19:28, Marcus D. Leech via USRP-users pisze:
>> >> On 06/17/2016 01:07 PM, Marcus M?ller via USRP-users wrote:
>> >>> Hi Xuesong,
>> >>>
>> >>> I was just told I misread your email. I'd like to apologize
>> for that!
>> >>>
>> >>>> 3) There will DEFINITELY be overruns (in less than 2
>> minutes) when
>> >>>> streaming data to a file even with sampling rate of 5 MHz:
>> >>>> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
>> >>>> --wirefmt=sc16 --duration=600
>> >>> Ooops, you're doing 5MS/s here.
>> >>> Ok, that's only 20MB/s, and now everything is comparable to
>> the N210
>> >>> case.
>> >>> This is actually not typical; let's do a quick benchmark with dd:
>> >>>
>> >>> yes | dd of=/home/marcus/Desktop/test.bin bs=512
>> count=$((4*600 * 5 * 10**6 / 512)) conv=fsync
>> >>>
>> >>> to try and write data in roughly the same granularity as
>> >>> rx_samples_to_file does by default for a B210 connected using
>> USB3
>> >>> with the same amount of data.
>> >>>
>> >>> Could you also copy&paste the full output of
>> rx_samples_to_file? That
>> >>> could be very helpful.
>> >>>
>> >>> I'm still pretty sure the problem is storage here ? my
>> suspicion is
>> >>> that the write buffer of your operating system fills up with
>> the 12GB
>> >>> of data coming in from the USRP, and then suddenly, the OS has to
>> >>> start throttling the USRP, because it can't write data to the SSD
>> >>> fast enough - possibly partly because filesystem access is
>> everything
>> >>> but CPU-free.
>> >>>
>> >>> Are you planning on using GNU Radio? If you want to do that
>> anyway,
>> >>> something like:
>> >>>
>> >>> UHD USRP Source ---> File Sink
>> >>>
>> >>> would probably work better than the rx_samples_to_file example,
>> >>> because GNU Radio is inherently multi-threaded. If you're
>> using the
>> >>> GNU Radio companion, the USRP Source block has an "advanced
>> options"
>> >>> tab, where you can set a larger minimum output buffer; try
>> something
>> >>> like 10**7, which will give you a couple Megabytes of buffering
>> >>> already, which might already compensate for the non-uniform write
>> >>> speeds of a storage device.
>> >>>
>> >>> Best regards,
>> >>> Marcus
>> >>>
>> >>>
>> >> Also try increasing num_recv_frames in the device argument--up to 128
>> >> or so.
>> >>
>> > Hi Xuesong,
>> >
>> > There is a genuine problem with streaming from B210 to a disk.
>> No amount
>> > of computer resources, optimizations and trying different streaming
>> > applications solved the problem for me (rx_sample_to_file is
>> just an
>> > example provided with the driver so it might not be the best
>> application).
>> >
>> > For all others who are trying to help - if you can stream from
>> B210 to a
>> > disk on your side at the sample rate of at least 10MHz (single
>> channel,
>> > 16bit) and save about 10 minutes of such stream to disk without an
>> > overflow - please share:
>> > -what is a configuration of a computer on which you achieved that
>> > (motherboard, processor, memory, disk),
>> > -what application did you use.
>> >
>> > Until someone proves otherwise (at sample rates >=10MSamp/s), it is
>> > officially not possible to stream from USRP B210 to a disk without
>> > transmission problems.
>> >
>> >
>> Hi all again,
>>
>> One little tip: streaming to a ramdisk works without problems with
>> overflows. If I need to make a short recording (single minutes as
>> amount
>> of RAM is usually quite limited) with USRP B210 I'm using a ramdisc
>> created with command like this:
>>
>> sudo mount -t tmpfs -o size=10000m tmpfs /path/to/ramdisc/directory
>>
>> where 10000m is size of the ramdisc in mega-bytes.
>>
>> Streaming to a real disc from B210 doesn't work without problems
>> - until
>> someone figures out what is the problem/bottleneck.
>>
>> Best Regards,
>> Piotr Krysik
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>>
>> *From: *Marcus M?ller <[email protected]
>> <mailto:[email protected]>>
>> *Subject: **Re: [USRP-users] USRP B210 Overflow*
>> *Date: *July 4, 2016 at 5:16:47 PM EDT
>> *To: *<[email protected] <mailto:[email protected]>>
>>
>>
>> I can also recommend doing two things:
>>
>> 1. Multi-thread your receiver, so that the thread calling recv()
>> isn't blocked for the duration of write()ing things to storage. Also,
>> now you're not inherently pushing one core to a high clock speed. The
>> rx_samples_to_file example is really really really just an example of
>> how to set up a multi_usrp object, get the rx_streamer and call
>> recv(), nothing to use as reference when building high-rate receivers.
>>
>> 2. Using something with a large buffering when writing to storage, as
>> storage rates and latencies are totally unpredictable.
>>
>> In fact, using GNU Radio you can get both at once: Just connect your
>> USRP source to a file sink. GNU Radio blocks run each in their own
>> thread, and the output/input connection is actually a ring buffer;
>> you can increase the size of that in the "advanced" tab of the USRP
>> source, by increasing the minimum output buffer size to something
>> relatively large; I tend to use values 512*2**20 (==512MB) because
>> RAM is cheap :)
>>
>> If you don't want to use GNU Radio, I can dig up a rather naively
>> implemented multi-thread-receiver that I wrote a while ago. It worked
>> pretty well at high rates, and does nothing but allocate a bunch of
>> "samples_per_packet*bytes_per_sample" sized buffers, puts them in a
>> "ready to use" queue, let's a thread running recv() fill them one by
>> one, push them into a "ready to write" queue, from which a storage IO
>> thread takes them and writes their content to a file, then pushes
>> them back to the "ready to use" queue. The design was really bad
>> (buffers aren't inherently allocated contiguously in memory, so we're
>> potentially losing memory bandwidth unnecessarily), but using enough
>> buffers, one can completely hide the fact that storage is highly
>> non-deterministic and that handling storage IO might interfere with
>> the amount of CPU the OS has available for handling USB traffic.
>>
>> Best regards,
>>
>> Marcus
>>
>> On 04.07.2016 22:49, Jeremy Hershberger via USRP-users wrote:
>>> I have had success streaming from a B210 (2 channel RX, 16-bit,
>>> 25MS/s) to a RAM disk. I have also had success writing smaller
>>> files to the RAM disk (maybe a second or two of data) and then
>>> moving those files in a separate background process to an SSD. By
>>> pulling data out of the RAM drive at a rate that is slightly less
>>> than data flows in, I can capture for a longer total duration. The
>>> performance would depend greatly on the speed at which your host can
>>> move data from RAM to disk, but by changing the size of the
>>> temporary files in RAM you should be able to extend your capture
>>> duration significantly.
>>>
>>> On Mon, Jul 4, 2016 at 10:33 AM, Piotr Krysik via
>>> USRP-users <[email protected]> wrote:
>>>
>>> W dniu 04.07.2016 o 14:45, Piotr Krysik via USRP-users pisze:
>>> > W dniu 17.06.2016 o 19:28, Marcus D. Leech via USRP-users pisze:
>>> >> On 06/17/2016 01:07 PM, Marcus M?ller via USRP-users wrote:
>>> >>> Hi Xuesong,
>>> >>>
>>> >>> I was just told I misread your email. I'd like to apologize
>>> for that!
>>> >>>
>>> >>>> 3) There will DEFINITELY be overruns (in less than 2
>>> minutes) when
>>> >>>> streaming data to a file even with sampling rate of 5 MHz:
>>> >>>> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
>>> >>>> --wirefmt=sc16 --duration=600
>>> >>> Ooops, you're doing 5MS/s here.
>>> >>> Ok, that's only 20MB/s, and now everything is comparable to
>>> the N210
>>> >>> case.
>>> >>> This is actually not typical; let's do a quick benchmark
>>> with dd:
>>> >>>
>>> >>> yes | dd of=/home/marcus/Desktop/test.bin bs=512
>>> count=$((4*600 * 5 * 10**6 / 512)) conv=fsync
>>> >>>
>>> >>> to try and write data in roughly the same granularity as
>>> >>> rx_samples_to_file does by default for a B210 connected
>>> using USB3
>>> >>> with the same amount of data.
>>> >>>
>>> >>> Could you also copy&paste the full output of
>>> rx_samples_to_file? That
>>> >>> could be very helpful.
>>> >>>
>>> >>> I'm still pretty sure the problem is storage here ? my
>>> suspicion is
>>> >>> that the write buffer of your operating system fills up with
>>> the 12GB
>>> >>> of data coming in from the USRP, and then suddenly, the OS
>>> has to
>>> >>> start throttling the USRP, because it can't write data to
>>> the SSD
>>> >>> fast enough - possibly partly because filesystem access is
>>> everything
>>> >>> but CPU-free.
>>> >>>
>>> >>> Are you planning on using GNU Radio? If you want to do that
>>> anyway,
>>> >>> something like:
>>> >>>
>>> >>> UHD USRP Source ---> File Sink
>>> >>>
>>> >>> would probably work better than the rx_samples_to_file example,
>>> >>> because GNU Radio is inherently multi-threaded. If you're
>>> using the
>>> >>> GNU Radio companion, the USRP Source block has an "advanced
>>> options"
>>> >>> tab, where you can set a larger minimum output buffer; try
>>> something
>>> >>> like 10**7, which will give you a couple Megabytes of buffering
>>> >>> already, which might already compensate for the non-uniform
>>> write
>>> >>> speeds of a storage device.
>>> >>>
>>> >>> Best regards,
>>> >>> Marcus
>>> >>>
>>> >>>
>>> >> Also try increasing num_recv_frames in the device argument--up to 128
>>> >> or so.
>>> >>
>>> > Hi Xuesong,
>>> >
>>> > There is a genuine problem with streaming from B210 to a disk.
>>> No amount
>>> > of computer resources, optimizations and trying different
>>> streaming
>>> > applications solved the problem for me (rx_sample_to_file is
>>> just an
>>> > example provided with the driver so it might not be the best
>>> application).
>>> >
>>> > For all others who are trying to help - if you can stream from
>>> B210 to a
>>> > disk on your side at the sample rate of at least 10MHz (single
>>> channel,
>>> > 16bit) and save about 10 minutes of such stream to disk without an
>>> > overflow - please share:
>>> > -what is a configuration of a computer on which you achieved that
>>> > (motherboard, processor, memory, disk),
>>> > -what application did you use.
>>> >
>>> > Until someone proves otherwise (at sample rates >=10MSamp/s),
>>> it is
>>> > officially not possible to stream from USRP B210 to a disk without
>>> > transmission problems.
>>> >
>>> >
>>> Hi all again,
>>>
>>> One little tip: streaming to a ramdisk works without problems with
>>> overflows. If I need to make a short recording (single minutes
>>> as amount
>>> of RAM is usually quite limited) with USRP B210 I'm using a ramdisc
>>> created with command like this:
>>>
>>> sudo mount -t tmpfs -o size=10000m tmpfs /path/to/ramdisc/directory
>>>
>>> where 10000m is size of the ramdisc in mega-bytes.
>>>
>>> Streaming to a real disc from B210 doesn't work without problems
>>> - until
>>> someone figures out what is the problem/bottleneck.
>>>
>>> Best Regards,
>>> Piotr Krysik
>>>
------------------------------
Message: 14
Date: Tue, 5 Jul 2016 17:02:23 -0600
From: Jacob Gilbert <[email protected]>
To: Ian Buckley <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Queueing Timed Commands
Message-ID:
<cac52akbptrv4kgfibcez1ngxkhmgnavbrubxcaomgypckqp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Ok, so I will take the info you and Marcus provided to mean that what I am
attempting to do (queue timed CORDIC tunes) _should_ work. The other radio
operations might explain why the behavior is different without any delay
after starting, but it still does not make sense to me that I cannot queue
up commands later. I'll wait for someone from Ettus to weigh in on what
might be going on here.
Thanks again,
Jacob
On Tue, Jul 5, 2016 at 12:30 PM, Ian Buckley <[email protected]> wrote:
> Jacob,
> A CORDIC retune is a single 32bit write transaction, so that would be
> efficient in terms of cmd-q usage. Other operations that change state in
> the radio would share this queue. Typically (after initial config) that
> would include operations such as starting and stopping RX/TX and RF switch
> configuration changes. The command queue is also probably 32 entries on any
> B2xx style device.
> I'll let one of the Ettus team respond to your more involved question in
> detail but generically, its the AD936x based products that lack timed
> operations related to (RF) radio interactions. Daughter board based USRP's
> should offer timed operations for pretty much all commands.
>
> -Ian
>
>
> On Tue, Jul 5, 2016 at 10:45 AM, Jacob Gilbert <[email protected]>
> wrote:
>
>> Ian,
>>
>> Thanks for the reply - I should have mentioned that to get around the
>> 936x-based lack of timed commands, I am only CORDIC tuning (verified in
>> output) - do you happen to know many bus transactions would this be?
>>
>> Somewhat related, is there a list of commands that can be timed for
>> various USRP models?
>>
>> Jacob
>>
>> On Tue, Jul 5, 2016 at 11:29 AM, Ian Buckley <[email protected]>
>> wrote:
>>
>>> Jacob, this is an off the cuff comment, I haven't the time to look at
>>> your example but one thing that might bring greater understanding.
>>> When we talk about command queue depth, it's in terms of a simple bus
>>> transaction=1 cmd-queue entry. Retuning some of the USRP front ends might
>>> well take a fair number of SPI transactions initiated with bus
>>> transactions.
>>> BTW when I say "bus transaction" I mean a simple "PEEK/POKE memory map"
>>> style operation.
>>>
>>> Now specific to B200mini, unless there has been a very recent FPGA
>>> change then retuning operations that reprogram the RF synthesizers are not
>>> available as timed commands, they always complete best effort
>>> asynchronously. If you supply a time then I suspect (knowning how the H/W
>>> is designed) that it is just ignored.
>>> -Ian
>>>
>>>
>>>
>>> On Tue, Jul 5, 2016 at 9:26 AM, Jacob Gilbert via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> I am having trouble queueing multiple timed commands up for a USRP
>>>> source, in this case the next several frequencies for a fast hopping FHSS
>>>> transmitter. I understand there is a 16 command deep queue on the USRP,
>>>> but something is causing an inability to queue up commands.
>>>>
>>>> Rather than attempt explain what I've tried, I attached an example
>>>> flowgraph of the behavior. Modifying the variables at the top gives a
>>>> better perspective of the issue:
>>>>
>>>> PREQUEUE_TUNES: Setting this will attempt to queue up the retunes
>>>> before starting the FG. No matter which way commands are tuned, the
>>>> behavior appears to be the same.
>>>> INITIAL_DELAY: This confuses me, but if set to a value larger than 0.01
>>>> seconds will allow two commands to queue up as expected. If it is very
>>>> small (eg: < 0.001 s) no commands queue as expected.
>>>> DELAY_BETWEEN_RETUNES: does not appear to have any effect but included
>>>> due to the oddness of the initial delay.
>>>>
>>>> I have also observed this blocking behavior with a C++ block that works
>>>> in a similar way. This behavior was observed with a B200 mini, and I can
>>>> try to test other USRPs when I have access to them if this is suspected to
>>>> be specific to the B200mini.
>>>>
>>>> My question then is: Is this the desired/expected behavior? If so what
>>>> is the point of the command queue. If not, am I doing something wrong and
>>>> how can I achieve the same result in the correct way?
>>>>
>>>> Thanks,
>>>> Jacob
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160705/46f607f4/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 6 Jul 2016 08:56:46 +0800
From: john liu <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] monitor with E310/312
Message-ID:
<caf6nntjppoazolaaudmkfeq+ytfnoawjgizv25jwbte+zrk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
we used a USB TO VGA adapter connected E310 to a dell E190S monitor,but
nothing appeared.
the E310 images is sdimage-gnuradio-demo.direct.xz.
need we do something special?
best regards
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160706/4fe08aed/attachment-0001.html>
------------------------------
Message: 16
Date: Tue, 5 Jul 2016 23:15:50 -0400
From: Philip Balister <[email protected]>
To: john liu <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] monitor with E310/312
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 07/05/2016 08:56 PM, john liu via USRP-users wrote:
> Dear all,
> we used a USB TO VGA adapter connected E310 to a dell E190S monitor,but
> nothing appeared.
> the E310 images is sdimage-gnuradio-demo.direct.xz.
> need we do something special?
Not all USB to VGA adpaters will work. We have tested with a couple of
USB LCD panels but no the actual converters. Linux only has support for
the older converters.
The newer converters also use the on board video card. Since the E
series has no video card, the do not work.
Philip
>
> best regards
> John
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 17
Date: Wed, 6 Jul 2016 11:22:51 +0800
From: john liu <[email protected]>
To: Philip Balister <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] monitor with E310/312
Message-ID:
<CAF6NnT+5Fy7HNwvA4=tgb2spytnthkbqbkkbjcvhcfa5y1-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Philip,
thank you.
could you tell me what type of converters you used?
John
On Wed, Jul 6, 2016 at 11:15 AM, Philip Balister <[email protected]> wrote:
> On 07/05/2016 08:56 PM, john liu via USRP-users wrote:
> > Dear all,
> > we used a USB TO VGA adapter connected E310 to a dell E190S monitor,but
> > nothing appeared.
> > the E310 images is sdimage-gnuradio-demo.direct.xz.
> > need we do something special?
>
> Not all USB to VGA adpaters will work. We have tested with a couple of
> USB LCD panels but no the actual converters. Linux only has support for
> the older converters.
>
> The newer converters also use the on board video card. Since the E
> series has no video card, the do not work.
>
> Philip
>
> >
> > best regards
> > John
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160706/3c6c3269/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 6 Jul 2016 09:22:02 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Queueing Timed Commands
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Jacob, Ian and Marcus,
so, having had a look at your Python code (haven't yet executed it):
this looks about right. There's a couple of things that would be worth
investigating:
> INITIAL_DELAY: This confuses me, but if set to a value larger than
> 0.01 seconds will allow two commands to queue up as expected. If it is
> very small (eg: < 0.001 s) no commands queue as expected.
this might actually be a hint. Knowing gr-uhd a bit, what happens in the
usrp_source::start() method is that an UHD rx_streamer object is
created, and a timed "start streaming" command is queued ? a
"reasonable" delay in the future (which happens to be 0.1s, determined
by high-quality eyeballing) to avoid overflows from happening before the
flow graph is even up and running. The start() method of all blocks in a
flowgraph is called (sequentially, btw) when you call tb.start().
So, two cases:
*1. PREQUEUE_TUNES is not set*
The first entry in the command queue is the start streaming command at
now+0.1s ? and all the commands will be queued behind that, so if their
execution time was before that, they will be executed but immediately
after the start of streaming
*2. PREQUEUE_TUNES is not set*
The commands _SHOULD_ get queued correctly; the fact that they "clog"
the command queue can lead to a situation where your tuning happens
before you get any samples ? making it rather pointless.
Based on these considerations, you should probably not set
PREQUEUE_TUNES, but should set_start_time() explicitely before calling
start() before issueing tune requests and base your time offsets on the
start time as reference.
Still, I'm not 100% this explains that queuing doesn't work as you
expect it; would you be as nice as to share the output of running your
flow graph as it is (and maybe even with the changes I propose)?
Best regards,
Marcus
On 06.07.2016 01:02, Jacob Gilbert via USRP-users wrote:
> Ok, so I will take the info you and Marcus provided to mean that what
> I am attempting to do (queue timed CORDIC tunes) _should_ work. The
> other radio operations might explain why the behavior is different
> without any delay after starting, but it still does not make sense to
> me that I cannot queue up commands later. I'll wait for someone from
> Ettus to weigh in on what might be going on here.
>
> Thanks again,
> Jacob
>
> On Tue, Jul 5, 2016 at 12:30 PM, Ian Buckley <[email protected]
> <mailto:[email protected]>> wrote:
>
> Jacob,
> A CORDIC retune is a single 32bit write transaction, so that would
> be efficient in terms of cmd-q usage. Other operations that change
> state in the radio would share this queue. Typically (after
> initial config) that would include operations such as starting and
> stopping RX/TX and RF switch configuration changes. The command
> queue is also probably 32 entries on any B2xx style device.
> I'll let one of the Ettus team respond to your more involved
> question in detail but generically, its the AD936x based products
> that lack timed operations related to (RF) radio interactions.
> Daughter board based USRP's should offer timed operations for
> pretty much all commands.
>
> -Ian
>
>
> On Tue, Jul 5, 2016 at 10:45 AM, Jacob Gilbert
> <[email protected] <mailto:[email protected]>> wrote:
>
> Ian,
>
> Thanks for the reply - I should have mentioned that to get
> around the 936x-based lack of timed commands, I am only CORDIC
> tuning (verified in output) - do you happen to know many bus
> transactions would this be?
>
> Somewhat related, is there a list of commands that can be
> timed for various USRP models?
>
> Jacob
>
> On Tue, Jul 5, 2016 at 11:29 AM, Ian Buckley
> <[email protected] <mailto:[email protected]>> wrote:
>
> Jacob, this is an off the cuff comment, I haven't the time
> to look at your example but one thing that might bring
> greater understanding.
> When we talk about command queue depth, it's in terms of a
> simple bus transaction=1 cmd-queue entry. Retuning some of
> the USRP front ends might well take a fair number of SPI
> transactions initiated with bus transactions.
> BTW when I say "bus transaction" I mean a simple
> "PEEK/POKE memory map" style operation.
>
> Now specific to B200mini, unless there has been a very
> recent FPGA change then retuning operations that reprogram
> the RF synthesizers are not available as timed commands,
> they always complete best effort asynchronously. If you
> supply a time then I suspect (knowning how the H/W is
> designed) that it is just ignored.
> -Ian
>
>
>
> On Tue, Jul 5, 2016 at 9:26 AM, Jacob Gilbert via
> USRP-users <[email protected]
> <mailto:[email protected]>> wrote:
>
> I am having trouble queueing multiple timed commands
> up for a USRP source, in this case the next several
> frequencies for a fast hopping FHSS transmitter. I
> understand there is a 16 command deep queue on the
> USRP, but something is causing an inability to queue
> up commands.
>
> Rather than attempt explain what I've tried, I
> attached an example flowgraph of the behavior.
> Modifying the variables at the top gives a better
> perspective of the issue:
>
> PREQUEUE_TUNES: Setting this will attempt to queue up
> the retunes before starting the FG. No matter which
> way commands are tuned, the behavior appears to be the
> same.
> INITIAL_DELAY: This confuses me, but if set to a value
> larger than 0.01 seconds will allow two commands to
> queue up as expected. If it is very small (eg: < 0.001
> s) no commands queue as expected.
> DELAY_BETWEEN_RETUNES: does not appear to have any
> effect but included due to the oddness of the initial
> delay.
>
> I have also observed this blocking behavior with a C++
> block that works in a similar way. This behavior was
> observed with a B200 mini, and I can try to test other
> USRPs when I have access to them if this is suspected
> to be specific to the B200mini.
>
> My question then is: Is this the desired/expected
> behavior? If so what is the point of the command
> queue. If not, am I doing something wrong and how can
> I achieve the same result in the correct way?
>
> Thanks,
> Jacob
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> <mailto:[email protected]>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160706/89d03cbf/attachment-0001.html>
------------------------------
Message: 19
Date: Wed, 6 Jul 2016 09:32:10 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 Overflow
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Piotr,
really, you're really really not the kind of person I'd describe as
"always complains, does nothing" :) Great having you around! I kind of
like the questions you ask, by the way ? discussing technical details
and approaches to problems.
Also, as you've probably already guessed, I'm always writing my mails
with a bit of thought about putting in a bit of redundant info if I
think that a mailing list thread will probably become popular with
future Google visitors ? on a few occassions it happened that I didn't
notice when I gave the same info twice. It's not optimal, but I hope you
understand.
Then: thanks for actually sharing a recipe! This is something that I
wish would happen more often; I think everyone prefers solutions over
frustrating problems (such as overflows!).
Best regards,
Marcus
On 05.07.2016 19:22, Piotr Krysik via USRP-users wrote:
> Hi all,
>
> If after what I said on the list (or privately ;) ) on some occasions
> about USRP B210 you have a feeling that I'm only complaining about the
> performance of the device, while not trying to help myself, maybe this
> post will convince you that this impression is far from the truth.
>
> I've just tested the optimization mentioned by Marcus (increasing Min
> Output Buffer value in the Advanced tab to some high number - in my case
> 100000000) in the previous post, together with the previous optimization
> (I've set value of Device Arguments to "num_recv_frames=1024") and I got
> 20 minutes of continuous recording (no overflows) with sample rate 25MHz
> (two channels with 16 bit samples). So it is much higher stream of data
> stored to disk (5x) than the minimum mentioned by me previously.
> Actually, this is maximum possible to get from B210 with 2 RX channels
> and 16bit sampling and it WORKS (at least for 20 minutes during which I
> tested it - probably more is possible).
>
> However, I'm not writing this to tell you that it works for me. I want
> to share the solution, so others can use it and improve it. The system I
> used for the recording is following:
> -Dell Latitude E6330, CPU Intel(R) Core(TM) i7-3540M CPU @ 3.00GHz, 16GB
> (2x8GB) RAM,
> -SSD disk used for storing the recording: Samsung SSD 850 EVO 1TB,
> -system: Ubuntu 16.04 with GNU Radio and UHD installed from packages
> provided with distribution.
>
> The gnuradio-companion application that I used is shown on the
> print-screen and the GRC file is also attached.
>
> Best Regards,
> Piotr Krysik
>
> W dniu 04.07.2016 o 23:16, Marcus M?ller via USRP-users pisze:
>> I can also recommend doing two things:
>>
>> 1. Multi-thread your receiver, so that the thread calling recv() isn't
>> blocked for the duration of write()ing things to storage. Also, now
>> you're not inherently pushing one core to a high clock speed. The
>> rx_samples_to_file example is really really really just an example of
>> how to set up a multi_usrp object, get the rx_streamer and call
>> recv(), nothing to use as reference when building high-rate receivers.
>>
>> 2. Using something with a large buffering when writing to storage, as
>> storage rates and latencies are totally unpredictable.
>>
>> In fact, using GNU Radio you can get both at once: Just connect your
>> USRP source to a file sink. GNU Radio blocks run each in their own
>> thread, and the output/input connection is actually a ring buffer; you
>> can increase the size of that in the "advanced" tab of the USRP
>> source, by increasing the minimum output buffer size to something
>> relatively large; I tend to use values 512*2**20 (==512MB) because RAM
>> is cheap :)
>>
>> If you don't want to use GNU Radio, I can dig up a rather naively
>> implemented multi-thread-receiver that I wrote a while ago. It worked
>> pretty well at high rates, and does nothing but allocate a bunch of
>> "samples_per_packet*bytes_per_sample" sized buffers, puts them in a
>> "ready to use" queue, let's a thread running recv() fill them one by
>> one, push them into a "ready to write" queue, from which a storage IO
>> thread takes them and writes their content to a file, then pushes them
>> back to the "ready to use" queue. The design was really bad (buffers
>> aren't inherently allocated contiguously in memory, so we're
>> potentially losing memory bandwidth unnecessarily), but using enough
>> buffers, one can completely hide the fact that storage is highly
>> non-deterministic and that handling storage IO might interfere with
>> the amount of CPU the OS has available for handling USB traffic.
>>
>> Best regards,
>>
>> Marcus
>>
>> On 04.07.2016 22:49, Jeremy Hershberger via USRP-users wrote:
>>> I have had success streaming from a B210 (2 channel RX, 16-bit,
>>> 25MS/s) to a RAM disk. I have also had success writing smaller files
>>> to the RAM disk (maybe a second or two of data) and then moving those
>>> files in a separate background process to an SSD. By pulling data
>>> out of the RAM drive at a rate that is slightly less than data flows
>>> in, I can capture for a longer total duration. The performance would
>>> depend greatly on the speed at which your host can move data from RAM
>>> to disk, but by changing the size of the temporary files in RAM you
>>> should be able to extend your capture duration significantly.
>>>
>>> On Mon, Jul 4, 2016 at 10:33 AM, Piotr Krysik via USRP-users
>>> <[email protected]> wrote:
>>>
>>> W dniu 04.07.2016 o 14:45, Piotr Krysik via USRP-users pisze:
>>> > W dniu 17.06.2016 o 19:28, Marcus D. Leech via USRP-users pisze:
>>> >> On 06/17/2016 01:07 PM, Marcus M?ller via USRP-users wrote:
>>> >>> Hi Xuesong,
>>> >>>
>>> >>> I was just told I misread your email. I'd like to apologize
>>> for that!
>>> >>>
>>> >>>> 3) There will DEFINITELY be overruns (in less than 2
>>> minutes) when
>>> >>>> streaming data to a file even with sampling rate of 5 MHz:
>>> >>>> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
>>> >>>> --wirefmt=sc16 --duration=600
>>> >>> Ooops, you're doing 5MS/s here.
>>> >>> Ok, that's only 20MB/s, and now everything is comparable to
>>> the N210
>>> >>> case.
>>> >>> This is actually not typical; let's do a quick benchmark with dd:
>>> >>>
>>> >>> yes | dd of=/home/marcus/Desktop/test.bin bs=512
>>> count=$((4*600 * 5 * 10**6 / 512)) conv=fsync
>>> >>>
>>> >>> to try and write data in roughly the same granularity as
>>> >>> rx_samples_to_file does by default for a B210 connected using
>>> USB3
>>> >>> with the same amount of data.
>>> >>>
>>> >>> Could you also copy&paste the full output of
>>> rx_samples_to_file? That
>>> >>> could be very helpful.
>>> >>>
>>> >>> I'm still pretty sure the problem is storage here ? my
>>> suspicion is
>>> >>> that the write buffer of your operating system fills up with
>>> the 12GB
>>> >>> of data coming in from the USRP, and then suddenly, the OS has to
>>> >>> start throttling the USRP, because it can't write data to the SSD
>>> >>> fast enough - possibly partly because filesystem access is
>>> everything
>>> >>> but CPU-free.
>>> >>>
>>> >>> Are you planning on using GNU Radio? If you want to do that
>>> anyway,
>>> >>> something like:
>>> >>>
>>> >>> UHD USRP Source ---> File Sink
>>> >>>
>>> >>> would probably work better than the rx_samples_to_file example,
>>> >>> because GNU Radio is inherently multi-threaded. If you're
>>> using the
>>> >>> GNU Radio companion, the USRP Source block has an "advanced
>>> options"
>>> >>> tab, where you can set a larger minimum output buffer; try
>>> something
>>> >>> like 10**7, which will give you a couple Megabytes of buffering
>>> >>> already, which might already compensate for the non-uniform write
>>> >>> speeds of a storage device.
>>> >>>
>>> >>> Best regards,
>>> >>> Marcus
>>> >>>
>>> >>>
>>> >> Also try increasing num_recv_frames in the device argument--up to 128
>>> >> or so.
>>> >>
>>> > Hi Xuesong,
>>> >
>>> > There is a genuine problem with streaming from B210 to a disk.
>>> No amount
>>> > of computer resources, optimizations and trying different streaming
>>> > applications solved the problem for me (rx_sample_to_file is
>>> just an
>>> > example provided with the driver so it might not be the best
>>> application).
>>> >
>>> > For all others who are trying to help - if you can stream from
>>> B210 to a
>>> > disk on your side at the sample rate of at least 10MHz (single
>>> channel,
>>> > 16bit) and save about 10 minutes of such stream to disk without an
>>> > overflow - please share:
>>> > -what is a configuration of a computer on which you achieved that
>>> > (motherboard, processor, memory, disk),
>>> > -what application did you use.
>>> >
>>> > Until someone proves otherwise (at sample rates >=10MSamp/s), it is
>>> > officially not possible to stream from USRP B210 to a disk without
>>> > transmission problems.
>>> >
>>> >
>>> Hi all again,
>>>
>>> One little tip: streaming to a ramdisk works without problems with
>>> overflows. If I need to make a short recording (single minutes as
>>> amount
>>> of RAM is usually quite limited) with USRP B210 I'm using a ramdisc
>>> created with command like this:
>>>
>>> sudo mount -t tmpfs -o size=10000m tmpfs /path/to/ramdisc/directory
>>>
>>> where 10000m is size of the ramdisc in mega-bytes.
>>>
>>> Streaming to a real disc from B210 doesn't work without problems
>>> - until
>>> someone figures out what is the problem/bottleneck.
>>>
>>> Best Regards,
>>> Piotr Krysik
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160706/ca5a8bb5/attachment-0001.html>
------------------------------
Message: 20
Date: Wed, 6 Jul 2016 09:35:17 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 Overflow
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Piotr,
note that Paul mentioned not to trust the metadata sink ? which actually
is quite different from the normal file sink in that it adds
headers/metadata to the file. I can't claim I've actually looked at its
implementation, though ? but I guess that maybe writing the metadata to
a separate file would be more efficient than seeking in an open file (?).
Best regards,
Marcus
On 05.07.2016 22:23, Piotr Krysik via USRP-users wrote:
> Hi Paul,
>
> The gr-analysis looks like a set of great tools to manipulate data
> captured with USRPs.
>
> Regarding efficiency GNU Radio - I've just posted three hours ago a
> gnuradio-companion application that stores 20 minutes of 50MSamp/s
> stream to a SSD disk (longer recordings are also possible, I don't know
> if there is some limit other than size of the disk). This was without
> meta-data. But now I connected unbuffered File Meta Sinks with detached
> meta-data and the result is the same - it works.
>
> Generally I haven't had yet a situation where the problems with storing
> the data to disk was GNU Radio's fault. Maybe imperfect configuration of
> UHD and GNU Radio (this was the problem in this case).
>
> Best Regards,
> Piotr
>
> W dniu 05.07.2016 o 19:05, Garver, Paul W via USRP-users pisze:
>> I can easily record for 10 minutes with the B210 at 25 MSPS on a
>> single Samsung Evo 840 mSSD without dropping samples on an
>> XFS-formatted partition. See last year?s GRCON (GRCON2015) for details:
>>
>>
>> Specifically, you may be interested in the specrec (Linux-only)
>> command-line tool in gr-analysis [2].
>>
>> I might point out that the file meta sink block in gnuradio is fairly
>> inefficient in how it writes metadata to disk as it does a fair bit of
>> seeking. If you need metadata with the files, you will probably get
>> poor performance using file meta sink and GNURadio. In our systems
>> with metadata, uhd_rx_cfile can only do 10 MSPS, whereas specrec can
>> go up to 25 MSPS for an improvement of 15 MSPS.
>>
>> Hope this helps.
>>
>> [1]
>> http://www.trondeau.com/grcon15-presentations#wednesday_Lincoln_Synchronized
>> [2] https://github.com/garverp/gr-analysis
>>> *From: *Jeremy Hershberger <[email protected]
>>> <mailto:[email protected]>>
>>> *Subject: **Re: [USRP-users] USRP B210 Overflow*
>>> *Date: *July 4, 2016 at 4:49:10 PM EDT
>>> *To: *Piotr Krysik <[email protected] <mailto:[email protected]>>
>>> *Cc: *usrp-users <[email protected]
>>> <mailto:[email protected]>>
>>>
>>>
>>> I have had success streaming from a B210 (2 channel RX, 16-bit,
>>> 25MS/s) to a RAM disk. I have also had success writing smaller files
>>> to the RAM disk (maybe a second or two of data) and then moving those
>>> files in a separate background process to an SSD. By pulling data
>>> out of the RAM drive at a rate that is slightly less than data flows
>>> in, I can capture for a longer total duration. The performance would
>>> depend greatly on the speed at which your host can move data from RAM
>>> to disk, but by changing the size of the temporary files in RAM you
>>> should be able to extend your capture duration significantly.
>>>
>>> On Mon, Jul 4, 2016 at 10:33 AM, Piotr Krysik via
>>> USRP-users <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> W dniu 04.07.2016 o 14:45, Piotr Krysik via USRP-users pisze:
>>> > W dniu 17.06.2016 o 19:28, Marcus D. Leech via USRP-users pisze:
>>> >> On 06/17/2016 01:07 PM, Marcus M?ller via USRP-users wrote:
>>> >>> Hi Xuesong,
>>> >>>
>>> >>> I was just told I misread your email. I'd like to apologize
>>> for that!
>>> >>>
>>> >>>> 3) There will DEFINITELY be overruns (in less than 2
>>> minutes) when
>>> >>>> streaming data to a file even with sampling rate of 5 MHz:
>>> >>>> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
>>> >>>> --wirefmt=sc16 --duration=600
>>> >>> Ooops, you're doing 5MS/s here.
>>> >>> Ok, that's only 20MB/s, and now everything is comparable to
>>> the N210
>>> >>> case.
>>> >>> This is actually not typical; let's do a quick benchmark with dd:
>>> >>>
>>> >>> yes | dd of=/home/marcus/Desktop/test.bin bs=512
>>> count=$((4*600 * 5 * 10**6 / 512)) conv=fsync
>>> >>>
>>> >>> to try and write data in roughly the same granularity as
>>> >>> rx_samples_to_file does by default for a B210 connected using
>>> USB3
>>> >>> with the same amount of data.
>>> >>>
>>> >>> Could you also copy&paste the full output of
>>> rx_samples_to_file? That
>>> >>> could be very helpful.
>>> >>>
>>> >>> I'm still pretty sure the problem is storage here ? my
>>> suspicion is
>>> >>> that the write buffer of your operating system fills up with
>>> the 12GB
>>> >>> of data coming in from the USRP, and then suddenly, the OS has to
>>> >>> start throttling the USRP, because it can't write data to the SSD
>>> >>> fast enough - possibly partly because filesystem access is
>>> everything
>>> >>> but CPU-free.
>>> >>>
>>> >>> Are you planning on using GNU Radio? If you want to do that
>>> anyway,
>>> >>> something like:
>>> >>>
>>> >>> UHD USRP Source ---> File Sink
>>> >>>
>>> >>> would probably work better than the rx_samples_to_file example,
>>> >>> because GNU Radio is inherently multi-threaded. If you're
>>> using the
>>> >>> GNU Radio companion, the USRP Source block has an "advanced
>>> options"
>>> >>> tab, where you can set a larger minimum output buffer; try
>>> something
>>> >>> like 10**7, which will give you a couple Megabytes of buffering
>>> >>> already, which might already compensate for the non-uniform write
>>> >>> speeds of a storage device.
>>> >>>
>>> >>> Best regards,
>>> >>> Marcus
>>> >>>
>>> >>>
>>> >> Also try increasing num_recv_frames in the device argument--up to 128
>>> >> or so.
>>> >>
>>> > Hi Xuesong,
>>> >
>>> > There is a genuine problem with streaming from B210 to a disk.
>>> No amount
>>> > of computer resources, optimizations and trying different streaming
>>> > applications solved the problem for me (rx_sample_to_file is
>>> just an
>>> > example provided with the driver so it might not be the best
>>> application).
>>> >
>>> > For all others who are trying to help - if you can stream from
>>> B210 to a
>>> > disk on your side at the sample rate of at least 10MHz (single
>>> channel,
>>> > 16bit) and save about 10 minutes of such stream to disk without an
>>> > overflow - please share:
>>> > -what is a configuration of a computer on which you achieved that
>>> > (motherboard, processor, memory, disk),
>>> > -what application did you use.
>>> >
>>> > Until someone proves otherwise (at sample rates >=10MSamp/s), it is
>>> > officially not possible to stream from USRP B210 to a disk without
>>> > transmission problems.
>>> >
>>> >
>>> Hi all again,
>>>
>>> One little tip: streaming to a ramdisk works without problems with
>>> overflows. If I need to make a short recording (single minutes as
>>> amount
>>> of RAM is usually quite limited) with USRP B210 I'm using a ramdisc
>>> created with command like this:
>>>
>>> sudo mount -t tmpfs -o size=10000m tmpfs /path/to/ramdisc/directory
>>>
>>> where 10000m is size of the ramdisc in mega-bytes.
>>>
>>> Streaming to a real disc from B210 doesn't work without problems
>>> - until
>>> someone figures out what is the problem/bottleneck.
>>>
>>> Best Regards,
>>> Piotr Krysik
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>
>>>
>>>
>>> *From: *Marcus M?ller <[email protected]
>>> <mailto:[email protected]>>
>>> *Subject: **Re: [USRP-users] USRP B210 Overflow*
>>> *Date: *July 4, 2016 at 5:16:47 PM EDT
>>> *To: *<[email protected] <mailto:[email protected]>>
>>>
>>>
>>> I can also recommend doing two things:
>>>
>>> 1. Multi-thread your receiver, so that the thread calling recv()
>>> isn't blocked for the duration of write()ing things to storage. Also,
>>> now you're not inherently pushing one core to a high clock speed. The
>>> rx_samples_to_file example is really really really just an example of
>>> how to set up a multi_usrp object, get the rx_streamer and call
>>> recv(), nothing to use as reference when building high-rate receivers.
>>>
>>> 2. Using something with a large buffering when writing to storage, as
>>> storage rates and latencies are totally unpredictable.
>>>
>>> In fact, using GNU Radio you can get both at once: Just connect your
>>> USRP source to a file sink. GNU Radio blocks run each in their own
>>> thread, and the output/input connection is actually a ring buffer;
>>> you can increase the size of that in the "advanced" tab of the USRP
>>> source, by increasing the minimum output buffer size to something
>>> relatively large; I tend to use values 512*2**20 (==512MB) because
>>> RAM is cheap :)
>>>
>>> If you don't want to use GNU Radio, I can dig up a rather naively
>>> implemented multi-thread-receiver that I wrote a while ago. It worked
>>> pretty well at high rates, and does nothing but allocate a bunch of
>>> "samples_per_packet*bytes_per_sample" sized buffers, puts them in a
>>> "ready to use" queue, let's a thread running recv() fill them one by
>>> one, push them into a "ready to write" queue, from which a storage IO
>>> thread takes them and writes their content to a file, then pushes
>>> them back to the "ready to use" queue. The design was really bad
>>> (buffers aren't inherently allocated contiguously in memory, so we're
>>> potentially losing memory bandwidth unnecessarily), but using enough
>>> buffers, one can completely hide the fact that storage is highly
>>> non-deterministic and that handling storage IO might interfere with
>>> the amount of CPU the OS has available for handling USB traffic.
>>>
>>> Best regards,
>>>
>>> Marcus
>>>
>>> On 04.07.2016 22:49, Jeremy Hershberger via USRP-users wrote:
>>>> I have had success streaming from a B210 (2 channel RX, 16-bit,
>>>> 25MS/s) to a RAM disk. I have also had success writing smaller
>>>> files to the RAM disk (maybe a second or two of data) and then
>>>> moving those files in a separate background process to an SSD. By
>>>> pulling data out of the RAM drive at a rate that is slightly less
>>>> than data flows in, I can capture for a longer total duration. The
>>>> performance would depend greatly on the speed at which your host can
>>>> move data from RAM to disk, but by changing the size of the
>>>> temporary files in RAM you should be able to extend your capture
>>>> duration significantly.
>>>>
>>>> On Mon, Jul 4, 2016 at 10:33 AM, Piotr Krysik via
>>>> USRP-users <[email protected]> wrote:
>>>>
>>>> W dniu 04.07.2016 o 14:45, Piotr Krysik via USRP-users pisze:
>>>> > W dniu 17.06.2016 o 19:28, Marcus D. Leech via USRP-users pisze:
>>>> >> On 06/17/2016 01:07 PM, Marcus M?ller via USRP-users wrote:
>>>> >>> Hi Xuesong,
>>>> >>>
>>>> >>> I was just told I misread your email. I'd like to apologize
>>>> for that!
>>>> >>>
>>>> >>>> 3) There will DEFINITELY be overruns (in less than 2
>>>> minutes) when
>>>> >>>> streaming data to a file even with sampling rate of 5 MHz:
>>>> >>>> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
>>>> >>>> --wirefmt=sc16 --duration=600
>>>> >>> Ooops, you're doing 5MS/s here.
>>>> >>> Ok, that's only 20MB/s, and now everything is comparable to
>>>> the N210
>>>> >>> case.
>>>> >>> This is actually not typical; let's do a quick benchmark
>>>> with dd:
>>>> >>>
>>>> >>> yes | dd of=/home/marcus/Desktop/test.bin bs=512
>>>> count=$((4*600 * 5 * 10**6 / 512)) conv=fsync
>>>> >>>
>>>> >>> to try and write data in roughly the same granularity as
>>>> >>> rx_samples_to_file does by default for a B210 connected
>>>> using USB3
>>>> >>> with the same amount of data.
>>>> >>>
>>>> >>> Could you also copy&paste the full output of
>>>> rx_samples_to_file? That
>>>> >>> could be very helpful.
>>>> >>>
>>>> >>> I'm still pretty sure the problem is storage here ? my
>>>> suspicion is
>>>> >>> that the write buffer of your operating system fills up with
>>>> the 12GB
>>>> >>> of data coming in from the USRP, and then suddenly, the OS
>>>> has to
>>>> >>> start throttling the USRP, because it can't write data to
>>>> the SSD
>>>> >>> fast enough - possibly partly because filesystem access is
>>>> everything
>>>> >>> but CPU-free.
>>>> >>>
>>>> >>> Are you planning on using GNU Radio? If you want to do that
>>>> anyway,
>>>> >>> something like:
>>>> >>>
>>>> >>> UHD USRP Source ---> File Sink
>>>> >>>
>>>> >>> would probably work better than the rx_samples_to_file example,
>>>> >>> because GNU Radio is inherently multi-threaded. If you're
>>>> using the
>>>> >>> GNU Radio companion, the USRP Source block has an "advanced
>>>> options"
>>>> >>> tab, where you can set a larger minimum output buffer; try
>>>> something
>>>> >>> like 10**7, which will give you a couple Megabytes of buffering
>>>> >>> already, which might already compensate for the non-uniform
>>>> write
>>>> >>> speeds of a storage device.
>>>> >>>
>>>> >>> Best regards,
>>>> >>> Marcus
>>>> >>>
>>>> >>>
>>>> >> Also try increasing num_recv_frames in the device argument--up to
>>>> 128
>>>> >> or so.
>>>> >>
>>>> > Hi Xuesong,
>>>> >
>>>> > There is a genuine problem with streaming from B210 to a disk.
>>>> No amount
>>>> > of computer resources, optimizations and trying different
>>>> streaming
>>>> > applications solved the problem for me (rx_sample_to_file is
>>>> just an
>>>> > example provided with the driver so it might not be the best
>>>> application).
>>>> >
>>>> > For all others who are trying to help - if you can stream from
>>>> B210 to a
>>>> > disk on your side at the sample rate of at least 10MHz (single
>>>> channel,
>>>> > 16bit) and save about 10 minutes of such stream to disk without an
>>>> > overflow - please share:
>>>> > -what is a configuration of a computer on which you achieved that
>>>> > (motherboard, processor, memory, disk),
>>>> > -what application did you use.
>>>> >
>>>> > Until someone proves otherwise (at sample rates >=10MSamp/s),
>>>> it is
>>>> > officially not possible to stream from USRP B210 to a disk without
>>>> > transmission problems.
>>>> >
>>>> >
>>>> Hi all again,
>>>>
>>>> One little tip: streaming to a ramdisk works without problems with
>>>> overflows. If I need to make a short recording (single minutes
>>>> as amount
>>>> of RAM is usually quite limited) with USRP B210 I'm using a ramdisc
>>>> created with command like this:
>>>>
>>>> sudo mount -t tmpfs -o size=10000m tmpfs /path/to/ramdisc/directory
>>>>
>>>> where 10000m is size of the ramdisc in mega-bytes.
>>>>
>>>> Streaming to a real disc from B210 doesn't work without problems
>>>> - until
>>>> someone figures out what is the problem/bottleneck.
>>>>
>>>> Best Regards,
>>>> Piotr Krysik
>>>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 21
Date: Wed, 6 Jul 2016 09:50:44 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] new E310 image won't boot on E312
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
I have rev 4 of the E310 image on my machine and I've been using it for
a while with no issues. I got my new E312s in recently and tried my
normal load on my usual SD cards and it doesn't boot, I get:
Loading fpga image from SD to HW...
reading fpga.bin
4045564 bytes read in 225 ms (17.1 MiB/s)
zynq_align_dma_buffer: Bitstream is not swapped(1) - swap it
Copying kernel from SD to RAM...
reading uImage
3416624 bytes read in 194 ms (16.8 MiB/s)
reading uImage-zynq-e31x-3.dtb
** Unable to read file uImage-zynq-e31x-3.dtb **
=>
What am I doing wrong? I've reloaded the SD card numerous times, but I
get the same issues every time. Does this have something to do with the
fact that I am now running this on an E312 instead of my normal E310?
My command for loading the SD card is: sudo bmaptool copy
sdimage-gnuradio-demo.direct.xz /dev/sdb --nobmap
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160706/ab48e49c/attachment-0001.html>
------------------------------
Message: 22
Date: Wed, 06 Jul 2016 10:00:06 -0400
From: [email protected]
To: Jason Matusiak <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] new E310 image won't boot on E312
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
You need the -SG3 images for E312:
http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/
On 2016-07-06 09:50, Jason Matusiak via USRP-users wrote:
> I have rev 4 of the E310 image on my machine and I've been using it for a
> while with no issues. I got my new E312s in recently and tried my normal
> load on my usual SD cards and it doesn't boot, I get:
> Loading fpga image from SD to HW...
> reading fpga.bin
> 4045564 bytes read in 225 ms (17.1 MiB/s)
> zynq_align_dma_buffer: Bitstream is not swapped(1) - swap it
> Copying kernel from SD to RAM...
> reading uImage
> 3416624 bytes read in 194 ms (16.8 MiB/s)
> reading uImage-zynq-e31x-3.dtb
> ** Unable to read file uImage-zynq-e31x-3.dtb **
> =>
>
> What am I doing wrong? I've reloaded the SD card numerous times, but I get
> the same issues every time. Does this have something to do with the fact
> that I am now running this on an E312 instead of my normal E310?
>
> My command for loading the SD card is: sudo bmaptool copy
> sdimage-gnuradio-demo.direct.xz /dev/sdb --nobmap
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160706/8ad8a3bd/attachment-0001.html>
------------------------------
Message: 23
Date: Wed, 6 Jul 2016 10:02:07 -0400
From: Mark Napier <[email protected]>
To: [email protected], [email protected]
Subject: [USRP-users] Macports Patch File
Message-ID:
<cafs2mbfcku0jead_2nhzrcwci7ahx5lsmfsxnpj8zjz0ho3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
With help from Michael I've made up a patch file for the db_tvrx.cpp and
dboard_iface.cpp.
Next step would be to apply the patch, recompile, and install the UHD to
test it using macports.
Google is not finding the recipe.
Anyone know how to do this?
Thank you much,
Mark Napier
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160706/ca25a671/attachment-0001.html>
------------------------------
Message: 24
Date: Wed, 6 Jul 2016 10:30:33 -0400
From: Jason Matusiak <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] new E310 image won't boot on E312
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Bingo! Thanks, I totally forgot that the new E312s had a different
speed grade. Has there been any talk of finding a way of combining the
two images so that SD cards can be swapped more freely?
On 07/06/2016 10:00 AM, [email protected] wrote:
>
> You need the -SG3 images for E312:
>
> http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/
>
> On 2016-07-06 09:50, Jason Matusiak via USRP-users wrote:
>
>> I have rev 4 of the E310 image on my machine and I've been using it
>> for a while with no issues. I got my new E312s in recently and tried
>> my normal load on my usual SD cards and it doesn't boot, I get:
>> Loading fpga image from SD to HW...
>> reading fpga.bin
>> 4045564 bytes read in 225 ms (17.1 MiB/s)
>> zynq_align_dma_buffer: Bitstream is not swapped(1) - swap it
>> Copying kernel from SD to RAM...
>> reading uImage
>> 3416624 bytes read in 194 ms (16.8 MiB/s)
>> reading uImage-zynq-e31x-3.dtb
>> ** Unable to read file uImage-zynq-e31x-3.dtb **
>> =>
>>
>> What am I doing wrong? I've reloaded the SD card numerous times, but
>> I get the same issues every time. Does this have something to do
>> with the fact that I am now running this on an E312 instead of my
>> normal E310?
>>
>> My command for loading the SD card is: sudo bmaptool copy
>> sdimage-gnuradio-demo.direct.xz /dev/sdb --nobmap
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160706/4fe799e5/attachment-0001.html>
------------------------------
Message: 25
Date: Wed, 6 Jul 2016 10:38:35 -0400
From: Philip Balister <[email protected]>
To: Jason Matusiak <[email protected]>, [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] new E310 image won't boot on E312
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 07/06/2016 10:30 AM, Jason Matusiak via USRP-users wrote:
> Bingo! Thanks, I totally forgot that the new E312s had a different
> speed grade. Has there been any talk of finding a way of combining the
> two images so that SD cards can be swapped more freely?
There is talk, but we can't easily tell what speed grade zynq we have
until late in the boot process and the clock setup is earlier. I agree
it is an annoying situation, but there isn't an easy fix.
Philip
>
> On 07/06/2016 10:00 AM, [email protected] wrote:
>>
>> You need the -SG3 images for E312:
>>
>> http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/
>>
>> On 2016-07-06 09:50, Jason Matusiak via USRP-users wrote:
>>
>>> I have rev 4 of the E310 image on my machine and I've been using it
>>> for a while with no issues. I got my new E312s in recently and tried
>>> my normal load on my usual SD cards and it doesn't boot, I get:
>>> Loading fpga image from SD to HW...
>>> reading fpga.bin
>>> 4045564 bytes read in 225 ms (17.1 MiB/s)
>>> zynq_align_dma_buffer: Bitstream is not swapped(1) - swap it
>>> Copying kernel from SD to RAM...
>>> reading uImage
>>> 3416624 bytes read in 194 ms (16.8 MiB/s)
>>> reading uImage-zynq-e31x-3.dtb
>>> ** Unable to read file uImage-zynq-e31x-3.dtb **
>>> =>
>>>
>>> What am I doing wrong? I've reloaded the SD card numerous times, but
>>> I get the same issues every time. Does this have something to do
>>> with the fact that I am now running this on an E312 instead of my
>>> normal E310?
>>>
>>> My command for loading the SD card is: sudo bmaptool copy
>>> sdimage-gnuradio-demo.direct.xz /dev/sdb --nobmap
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 26
Date: Wed, 6 Jul 2016 17:24:05 +0200
From: Piotr Krysik <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 Overflow
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Marcus,
I've made a 20 minutes long test with streaming 50MSamp/s from single
channel (to be more close to what was described in Paul's presentation)
of B210 to a File Meta Sink, set in a mode in which it embeds meta-data
in the output file. The test went without overflows. It looks that
streaming from B210 with meta-data (detached or embedded) is working as
well.
Best Regards,
Piotr
W dniu 06.07.2016 o 09:35, Marcus M?ller via USRP-users pisze:
> Hi Piotr,
>
> note that Paul mentioned not to trust the metadata sink ? which actually
> is quite different from the normal file sink in that it adds
> headers/metadata to the file. I can't claim I've actually looked at its
> implementation, though ? but I guess that maybe writing the metadata to
> a separate file would be more efficient than seeking in an open file (?).
>
> Best regards,
>
> Marcus
>
>
> On 05.07.2016 22:23, Piotr Krysik via USRP-users wrote:
>> Hi Paul,
>>
>> The gr-analysis looks like a set of great tools to manipulate data
>> captured with USRPs.
>>
>> Regarding efficiency GNU Radio - I've just posted three hours ago a
>> gnuradio-companion application that stores 20 minutes of 50MSamp/s
>> stream to a SSD disk (longer recordings are also possible, I don't know
>> if there is some limit other than size of the disk). This was without
>> meta-data. But now I connected unbuffered File Meta Sinks with detached
>> meta-data and the result is the same - it works.
>>
>> Generally I haven't had yet a situation where the problems with storing
>> the data to disk was GNU Radio's fault. Maybe imperfect configuration of
>> UHD and GNU Radio (this was the problem in this case).
>>
>> Best Regards,
>> Piotr
>>
>> W dniu 05.07.2016 o 19:05, Garver, Paul W via USRP-users pisze:
>>> I can easily record for 10 minutes with the B210 at 25 MSPS on a
>>> single Samsung Evo 840 mSSD without dropping samples on an
>>> XFS-formatted partition. See last year?s GRCON (GRCON2015) for details:
>>>
>>>
>>> Specifically, you may be interested in the specrec (Linux-only)
>>> command-line tool in gr-analysis [2].
>>>
>>> I might point out that the file meta sink block in gnuradio is fairly
>>> inefficient in how it writes metadata to disk as it does a fair bit of
>>> seeking. If you need metadata with the files, you will probably get
>>> poor performance using file meta sink and GNURadio. In our systems
>>> with metadata, uhd_rx_cfile can only do 10 MSPS, whereas specrec can
>>> go up to 25 MSPS for an improvement of 15 MSPS.
>>>
>>> Hope this helps.
>>>
>>> [1]
>>> http://www.trondeau.com/grcon15-presentations#wednesday_Lincoln_Synchronized
>>> [2] https://github.com/garverp/gr-analysis
>>>> *From: *Jeremy Hershberger <[email protected]
>>>> <mailto:[email protected]>>
>>>> *Subject: **Re: [USRP-users] USRP B210 Overflow*
>>>> *Date: *July 4, 2016 at 4:49:10 PM EDT
>>>> *To: *Piotr Krysik <[email protected] <mailto:[email protected]>>
>>>> *Cc: *usrp-users <[email protected]
>>>> <mailto:[email protected]>>
>>>>
>>>>
>>>> I have had success streaming from a B210 (2 channel RX, 16-bit,
>>>> 25MS/s) to a RAM disk. I have also had success writing smaller files
>>>> to the RAM disk (maybe a second or two of data) and then moving those
>>>> files in a separate background process to an SSD. By pulling data
>>>> out of the RAM drive at a rate that is slightly less than data flows
>>>> in, I can capture for a longer total duration. The performance would
>>>> depend greatly on the speed at which your host can move data from RAM
>>>> to disk, but by changing the size of the temporary files in RAM you
>>>> should be able to extend your capture duration significantly.
>>>>
>>>> On Mon, Jul 4, 2016 at 10:33 AM, Piotr Krysik via
>>>> USRP-users <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> W dniu 04.07.2016 o 14:45, Piotr Krysik via USRP-users pisze:
>>>> > W dniu 17.06.2016 o 19:28, Marcus D. Leech via USRP-users pisze:
>>>> >> On 06/17/2016 01:07 PM, Marcus M?ller via USRP-users wrote:
>>>> >>> Hi Xuesong,
>>>> >>>
>>>> >>> I was just told I misread your email. I'd like to apologize
>>>> for that!
>>>> >>>
>>>> >>>> 3) There will DEFINITELY be overruns (in less than 2
>>>> minutes) when
>>>> >>>> streaming data to a file even with sampling rate of 5 MHz:
>>>> >>>> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
>>>> >>>> --wirefmt=sc16 --duration=600
>>>> >>> Ooops, you're doing 5MS/s here.
>>>> >>> Ok, that's only 20MB/s, and now everything is comparable to
>>>> the N210
>>>> >>> case.
>>>> >>> This is actually not typical; let's do a quick benchmark with dd:
>>>> >>>
>>>> >>> yes | dd of=/home/marcus/Desktop/test.bin bs=512
>>>> count=$((4*600 * 5 * 10**6 / 512)) conv=fsync
>>>> >>>
>>>> >>> to try and write data in roughly the same granularity as
>>>> >>> rx_samples_to_file does by default for a B210 connected using
>>>> USB3
>>>> >>> with the same amount of data.
>>>> >>>
>>>> >>> Could you also copy&paste the full output of
>>>> rx_samples_to_file? That
>>>> >>> could be very helpful.
>>>> >>>
>>>> >>> I'm still pretty sure the problem is storage here ? my
>>>> suspicion is
>>>> >>> that the write buffer of your operating system fills up with
>>>> the 12GB
>>>> >>> of data coming in from the USRP, and then suddenly, the OS has to
>>>> >>> start throttling the USRP, because it can't write data to the SSD
>>>> >>> fast enough - possibly partly because filesystem access is
>>>> everything
>>>> >>> but CPU-free.
>>>> >>>
>>>> >>> Are you planning on using GNU Radio? If you want to do that
>>>> anyway,
>>>> >>> something like:
>>>> >>>
>>>> >>> UHD USRP Source ---> File Sink
>>>> >>>
>>>> >>> would probably work better than the rx_samples_to_file example,
>>>> >>> because GNU Radio is inherently multi-threaded. If you're
>>>> using the
>>>> >>> GNU Radio companion, the USRP Source block has an "advanced
>>>> options"
>>>> >>> tab, where you can set a larger minimum output buffer; try
>>>> something
>>>> >>> like 10**7, which will give you a couple Megabytes of buffering
>>>> >>> already, which might already compensate for the non-uniform write
>>>> >>> speeds of a storage device.
>>>> >>>
>>>> >>> Best regards,
>>>> >>> Marcus
>>>> >>>
>>>> >>>
>>>> >> Also try increasing num_recv_frames in the device argument--up to
>>>> 128
>>>> >> or so.
>>>> >>
>>>> > Hi Xuesong,
>>>> >
>>>> > There is a genuine problem with streaming from B210 to a disk.
>>>> No amount
>>>> > of computer resources, optimizations and trying different streaming
>>>> > applications solved the problem for me (rx_sample_to_file is
>>>> just an
>>>> > example provided with the driver so it might not be the best
>>>> application).
>>>> >
>>>> > For all others who are trying to help - if you can stream from
>>>> B210 to a
>>>> > disk on your side at the sample rate of at least 10MHz (single
>>>> channel,
>>>> > 16bit) and save about 10 minutes of such stream to disk without an
>>>> > overflow - please share:
>>>> > -what is a configuration of a computer on which you achieved that
>>>> > (motherboard, processor, memory, disk),
>>>> > -what application did you use.
>>>> >
>>>> > Until someone proves otherwise (at sample rates >=10MSamp/s), it is
>>>> > officially not possible to stream from USRP B210 to a disk without
>>>> > transmission problems.
>>>> >
>>>> >
>>>> Hi all again,
>>>>
>>>> One little tip: streaming to a ramdisk works without problems with
>>>> overflows. If I need to make a short recording (single minutes as
>>>> amount
>>>> of RAM is usually quite limited) with USRP B210 I'm using a ramdisc
>>>> created with command like this:
>>>>
>>>> sudo mount -t tmpfs -o size=10000m tmpfs /path/to/ramdisc/directory
>>>>
>>>> where 10000m is size of the ramdisc in mega-bytes.
>>>>
>>>> Streaming to a real disc from B210 doesn't work without problems
>>>> - until
>>>> someone figures out what is the problem/bottleneck.
>>>>
>>>> Best Regards,
>>>> Piotr Krysik
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From: *Marcus M?ller <[email protected]
>>>> <mailto:[email protected]>>
>>>> *Subject: **Re: [USRP-users] USRP B210 Overflow*
>>>> *Date: *July 4, 2016 at 5:16:47 PM EDT
>>>> *To: *<[email protected] <mailto:[email protected]>>
>>>>
>>>>
>>>> I can also recommend doing two things:
>>>>
>>>> 1. Multi-thread your receiver, so that the thread calling recv()
>>>> isn't blocked for the duration of write()ing things to storage. Also,
>>>> now you're not inherently pushing one core to a high clock speed. The
>>>> rx_samples_to_file example is really really really just an example of
>>>> how to set up a multi_usrp object, get the rx_streamer and call
>>>> recv(), nothing to use as reference when building high-rate receivers.
>>>>
>>>> 2. Using something with a large buffering when writing to storage, as
>>>> storage rates and latencies are totally unpredictable.
>>>>
>>>> In fact, using GNU Radio you can get both at once: Just connect your
>>>> USRP source to a file sink. GNU Radio blocks run each in their own
>>>> thread, and the output/input connection is actually a ring buffer;
>>>> you can increase the size of that in the "advanced" tab of the USRP
>>>> source, by increasing the minimum output buffer size to something
>>>> relatively large; I tend to use values 512*2**20 (==512MB) because
>>>> RAM is cheap :)
>>>>
>>>> If you don't want to use GNU Radio, I can dig up a rather naively
>>>> implemented multi-thread-receiver that I wrote a while ago. It worked
>>>> pretty well at high rates, and does nothing but allocate a bunch of
>>>> "samples_per_packet*bytes_per_sample" sized buffers, puts them in a
>>>> "ready to use" queue, let's a thread running recv() fill them one by
>>>> one, push them into a "ready to write" queue, from which a storage IO
>>>> thread takes them and writes their content to a file, then pushes
>>>> them back to the "ready to use" queue. The design was really bad
>>>> (buffers aren't inherently allocated contiguously in memory, so we're
>>>> potentially losing memory bandwidth unnecessarily), but using enough
>>>> buffers, one can completely hide the fact that storage is highly
>>>> non-deterministic and that handling storage IO might interfere with
>>>> the amount of CPU the OS has available for handling USB traffic.
>>>>
>>>> Best regards,
>>>>
>>>> Marcus
>>>>
>>>> On 04.07.2016 22:49, Jeremy Hershberger via USRP-users wrote:
>>>>> I have had success streaming from a B210 (2 channel RX, 16-bit,
>>>>> 25MS/s) to a RAM disk. I have also had success writing smaller
>>>>> files to the RAM disk (maybe a second or two of data) and then
>>>>> moving those files in a separate background process to an SSD. By
>>>>> pulling data out of the RAM drive at a rate that is slightly less
>>>>> than data flows in, I can capture for a longer total duration. The
>>>>> performance would depend greatly on the speed at which your host can
>>>>> move data from RAM to disk, but by changing the size of the
>>>>> temporary files in RAM you should be able to extend your capture
>>>>> duration significantly.
>>>>>
>>>>> On Mon, Jul 4, 2016 at 10:33 AM, Piotr Krysik via
>>>>> USRP-users <[email protected]> wrote:
>>>>>
>>>>> W dniu 04.07.2016 o 14:45, Piotr Krysik via USRP-users pisze:
>>>>> > W dniu 17.06.2016 o 19:28, Marcus D. Leech via USRP-users pisze:
>>>>> >> On 06/17/2016 01:07 PM, Marcus M?ller via USRP-users wrote:
>>>>> >>> Hi Xuesong,
>>>>> >>>
>>>>> >>> I was just told I misread your email. I'd like to apologize
>>>>> for that!
>>>>> >>>
>>>>> >>>> 3) There will DEFINITELY be overruns (in less than 2
>>>>> minutes) when
>>>>> >>>> streaming data to a file even with sampling rate of 5 MHz:
>>>>> >>>> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
>>>>> >>>> --wirefmt=sc16 --duration=600
>>>>> >>> Ooops, you're doing 5MS/s here.
>>>>> >>> Ok, that's only 20MB/s, and now everything is comparable to
>>>>> the N210
>>>>> >>> case.
>>>>> >>> This is actually not typical; let's do a quick benchmark
>>>>> with dd:
>>>>> >>>
>>>>> >>> yes | dd of=/home/marcus/Desktop/test.bin bs=512
>>>>> count=$((4*600 * 5 * 10**6 / 512)) conv=fsync
>>>>> >>>
>>>>> >>> to try and write data in roughly the same granularity as
>>>>> >>> rx_samples_to_file does by default for a B210 connected
>>>>> using USB3
>>>>> >>> with the same amount of data.
>>>>> >>>
>>>>> >>> Could you also copy&paste the full output of
>>>>> rx_samples_to_file? That
>>>>> >>> could be very helpful.
>>>>> >>>
>>>>> >>> I'm still pretty sure the problem is storage here ? my
>>>>> suspicion is
>>>>> >>> that the write buffer of your operating system fills up with
>>>>> the 12GB
>>>>> >>> of data coming in from the USRP, and then suddenly, the OS
>>>>> has to
>>>>> >>> start throttling the USRP, because it can't write data to
>>>>> the SSD
>>>>> >>> fast enough - possibly partly because filesystem access is
>>>>> everything
>>>>> >>> but CPU-free.
>>>>> >>>
>>>>> >>> Are you planning on using GNU Radio? If you want to do that
>>>>> anyway,
>>>>> >>> something like:
>>>>> >>>
>>>>> >>> UHD USRP Source ---> File Sink
>>>>> >>>
>>>>> >>> would probably work better than the rx_samples_to_file example,
>>>>> >>> because GNU Radio is inherently multi-threaded. If you're
>>>>> using the
>>>>> >>> GNU Radio companion, the USRP Source block has an "advanced
>>>>> options"
>>>>> >>> tab, where you can set a larger minimum output buffer; try
>>>>> something
>>>>> >>> like 10**7, which will give you a couple Megabytes of buffering
>>>>> >>> already, which might already compensate for the non-uniform
>>>>> write
>>>>> >>> speeds of a storage device.
>>>>> >>>
>>>>> >>> Best regards,
>>>>> >>> Marcus
>>>>> >>>
>>>>> >>>
>>>>> >> Also try increasing num_recv_frames in the device argument--up to
>>>>> 128
>>>>> >> or so.
>>>>> >>
>>>>> > Hi Xuesong,
>>>>> >
>>>>> > There is a genuine problem with streaming from B210 to a disk.
>>>>> No amount
>>>>> > of computer resources, optimizations and trying different
>>>>> streaming
>>>>> > applications solved the problem for me (rx_sample_to_file is
>>>>> just an
>>>>> > example provided with the driver so it might not be the best
>>>>> application).
>>>>> >
>>>>> > For all others who are trying to help - if you can stream from
>>>>> B210 to a
>>>>> > disk on your side at the sample rate of at least 10MHz (single
>>>>> channel,
>>>>> > 16bit) and save about 10 minutes of such stream to disk without an
>>>>> > overflow - please share:
>>>>> > -what is a configuration of a computer on which you achieved that
>>>>> > (motherboard, processor, memory, disk),
>>>>> > -what application did you use.
>>>>> >
>>>>> > Until someone proves otherwise (at sample rates >=10MSamp/s),
>>>>> it is
>>>>> > officially not possible to stream from USRP B210 to a disk without
>>>>> > transmission problems.
>>>>> >
>>>>> >
>>>>> Hi all again,
>>>>>
>>>>> One little tip: streaming to a ramdisk works without problems with
>>>>> overflows. If I need to make a short recording (single minutes
>>>>> as amount
>>>>> of RAM is usually quite limited) with USRP B210 I'm using a ramdisc
>>>>> created with command like this:
>>>>>
>>>>> sudo mount -t tmpfs -o size=10000m tmpfs /path/to/ramdisc/directory
>>>>>
>>>>> where 10000m is size of the ramdisc in mega-bytes.
>>>>>
>>>>> Streaming to a real disc from B210 doesn't work without problems
>>>>> - until
>>>>> someone figures out what is the problem/bottleneck.
>>>>>
>>>>> Best Regards,
>>>>> Piotr Krysik
>>>>>
>>
------------------------------
Message: 27
Date: Wed, 06 Jul 2016 11:58:30 -0400
From: Michael Dickens <[email protected]>
To: Mark Napier <[email protected]>, [email protected],
[email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] Macports Patch File
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I'm replying right now off list to Mark's query. What he's asking is not
of interest to most users; mostly for advanced developers. - MLD
On Wed, Jul 6, 2016, at 10:02 AM, Mark Napier wrote:
> Hello,
>
> With help from Michael I've made up a patch file for the db_tvrx.cpp
> and dboard_iface.cpp.
>
> Next step would be to apply the patch, recompile, and install the UHD
> to test it using macports.
>
> Google is not finding the recipe.
>
> Anyone know how to do this?
>
> Thank you much,
>
> Mark Napier
>
> _________________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160706/9acc79d3/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 71, Issue 5
*****************************************
