[nos-bbs] High CPU jnos, sockets and CHR character special files ; =)

[Bob Tenty]

An interesting story follows :=)

I started monitoring the system calls made by jnos with strace because 
of the high CPU
consumption with forwarding. (without forwarding it is low)

I noticed many entries in the strace log with:

5:50:36.543218 read(5, 0x9738af8, 3000) = -1 EAGAIN (Resource 
temporarily unavailable)
15:50:36.724403 read(5, 0x9738af8, 3000) = -1 EAGAIN (Resource 
temporarily unavailable)
15:50:38.996781 read(5, 0x9645040, 3000) = -1 EAGAIN (Resource 
temporarily unavailable)

This during the read() function call, reading FD  (file descriptor) 5 
what is a CHR (character special file)

jnos2f4-j 1930 root    5u   CHR    3,1            2930 /dev/ttyp1

No doubt a busy-wait loop is used I guess to get this data what may 
significantly increase the CPU usage, see below.


I started monitoring the system calls in jnos  as I had a lookalike 
problem with FBB (xfbbd daemon) what also had
a (very) high CPU  This was an ongoing problem at other machines for 
months and I was not alone as it seems.

Here I had the same "resource temporarily  unavailable"  problem but now 
during the recvfrom() function call,
reading a socket.  (telnet forwarding)

After forwarding the (strace) log and my findings to F6BVP  a couple of 
days ago  I started to do
some research about socket programming in Linux to find a solution.

A  remark about high CPU and recvfrom()  can be found in Chapter 7.1 of  
the


  Beej's Guide to Network Programming

http://beej.us/guide/bgnet/

"Generally speaking, however, this type of polling is a bad idea.
If you put your program in a busy-wait looking for data on the socket, 
you'll suck up CPU
time like it was going out of style."

While I was still digesting the FBB source code, F6FVB came up already 
with a patch yesterday what introduced micro
delays in the revfrom() blocking function.

It seems that this  unmodified function call is a problem at fast(er) 
CPUs and the latest kernels


This patch reduced the FBB CPU consumption from max 40 % to 0.7 %  at 
Ubuntu 9.04 kernel 2.6-27 running at my gateway
and at Ubuntu 8.04  it reduced the CPU consumption from 69 % to 0.7  
according to Ray VK2TV

It seems this function call is a problem at fast(er) CPUs and the latest 
kernels

I noticed for instance no problem with a unpatched FBB version "r"at a 
Pentum 1 using Ubuntu 8.04 and kernel 2.6-15

and at a Celeron 2.6 GHz CPU  with Ubuntu 8.10 (kernel 2.6-27) it used 
originally a whoping 96 % CPU !

73,

Bob VE3TOK



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20090620/905d96bb/attachment.html>