KR0169590B1 - The terminal driving method of high speed parallel computer in communication node - Google Patents

Abstract

The present invention relates to a method for driving a terminal device on a dedicated node for high-speed parallel computer communication. In addition to providing terminal device driver accessibility and fault tolerance, a method of driving a terminal device on a node dedicated to high-speed parallel computer communication that maximizes processing capabilities by separating terminal-related tasks from general computational processing is disclosed.

Description

How to Drive Terminal Devices on Nodes Dedicated to High-Speed Parallel Computer Communications

The present invention relates to a method for driving a terminal device on a node dedicated to high speed parallel computer communication.

A high speed parallel computer (hereinafter referred to as main computer 4) is a weakly coupled multiprocessing system in which a plurality of clusters are interconnected. An arbitrary cluster has a structure in which nodes consisting of a shared memory based on the P6 bus and a plurality of main processing devices are interconnected with each other. The microcomputer kernel-based operating system is built into the structure of the host computer 4 to maximize fault tolerance, ease of system management, and scalability. The communication dedicated node is responsible for communicating with the outside of the various types of nodes in the cluster, and communication-related controllers, serial input / output controllers, real-time controllers, and nonvolatile memories exist in the node.

The system console and user terminal (hereinafter referred to as "terminal"), which are mounted through the serial input / output controller (hereinafter referred to as "asynchronous port"), allow the system administrator or user (hereinafter referred to as "user") to transmit commands to the system. It shows the processed result to the user.

Terminal device drivers are necessary to make these terminals available to the operating system. In particular, in a structure in which a communication kernel has a dedicated node, such as the main computer 4, and a microkernel operates at each node, a method of driving a new terminal device driver different from the existing terminal device driver is required.

According to an aspect of the present invention, there is provided a method of driving a terminal device on a high-speed parallel computer communication dedicated node according to the present invention. Whenever a request message arrives at a transmitting / receiving connection point, a second step of driving the control and general message handler according to the work separation table in the request message processor, and connecting the message to the write queue according to the driving of the control and general message handler, A third step of controlling the stream manager and the transmission flow through the QFULL flag and requesting execution of the message transmission driver; and a message connected to the write queue in the message transmission driver to the terminal transmission buffer according to the execution request of the control and general message handler. Save and set the interruptible flag A fourth step of generating an interrupt, and transmitting the data in the terminal transmit buffer to the asynchronous port through the asynchronous port transmit buffer in the interrupt handler driven by the interrupt, and then sending the message of the asynchronous port to the asynchronous port receive buffer. And a fifth step of transmitting the data in the asynchronous port receiving buffer to the terminal receiving buffer using a scan driver, and configuring the received data in the terminal receiving buffer in a message form according to the RQFULL state to transmit the data to the stream manager. Characterized in consisting of steps.

1 is a block diagram of a communication dedicated node to which the present invention is applied.

2 is a block diagram of a terminal device driver to which the present invention is applied.

3 is a flow chart for initializing a terminal driver according to the present invention.

4 is a flowchart illustrating a method of processing a request message processor according to the present invention.

5 is a flowchart illustrating a processing method of a general and control processor according to the present invention.

6 is a flowchart illustrating a method of driving a message transmission driver according to the present invention.

7 is a flowchart illustrating a method of processing an interrupt handler according to the present invention.

8 is a flowchart illustrating a method of driving a scan driver according to the present invention.

* Explanation of symbols for main parts of the drawings

101: P6 bus

102: main processing unit (MPU)

103: shared memory 104: PCI bus

105: Ethernet controller 106: FDDI controller

107: X-bar Network InterFace (XNIF)

108: Local Resource Controller (LRC)

109: interrupt controller (IC)

110: interconnection network (X-bar: Cross-Bar)

111: Serial Input Output Controller (SIOC)

112: non-volatile memory (NVRAM)

113: Real Time Clock (RTC)

Hereinafter, with reference to the accompanying drawings will be described in detail the present invention.

1 is a block diagram of a communication dedicated node to which the present invention is applied. Within the communication dedicated node, the P6 main processing unit 102 and the shared memory 103 exist based on the P6 bus 101. Two PCI buses 104 are in contact with the P6 bus 101, and an interconnection network access controller (X-bar Network InterFace) which allows access to the crossbar structure interconnection network 110 is connected to the first PCI bus 104. , XNIF) 107 and Serial Input Output Controller (SIOC) 111 for serial communication, Real Time Controller (RTC), which provides time to the system. 113, a local resource controller (hereinafter referred to as LRC) that manages local resources such as non-volatile memory (NVRAM, hereinafter referred to as NVRAM) 112 storing shape information in the system. 108 and an Interrupt Controller (hereinafter referred to as IC) 109 are mounted. The second PCI bus 104 is equipped with communication device controllers 105 and 106 such as Ethernet, Fiber Distributed Data Interface (FDDI) for communication with the outside. The terminal device driver is loaded into the shared memory 103 and used, and is executed by the main processing device 102. The user terminal is connected asynchronously through a port in the SIOC 111.

2 shows a configuration and processing model of a terminal device driver to which the present invention is applied. Whenever a request message arrives at the message transmission / reception connection point 201, a request is made to transfer control to the general message processor 204 or the control message processor 205 according to the job classification table 203 composed of the type of job and the handler in charge. The message handler 202 is executed. The control message processor 205 immediately processes or connects the control message to the front of the write queue 206 in the one-way connection list according to the type of work. The generic message handler 204 connects the received message to the back of the write queue 205. In the control and general message processing, the message is connected to the write queue, and transmission flow control is performed with the stream manager through the QFULL flag 207 according to the number of messages in the queue. If the message transmission driver 210 is waiting, it executes a request. The message transmission driver 210 takes the messages connected to the write queue 206 one by one from the beginning, stores them in the terminal transmission buffer 208 (219), and sets an interruptible flag. As a result, an interrupt is caused. The interrupt handler 211 transmits all the data stored in the asynchronous port transmit buffer 209 to the terminal-connected asynchronous port 212 (217), and all the data in the terminal transmit buffer 208 are also the asynchronous port transmit buffer 209. 218 and both transmit to the asynchronous port 212. When received data arrives at the asynchronous port 212 from the terminal, an interrupt is caused, and the interrupt handler 21 is driven to move the received data to the asynchronous port receive buffer 216 (222). The scan driver 213 periodically wakes up and transfers the data present in the asynchronous port receive buffer 216 to the terminal receive buffer 215 (221) and then receives it according to the RQFULL 214 state indicating the stream manager and receive flow control conditions. The data is configured in the form of a message and transmitted to the stream manager (220).

3 is a flowchart for initializing a terminal driver according to the present invention. This process begins after the microkernel is connected on the dedicated node for communication. Initializing the message transmission / reception connection point 201 (301), initializing the job classification table (203) composed of the type of job and the handler in charge (302), and transferring control to the handler for the request message arriving at the connection point. The request message processor 202, which is performed before, is driven (302). The write queue 206, the terminal transmit / receive buffers 208 and 215, and the asynchronous transmit / receive buffers 209 and 216 are initialized (303), and the message transmission driver 210 and the scan driver 213 are driven (304). Finally, the asynchronous port 212 is initialized (305) and the execution ends.

4 is a flowchart illustrating a method of processing a request message processor according to the present invention. Execution starts at terminal driver initialization (302), and is in a waiting state for execution until a request message arrives (402). Execution starts when a request message arrives at the message transmission / reception connection point 201 through a microkernel which is operated on the communication dedicated node from the stream manager. The request message arrives at the access point and the content of the job requested by the message is determined (403). The processor for this task is found based on the job division table 203 created at the time of generating the terminal device driver (404). If the responsible processor is present, an execution request is made to the processor (406) and a check is made to see if another request message has arrived at the access point (401). If another request message exists at the message transmission / reception access point 201 (401), the execution is repeated, otherwise waiting for execution (402).

5 is a flowchart illustrating a method of processing a general and control message processor according to the present invention. The request message handler 202 starts execution by making an execution request 406. If it is a control message requesting urgent processing (501) immediately processing (502) and execution ends (512). For other control messages (503), only when the terminal state satisfies the state requiring processing (504), such as terminal BUSY state (504), otherwise it is connected (506) to the front of the write queue. If it is a normal message, it is connected to the end of the write queue unconditionally in arrival order (505). After the message is connected to the write queue, if the number of control and general messages waiting in the write queue is greater than the high water level set by the write queue for transmit flow control (507), set the QFULL flag (207) and stream (508). Request to stop transmitting the message to the administrator (509). If the message transmission driver 210 is in standby 1 (510), it executes a request (511), and execution ends (512).

6 is a flowchart illustrating a method of driving a message transmission driver according to the present invention. The execution begins at terminal driver initialization (304) and remains in wait 1 until a message exists in the write queue (602). When a message is connected to the write queue by the general and control message handler, the execution request 511 is received and execution starts. Then, the message is brought to the front of the write queue (603). If the number of messages queued in the write queue is smaller than the low water level defined for transmission flow control (604), the stream manager is notified of the previous message transmission stop request (605). If a control message is obtained (606), if the state of the current terminal is satisfactory for execution (607), the control message is processed (611), otherwise it is stored again at the beginning of the write queue (608). Then repeat the above operation. If it is a normal message, the terminal transmit buffer 208 checks whether it is empty (609). If not empty, wait 2 (610), the interrupt handler 211 is requested to run (710) to exit the wait state. If empty, store the message in the terminal transmit buffer 208 and set the interruptible flag (612). If the write queue is empty, it waits 1 (602). Otherwise, the operation is repeated.

7 is a flowchart illustrating a method of processing an interrupt handler according to the present invention. Execution starts when an interrupt occurs on the asynchronous port 212. If it is ready to receive (701). The received data is stored in the asynchronous port receive buffer 216 (702). If the number of data stored in the asynchronous reception buffer 216 exceeds the high level value defined by the buffer (707), the data transmission stop request is made to the terminal (704). If there is another data in the asynchronous port (705), the operation is performed again. If it is ready to transmit (706), first, all data stored in the asynchronous transmission buffer 209 is transferred to the terminal, and all the data stored in the terminal transmission buffer 208 is transferred to the asynchronous transmission buffer to the terminal. To be transmitted (707). Then, the interruptible flag is reset (708). If the message transmission driver 210 is in standby 2 (709), an execution request is made (710), and execution ends (711).

8 is a flowchart illustrating a method of driving a scan driver according to the present invention. The driver wakes up periodically and starts running. First, when the terminal reception buffer 215 is full (801), it is checked whether the RQFULL flag 214, which is used for flow control with the stream manager, is set (802). If set, execution ends (807). Otherwise, all data stored in the terminal receive buffer 215 is transmitted to the stream manager in the form of a message (803). If there is excess in the terminal receive buffer, it is checked whether there is data stored in the asynchronous receive buffer 216 (804). If no data exists, execution ends if the RQFULL flag is set (805) (807). If the data is reset, all data stored in the buffer is sent to the stream manager in the form of a message (806). End (807). If data exists in the asynchronous receive buffer 216, the data is moved to the terminal receive buffer 215 (808). If the number of data stored in the asynchronous receive buffer is less than the low water level set in the buffer for flow control with the terminal (809), the terminal is informed of the release of the previous data transmission stop request (810). Repeat the above operation.

As described above, according to the present invention, a new terminal device driver operating based on a microkernel in the same structure as the communication dedicated node of the main computer 4 uses various terminal device driver accessible functions and fault tolerance to stream managers operating at other nodes. In addition to providing functionality, it has the advantage of maximizing processing power by separating terminal-related tasks from normal computational processing.

The new terminal device driver, which operates based on the microkernel in the same structure as the communication dedicated node of the main computer 4, which is a high-speed parallel computer, provides stream terminal managers operating in other nodes with various terminal device driver access and fault tolerance functions. In addition, the purpose is to maximize the processing capabilities by separating the terminal-related work from the normal calculation processing.

Claims (7)

A first step of initializing the terminal driver after connecting the microkernel to a dedicated node for communication, and driving the control and general message handlers according to the work classification table in the request message processor whenever a request message arrives at the message transmission / reception point in the initialization state. And a third step of connecting the message to the write queue according to the control and the operation of the general message processor, controlling the stream manager and the transmission flow through the QFULL flag in the queue, and requesting the message transmission driver to execute. A fourth step of storing a message connected to a write queue in a message transmission driver in a terminal transmission buffer and generating an interrupt by setting an interruptible flag according to a request for execution of the control and general message processor; and an interrupt driven by the interrupt. In the terminal send buffer in the handler Transmitting a message from the asynchronous port to the asynchronous port receive buffer through the asynchronous port transmit buffer, and transmitting the data in the asynchronous port receive buffer to the terminal receive buffer using a scan driver. And a sixth step of constructing the data received in the terminal reception buffer in a message form according to the RQFULL state and transmitting the data to the stream manager. 2. The method of claim 1, wherein the first step comprises: performing a microkernel on a communication-only node, starting a message to initialize a message transmission / reception connection point; initializing a message transmission / reception point; Driving a processor; initializing a write queue, a terminal transmit / receive buffer, and an asynchronous transmit / receive buffer after driving the request message processor; drive a message transmission driver and a scan driver after performing the initialization; A method of driving a terminal device on a node dedicated to high-speed parallel computer communication, comprising the steps of: initializing the asynchronous port and ending execution after driving the message transmission driver and the scan driver. 2. The method of claim 1, wherein the second step is performed when the terminal driver is initialized to check for the presence of the request message, and if the request message does not exist according to a result of checking the existence of the request message, Waiting for execution until arrival, and if a request message exists or a request message arrives at a message transmission / reception access point through a microkernel operating on a communication dedicated node from a stream manager according to a result of checking the existence of the request message. Starting execution, receiving a request message arriving at the access point, extracting the contents of the job requested by the message, and checking the existence of the driver in accordance with the work division table according to the extraction result; According to the result of checking the presence of the driver in charge Requesting execution of the responsible handler if there is a refresher, and then checking whether another request message has arrived at the access point, and if the responsible handler does not exist according to a result of checking whether the responsible driver exists, returning an error. Checking whether another request message arrives at the access point, repeating the execution if another request message exists at the message transmission / reception connection point according to a result of the check of the access point, and requesting another request according to the result of the check of the access point. And waiting for execution if the message does not exist at the message transmission / reception connection point. The method as claimed in claim 1, wherein the third step comprises: starting execution according to a request for execution of the request message processor to check whether the control message requires emergency processing, and checking whether the control message requires emergency processing. If the control message requesting urgent processing according to the step of immediately processing and ending the execution, and if it is a control message requesting the urgent processing according to the result of checking whether it is a message if the other message; Checking whether the terminal state satisfies the request state of the processor in the case of the control message according to a result of checking whether it is a control message; if the terminal state is satisfied according to the test result of the terminal state, processing the control message and ending execution And not satisfying the terminal state according to the test result of the terminal state. Connecting the control message to the front of the write queue; and connecting the control message to the rear of the write queue in the order of arrival in the case of a normal message according to a check result of the control message. Comparing and checking whether the number of data in the write queue is greater than the high level value set for transmission flow control in the write queue, and the number of data in the write queue is greater than the high level value according to the comparison test result of the number of data in the write queue and the high level value. If the QFULL flag is set and the stream manager is requested to stop sending the message, and then the message sending driver is checked for waiting 1 and the number of data in the write queue according to the result of the comparison between the number of data in the write queue and the high level value is high. Checking if the message send driver is waiting 1 if smaller, and said mesh Requesting execution of the message transmission driver when the message transmission driver is in standby 1 and ending execution according to the result of checking whether the message transmission driver is in standby 1; and according to the result of checking that the message transmission driver is in standby 1, the message transmission driver is in standby. A method for driving a terminal device on a dedicated node for high speed parallel computer communication, comprising: terminating execution if not one. The method of claim 1, wherein the fourth step is performed when the terminal driver is initialized to check whether a write queue exists, and if the write queue does not exist according to a result of checking the existence of the write queue, Maintaining a state of Wait 1 until a message exists, and is requested to execute when a write queue exists or a message is connected to the write queue by a general and control message handler according to a result of checking the existence of the write queue. Starting, receiving the message at the beginning of the write queue at the beginning of the execution, comparing the number of messages queued in the write queue with a low level value determined for transmission flow control; Stream management when the number of messages in the queue is lower than the low level value as a result of comparing the low level value with the message in the write queue Informing the release of the previous message transmission stop request and checking if the message in the queue is a control message, and if the number of messages in the queue is greater than the low water value as a result of comparing the low water value with the message in the write queue. Checking whether the message in the terminal is a control message, checking whether the state of the terminal is satisfactory for execution according to a result of checking whether the message in the queue is a control message, and checking the terminal state. Processing a control message if the terminal satisfies the state of the terminal; and if the state of the terminal is not satisfied according to the result of the terminal state checking, storing the control message again at the beginning of the write queue and repeating the execution; If the message in the message is a normal message, Checking whether a terminal transmit buffer is empty; if the terminal transmit buffer is not empty according to a check result of the terminal transmit buffer, requesting an interrupt handler to execute in standby 2 state to exit the standby state; and If the terminal send buffer is empty according to the check result of the buffer, the message is stored in the terminal send buffer, the interruptible flag is set, and the operation goes back to the beginning, and if the write queue is empty, it waits 1; otherwise, repeats the above operation. A method of driving a terminal device on a dedicated node for high speed parallel computer communication. The method of claim 1, wherein the fifth step includes: performing execution when an interrupt occurs on the asynchronous port and checking whether the reception ready state is ready, and according to a result of checking the reception ready state, Storing the received data in an asynchronous port receiving buffer; and checking whether the receiving data is ready for transmission if it is not ready for receiving according to a result of checking the receiving ready state, and storing the data in the asynchronous receiving buffer. Comparing the number of times and the high water value set by the buffer, and requesting to stop transmitting data to the terminal when the number of data stored in the receiving buffer is greater than the high water value according to the result of comparing the number of data in the asynchronous receiving buffer with the high water value. And other data in the asynchronous port after requesting to stop transmitting data to the terminal. Checking whether there is any other data in the asynchronous port according to the result of checking the presence of other data in the asynchronous port, and repeating the execution of the data, and checking the presence of the other data in the asynchronous port. Checking whether the data is ready to be transmitted when no other data exists in the terminal; and when the data is ready to be transmitted according to the result of checking whether the data is ready to be transmitted, the data stored in the asynchronous transmission buffer Transmitting to the terminal; terminating execution if it is not ready to be transmitted according to the result of checking whether the ready to be transmitted state; and transmitting the data in the asynchronous buffer to the terminal, and clearing the interruptible flag. Setting and resetting the interruptible flag; Checking whether the state of the new driver is in standby 2; requesting execution and ending execution when the state of the message transmission driver is in standby 2 according to a test result of the message transmission driver; and checking the message transmission driver. And terminating the execution when the message transmission driver is not in standby state 2 according to the result. The method of claim 1, wherein the sixth step includes checking whether there is an extra space in the terminal receive buffer, and if there is no extra space in the terminal receive buffer according to a result of the check of the terminal receive buffer, the RQFULL flag. Checking whether the RQFULL flag is set or not, if the RQFULL flag is not set according to the result of the check if the RQFULL flag is set. Transmitting all data stored in the terminal receive buffer in the form of a message; and checking whether the data exists in the asynchronous receive buffer if there is extra space in the terminal receive buffer according to a result of the terminal receive buffer checking; RQFULL flag if data does not exist according to the asynchronous receive buffer check result Checking whether the RQFULL flag is set or not, if the RQFULL flag is set according to a result of checking whether the RQFULL flag is set, and ending the execution of the RQFULL flag. If it is reset, transmitting all the data stored in the buffer to the stream manager in the form of a message and ending the execution, and the data exists in the asynchronous receiving buffer according to the result of checking whether the data exists in the asynchronous receiving buffer. Moving the data to a terminal receive buffer, comparing the number of data stored in the asynchronous receive buffer with a low level value set for flow control with the terminal in the buffer, and the data of the asynchronous receive buffer. The number of data in the asynchronous receive buffer depends on the result of comparing the number to the low water value. If smaller, the terminal repeats the execution after notifying the previous data transmission stop request, and the number of data in the asynchronous receiving buffer is low according to the result of comparing the data number of the asynchronous receiving buffer with the low water level value. And repeating said execution if larger. The method of driving a terminal device on a dedicated node for high speed parallel computer communication.