<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
An interesting story follows :=)<br>
<br>
I started monitoring the system calls made by jnos with strace because
of the high CPU <br>
consumption with forwarding. (without forwarding it is low)<br>
<br>
I noticed many entries in the strace log with: <br>
<br>
5:50:36.543218 read(5, 0x9738af8, 3000) = -1 EAGAIN (Resource
temporarily unavailable)<br>
15:50:36.724403 read(5, 0x9738af8, 3000) = -1 EAGAIN (Resource
temporarily unavailable)<br>
15:50:38.996781 read(5, 0x9645040, 3000) = -1 EAGAIN (Resource
temporarily unavailable)<br>
<br>
This during the read() function call, reading FD (file descriptor) 5
what is a CHR (character special file)<br>
<br>
jnos2f4-j 1930 root 5u CHR 3,1 2930 /dev/ttyp1<br>
<br>
No doubt a busy-wait loop is used I guess to get this data what may
significantly increase the CPU usage, see below.<br>
<br>
<br>
I started monitoring the system calls in jnos as I had a lookalike
problem with FBB (xfbbd daemon) what also had<br>
a (very) high CPU This was an ongoing problem at other machines for
months and I was not alone as it seems.<br>
<br>
Here I had the same "resource temporarily unavailable" problem but
now during the recvfrom() function call,<br>
reading a socket. (telnet forwarding)<br>
<br>
After forwarding the (strace) log and my findings to
F6BVP a couple of days ago I started to do <br>
some research about socket programming in Linux to find a solution.<br>
<br>
A remark about high CPU and recvfrom() can be found in Chapter 7.1
of the <br>
<h1 class="maintitle">Beej's Guide to Network Programming</h1>
<a href="http://beej.us/guide/bgnet/">http://beej.us/guide/bgnet/</a><br>
<br>
"Generally speaking, however, this type of polling is a bad idea.
<br>
If you put your program in a busy-wait looking for data on the socket,
you'll suck up CPU <br>
time like it was going out of style."
<br>
<br>
While I was still digesting the FBB source code, F6FVB came up already
with a patch yesterday what introduced micro<br>
delays in the revfrom() blocking function.<br>
<br>
It seems that this unmodified function call is a problem at fast(er)
CPUs and the latest
kernels<br>
<br>
<br>
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<br>
and at Ubuntu 8.04 it reduced the CPU consumption from 69 % to 0.7
according to
Ray VK2TV<br>
<br>
It seems this function call is a problem at fast(er) CPUs and the
latest
kernels<br>
<br>
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<br>
<br>
and at a Celeron 2.6 GHz CPU with Ubuntu 8.10 (kernel 2.6-27) it used
originally a
whoping 96 % CPU !<br>
<br>
73,<br>
<br>
Bob VE3TOK<br>
<br>
<br>
<br>
</body>
</html>