[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linrad] Abit IC7 allows 192kHz settings for CPU-load tests; Re: [linrad] CPU usage
Leif-san,
Multi-threading keeps you busy and hopefully you have
received expert advice for some of your questions....
I have now understood that the CPU is not determining
the delay in 'Linrad', but rather: the slower the CPU,
the higher its relative usage, until it reaches 100%..
Then the application probably "collapses"... a rare
occurrence with today's fast processors.
All of the integrated audio on several motherboards
"propose" a sample rate choice up to 48000, except the
Abit IC7 (proposing choices up to 192000). It does not
mean that one can build an I/Q-receiver with successful
utilization of the full bandwidth. Actually the IC7 is
the worst quality board (compared to all others here)
regarding the operation of the integrated audio circuit
(at least as far as the microphone input is concerned).
For example under Skype VoIP-communications there is a
strong tapping noise on the outgoing audio, and under
'Linrad' the input spectrum shows wide noise bands at
7 kHz and 41 kHz on the frequency spectrum when using
48000 sampling rate (when no input signals are fed).
All of this may be better on the line input (however
not tested). Also another main power supply should be
tried to ensure that all MB-voltages have been clean.
As Leif/SM5BSZ suggested, some audio cards can be set
beyond their specs to give the CPU some more samples
and a bigger work load. So the sampling rate of the
integrated audio of the Abit IC7 was set to 192000
and the output rate to 8000 Hz. With a 2400 MHz P4
this resulted in about 26% CPU-load, and with the
inefficient Lagrange-interpolation under 192000 Hz
output sampling, the load was 36%. I do not know what
the extra load is for 4-channel operation, but probably
this setup could process future 8-channel 192 kHz input
sampling if the output rate is limited to the low rates.
When feeding audio to the IC7 input, it was clearly seen
that the circuitry was not designed for these high rates
as the input spectrum showed multiple aliased responses,
and the baseline level dropped off above 24 kHz separation
form the center frequency. Also I noticed that the 'Linrad'
frequency scale of the waterfall behaves like an old car's
mileage meter, showing 100 000 as 00 000 (actually just 0).
So the parameter needs an allocation for one more figure
on the right end of the scale: e.g. 140000 Hz now 40000 Hz.
Initially this was a little confusing, but the experiment
yielded this improvement suggestion for the user-interface.
As such all these experiments have again derailed me from
the goal to get some form of real world reception ability.
Thus it is about time to link up some of the analog stuff
in front of the sound inputs. That is actually the best
incentive to learn about the use and optimization of the
various parameters. The impulse generator for the quick
calibration of the I/Q-channels (and the smart blanker)
is actually not too complicated, but here its construction
has been delayed already for years, due to all the other
"interesting" 'Linrad' experiments and software challenges.
A key for quick successful results would be an "approach
guidebook" that should be fairly strictly followed. The
ongoing Live_CD development by Roger/W3SZ will certainly
speed up the start-up time of new candidates (by 10 dB).
73, "Zaba" OH1ZAA/2 [The sky is no limit]
At 19:28 26.4.2005 +0200, SM5BSZ wrote:
Hi All,
In the current Linrad package, the CPU spends its
surplus time in an "idle loop" which is just doing
nothing or sending the process to sleep with usleep();
depending on the parameters selected by the user in
the initial setup.
Just by comparing the time spent in the idle loop
to the total time one gets a good number for how much
of the time available to Linrad that could be used for
heavier processing.
In the multi-threaded version the above strategy is
not possible. Any time not needed by Linrad is consumed
by the kernel or another task. Instead a system call
getrusage() is used to get the total amount of time
that the CPU spent with the task. This works fine
with the 2.6 core and is how getrusage is defined
according to POSIX (whatever that is) but in the 2.4
and older kernels getrusage works differently. It
just gives the time consumed by the calling thread
and therefore all threads have to be interrogated.
This is fine in the development phase because it
allows me to see where the time is spent, but summing
over the fifteen threads which gives the correct load
under 2.4 kernels gives a value that is too big by 15
times under 2.6.
By setting a global define GETRUSAGE_OLD to 0 or 1
Linrad works fine under both kernels. Currently
a header file has to be edited manually, but I am sure
it is possibe to use the configure script to find out
which of the behaviours to implement at compile time.
Presumably it amounts to find the GCC version and make
a test on it to get a yes or no answer.
I just do not know how to do it. Is there anyone on the
list who knows? I do not understand anything about how
the configure script really works - someone made it for
me - so I really need a few lines to add to the Linrad
configure.in file to get an input to AC_SUBST.
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