[Xastir-Dev] CPU still too busy for the wrong reasons

[Henk de Groot]

Hello,

At 09:45 28-11-2003 -0800, Curt Mills, WE7U wrote:
>On Thu, 27 Nov 2003, Jack Twilley wrote:
>
> > xastir takes 90% of the CPU, but only 15% of the cpu is in user time,
> > the other 85% is mostly in system time.
> >
> > This is about what I saw on a 450MHz machine, and now I'm on a 2000MHz
> > machine.
>
>Running on a Pentium-Pro 200MHz machine, SuSE 7.3.  Hooked to a local
>TNC and Firenet filtered feed grabbing objects & weather alerts only.
>Set "top" to 30-second intervals.  Xastir is running at less than 10%
>CPU, mostly at 1-2%.  System is 90+% idle.

The only time I have seen programs using a huge amount of system time is 
when the program performs a non-blocking systemcall in a loop, for example 
reading /dev/ttyS0 which is programmed in non-cooked mode for reception of 
at most zero bytes and a timeout of zero (i.e. via termios program both 
VMIN and VTIME to zero). Making VTIME 1 (0.1 sec timeout) already drops the 
load down to nearly zero on most systems.

If Xastir burns a lot of system time I bet it is such a case. Tracking 
these down can be hard, but Curt mentioned high-load cases while 
reconnecting the network and zooming out, I don't know if that are 
user-cycles or system-cycles. For user cycles its of course the program 
itself causing the load, maybe it just happens to be a bunch of hard work...

If it is system-time then you have to find the systemcall that is causing 
it. If the systemcall itself doesn't have a timeout on its own, I suggest 
to insert a usleep() call in the loop to slow the loop down. "usleep" may 
not be available on every flavour of unix/windows or may be mapped to a 10 
ms timer in which case a usleep(1000) (1 ms) is rounded to zero... If you 
are not in a hurry, like reconnecting interfaces, its safer to go with an 
ordinary sleep(1) call.

The results may vary, unfortunately "libc" of a genuine Unix(tm) doesn't 
have a finer timeout than the 1 second sleep, unless you use a tty 
interface to create a 100ms timeout (since VTIME is in deci-seconds). When 
I wrote "aprs_tty" I remeber I had to set VTIME for the serial interface to 
2 to cause any effect, so any solution other than "sleep" may be prone to 
platform differences. It is a tricky business.

Of course the real solution is to use blocking systemcalls and have these 
things run in a separate thread. I believe Xastir does this most (all?) of 
the time. Still even then the system call may have an answer instantly 
causeing it to return without delay, which will cause the same problem if 
that happens in a loop.

I hope this gave some ideas where to look. I never seen another case of 
90%+ system load, other than a bug in the OS itself.

Kind regards,

Henk.