#543 xastir consumes CPU time in X11 socket I/O

[Kamal Mostafa]

Originally reported against xastir-1.9.4-3 in Ubuntu; I still see this same behavior in my own build of xastir-1.9.6 on Ubuntu:

https://bugs.launchpad.net/ubuntu/+source/xastir/+bug/454740

Strace on xastir-1.9.6 shows this sequence spinning hard:

sched_yield() = 0
sched_yield() = 0
read(5, 0x1694914, 4096) = -1 EAGAIN (Resource temporarily unavailable)
read(5, 0x1694914, 4096) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN|POLLPRI}], 2, 9) = 0 (Timeout)
poll([{fd=6, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout)
read(5, 0x1694914, 4096) = -1 EAGAIN (Resource temporarily unavailable)
read(5, 0x1694914, 4096) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN|POLLPRI}], 2, 0) = 0 (Timeout)
poll([{fd=6, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout)
[...]

[Gerald J. Stueve]

Why is this a problem? The system is not loaded to 100% is it? Xastir is being a good citizen by scheduling resource round robin at the end of a process loop. This is a normal sequence of actions from a select that is timing out rather than having any of the file descriptors with data to process. To change this behavior would require that all of the active file descriptors be mapped into the entries for the select() system call and then adjusting the timeout to a larger value that still would wake up the thread for housekeeping details.

[Kamal Mostafa]

Thanks for your response, Jerry.

Why is this a problem? The system is not loaded to 100% is it?

I guess that would depend on the speed of the system. :-)

In my opinion, xastir really shouldn't spin at all, but instead should just block when it has nothing to do. But having seen the process loop implemented by main.c UpdateTime(), I do understand that changing it would be difficult.

Perhaps just increasing the timeout to alleviate the issue would be appropriate. Am I correct that the following excerpt from UpdateTime() relates to the issue we're talking about? It looks like this spin timeout has caused some grief in the past.

Could nexttime be set to e.g. 200 ms for all platforms?

    // Start UpdateTime again 10 milliseconds after we've completed.
    // Note:  Setting this too low can cause // some systems
    // (RedHat/FreeBSD) to spin their wheels a lot, using up great
    // amounts of CPU time.  This is heavily dependent on the true
    // value of the "HZ" value, which is reported as "100" on some
    // systems even if the kernel is using another value.
#ifdef __CYGWIN__
    // Cygwin performance is abysmal if nexttime is lower than 50, almost
    // acceptable at 200.
    nexttime = 200;
#else
    // Changed from 2 to 10 to fix high CPU usage problems on
    // FreeBSD.
    nexttime = 10;
#endif // __CYGWIN__

[Tom Russo]

Changing Xastir from calling UpdateTime periodically to doing some other technique will be a major change. If one finds Xastir consuming excessive CPU, one could change the "nexttime" setting for that platform.

The current values of nexttime are the result of quite a bit of tuning on a number of systems, so changing it globally is not desirable.

marking CLOSED WONTFIX.