Re: [Discuss-gnuradio] Intel Atom Processor

2010-10-11 Thread Sharif Shaher
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 Shaher To: Marcus D. Leech Cc: discuss-gnuradio@gnu.org Sent: Sat, 9 October, 2010 2:47:53 Subject: Re: [Disc

Re: [Discuss-gnuradio] Intel Atom Processor

2010-10-09 Thread David Evans
), but then, this is two channels, not one full 25MHz capture. Dave. - Original Message From: Sharif Shaher To: Marcus D. Leech Cc: discuss-gnuradio@gnu.org Sent: Sat, 9 October, 2010 2:47:53 Subject: Re: [Discuss-gnuradio] Intel Atom Processor Hi Marcus, Thank you so much for doing th

Re: [Discuss-gnuradio] Intel Atom Processor

2010-10-08 Thread Sharif Shaher
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: On 10/08/2010 04:44 PM, Sharif Shaher wrote: Hi Marcus, That would be great, and greatly appreciated, we are just n

Re: [Discuss-gnuradio] Intel Atom Processor

2010-10-08 Thread Tom Rondeau
On Oct 8, 2010, at 6:21 PM, "Marcus D. Leech" wrote: > On 10/08/2010 04:44 PM, Sharif Shaher 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, >> Shari

Re: [Discuss-gnuradio] Intel Atom Processor

2010-10-08 Thread Marcus D. Leech
On 10/08/2010 04:44 PM, Sharif Shaher 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 a

Re: [Discuss-gnuradio] Intel Atom Processor

2010-10-08 Thread Sharif Shaher
No, not really, its an indefinite data collection. On 10/8/2010 4:40 PM, Marc Epard wrote: On Oct 8, 2010, at 1:46 PM, Sharif Shaher 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

Re: [Discuss-gnuradio] Intel Atom Processor

2010-10-08 Thread Tom Rondeau
On Fri, Oct 8, 2010 at 3:46 PM, Sharif Shaher 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 diskgiven > that > do you still see a problem with 2 USRP2s, 4 USRP2s, 6 USRP2s using a 1.6 GHz > atom

Re: [Discuss-gnuradio] Intel Atom Processor

2010-10-08 Thread Sharif Shaher
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 10/8/2010 4:35 PM, Marcus D. Leech wrote: On 10/08/2010 03:25 PM, Jeffrey Lambert wrote: Running an FFT is a CPU i

Re: [Discuss-gnuradio] Intel Atom Processor

2010-10-08 Thread Marc Epard
On Oct 8, 2010, at 1:46 PM, Sharif Shaher 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 c

Re: [Discuss-gnuradio] Intel Atom Processor

2010-10-08 Thread Marcus D. Leech
On 10/08/2010 03:25 PM, Jeffrey Lambert 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 perfectl

Re: [Discuss-gnuradio] Intel Atom Processor

2010-10-08 Thread Tom Rondeau
On Fri, Oct 8, 2010 at 3:25 PM, Jeffrey Lambert 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

Re: [Discuss-gnuradio] Intel Atom Processor

2010-10-08 Thread Jeffrey Lambert
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

Re: [Discuss-gnuradio] Intel Atom Processor

2010-10-08 Thread Sharif Shaher
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 diskgiven that do you still see a problem with 2 USRP2s, 4 USRP2s, 6 USRP2s using a 1.6 GHz atom? On 10/8/2010 3:08 PM, Tom Rondeau wrote: On Fri, Oct 8,

Re: [Discuss-gnuradio] Intel Atom Processor

2010-10-08 Thread Tom Rondeau
On Fri, Oct 8, 2010 at 2:54 PM, Marcus D. Leech wrote: > On 10/08/2010 02:46 PM, Sharif Shaher wrote: >>  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. >>

Re: [Discuss-gnuradio] Intel Atom Processor

2010-10-08 Thread Sharif Shaher
Thank you for the heads up. On 10/8/2010 2:54 PM, Marcus D. Leech wrote: On 10/08/2010 02:46 PM, Sharif Shaher wrote: 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 di

Re: [Discuss-gnuradio] Intel Atom Processor

2010-10-08 Thread Marcus D. Leech
On 10/08/2010 02:46 PM, Sharif Shaher wrote: > 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

[Discuss-gnuradio] Intel Atom Processor

2010-10-08 Thread Sharif Shaher
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 wil