Re: 400 Mb/s ADC

"Nik Simpson" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> Jeff Peterson wrote:
> >> 1. Just capturing the data performing some operation on it, storing
> >> the results and throwing away the sample
> >
> > we accumualte averages (of cross products of fourier tranforms)
> >
> 
> So the basic problem is getting 400MB/s of data into memory and processing
> it, but are you reading 400MB every second, or sampling say once every ten
> seconds. If it's every second, then you've got a bigger problem because I'd
> be surprised if you can process it fast enough to get the job done before
> the next sample comes along.
we will take about 64K samples, then can pause while processing...
however all the time we are pausing we are losing data.  so we do want to
keep the duty cycle up.  50% dudty cyle is not a problem. 5% would be.


> 
> >>
> >> 2. You might be actually planning to capture to disk 400MB/s for a
> >> sustained period which has some pretty hairy implications for
> >> storage capacity.
> >>
> > we wont store the raw data, just a very much reduced set.
> 
> So disk output bandwidth is not going to be a problem, what you are looking
> for is a way of getting 400MB/s of data into memory for post-processing,
> correct. Is it possible to break-up the input stream, so for example instead
> of reading a single stream of 400MB/s, you've five devices reading 80MB/s in
> parralel? Is the design of the device capturing the data set in stone or can
> it be "parrallelized" if so it would make the problem much simpler and any
> solution more scalable and less expensive.
this could work.  for example we have considered using 2 x scsi 320 
interfaces.  might work but its a bit of a kludge, and if we got the
two interfaces out of sync we would have a real mess.