I have attached a patch to allow users to define the ethernet packet
ring size. I remove the SLAB_SIZE restriction. I think gnuradio needs
a fairly new >2.6.5 kernel anyway.
Why is this needed? I challenge anyone to sample at 25 MHz
continuously for two hours without overruns or missing packets to a
five disk raid array (be it ext2 or anything else) with the default 25
MB buffer.
Still, the patch maintains the original 25e6 buffer size. A value of
250e6 to 500e6 allows fairly reliable sampling to disk at 25 MHz, so I
recommend increasing the default buffer size to something higher than
25 MB. Otherwise new users will have problems with overruns. Even
Firefox consumes hundreds of megabytes.
juha
---------- Forwarded message ----------
From: Juha V. [email protected]
Date: Thu, Apr 23, 2009 at 11:00
Subject: Re: [Discuss-gnuradio] USRP2 eth_buffer
To: Bruce Stansby [email protected]
Cc: Eric B. [email protected], Johnathan C.
[email protected], “[email protected]”
[email protected]
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:
j@liang:/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:
j@liang:/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