Data transfer system and data transfer method

Abstract

In this data transfer system, a transmission node 100 transfers data to a plurality of reception nodes 200B, 200C by using RDMA. The transmission node 100 comprises: a delay measurement unit 32 that measures a delay when the transmission node transfers data to each of the plurality of reception nodes 200B, 200C, and manages delay information for each transmission destination; and a scheduling unit 31 that, on the basis of the delay information, assigns priority levels to transmission requests requesting transfer of data to the respective reception nodes 200B, 200C such that a higher priority level is assigned to a transmission destination having a shorter delay, and processes the transmission requests according to the priority levels.

Description

Data transfer system and data transfer method

[0001] The present disclosure relates to a data transfer system and a data transfer method.

[0002] Advances in Information and Communication Technology (ICT) are driving demand for applications requiring real-time performance, such as remote medical robots, as services that create new value. The jitter requirements for next-generation services are set to be the same as or three orders of magnitude lower than the communication latency (non-patent document 1).

[0003] Remote Direct Memory Access (RDMA) is a method for high-speed data transfer that reduces memory copies by bypassing the kernel. Native implementations of RDMA lack a scheduling function for transmitted data or a concept of data priority, resulting in differences in communication delays for each data item, making it difficult to meet the requirements of applications that require low-jitter communication (Non-Patent Document 2). In Non-Patent Document 2, data prioritization and a scheduling function that allows preemption of high-priority data are implemented on Soft-RoCE, and the system is applied to data communication between accelerators used in autonomous driving systems for automobiles, which require real-time performance.

[0004] 3GPP TS22.104 V1.0.0, "Service requirements for cyber-physical control applications in vertical domains," 2018-12H. Abaza et al., "RDMA-Based Deterministic Communication Architecture for Autonomous Driving," 2023 IEEE 29th International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA), Niigata, Japan, 2023, pp. 137-146

[0005] In a typical server environment, a server communicates with multiple nodes on a network. On the other hand, the scheduling method in Non-Patent Document 2 targets communication between accelerators with only one communication partner node, and does not consider whether the actually transmitted data satisfies the latency and jitter requirements. Therefore, it is effective only in an environment where the requirements can be met if the sender preferentially transmits high-priority packets.

[0006] In the method of Non-Patent Document 2, when multiple applications that require real-time performance run on a server and high-priority data transfer to different nodes is required, such as in a server environment in an edge data center, the jitter requirements of each application are not guaranteed. In an environment communicating with multiple nodes, a mechanism for prioritizing and scheduling that satisfies the jitter requirements of each application is required.

[0007] The present disclosure has been made in view of the above, and aims to provide prioritization and scheduling that meets the jitter requirements of each application in an environment in which communication is performed with multiple nodes.

[0008] A data transfer system according to one aspect of the present disclosure is a data transfer system in which a transmitting node transfers data to multiple receiving nodes using RDMA, and the transmitting node includes a delay measurement unit that measures the delay when transferring data to each of the multiple receiving nodes and manages delay information for each destination, and a scheduling unit that assigns priorities to transmission requests requesting data transfer from each of the multiple receiving nodes based on the delay information so that transmission requests with shorter delays have higher priority, and processes the transmission requests according to the priorities.

[0009] According to the present disclosure, it is possible to provide prioritization and scheduling that meets the jitter requirements of each application in an environment communicating with multiple nodes.

[0010] FIG. 1 is a diagram showing an example of the configuration of a data transfer system according to this embodiment. FIG. 2 is a flowchart showing an example of the flow of data transfer processing according to this embodiment. FIG. 3 is a diagram for explaining scheduling processing. FIG. 4 is a flowchart showing an example of the flow of scheduling processing. FIG. 5 is a diagram showing an example of the state of priority queues during scheduling processing. FIG. 6 is a diagram showing four priority queues. FIG. 7A is a flowchart showing an example of the flow of scheduling processing. FIG. 7B is a flowchart showing an example of the flow of scheduling processing. FIG. 8 is a diagram showing an example of the hardware configuration of a sending node.

[0011] [Data Transfer System] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings.

[0012] An example of the configuration of a data transfer system according to this embodiment will be described with reference to FIG. 1. The data transfer system shown in the figure includes a sending node 100 and multiple receiving nodes 200B and 200C. The sending node 100 and the receiving nodes 200B and 200C are connected via a network. Applications 150B and 150C run on the sending node 100, an application 250B runs on the receiving node 200B, and an application 250C runs on the receiving node 200C. Application 150B transfers data to application 250B, and application 150C transfers data to application 250C. The sending node 100 and the receiving nodes 200B and 200C are equipped with RDMA-compatible network interface cards (hereinafter referred to as RNICs) and transfer data (also referred to as messages) using RDMA. In this disclosure, RoCEv2 (RDMA over Converged Ethernet version 2) can be used as a protocol for implementing RDMA. Methods that can perform RDMA, such as Infiniband and iWARP, can also be applied.

[0013] The sending node 100 shown in FIG. 1 includes hardware such as an RNIC 11, a CPU 12, and a memory 13. A scheduling function 300 including a scheduling unit 31, a delay measurement unit 32, a session control unit 33, and a time reference unit 34 operates on software such as an OS 21, an RDMA general-purpose library 22, a time synchronization function 23, and a system clock 24. Applications 150B and 150C that require real-time performance can communicate with reduced jitter relative to latency by passing information about the transmission data and information about the destination node (receiving node 200B or 200C) to the scheduling function 300. The applications 150B and 150C may transfer data to the receiving node 200B or 200C using the RDMA general-purpose library 22. Each unit included in the scheduling function 300 will be described below.

[0014] The scheduling unit 31 assigns priorities to the transmission requests of the applications 150B and 150C (which may be data of the applications 150B and 150C or sessions used by the applications 150B and 150C) by referring to delay information for each session managed by the session control unit 33, and schedules the processing of the transmission requests so that the jitter requirements of each application 150B and 150C are satisfied. The scheduling unit 31 has multiple queues (hereinafter referred to as priority queues) with assigned priorities, and places the transmission requests of the applications 150B and 150C in the priority queues according to their priorities. The scheduling unit 31 passes the transmission requests placed in the priority queues in order of priority to the RNIC 11 and transfers the data.

[0015] In this embodiment, the requirements for applications requiring low-jitter communication generally tend to be such that the larger the latency requirement value, the larger the jitter requirement value. This utilizes the fact that data with long latency is more likely to tolerate larger jitter than data with short latency. After establishing a session with the receiving nodes 200B and 200C, the latency is measured, and priorities are assigned to each session based on the acquired delay information (latency, jitter, etc.), and scheduling is performed. This makes it possible to increase the number of applications requiring real-time performance (e.g., applications 150B and 150C running on the transmitting node 100) accommodated in the server. The scheduling method used by the scheduling unit 31 will be described in detail later.

[0016] In response to a request from the session control unit 33, the delay measurement unit 32 measures the latency when transferring data in a session established with the receiving nodes 200B and 200C, calculates delay information such as average latency and jitter, and returns the calculated information to the session control unit 33. In the present disclosure, latency refers to the difference in time between when the applications 150B and 150C prepare data in memory and are ready to transmit, and when the receiving nodes 200B and 200C receive all the data and are ready to process the data using the applications 250B and 250C. In other words, the latency refers to the time it takes for the OS 21 of the transmitting node 100 to perform the processing required for data transmission, send the data from the RNIC 11, and then for the OS to perform reception processing of the results via the RNICs of the receiving nodes 200B and 200C, and finally pass all the data to the applications 250B and 250C.

[0017] When determining the data transfer time (latency) required to transfer data from a sender to a receiver, there are generally two methods for measuring it: Round Trip Time (RTT) and timestamp.

[0018] In the RTT measurement method, the data to be transferred sent from the sender is returned from the receiver and the RTT is measured based on the arrival time. The sender stamps the time when sending starts (hereafter referred to as the sending timestamp) and the time when receiving ends (hereafter referred to as the receiving timestamp), and it is possible to measure latency from the difference between the sending timestamp and the receiving timestamp. One example is a method using ping using ICMP.

[0019] In the timestamp measurement method, the sender sends data with a transmission timestamp. After receiving all the data, the receiver saves the reception timestamp and can measure latency from the difference between the reception timestamp and the transmission timestamp attached to the data. In this case, the reference times of the sender and receiver must be synchronized.

[0020] Since the measurement method using timestamps is more accurate than the measurement method using RTTs, the measurement method using timestamps is used in this embodiment.

[0021] For example, the delay measurement unit 32 acquires a transmission timestamp when transmitting a message for latency measurement, and transfers the message with the transmission timestamp to the receiving nodes 200B, 200C using the established session. The receiving nodes 200B, 200C acquire a reception timestamp when all messages are received. The receiving nodes 200B, 200C transmit the difference between the transmission timestamp and the reception timestamp as the latency to the delay measurement unit 32. The receiving nodes 200B, 200C include a delay measurement unit 32, a session control unit 33, and a time reference unit 34 for measuring latency. It is assumed that time synchronization between the sending node 100 and the receiving nodes 200B, 200C is complete when delay measurement is performed.

[0022] The delay measurement unit 32 measures latency for different message sizes and RDMA transfer methods (RDMA WRITE, RDMA SEND / RECV, etc.), and calculates delay information such as average latency, worst-case latency, and jitter for each message size and each RDMA transfer method.

[0023] The session control unit 33 manages delay information for each session in addition to the function of starting and ending a session using the RDMA general-purpose library 22. The session control unit 33 establishes a session based on information such as the destination IP address and port number from the applications 150B and 150C. In this embodiment, the session is established using rdma-cm (communication manager), but this is not limiting.

[0024] After establishing a session, the session control unit 33 requests the delay measurement unit 32 to measure delay information for that session. The session control unit 33 manages the obtained delay information for each session.

[0025] The time reference unit 34 performs time synchronization with the receiving nodes 200B, 200C, measures delays, and provides a clock referenced by the scheduling unit 31. The time reference unit 34 acquires timestamps by referencing the system clock 24 or the hardware clock (HWC) 111. Either the system clock 24 or the hardware clock (HWC) 111 may be used to acquire timestamps. Generally, referring to the system clock 24 imposes a smaller load, and therefore in this embodiment, the timestamps are acquired by referencing the system clock 24.

[0026] For example, Precision Time Protocol (PTP) can be used to synchronize the time between the sending node 100 and the receiving nodes 200B, 200C. Time synchronization is performed with the sending node 100 as the master and the receiving nodes 200B, 200C as slaves. The time synchronization method is not limited to this, and other methods may be used to synchronize the time between the sending node 100 and the receiving nodes 200B, 200C.

[0027] [Data Transfer Processing] An example of the flow of data transfer processing will be described with reference to the flowchart of FIG.

[0028] In step S11, the applications 150B and 150C pass information for establishing a session (for example, the IP address of the connection destination) to the session control unit 33, and the session control unit 33 establishes a session with the connection destination.

[0029] In step S12, the session control unit 33 requests the delay measurement unit 32 to measure the delay. The delay measurement unit 32 measures the delay of the established session and returns the delay information to the session control unit 33. The session control unit 33 manages the delay information for each session.

[0030] In step S13, the scheduling unit 31 assigns a priority to the data of each session based on the delay information, and sets the size of each priority queue.

[0031] When the scheduling is set, in step S14, the applications 150B and 150C pass transmission requests including information about the data to be transmitted to the scheduling unit 31. The scheduling unit 31 places the transmission requests of the applications 150B and 150C in priority queues according to the priorities. The scheduling unit 31 extracts the transmission requests from the priority queues according to the priorities of the priority queues, passes them to the RNIC 11, and transfers the data.

[0032] When the data transfer is completed in step S15, the session control unit 33 terminates the session established with the connection destination.

[0033] [Scheduling Process] Next, a description will be given of the scheduling by the scheduling unit 31. It is assumed that the delay measurement by the delay measurement unit 32 has been completed and delay information has been obtained.

[0034] A diagram for explaining the scheduling process is shown in Fig. 3. In the example of Fig. 3, the scheduling unit 31 has two priority queues: a high-priority queue HP and a low-priority queue LP.

[0035] The scheduling unit 31 references the delay information and determines the priority queues HP and LP to which the transmission requests of the applications 150B and 150C are allocated based on the measured latency. The scheduling unit 31 assumes that the jitter requirement of an application with high latency (long delay) is lower than the jitter requirement of an application with low latency (small delay), and allocates the application with low latency to the high-priority priority queue HP and the application with high latency to the low-priority priority queue LP. For example, if the link speed is 100 Gbps and the latency of the application 150B is 100 μs and the latency of the application 150C is 500 μs, the scheduling unit 31 assumes that the jitter requirement of the application 150B is 10 μs and the jitter requirement of the application 150C is 50 μs. The scheduling unit 31 allocates the application 150B, which has a high jitter requirement, to the priority queue HP and the application 150C to the priority queue LP.

[0036] Furthermore, to avoid the problem of increased jitter (head-of-line blocking) caused by transmission requests with large message sizes, the scheduling unit 31 sets a maximum message size for transmission requests placed in each priority queue. A transmission request for data exceeding the maximum message size is divided into transmission requests for data of the maximum message size when placed in a priority queue. For example, the scheduling unit 31 determines the maximum message size to be set for each priority queue based on the jitter requirements of the other queue. Specifically, the scheduling unit 31 sets the maximum message size of the priority queue LP to 1 Mbit corresponding to the jitter requirement of 10 μs for application 150B, and sets the maximum message size of the priority queue HP to 5 Mbit corresponding to the jitter requirement of 50 μs for application 150C. Transmission requests from applications 150B and 150C for data exceeding the maximum message size of each priority queue HP and LP are divided into multiple transmission requests and placed in each priority queue HP and LP. The message sizes of the divided transmission requests are each within the maximum message size.

[0037] The scheduling unit 31 performs scheduling that allows preemption (high-priority message transmission can interrupt low-priority message transmission). Specifically, when a transmission request is queued in the priority queue HP, the scheduling unit 31 basically processes the request in the priority queue HP. If the message size of the processed priority queue HP exceeds a threshold, the scheduling unit 31 processes the request in the priority queue LP. For example, the threshold is calculated using the following formula:

[0038] Threshold (B) = LP jitter requirement (s) x link speed (bps) / 8

[0039] The scheduling unit 31 issues requests to the RNIC 11 for transmission requests for the priority queues HP and LP to be processed in units called Work Requests (WR). The WRs of transmission requests are placed in a Send Queue (SQ). The WRs placed in the SQ are called Work Queue Elements (WQE). The RNIC 11 retrieves the WQEs in order according to FIFO and performs data transfer processing based on the WQEs.

[0040] Next, an example of the flow of scheduling processing by the scheduling unit 31 having the priority queues HP and LP will be described with reference to the flowchart in Fig. 4. It is assumed that transmission requests are input to each of the priority queues HP and LP.

[0041] In step S101, the scheduling unit 31 processes a transmission request in the priority queue HP. Processing a transmission request means issuing a transmission request to the RNIC 11 based on the transmission request. The processed transmission request is removed from the priority queue HP.

[0042] In step S102, the scheduling unit 31 adds the message size transferred in the processed transmission request to the variable lp, and if the variable lp is greater than a threshold, sets the L flag. The variable lp is a variable associated with the priority queue LP. When a transmission request in another priority queue is processed, a value equal to the message size transferred in the processed transmission request is added to the variable lp.

[0043] In step S103, the scheduling unit 31 determines whether or not the L flag of the priority queue LP is set.

[0044] If the L flag is not set, the process returns to step S101, and the scheduling unit 31 processes the transmission request in the priority queue HP.

[0045] If the L flag is set, the scheduling unit 31 determines in step S104 whether or not a transmission request exists in the priority queue LP.

[0046] If there is no transmission request in the priority queue LP, the process returns to step S101, and the scheduling unit 31 processes the transmission request in the priority queue HP.

[0047] If there is a transmission request in the priority queue LP, in step S105 the scheduling unit 31 clears the L flag and subtracts the threshold value from the variable lp.

[0048] In step S106, the scheduling unit 31 processes the transmission request of the priority queue LP.

[0049] In step S107, the scheduling unit 31 determines whether or not a transmission request exists in the priority queue HP.

[0050] If there is a transmission request in the priority queue HP, the process returns to step S101, and the scheduling unit 31 processes the transmission request in the priority queue HP.

[0051] If there is no transmission request in the priority queue HP, the process returns to step S105, and the scheduling unit 31 processes the transmission request in the priority queue LP.

[0052] Through the above processing, the transmission request of the priority queue HP is processed preferentially, and when the transmission request of the priority queue HP transfers data equal to or greater than the threshold, the transmission request of the priority queue LP is processed.

[0053] An example of the scheduling process will be described with reference to the state of the priority queues in Fig. 5. In the example of Fig. 5, a priority queue HP, a priority queue LP, and a variable lp associated with the priority queue LP are illustrated.

[0054] In the state shown in Figure 5(a), there are three transmission requests in the priority queue HP and two transmission requests in the priority queue LP. The variable lp is empty. In the state shown in Figure 5(a), the L flag is not set, so the transmission request in the priority queue HP is processed.

[0055] When a transmission request in the priority queue HP is processed in the state shown in Fig. 5(a), the transmission request is removed from the priority queue HP and the value of the transferred message size is added to the variable lp, as shown in Fig. 5(b). In the state shown in Fig. 5(b), the L flag is not set, so the transmission request in the priority queue HP is processed.

[0056] When a transmission request in the priority queue HP is processed in the state shown in Figure 5(b), the transmission request is removed from the priority queue HP and the value of the transferred message size is added to the variable lp, as shown in Figure 5(c). Since the variable lp is full, the L flag is set. In the state shown in Figure 5(c), the L flag is set, so the transmission request in the priority queue LP is processed.

[0057] When a transmission request in the priority queue LP is processed in the state shown in Fig. 5(c), the transmission request is removed from the priority queue LP, the L flag is cleared, and the threshold value is subtracted from the variable lp, as shown in Fig. 5(d). In the state shown in Fig. 5(d), the L flag is not set, so the transmission request in the priority queue HP is processed.

[0058] When a transmission request in the priority queue HP is processed in the state shown in Fig. 5(d), the transmission request is removed from the priority queue HP and the value of the transferred message size is added to the variable lp, as shown in Fig. 5(e). In the state shown in Fig. 5(e), the L flag is set, so the transmission request in the priority queue LP is processed.

[0059] Next, an example of the scheduling process of the scheduling unit 31 having four priority queues HP, MP, LP, and BE as shown in FIG. 6 will be described.

[0060] In the example of Figure 6, the priority is highest in the priority queue HP, followed by the priority queue MP, the priority queue LP, and the priority queue BE. In other words, the priority queue HP has the highest priority, and the priority queue BE has the lowest priority. The priority queues MP and LP are associated with variables mp and lp. A transmission request is processed in the priority queues MP and LP when the variables mp and lp are full. No variables are associated with the priority queue BE. A transmission request is processed in the priority queue BE when there are no transmission requests in the other priority queues HP, MP, and LP.

[0061] An example of the scheduling process of the scheduling unit 31 having four priority queues HP, MP, LP, and BE will be described with reference to the flowcharts of FIGS. 7A and 7B.

[0062] In step S201, the scheduling unit 31 processes a transmission request in the priority queue HP.

[0063] In step S202, the scheduling unit 31 adds the message size transferred in the processed transmission request to the variables mp and lp, and sets the M flag or the L flag if the variable mp or the variable lp is greater than the threshold value.

[0064] In step S203, the scheduling unit 31 determines whether the M flag or the L flag is set.

[0065] If the M flag or the L flag is set, the scheduling unit 31 proceeds to step S211 in FIG. 7B.

[0066] If neither the M flag nor the L flag is set, the scheduling unit 31 determines in step S204 whether or not a transmission request exists in the priority queue HP.

[0067] If there is a transmission request in the priority queue HP, the process returns to step S201, and the scheduling unit 31 processes the transmission request in the priority queue HP.

[0068] If there is no transmission request in the priority queue HP, the scheduling unit 31 determines in step S205 whether there is a transmission request in the priority queue MP.

[0069] If there is a transmission request in the priority queue MP, the process proceeds to step S213 in FIG. 7B, where the transmission request in the priority queue MP is processed.

[0070] If there is no transmission request in the priority queue HP, the scheduling unit 31 determines in step S206 whether there is a transmission request in the priority queue LP.

[0071] If there is a transmission request in the priority queue LP, the process proceeds to step S216 in FIG. 7B, where the transmission request in the priority queue LP is processed.

[0072] If there is no transmission request in the priority queue LP, the scheduling unit 31 determines in step S207 whether there is a transmission request in the priority queue BE.

[0073] If there is no transmission request in the priority queue BE, the scheduling unit 31 proceeds to step S210.

[0074] If there is a transmission request in the priority queue BE, the transmission request in the priority queue BE is processed in step S208.

[0075] In step S209, the scheduling unit 31 adds the message size transferred in the processed transmission request to the variables mp and lp, and sets the M flag or the L flag if the variable mp or the variable lp is greater than the threshold value.

[0076] In step S210, the scheduling unit 31 determines whether or not a transmission request exists in the priority queue HP.

[0077] If there is a transmission request in the priority queue HP, the process returns to step S201, and the scheduling unit 31 processes the transmission request in the priority queue HP.

[0078] If there is no transmission request in the priority queue HP, the process returns to step S203, where the scheduling unit 31 checks the M flag or the L flag.

[0079] If it is determined in step S203 that the M flag or the L flag is set, the scheduling unit 31 determines in step S211 of FIG. 7B whether or not the M flag is set.

[0080] If the M flag is set, in step S212, the scheduling unit 31 clears the M flag and subtracts a threshold value from the variable mp.

[0081] In step S213, the scheduling unit 31 processes the transmission request of the priority queue MP.

[0082] In step S214, the scheduling unit 31 adds the message size transferred in the processed transmission request to the variable lp, and if the variable lp is greater than the threshold, sets the L flag.

[0083] Thereafter, the scheduling unit 31 advances the process to step S210 in FIG. 7A.

[0084] The processes of steps S213 and S214 are also executed when it is determined in step S205 of FIG. 7A that a transmission request exists in the priority queue MP.

[0085] On the other hand, if the M flag is not set, the scheduling unit 31 clears the L flag and subtracts the threshold value from the variable lp in step S215.

[0086] In step S216, the scheduling unit 31 processes the transmission request of the priority queue LP.

[0087] In step S217, the scheduling unit 31 adds the message size transferred in the processed transmission request to the variable mp, and if the variable mp is greater than the threshold, sets the M flag.

[0088] Thereafter, the scheduling unit 31 advances the process to step S210 in FIG. 7A.

[0089] The processes of steps S216 and S217 are also executed when it is determined in step S206 of FIG. 7A that a transmission request exists in the priority queue LP.

[0090] As described above, the data transfer system of this embodiment is a data transfer system in which the sending node 100 transfers data to multiple receiving nodes 200B, 200C using RDMA. The sending node 100 includes a delay measurement unit 32 that measures the delay when transferring data to each of the multiple receiving nodes 200B, 200C and manages delay information for each destination, and a scheduling unit 31 that assigns priorities to transmission requests that request data transfer to each of the multiple receiving nodes 200B, 200C based on the delay information so that transmission destinations with shorter delays have higher priority, and processes the transmission requests according to the priorities. This makes it possible to perform communication with reduced jitter relative to latency.

[0091] The above-described sending node 100 can be, for example, a general-purpose computer system including a central processing unit (CPU) 901, a memory 902, a storage 903, a communication device 904, an input device 905, and an output device 906, as shown in Fig. 8. In this computer system, the sending node 100 is realized by the CPU 901 executing a predetermined program loaded onto the memory 902. This program can be recorded on a computer-readable non-transitory recording medium such as a magnetic disk, an optical disk, or a semiconductor memory, or can be distributed via a network.

[0092] 100 Sending node 200B, 200C Receiving node 11 RNIC 12 CPU 13 Memory 111 Hardware clock (HWC) 21 OS 22 RDMA general-purpose library 23 Time synchronization function 24 System clock 300 Scheduling function 31 Scheduling unit 32 Delay measurement unit 33 Session control unit 34 Time reference unit

Claims

1. A data transfer system in which a sending node transfers data to multiple receiving nodes using RDMA, wherein the sending node comprises: a delay measurement unit that measures the delay when transferring data to each of the multiple receiving nodes and manages delay information for each destination; and a scheduling unit that assigns priorities to transmission requests requesting data transfer to each of the multiple receiving nodes based on the delay information so that transmission requests with shorter delays have higher priority, and processes the transmission requests according to the priorities.

2. A data transfer system according to claim 1, wherein the scheduling unit has a plurality of queues with priorities assigned, places the transmission requests in the queues according to their priorities, and processes the transmission requests in the queues with the highest priorities first.

3. A data transfer system according to claim 2, wherein the scheduling unit sets a maximum message size for transmission requests to be submitted to each of the queues, and divides a transmission request requesting the transfer of data exceeding the maximum message size into multiple transmission requests and submits them to the queues.

4. A data transfer system according to claim 3, wherein the maximum message size of the queue is determined based on the jitter requirements of the destinations of the other queues.

5. A data transfer system according to claim 2, wherein the scheduling unit processes a transmission request from a low priority queue each time the total size of data transferred after processing a transmission request from a high priority queue exceeds a threshold.

6. A data transfer method in which a sending node transfers data to multiple receiving nodes using RDMA, wherein the sending node measures the delay when transferring data to each of the multiple receiving nodes, manages delay information for each destination, and based on the delay information, assigns priorities to transmission requests requesting data transfer to each of the multiple receiving nodes so that transmission requests with shorter delays have higher priority, and processes the transmission requests according to the priorities.

Images