Browse Prior Art Database

LCE daemon and its use of threads to maintain connections to multiple pSeries eServers

IP.com Disclosure Number: IPCOM000014670D
Original Publication Date: 2001-Jul-23
Included in the Prior Art Database: 2003-Jun-20
Document File: 2 page(s) / 30K

Publishing Venue

IBM

Abstract

LCE daemon and its use of threads to maintain connections to multiple pSeries eServers The LCED (Local Control Element Daemon) is a router process that runs on a standalone PC (aka the Platform Management Console (PMC). This PMC could attach to pSeries eServers. The LCED controls all communication from any PMC application to the CSP (Common Service Processor) in a pSeries eServer system, and vice-versa. This daemon has to be able to accommodate multiple CSPs attached via serial connection in its first release, as well as future new objects (i.e. switch units, bulk power assembly, etc.) and communications types (i.e. ethernet, TCP/IP, etc.). The LCE needs to be able to communicate to multiple PMC applications, multiplexing data packets they may send to multiple CSPs. If we have one thread trying to handle all of the communications, there could be bottlenecks. For instance, one PMC application could be engaged in communication to a particular CSP. Any other communications (whether downstream to the CSP or upstream to another PMC application) would have to wait for the first application to complete its transaction. This becomes important when considering an PMC application such as the Terminal Emulator (Virtual TTY), which needs to get data from the CSP up to the PMC user as quickly as possible.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

LCE daemon and its use of threads to maintain connections to multiple pSeries

eServers

The LCED (Local Control Element Daemon) is a router process that
runs on a standalone PC (aka the Platform Management Console
(PMC). This PMC could attach to pSeries eServers. The LCED
controls all communication from any PMC application to the CSP
(Common Service Processor) in a pSeries eServer system, and
vice-versa. This daemon has to be able to accommodate multiple
CSPs attached via serial connection in its first release, as well
as future new objects (i.e. switch units, bulk power assembly,
etc.) and communications types (i.e. ethernet, TCP/IP, etc.).

The LCE needs to be able to communicate to multiple PMC
applications, multiplexing data packets they may send to multiple
CSPs. If we have one thread trying to handle all of the
communications, there could be bottlenecks. For instance, one
PMC application could be engaged in communication to a particular
CSP. Any other communications (whether downstream to the CSP or
upstream to another PMC application) would have to wait for the
first application to complete its transaction. This becomes
important when considering an PMC application such as the
Terminal Emulator (Virtual TTY), which needs to get data from the
CSP up to the PMC user as quickly as possible.

The solution was to create a thread per type of communication,
e.g. one thread for serial communication, one thread for ethernet
communication, etc. For example, the serial communications
thread will send and receive all serial data over a serial port.
When a SLIP formatted data packet is received from the CSP, this
thread will package it as appropriate and send it to the proper
CSP thread. There is a CSP thread for each CSP that the PMC is
communicating with. If the PMC is only communicating with one
CSP, there will be one CSP thread. If there are two CSPs that
the PMC is communicating with, there will be two CSP thread...