[Top][All Lists]
[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