Hello:
What is the roadmap for GNU Radio releases over the next 12 to 18
months?? What new features are planned?? Will the next release be a
minor release (3.3.1), or major release (3.4.0)?? When is the next
release planned for?? Any insight is much appreciated. Thanks.
–Sunil
Hi everybody,
I am running a USRP2 with a DBSRX and talking to the hardware via raw
ethernet. Running GRC goes well (e.g. doing a real-time FFT spectrum),
but when I start recording on disc I get many “S” messages (“2
successive packets which do not have 2 successive sequence numbers”)
after about 10 seconds. I am currently sampling with a decimation of 4,
but the problem remains with other decimation factors as wekk, just the
messages show up slightly delayed. I think the HD itself is not the
reason as I am recording to a 80 GB SSD, which has EXT4 and is mounted
in a quite fast mode (I have benchmarked the I/O giving me much more
bandwidth than what streams in from the USRP2).
I have started to modify parts of the GNURADIO code, but changing buffer
sizes does not help much.
Is there anybody who experienced similar troubles?
Regards,
Thomas H.
–
4-2-1 Nukui-Kitamachi, Koganei
184-8795 Tokyo
Japan
Can you benchmark your hard disk for sustained rate?
I don’t think that most disks, even SSD,s can sustain a write rate of
25Msps @ 4 bytes a sample (if you are capturing shorts) = 100MB/s
-Josh
On Tue, Oct 5, 2010 at 10:10 PM, Josh B. [email protected] wrote:
I have started to modify parts of the GNURADIO code, but changing buffer
sizes does not help much.Is there anybody who experienced similar troubles?
Regards,
Thomas H.
Josh is probably right about this: sustained throughput at that rate
to anything, even an SSD, is unlikely.
Anecdotally, I found that JFS provided me with higher throughput, but
only by a few % points, which I don’t think is going to do it for you.
Tom
Raid 0 with sata3 drives or 15k scsi drives maybe?
Or if your rich…
http://www.newegg.com/Product/Product.aspx?Item=N82E16820227499&Tpk=OCZSSDPCIE
Sent from my iPad
On 10/05/2010 09:35 PM, Thomas H. wrote:
mounted in a quite fast mode (I have benchmarked the I/O giving me
much more bandwidth than what streams in from the USRP2).
I have started to modify parts of the GNURADIO code, but changing
buffer sizes does not help much.Is there anybody who experienced similar troubles?
Regards,
Thomas H.
You might try converting your samples to a more-compact format prior to
recording them.
If you’re trying to record complex-float at 25Msps, you’ll run out of
disk-io throughput pretty
quickly.
If the dynamic range of your data can be represented in bytes, for
example, then you only
need to sustain sps x 2 bytes per second for complex signals. If you
can get away with
real-only signals, then you’re looking at sps x 1 bytes per second of
required write performance.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Dear all,
Thanks for all the comments and suggestions.
Can you benchmark your hard disk for sustained rate?
Here are the results from a simple DD test
|
dd if=/dev/zero of=/SSD/test.bin bs=1K count=1000000
1000000+0 records in
1000000+0 records out
1024000000 bytes (1.0 GB) copied, 11.5431 s, 88.7 MB/s
dd if=/dev/zero of=/SSD/test.bin bs=10K count=100000
100000+0 records in
100000+0 records out
1024000000 bytes (1.0 GB) copied, 9.8813 s, 104 MB/s
dd if=/dev/zero of=/SSD/test.bin bs=100K count=10000
10000+0 records in
10000+0 records out
1024000000 bytes (1.0 GB) copied, 9.87555 s, 104 MB/s
dd if=/dev/zero of=/SSD/test.bin bs=1000K count=1000
1000+0 records in
1000+0 records out
1024000000 bytes (1.0 GB) copied, 9.76347 s, 105 MB/s|
This makes me think, that in whatever packet size the data streams in,
as long as I do a decimation of 8 and record complex shorts (100 / 8 * 4
= 50 MB/s ) I should be able to do it without lagging behind?
Here are the expected “S” showing up for a decimation of 4 (no surprise)
|
./rx_streaming_samples -f 1.575G -d 4 -N 1000000000 -s -o
/SSD/test.bin
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS|
When doing a few samples with decimation of 8 nothing happens.
|
./rx_streaming_samples -f 1.575G -d 8 -N 1000000000 -s -o
/SSD/test.bin
./rx_streaming_samples -f 1.575G -d 8 -N 2000000000 -s -o
/SSD/test.bin|
But when taking more data
|> ./rx_streaming_samples -f 1.575G -d 8 -N 4000000000 -s -o /SSD/test.bin
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
|
Why does this happen?
Raid 0 with sata3 drives or 15k scsi drives maybe?
Or if your rich…
http://www.newegg.com/Product/Product.aspx?Item=N82E16820227499&Tpk=OCZSSDPCIE
Both options sound interesting. Nevertheless, the latter one makes the
idea of GNURADIO obsolete, as for adding a few more dollars I could get
a commercial sampler.
can get away with
real-only signals, then you’re looking at sps x 1 bytes per second of
required write performance.
I was thinking also of this idea. The sampler which we used before
provided us only 8 bit (real) so we were interested in the URSP2 as it
extended our options. But as long as there is no way to bring the data
to disc, it remains just an idea…
BTW, is there a ring/circular buffer in GNU radio which I can use before
writing the data to disc?
Best regards,
Thomas H.
–
4-2-1 Nukui-Kitamachi, Koganei
184-8795 Tokyo
Japan
On Wed, 2010-10-06 at 13:17 +0900, Thomas H. wrote:
1000000+0 records in
10000+0 records out
1024000000 bytes (1.0 GB) copied, 9.87555 s, 104 MB/sdd if=/dev/zero of=/SSD/test.bin bs=1000K count=1000
1000+0 records in
1000+0 records out
1024000000 bytes (1.0 GB) copied, 9.76347 s, 105 MB/s
Try /dev/random instead of /dev/zero. SSDs are known to use data
compression algorithms to run-length-encode drive data on the fly, to
increase bandwidth and reduce data replication on the drive. It’s
possible that your drive is performing write optimization on your test
which is not applicable to the real world.
–n
How is the sustained rate when you simultaneously run
rx_streaming_samples (without dump) and dd?
|> ./rx_streaming_samples -f 1.575G -d 8 -N 4000000000 -s -o /SSD/test.bin
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS|
Why does this happen?
File IO back-pressures the usrp2 driver, which back-pressures the socket
recv, and when that happens, eventually, the kernel will overwrite
datagrams, packets are lost, the S means sequence error.
Raid 0 with sata3 drives or 15k scsi drives maybe?
Or if your rich…
http://www.newegg.com/Product/Product.aspx?Item=N82E16820227499&Tpk=OCZSSDPCIEBoth options sound interesting. Nevertheless, the latter one makes the
idea of GNURADIO obsolete, as for adding a few more dollars I could get
a commercial sampler.
BTW, rx_streaming_samples does not use the gnuradio framework, it reads
directly from the usrp2 driver and writes to disk.
-Josh
Nick F. writes:
which is not applicable to the real world.
If you want a speed benchmark you probably want /dev/urandom instad
of /dev/random, because /dev/random will block when it runs out
of high-quality random numbers.
–
Seth David S. [email protected] | Qué empresa fácil no pensar en
http://www.loyalty.org/~schoen/ | un tigre,
reflexioné. http://vitanuova.loyalty.org/ | – Borges, El Zahir
Oops… typo
If I read directly from /dev/urandom the whole performance goes down
as random numbers can be generated fast enough…
If I read directly from /dev/urandom the whole performance goes down as
random numbers can’t be generated fast enough…
Hi,
I’ve used /dev/urandom output from a file
|> dd if=/dev/urandom of=random.bin bs=1K count=10000000
dd if=random.bin of=/SSD/test.bin bs=1K count=1000000
1000000+0 records in
1000000+0 records out
1024000000 bytes (1.0 GB) copied, 11.1116 s, 92.2 MB/s
dd if=random.bin of=/SSD/test.bin bs=10K count=100000
100000+0 records in
100000+0 records out
1024000000 bytes (1.0 GB) copied, 9.74512 s, 105 MB/s
dd if=random.bin of=/SSD/test.bin bs=100K count=10000
10000+0 records in
10000+0 records out
1024000000 bytes (1.0 GB) copied, 9.38715 s, 109 MB/s
dd if=random.bin of=/SSD/test.bin bs=1000K count=1000
1000+0 records in
1000+0 records out
1024000000 bytes (1.0 GB) copied, 9.38381 s, 109 MB/s
dd if=random.bin of=/SSD/test.bin bs=10000K count=100
100+0 records in
100+0 records out
1024000000 bytes (1.0 GB) copied, 9.29913 s, 110 MB/s
|
If I read directly from /dev/urandom the whole performance goes down as
random numbers can be generated fast enough…
Thanks,
Thomas
–
4-2-1 Nukui-Kitamachi, Koganei
184-8795 Tokyo
Japan
I ended up writing my own command line tool to get around this.
Depending on your particular needs, it might work for you. Instead of
filling a buffer and writing it to disk over and over, I allocate a
buffer as large as I need, fill it, stop sampling, and write it to disk.
There is no point where it’s depends on disk speed unless the buffer
won’t fit in RAM.
You’ll find the source at https://public.me.com/mepard. There’s a UHD
version, too. Feel free to use them as you wish.
-Marc
Hi Marc,
Thanks for the code. I will give it a try tomorrow (I am out of the
office already). I intend to sample continously for 10-15 minutes to
disk, so your solution might not work directly for me, but if you agree
I’d like to modify your code. If it works as expected, I can post it
somewhere (giving full credit to your prior work).
Regards,
Thomas
----- Original Message -----
I ended up writing my own command line tool to get around this.
Depending on your particular needs, it might work for you. Instead of
filling a buffer and writing it to disk over and over, I allocate a
buffer as large as I need, fill it, stop sampling, and write it to disk.
There is no point where it’s depends on disk speed unless the buffer won
't fit in RAM.You’ll find the source at https://public.me.com/mepard. There’s a UHD
version, too. Feel free to use them as you wish.
Hi Josh,
How is the sustained rate when you simultaneously run
rx_streaming_samples (without dump) and dd?
Acutally, the result I got is more than unexpected. :o)
Running dd in one terminal and rx_streaming_samples in a second terminal
gives me this:
Terminal 1:
|> dd if=/dev/zero of=/SSD/test2.bin bs=10000K count=100
100+0 records in
100+0 records out
1024000000 bytes (1.0 GB) copied, 19.7982 s, 51.7 MB/s
dd if=/dev/zero of=/SSD/test2.bin bs=10000K count=100
100+0 records in
100+0 records out
1024000000 bytes (1.0 GB) copied, 14.2399 s, 71.9 MB/s
dd if=/dev/zero of=/SSD/test2.bin bs=10000K count=100
100+0 records in
100+0 records out
1024000000 bytes (1.0 GB) copied, 10.7249 s, 95.5 MB/s|
Terminal 2:
|./rx_streaming_samples -f 1.575G -d 4 -N 1000000000 -s -o /SSD/test.bin
S|
A single “S” occurrence (!!!) although I used decimation of 4!!! How can
you explain this?
Regards,
Thomas
–
4-2-1 Nukui-Kitamachi, Koganei
184-8795 Tokyo
Japan
On Tue, Oct 5, 2010 at 7:36 PM, Pandeya, Neel L. [email protected]
wrote:
–Sunil
Sunil,
Thanks for asking. That’s a fair question, and I haven’t been ignoring
it. The problem is, we don’t have a really well-defined roadmap right
now, but it’s something we are working on. By “we,” I’m mostly talking
about Johnathan C. and myself. If I tried to tell you everything
we are thinking about for the future, it would be a) a really long
list and b) pretty incoherent. We have a few big ideas coming down the
line, but it’s going to take some time still, and we need a bit more
time to define when we can properly role them out and in what
releases.
I will give you some insight into the next couple of things we want to
do in the immediate future.
Rework the USRP-based examples to use UHD and get rid of
duplication (usrp_thing.py and usrp2_thing.py)
Refactor the build system. This is pretty major from the developers
side but hopefully fairly transparent to the user (if we do it right,
of course). This will make more top-level blocks that will be mostly
split out of gnuradio-core. The main purpose of this is to make
libgnuradio-core hold just what you need to get the runtime engine
working. We will then have a separate library for all of the signal
processing blocks. We also want to move all of the digital modulation
stuff (including OFDM) into its own top-level block space.
This work is to help with a few issues. First, ease up the
requirements for getting the runtime engine installed, and second,
make it easier to understand how things interact. Exposing the second
bit of information will, hopefully, allow people more easily work with
the existing blocks as well as add their own.
A third consequence of this move is that I want to improve the code
maintenance by making unit testing procedures that exercise more of
the code and make sure we don’t let bit rot bite us. With the new
structure, we expect to improve on the testing procedures and help
make it obvious how to add your test code.
There are a few other ideas coming out soon that I want to announce
before December. My timeline here is due to a tutorial on GNU Radio
that I am giving at the WinnForum’s SDR Technical Conference.
So more soon, but I hope that helps give you some clues as to where we
are headed.
Tom
On Tue, Oct 5, 2010 at 9:17 PM, Thomas H. [email protected]
wrote:
SSSSSSSSSS…
The default receive buffer in the Linux kernel is relatively small, I
think just over 100k. It may not help, but would be worth a shot to
increase the buffer size to smooth out the data flow. Use “sysctl
net.core.rmem_max” and “sysctl net.core.rmem_default” to see the max
and default you have now, and “sysctl -w net.core.rmem_max=4194304”
(or whatever) to set them. The default is what all new sockets are
allocated, and you can use setsockopt to set the SO_RCVBUF option on
the socket to change it after that (up to the max of course). I’m not
sure if the usrp2 driver is currently trying to increase that buffer
size or not, but if your max is low it won’t help much.
Jared
It’s probably more Ettus than GNU Radio, but I’m interested in the
direction of the UHD wire protocol, particularly ethernet host side flow
control, which gets mentioned now and then on this list.
-Marc
Tom,
You have been doing some good work in using more efficient filters; have
you integrated your code into GNU Radio code base yet? If there is a
working version, could you please tell me where I can find it? Is it in
the development version or in GNU Radio 3.3 release version.
More importantly, which function modules are using the new filters?
Thanks,
Andrew
Tom,
Can you make the materials of the tutorial available?
Cheers,
Rafael D.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs