[Serdev] TCP problems

[Andrei Pelinescu-Onciul]

On Jan 17, 2007 at 14:30, Katty Xiong <cyyxiong at yahoo.com> wrote:
> 
> Hi Andrei,
> 
> I am trying to root cause the problem that one CPU at
> SER is saturated when using one TCP connection between
> UAC and SER. I have 8 TCP child process, and I notice
> two TCP child processes are doing work, the others are
> idle. The two child processes are doing many send()
> and read() system calls, and one TCP child process is
> doing many more read() than the other one. I guess the
> one doing more read() causes one CPU saturated at SER.
> 
> 
> My understanding about this 2 child processes is: one
> TCP child process is responsible for receiving data
> through the connection between UAC and SER, another
> one is responsible for receiving data through the
> connection between UAS and SER. Both TCP child
> processes can use either two connections to send data.
> Is this understanding correct? 

Yes, each connection is handled by only one tcp process, which does all
the reads. Some side notes: an idle connection moves back to the tcp
main process and in the future it can end up being handled by a
different tcp process. A tcp process can handle more then one connection
(the main tcp process will always distribute an active connection to the
tcp process which "owns" the smallest number of connections).

>If this is correct, how
> can I explain why one TCP process is doing more read()
> than another one? 

This is strange, maybe it receives more packets from the UAC then form
the UAS?

> 
> I don't quite understand how SER relays data using TCP
> connections. Is the following right? The TCP main
> processes keeps a complete list of all TCP
> connections. TCP child process has a partial list of
> TCP connections. 

So far is correct.

> When a TCP child needs a connection
> to send data, it will first check its own list to see
> if it has the connection. If not, it then asks the
> main TCP process for the connection information.

No, it will always ask the main process for the connection information
(but I'll fix it in the post-Ottendorf release :-)).


Andrei