discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] USRP2 eth_buffer


From: Juha Vierinen
Subject: Re: [Discuss-gnuradio] USRP2 eth_buffer
Date: Thu, 23 Apr 2009 08:00:45 +0000

> ext file system is the go, with my high speed digitizer I stream 250
> MB/s (thats bytes) to a six disk raid (0) array. The raid zero is the go
> if you can afford to loose data in the unlikely event of a disk failure.

I'd guess that your high-speed digitizer has a buffer that is larger
than 25 MB too. Do you know what the buffer size is for your sampler?

I did a simple benchmark of filesystem bandwidth with xfs and ext2.

xfs:
address@hidden:/data0$ sudo time dd if=/dev/zero of=tmp.bin bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 68.1847 s, 154 MB/s

ext2:
address@hidden:/data0$ sudo time dd if=/dev/zero of=tmp.bin bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 68.1712 s, 154 MB/s

Both give approximately the same bandwidth. I totally agree that ext2
might have less variability in i/o bandwidth, but at the same time, I
don't really think there is that large difference between any decent
modern filesystem in terms of long time average bandwidth of writing
large files to disk. Large distributed filesystems are a different
issue, and I'd guess that XFS and IBM's GPFS are good for those uses.

I now took the time to reformat the disk to ext2 and tried to write 25
MHz to disk with the vanilla eth_buffer. It also gave an underrun
after a few seconds. This might be because I am chopping the data into
100 MB files, but this is a necessity. I cannot have 24 hours of 25
MHz data in one large file.

I have suggested a modification to the usrp2 API that would allow
increasing the packet_ring buffer, why is that not a good idea? Isn't
it a good idea to add a feature that allows people to reliably sample
and store to disk at high bandwidth, even with more jittery
filesystems? I think nobody is using a pre 2.6.5 kernel, so this there
shouldn't really be any reason to restrict the size to the number of
pointers that fit into a kernel slab size.

I'll write a patch anyway and send it to the list.

BR,
juha




reply via email to

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