[Linrad] Re: RX OVERRUN_ERROR

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

Hello Thomas,

> I slowed things way down.  It sort of works.
> 
> M_CIC2 [16]
> M_CIC5 [32]
> M_RCF [32]
> OL_RCF [2]

> If I click in the waterfall area then press X, after several seconds, I
> get the change parameter screen.  Pressing X again returns me to the
> main menu and things seem sort of normal.
> 
> The response to the keyboard or mouse is VERY slow!  The CPU usage is
> low.

I do not know why your ultra-fast computer misbehaves. One thing is that
the parameters above causes a very slow response to the mouse.
The reason is that Linrad reads blocks of 8192 bytes and that therefore 
the the sampling speed of 4 kHz that the above parameters give leads
to an interrupt rate of 2 Hz only. The delay on mouse or keyboard
is therefore 0.5 seconds. 

Mouse or keybouard commands are only serviced from the thread that 
they belong to when the thread in question is not overloaded and
has waken up from waiting on a semaphore. The reason is that the
commands may change memory allocations and therefore must not be
serviced unless the thread is in its idle state. Under reasonable
operating conditions the delay is 20 ms or less.

Surely it would be possible to do something about this, but running 
the SDR-IQ at extremely low sampling rates is not something that seems
reasonable in Linrad.

You may modify the routine lir_sdr14_read like this:
int lir_sdr14_read(void *s,int bytes)
{
int i;
qq("READ");
i=read(sdr, s, bytes);
qq("  OK");
return i;
}

The routine is near line 936 in lsetad.c

The qq function will write READ on the screen when calling the kernel
module and OK when returning from the kernel. This modification causes
frequent calls to the X11 server from the input thread that has the 
responsibility to read from the USB before an overrun occurs. Nevertheless
Linrad runs without any error at all on my 2.67 GHz Pentium 4 as long as I do
not run other programs. When I grab the title bar of another window on 
the desktop and move that other window around, I will see OK from the
qq routine for a long time. Moving windows has higher priority than
Linrad so Linrad does not get the time to process its data and
the read from the USB becomes delayed. When I stop moving the other
window around, OK becomes replaced by READ and Linrad would write
"No input" in the lower left corner of the screen. At this point the 
USB subsystem has crashed. Linrad calls the ft245 kernel module, but
there is no return. Linrad will continue at negligible processor load
until ESC is pressed which would cause 100% cpu load. That is a misbehaviour
of Linrad, should be fixed some day, but not of high priority.
It happens only when the input thread hangs on a read.
It is possible, but not quite as easy to make the USB subsystem crasch 
by moving around the Linrad window on the desktop.

Running Linrad on a dual core machine does not help at all. The USB
sub-system crasches when I move another window around just like on the 
single core machine.

When Linrad is disturbed by my moving another window there are
overrun errors as well as several other types of errors. The X11
system is not designed for a real-time application like Linrad.
It gives priority to user commands (like moving a window) with
no respect for other applications. Setting the maximum possible
priority to the thread that does the reading from SDR-IQ does not
help. X11 window moves have higher priority:-(
int policy;
struct sched_param parms;
policy=SCHED_RR;
parms.sched_priority=sched_get_priority_max(policy);
pthread_setschedparam(thread_identifier[THREAD_RX_OUTPUT],policy,&parms);
i=pthread_getschedparam(thread_identifier[THREAD_RX_OUTPUT],&policy,&parms);
The retunded priority becomes 99. Max allowed.

Soundcard inputs recover automatically after not have been serviced 
for a long time. With SDR-IQ a blocking of the USB-system causes
the software inside the SDR-IQ to crasch. After that an attempt to read
the SDR-IQ will not cause any data to be transferred over the
USB and consequently Linrad will hang on the blocking read on the USB.

Dear Thomas, it seems to me that your systems runs something that
other Linrad users do not run. Something that does not respect that
the USB subsystem has to be serviced in time ALWAYS. If an error
occurs the FT245 driver does not have the error handling required
so it hangs on a read statement. It would be possible to use a non-blocking
read and to put new routines into Linrad to try to reset a crashed
SDR-IQ. It would work sometimes, but not always. In some cases it
is necessary to hard reset the SDR-IQ by switching off the DC power.

The tests I have made were with normal sampling rates, decimation
700 for sampling at 96 kHz. Nobody else has reported the problems you 
have. I would be interested in reports of similar problems and if
they have or have not been resolved.

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