discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] File sink causes "S" errors


From: Thomas Hobiger
Subject: Re: [Discuss-gnuradio] File sink causes "S" errors
Date: Wed, 06 Oct 2010 13:17:23 +0900
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Lightning/1.0b2pre Mnenhy/0.8.3 Thunderbird/3.0.7

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
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS


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.

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.
  

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 Hobiger


--
******************************************************************
Dr. Thomas Hobiger
Space-Time Measurement Project
Space-Time Standards Group
New Generation Network Research Center
National Institute of Information and Communications Technology
------------------------------------------------------------------
4-2-1 Nukui-Kitamachi, Koganei
184-8795 Tokyo
Japan
------------------------------------------------------------------
email:  address@hidden
phone:  ++81-042-327-7561
fax:    ++81-042-327-6664
------------------------------------------------------------------
homepage (priv.): http://www.hobiger.org
****************************************************************** 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]