[Linrad] Re: Setting priorities in Windows

[Leif Asbrink <sm5bsz.com; leif@xxxxxxxxxxxxxxxx>]

Hi All,

> You should almost never use REALTIME_PRIORITY_CLASS, 
> because this interrupts system threads that manage mouse input, 
> keyboard input, and background disk flushing. This class can 
> be appropriate for applications that "talk" directly to hardware 
> or that perform brief tasks that should have limited interruptions.
Hmmm, Linrad works as follows:

1) The normal state is that all threads sleep.

2) Occasionally there is an interrupt from the hardware saying
that one block of data has arrived. That will cause a return
from a blocking read (or equivalent) that awakes the input
thread which will move the data to user space. It will also
send a block of data (of each kind) to the network in case network
tx is enabled. Both these things are time critical. Network
packages have to be evenly distributed in time to allow a high 
throughput.

As it happens, the hardware block will typically contain the amount 
of data required to fill the input buffer of the first fft. The input
thread will awake the first fft thread only when there is data for it.

3) It is essential that the first fft is started immediately
when one block of data has arrived. Any delay will add to the
delay from antenna to loudspeaker which we want to keep at minimum.
The parameter "Output delay margin" in Linrad must be increased
by the time stolen by other processes even if such a "theft"
happens very infrequently. The "margin" is always added to the 
delay from antenna to loudspeaker.

Actually this is true only every N-th time, that is when the 
first fft thread has produced enough data to fill the fft2 input
buffer. At the point when this happens, the summed delay in starting
the fft1 threads and the fft2 threads will add to the system delay.
It would be OK to set a lower priority for the fft1 thread those
N-1 times when fast response is not needed. On the other hand,
when running time critical modes N=1 so then it does not help.
In other modes, there is no need to set high priority for
Linrad.
 
4) fft2 will awake the baseband thread (if there is enough data)
Any waiting time due to lack of priority will add to system
delay.

5) The baseband thread is more complicated because it can be
woken up from both sides. It could be woken up by the baseband thread
but it could also be sleeping for zero seconds or perhaps
5 ms while waiting for buffer space to become available in the 
output thread. This thread is time critical. In applications where
a fast response is desired there is only a couple of milliseconds
of data available at the time when the output thread needs
its data. This thread could be optimized to always sleep for
a finite time, never zero seconds. At normal priority it does not
matter, but at real time priority other threads would benefit
from a better CPU usage in not splitting up the output data in
smaller chunks than necessary.

                            - o -

When Linrad runs at i.e. 50% CPU load, the system is sleeping
(or available for anything else) 50% of the time. Linrad wakes up
at the DMA rate which is typically 500 Hz in a time critical
application. Mouse, keyboard or disk flushing do not have to
be serviced more frequently than that.

When Linrad is set for high resolution the situation is very different.
The fft2 thread may be sleeping for 1 second while collecting 1048576
samples at 1 MHz (to produce a 1 Hz waterfall at 1 MHz bandwidth)
The computational time for such a large FFT could be a significant 
fraction of 1 second. Linrad will automatically set a low DMA
rate (big hardware buffers) and the fft2 thread will issue sleep
statements regularly in order to never block the CPU for
a long time. Under such conditions there would be no reason 
to sety high priority, but it does not seem to be very harmful. 

The only threads that do not suffer from low priority in
Linrad are the mouse and keyboard threads. It does not seem
reasonable to set highest priority on all threads except
those two. They nearly always sleep anyway.....

I write this onboard the airplane on my way home. I will
do some testing on slower computers with a single core
to see if realtime priority causes anything bad that I
can discover before I make this option available for testing
by others. 

73

Leif / SM5BSZ


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Linrad" group.
To post to this group, send email to linrad@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to linrad+unsubscribe@xxxxxxxxxxxxxxxx
For more options, visit this group at http://groups.google.com/group/linrad?hl=en
-~----------~----~----~----~------~----~------~--~---


LINRADDARNIL