Intel Atom Processor

GNU Radio
1

Hello,

We are thinking of using a 1.6GHz Intel Atom processor based PC with
multiple gigabit Ethernet ports
to collect data from multiple USPR2s and save that data off to disk. We
are hoping to be able to
use decimation rates as low as 4 for captures of shorts (16bit I and 16
bit Q). We will be doing
nothing else on this PC, just capturing data. So it will host ubuntu
and gnuradio. Does anyone have
any idea if there is a throughput limit that we might be up against, say
for 2 USRP2s, say 4 USRP2s.
Has anyone successfully run gnuradio on an Atom?

Thanks,
Sharif

2

On 10/08/2010 02:46 PM, Sharif S. wrote:

any idea if there is a throughput limit that we might be up against,

I run Gnu Radio on an Atom D510 system for narrow-bandwidth radiometry.

No way in heck are you going to be able to run at 25Msps for even a
single USRP2, let alone multiple ones.
I tried a 25Msps usrp2_fft.py on my atom D510 system (which is
dual-core at 1.6GHz), and it couldn’t keep
up.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

3

On Fri, Oct 8, 2010 at 2:54 PM, Marcus D. Leech [email protected]
wrote:

and gnuradio. Does anyone have
Discuss-gnuradio Info Page

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

I’m just going to parrot Marcus here. Nope, you are not going to be
able to handle that wide a bandwidth with an Atom.

I think the most I ever did was take in about 6 FM channels,
channelize them, and FM demod each, and save each to a file. That’s
1.2 MHz of bandwidth there with some processing. My guess, you’re
looking at 1.5 MHz of bandwidth with an upper limit on 2 MHz (and
that’s if the gods favor you).

You might try to find a dual-core Atom, which still won’t give you
what you want, but it will be better.

Tom

4

Running an FFT is a CPU intensive application, and not a bandwidth/IO
restricted application. The comparison made here is likely not an
accurate representation of throughput if only data stream to disk is the
goal.

~Jeff

I run Gnu Radio on an Atom D510 system for narrow-bandwidth radiometry.

No way in heck are you going to be able to run at 25Msps for even a
single USRP2, let alone multiple ones.
I tried a 25Msps usrp2_fft.py on my atom D510 system (which is
dual-core at 1.6GHz), and it couldn’t keep
up.

–
~Jeffrey L., K1VZX

5

Thank you for the heads up.

6

On Fri, Oct 8, 2010 at 3:25 PM, Jeffrey L. [email protected] wrote:

Running an FFT is a CPU intensive application, and not a bandwidth/IO
restricted application. The comparison made here is likely not an accurate
representation of throughput if only data stream to disk is the goal.

~Jeff

FFT’s are actually pretty cheap to calculate (profile it; they usually
aren’t a huge consumer of resources unless you’re running very large
FFTs).

Tom

7

In both instances you guys were doing more than what we hoped to do, we
are not going to demod nor run an FFT, just store the data to
disk…given that
do you still see a problem with 2 USRP2s, 4 USRP2s, 6 USRP2s using a 1.6
GHz atom?

8

On 10/08/2010 03:25 PM, Jeffrey L. wrote:

Running an FFT is a CPU intensive application, and not a bandwidth/IO
restricted application. The comparison made here is likely not an
accurate representation of throughput if only data stream to disk is
the goal.

~Jeff

This is perfectly true. It might work at full-bore for a single USRP2
with SSDs, but certainly
not for more than one.

Perhaps I shall run a quick benchmark tonight on my D-510 system, which
has an SSD, and
see what bandwidth it can sustain to disk before losing badly. My gut
tells me that it won’t
be impressive.

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

9

Hi Marcus,

That would be great, and greatly appreciated, we are just not sure
is if there is a fighting chance or not…thus the question to the
forum.

Thanks so much,
Sharif

10

On Fri, Oct 8, 2010 at 3:46 PM, Sharif S. [email protected]
wrote:

In both instances you guys were doing more than what we hoped to do, we
are not going to demod nor run an FFT, just store the data to disk…given
that
do you still see a problem with 2 USRP2s, 4 USRP2s, 6 USRP2s using a 1.6 GHz
atom?

This is why I gave you a bit of an upper bound beyond what I was
doing. I was doing a bit more calculation and only getting 1.2 MHz. No
way are you going to be able to do much more than that even just
writing to disk.

Also, see the other ongoing thread discussing limitations of writing
to disk. Even if you could stream in from multiple USRP2s with a
decimation of 4, you still have the problem of writing all of that
data.

Tom

11

No, not really, its an indefinite data collection.

12

On Oct 8, 2010, at 1:46 PM, Sharif S. wrote:

We are thinking of using a 1.6GHz Intel Atom processor based PC with multiple gigabit Ethernet ports
to collect data from multiple USPR2s and save that data off to disk. We are hoping to be able to
use decimation rates as low as 4 for captures of shorts (16bit I and 16 bit Q). We will be doing
nothing else on this PC, just capturing data. So it will host ubuntu and gnuradio. Does anyone have
any idea if there is a throughput limit that we might be up against, say for 2 USRP2s, say 4 USRP2s.

I’d guess you’ll first run into disk throughput issues. If you solve
those, there still might not be enough overall system (CPU, chipset,
memory, I/O) throughput. I don’t have any intuition for what the limits
might be. How long is your sampling run? Will all the data fit in RAM?

-Marc

13

On 10/08/2010 04:44 PM, Sharif S. wrote:

Hi Marcus,

That would be great, and greatly appreciated, we are just not sure
is if there is a fighting chance or not…thus the question to the forum.

Thanks so much,
Sharif
On my dual-core Atom D-510 at 1.67GHz, with 4GB of memory, and an Intel
80GB SSD, I can run at 12.5Msps without a problem.
Once I step it up to 16.67Msps, it starts getting long sequences of
overruns “O”.

This is with the UHD “Single USRP” source, using complex-short output,
into a “file sink” with a short input, vector-length 2. From
a USRP2.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

14

Hi Marcus,

Thank you so much for doing this and for informing all of us of your
results.
Helpful to us, and probably to others.

15

This may also be helpful.

-Zotac ION Dual Core 1.6GHz Atom N330 Mini-ITX Board
-2x USRP2 Rev 3, 10MHz bandwidth each
-Netgear GigE Switch, the MB has only one port
-Seagate 1TB baracuda (5900 rpm I think)
-ext2 filesystem, Ubuntu 9.04

Using VRT branch code to just dump raw 16bit I&Q I was able to dump 15
minute
cuts without problems (i didn’t test for longer).
I found though once the disk got to 30% capacity, dropouts occur,
probably due
to the write speed slowing down as the head nears the centre of the
disk.
Splitting the data from each USRP2 to seperate disks solved this
problem.
I was also able to test a few different boards, and concluded that the
disk
chipset/driver was a notable bottleneck between boards. eg, a Dell i7
based PC
could not achieve this! I also used “bonnie++” to test disk throughput,
the
results of which tallied with the streaming results.

From what I remember, if the bonnie++ write result was around 100MB/s,
then you
could sustain the 80MB/s (Going by disk test results on the web, this
seemed in
line with most max rates for sata drives).
Also, I believe I also got 12.5MHz BW per channel (I’ll check if I get a
chance), but then, this is two channels, not one full 25MHz capture.

Dave.

----- Original Message ----
From: Sharif S. [email protected]
To: Marcus D. Leech [email protected]
Cc: [email protected]
Sent: Sat, 9 October, 2010 2:47:53
Subject: Re: [Discuss-gnuradio] Intel Atom Processor

Hi Marcus,

Thank you so much for doing this and for informing all of us of your
results.
Helpful to us, and probably to others.

On 10/8/2010 6:21 PM, Marcus D. Leech wrote:

Once I step it up to 16.67Msps, it starts getting long sequences of
overruns “O”.

This is with the UHD “Single USRP” source, using complex-short output,
into a “file sink” with a short input, vector-length 2. From
a USRP2.

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

16

Hi David,

Thank you so much, very helpful.

17

On Oct 8, 2010, at 6:21 PM, “Marcus D. Leech” [email protected] wrote:

Once I step it up to 16.67Msps, it starts getting long sequences of
overruns “O”.

I’m impressed. Much better than I would have expected.

This is with the UHD “Single USRP” source, using complex-short output,
into a “file sink” with a short input, vector-length 2. From
a USRP2.

Ah, that makes a difference. I was running with the the non-UHD with
complex floats. It’s non-vectorized, so the Endian and short-to-float
conversion were costing quite a bit.

Tom