Eric Wachsmann wrote:
This isn't hard to imagine given CPU benchmarks like Passmark (
http://www.cpubenchmark.net/). The Atom 330 gets 586 marks while a Q6600
(quad core) gets 2859 marks. Even the lowest end E4000 series Core 2 Duos
get >1000. The Atom 330 is roughly equivalent to a P4 3.6GHz based on this
benchmark.
Eric
Eric and I were supposed to meet yesterday online for a four hour
session on the resampler. I was derailed by work (my paying day job).
Shortly the Atom 330 will be overkill for this work. The cpubenchmark
measures things that are inappropriate for our application and while it
is relevant, it is not the whole story and by a lot.
In one of my branches, and as it is perfected, moved into the test
branch and then the main distribution, we will downsample the
computations to the minimum needed.
So for example, everyone who wants a 2.7 kHz channel will actually have
everything but impulse noise (NB,NB2) running at a much reduced sample
rate. The sample rate will necessarily be an integer divisor of 192000
samples per second. So the 2.7 kHz channel MIGHT be done at 3 ksps, but
will certainly be done at 4 ksps or less, the exact same operations
will be done but the amount of CPU required to do them will be reduced
by a factor of 48 or 64 (4 kHz or 3 kHz respectively). If you want to
do DRM, for example, the rate will be reduced to 16 ksps probably,
etc. The complex sampling rate needs only to be larger than channel you
desire.
The single biggest gain for us will be in the application of the agc
which is the current pig in the entire operation. Next to downsampling,
the agc will begin to use approximations for sqrt(SUM (sample_mag)^2)
and that will be another hug factor, so large that we will not call agc
the pig any more. As soon as that is not a pig in the agc, we will
upgrade the overall structure of the agc. Our current smallest time
scale in the agc is 1ms so even at the slowest proposed sample rate, we
will be oversampling for the agc by a factor of 3,4, or more.
The signal processing tools needed to do this have been in our code for
a long time. The problem with all of this is two fold. It must be done
in a way that the user is not troubled with worrying about it at all.
It just suddenly becomes magically more efficient. This is a big
software engineering job inside for the GUI maintainer (Eric). There
are other places I could do this and not worry about the GUI, but I
would not get feedback from hundreds of howling paying customers who
demand perfection and satisfaction. Imagine how unhappy all of you
would be if suddenly we broke your connection to CWSkimmer, etc. because
we narrowbanded the signal. In other words, we have to roll this out
in stages, gather all the complaints, fix all the things we break by
doing this and then everyone benefits.
Stand by, this will get tremendously better and quickly. On most of
your ATOM 330 based mother boards, you REALLY need to slow down the
display to 8-9 frames a second from the default 15. I find you don't
lose much and you are paying much less penalty for the horribly slow
Intel graphics engine.
Bob
Bob
_______________________________________________
FlexRadio Systems Mailing List
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
Knowledge Base: http://kc.flex-radio.com/ Homepage: http://www.flex-radio.com/
