[linrad] Re: CPU-load and delay on 486

[<leif@xxxxxxxxxx>]

> Before taking my couple of old 486's out of the dust, wouldn't
> it be good to have a couple of reference values for the CPU-load
> and signal delay under 'Linrad'. Possibly not much RAM-hardware
> is needed for the actual running operation. Even if the delay would
> be a couple of seconds, it would make 'Linrad' a perfect monitoring
> tool around the 50/70/144 MHz calling frequencies, especially in
> industrial or city environments with a lot of man-made noise.
???????
What sampling speed (bandwidth) are you talking about?
I think a 486 would be limited to SSB bandwidth  or just a little
more. I do not think the CPU will be fast enough to allow the
noise blanker but collecting a long time averaged waterfall
would be possible for monitoring purposes.

> As far as I have understood there are a few issues related to
> CPU-load and delay. The reason that my Duron_1000 is taking so
> much (15%) CPU load is probably mainly due to my high output
> rate (48000). Adequate performance would be achieved already
> with 6000 Hz sampling in the D/A converter, which would reduce
> FFT-calculations substantially.
Hmmm, that is not the way Linrad works. The FFT calculations are
determined by the input sampling rate and the window. To a lesser
extent also by the fft1 bandwidth. The second fft is not used
in these cases unless you have a SSB receiver with a good dynamic
range within the passband such as the FT1000D. The third fft
is at a rate explicitly set by the user and on a slow computer
one would set the parameters for a sampling rate in the order
of 200Hz. The filtered signal is finally resampled to the
output sampling speed of the D/A. No FFT is involved here - I have
written a stupid routine that uses Lagranges interpolation formula to
fit four points on the baseband (200Hz) function to a third order
polynomial. The non-integer (and variable) re-sampling rate needs
typically data points that are about 10 times more closely spaced
(big computer baseband rateP0Hz for CW, D/A rate 5kHz) and
despite the stupid design of the routine it does not take much time.

At 48 kHz output sampling speed it is very different. The routine becomes
ridiculous. The interpolation formula is used for each data point
in the output data stream:-( Absolutely stupid!!!

The purpose of the routine is to allow non-integer resampling rates
to permit non-synchronous audio cards for input and output. The
routine will produce a low distortion audio signal, something
that might be essential. Fitting a second order polynomial would
produce audible distortion on a noise-free sinewave.

Obviously an FFT should have been used to fit a sine-wave over a
couple of points. That sinewave could then be used to take samples
from at any desired output rate.

Another thing is that the BFO uses the sine and cosine functions of
the C library (presumably the processor) to shift the frequency
from zero to 400Hz or whatever the operator asks for. This is also
ridiculously slow if you go for 48kHz and there is no reason for
it because the BFO could be generated by phase increments through
multiplications.

Under normal operating conditions the carelessnes described above
is totally insignificant.

> Another thing is that 'Linrad' development has not been linear
> through the years, meaning that Leif has reported several times
> that the code has been substantially improved.
Hmm, I would say it has been very linear. Like a good 3 bit A/D
converter;-)  I have added new functions one by one, but once
added and coarse debugged, established functions are essentially
unchanged.

> Therefore it may be that some listed values are not valid
> anymore for the newest lir01-xx series
I do not think so. The total CPU load has been too high
on some systems occasionally due to various bugs but the
actual CPU use is not different over time.

> (Leif, if that is what you mean by "too much"
> information, then I could possibly agree, but there is a risk
> to lose other embedded information if these old reports would
> be removed; I guess the best is to display clearly the time
> frame and technology/software versions during measurement).
No. I referred to my habit of giving alternate solutions on
each problem - seems that many people want to know "the one
and only good solution" (just think about how X-yagis are
used on 144 MHz.......)

> Finally the (not so hypothetical) question is. Given a 486/33,
> what is the approximate CPU load and delay with input sampling
> at 48000 and output at 6000?
I do not think you can sample at 48 kHz with such a machine.
I would suggest 6000 for input and 5000 for output (if you can)
The delay is small - it is not much related to the processor.

> My experience was that the screen
> update was very sluggish initially in the lir00-xx series. So
> possibly the main improvement has been there.
Yes. I made many changes motivated by various timing issues.
I think late versions handle priorities reasonably well. It
will skip screen updates in a way that you can hardly notice
in case there is a shortage of CPU time.

> Also ISA-cards
> seem to slow down the CPU during transfers (a DMA issue)? For
> passive monitoring I would allow several seconds of delay, but
> for regular QSO's one second is about maximum, dependent on the
> mode.
????????
I have never seen anything like this.
Is it really something you have seen with Linrad?

Just remember, if you want a filter that is flat over 18 Hz
and that drops by 6 dB for a 20 Hz bandwidth, that filter has
a Q that makes the delay about one second.

For a short delay, expand the baseband graph and put only three
yellow points on the passband. The filter will then have a
"normal" Q and a much shorter delay.

It is not computing - it is just math;-)


73

Leif / SM5BSZ






#############################################################
This message is sent to you because you are subscribed to
  the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>


LINRADDARNIL