Accelerator state control device, accelerator state control system, accelerator state control method and program

Abstract

Provided is an accelerator state control device (100) having a plurality of accelerators (12) differing in processing performance, the accelerator state control device (100) controlling the state of an accelerator (12) when offloading the specific processing of an application (1) to the accelerator and performing computation processing, wherein the accelerator state control device (100) comprises: a computation device performance collecting / recording unit (110) that collects and records performance information pertaining to the accelerators (12) when data in which different processing deadlines coexist is inputted; a traffic volume / processing deadline prediction unit (150) that predicts a traffic volume and a processing deadline after the elapse of a prescribed time, from the ratio of present and past traffic volumes and processing deadlines; and a computation device allocation determination unit (130) that, on the basis of the predicted traffic volume and processing deadline after the elapse of the prescribed time and the recorded performance of the accelerators (12), derives a data volume corresponding to the processing deadline and determines an accelerator that satisfies performance on the basis of the data volume.

Description

[Technical Field]

[0001] The present invention relates to an accelerator state control device, an accelerator state control system, an accelerator state control method, and a program. [Background technology]

[0002] Different types of processors excel at different workloads (high processing power). While general-purpose central processing units (CPUs) are capable of handling highly parallel workloads that CPUs struggle with (low processing power), accelerators such as field programmable gate arrays (FPGAs), graphics processing units (GPUs), and application-specific integrated circuits (ASICs) (hereafter referred to as ACCs) can handle these workloads with high speed and efficiency. By combining these heterogeneous processors and offloading workloads that CPUs struggle with to the ACCs, offloading these workloads is becoming increasingly common, improving overall computing time and efficiency.

[0003] In vRAN (virtual Radio Access Network), when the CPU alone does not have enough performance to meet the requirements, some processing is offloaded to accelerators capable of high-speed calculations such as FPGAs and GPUs. Typical examples of workloads that are subject to ACC offloading include encoding / decoding processing (FEC: Forward Error Correction processing) in vRAN, audio and video media processing, and encryption / decryption processing.

[0004] In computer systems, a computer (hereafter referred to as an accelerator-equipped server) may be configured to have hardware (CPU) capable of general-purpose processing and hardware (accelerator) specialized for specific calculations, with some calculation processing offloaded from the general-purpose processor running the software to the accelerator.

[0005] Furthermore, with the advancement of cloud computing, it is becoming common to simplify the configuration of client machines by offloading some of the computationally intensive processing from client machines deployed at user sites to servers at remote sites (such as data centers located near the users) via a network (NW).

[0006] Fig. 14 is a diagram illustrating a computer system, in which arrows indicate the flow of data. As shown in FIG. 14, the server 50 is equipped with a CPU 11 on hardware 10, multiple accelerators (high performance) 12-1 and 12-2 with different processing capabilities, and an input / output unit 13, and is provided with an application (hereinafter referred to as APL) 1 of software 20 that runs on the CPU 11 on the server 50.

[0007] The application 1 calls a set of functions (API) defined as a standard and offloads part of the processing to the accelerator 12.

[0008] In this specification, a configuration that allows the use of multiple accelerators with different processing capabilities is referred to as a "heterogeneous performance configuration." Figure 14 shows a heterogeneous configuration with an accelerator (high performance) 12-1 with high processing capabilities and an accelerator (low performance) 12-2 with low processing capabilities. When there is no need to distinguish between the accelerator (high performance) 12-1 and the accelerator (low performance) 12-2, they are collectively referred to as accelerators 12. The accelerator 12 is a calculation accelerator device such as an FPGA / GPU, etc. The accelerator 12 has an accelerator arithmetic circuit or program, and performs calculations using the accelerator arithmetic circuit or program. The input / output unit 13 receives and outputs input data.

[0009] The server 50 receives input data from the outside, performs calculation processing within the server, and then outputs the data to the outside. The server 50 has assumptions regarding the input data. (1) The amount of input data fluctuates over time, for example, in the case of sudden traffic when an event occurs in a Radio Access Network (RAN). (2) Different input data have different processing deadlines. For example, processing deadlines are set for Ultra-Reliable and Low Latency Communications (URLLC) traffic (ultra-low latency) and enhanced Mobile Broadband (eMBB) traffic (low to medium latency requirements) in 5G NR. Also, in 5G NR, URLLC traffic (ultra-low latency) and eMBB traffic (low to medium latency requirements) coexist.

[0010] Fig. 15 is a diagram illustrating fluctuations in the amount of input data to the server 50 and the breakdown of processing deadlines. The solid line in Fig. 15 indicates the total traffic amount, and the dashed line in Fig. 15 indicates the traffic amount with a short processing deadline. In Fig. 15, the areas where the traffic amount is high are sudden traffic. An example of sudden traffic is caused by an event in the RAN system that increases traffic in a certain area (for example, a fireworks display).

[0011] In the server 50, the requirements for meeting the processing deadline for each piece of input data whose amount varies over time are as follows: Requirement 1: [Meeting the processing deadline for each data item] When input data has a mixture of different processing deadlines, processing on the server must be completed within a certain time from input so that each deadline is met. Requirement 2: [Scalability] Processing performance can be scaled according to the amount of input traffic.

[0012] In an accelerator-equipped server, the following techniques are available for allocating accelerators to traffic of a certain volume and a certain percentage of the processing deadline.

[0013] [Allocation of accelerators for traffic with a percentage of the processing deadline] First, we will discuss a technology for fixedly allocating accelerators to accelerator-equipped servers, targeting traffic that is a proportion of the processing deadline (Non-Patent Document 1).

[0014] [Existing technology 1] 16 is a diagram for explaining static accelerator allocation in existing technology 1 (Non-Patent Document 1). The same components as in FIG. 14 are assigned the same reference numerals. As shown in Figure 16, the server 50 is equipped with a CPU 11 on hardware 10, multiple accelerators (high performance) 12-1 and accelerators (low performance) 12-2 with different processing capabilities, and has an application 1 of software 20 running on the CPU 11 on the server 50. The server 50 allocates an accelerator in a fixed manner for traffic of a certain volume and a certain proportion of the processing deadline (double line a in FIG. 18). In FIG. 16, a fixed allocation is performed in which the accelerator (high performance) 12-1 is allocated to the application 1. The processing deadline for each input data is designed to be a fixed value.

[0015] Existing technology 1 has characteristics that satisfy / do not satisfy the following requirements. <Requirement 1: Meeting the processing deadline for each piece of data> The processing deadline for each piece of input data is designed on the assumption that it is a fixed value, and the input data will never exceed the fixed value, so "fulfilling the processing deadline for each piece of data" is conditionally met. <Requirement 2: Scalability> The amount of resources is fixed, and the accelerator does not satisfy the "scalability" of scaling out / in.

[0016] Fig. 17 is a diagram for explaining fluctuations in the amount of input data in Existing Technique 1. The solid line in Fig. 17 indicates the total traffic amount, and the dashed line in Fig. 17 indicates the traffic amount at which the system can ensure responsiveness. As shown in FIG. 17, the traffic volume (dashed line in FIG. 17) at which the system can ensure responsiveness is constant. In existing technology 1, accelerators are statically allocated according to the maximum amount of traffic during normal times. As a result, when the amount of input data suddenly increases, the processing capacity becomes insufficient (white arrow b in Figure 17).

[0017] Next, we will discuss a technology that uses function proxies to achieve ACC scaling in accelerator-equipped servers (Non-Patent Document 1).

[0018] [Existing technology 2] Fig. 18 is a diagram for explaining the realization of scaling of ACC by function proxies in existing technique 2. The same components as in Fig. 14 are assigned the same reference numerals. 18, in the server 50, the software 20 includes proxy software 2. The proxy software 2 includes a function proxy 3 and an accelerator I / O control unit 4 that controls input and output to and from the accelerator via the function proxy 3. The server 50 dynamically allocates accelerators by scaling out using the function proxy 3 for ACC-using functions (double line c in Figure 18). In Figure 18, the proxy software 2 dynamically allocates the processing of application 1 to accelerator (high performance) 12-1 or accelerator (low performance) 12-2.

[0019] Existing technology 2 has characteristics that satisfy / do not satisfy the following requirements. <Requirement 1: Meeting the processing deadline for each piece of data> Because ACC performance is not taken into consideration, responsiveness is not met when the proportion of traffic that requires low latency processing increases. <Requirement 2: Scalability> It is possible to scale out according to traffic volume.

[0020] Fig. 19 is a diagram explaining the processing deadline in Existing Technology 2. The solid line in Fig. 19 indicates the total traffic volume, the dashed line in Fig. 19 indicates the traffic volume with a short processing deadline, and the double line in Fig. 19 indicates the traffic volume at which responsiveness can be ensured. As shown by the white arrow c in Figure 19, there are moments when the allocated ACC cannot meet the deadline. In particular, as the proportion of traffic requiring low latency processing increases, responsiveness is not met. [Prior art documents] [Non-patent literature]

[0021] [Non-Patent Document 1] "16.2. Assigning PCI Devices Using SR-IOV Devices Red Hat Enterprise Linux 7 | Red Hat Customer Portal", [online], [Retrieved July 6, 2022], Internet〈URL:https: / / access.redhat.com / documentation / ja-jp / red_hat_enterprise_linux / 7 / html / virtualization_deployment_and_administration_guide / sect-pci_devices-pci_passthrough〉 Summary of the Invention [Problem to be solved by the invention]

[0022] Existing technologies 1 and 2 have the following issues: Existing technology 1 (static allocation) has the problem that the amount of accelerator resources is fixed, and does not satisfy <Requirement 2: scalability>. Existing technology 2 (scaling out using function proxies) does not take into account the performance differences between individual accelerators, and therefore has the problem of not meeting requirement 1: meeting the processing deadline for each piece of data.

[0023] The present invention was made in light of this background, and its objective is to reduce the amount of computing resources used in a heterogeneous accelerator-equipped server while ensuring responsiveness in response to fluctuations in the amount of data corresponding to each processing deadline. [Means for solving the problem]

[0024] In order to solve the above-mentioned problems, the present invention provides an accelerator state control device that has a plurality of accelerators with different processing performance and controls the state of the accelerators when specific processing of an application is offloaded to the accelerators for computational processing, the accelerator state control device comprising: a recording unit that collects and records performance information of the accelerators when data with different processing deadlines is input; a prediction unit that predicts the traffic volume and processing deadline after a predetermined time has elapsed based on the ratio of current and past traffic volume and processing deadline; and a judgment unit that calculates the data volume corresponding to the processing deadline based on the traffic volume and processing deadline after the predetermined time has elapsed predicted by the prediction unit and the performance of the accelerators recorded in the recording unit, and judges an accelerator that meets the performance based on the data volume. [Effects of the Invention]

[0025] According to the present invention, it is possible to reduce the amount of computing resources used while ensuring responsiveness in response to fluctuations in the amount of data corresponding to each processing deadline. [Brief explanation of the drawings]

[0026] [Figure 1] 1 is a schematic configuration diagram of an accelerator state control system according to an embodiment of the present invention; [Figure 2] 1 is a schematic configuration diagram of an accelerator state control system according to an embodiment of the present invention; [Figure 3] 1 is a schematic configuration diagram showing variations in the arrangement of an accelerator state control device of an accelerator state control system according to an embodiment of the present invention. FIG. [Figure 4] FIG. 2 is a diagram showing an example of a DB table of an accelerator state control device of the accelerator state control system according to the embodiment of the present invention. [Figure 5] FIG. 2 is a diagram illustrating an example of a latency table of an accelerator state control device of the accelerator state control system according to the embodiment of the present invention. [Figure 6] 10 is a diagram showing an example of the configuration of an ACC function / argument data packet of the accelerator state control device of the accelerator state control system according to the embodiment of the present invention. FIG. [Figure 7] FIG. 10 is a diagram showing an example of calculation of an available ACC list from Host-1 in the accelerator state control system according to the embodiment of the present invention. [Figure 8] 4 is a flowchart showing operation 1 of a calculation unit allocation determination unit and a traffic volume / processing deadline prediction unit of the accelerator state control system according to the embodiment of the present invention. [Figure 9] 10 is a flowchart showing operation 2 of the arithmetic unit allocation determination unit and the traffic volume / processing deadline prediction unit of the accelerator state control system according to the embodiment of the present invention. [Figure 10] 4 is a flowchart showing arithmetic unit allocation (ACC allocation) of an accelerator state control device of the accelerator state control system according to the embodiment of the present invention. [Figure 11A] 4 is a flowchart illustrating input data processing of the accelerator state control system according to the embodiment of the present invention. [Figure 11B]4 is a flowchart illustrating input data processing of the accelerator state control system according to the embodiment of the present invention. [Figure 11C] 4 is a flowchart illustrating input data processing of the accelerator state control system according to the embodiment of the present invention. [Figure 12A] 4 is a flowchart illustrating input data processing of the accelerator state control system according to the embodiment of the present invention. [Figure 12B] 4 is a flowchart illustrating input data processing of the accelerator state control system according to the embodiment of the present invention. [Figure 12C] 4 is a flowchart illustrating input data processing of the accelerator state control system according to the embodiment of the present invention. [Figure 13] FIG. 2 is a hardware configuration diagram illustrating an example of a computer that realizes the functions of the accelerator state control system according to the embodiment of the present invention. [Figure 14] FIG. 1 is a diagram illustrating a computer system. [Figure 15] 10A and 10B are diagrams illustrating variations in the amount of input data to a server and the breakdown of processing deadlines. [Figure 16] FIG. 1 is a diagram illustrating static accelerator allocation in existing technology 1 (Non-Patent Document 1). [Figure 17] FIG. 10 is a diagram illustrating fluctuations in the amount of input data in the existing technique 1. [Figure 18] FIG. 10 is a diagram illustrating the realization of scaling of ACC using function proxies in existing technology 2. [Figure 19] FIG. 10 is a diagram illustrating a processing deadline in the existing technique 2. DETAILED DESCRIPTION OF THE INVENTION

[0027] An accelerator state control system and the like in an embodiment for carrying out the present invention (hereinafter referred to as "the present embodiment") will be described below with reference to the drawings. (Embodiment) [overview] Figure 1 is a schematic diagram of an accelerator state control system according to an embodiment of the present invention. Figure 1 shows an example of application to a Look-Aside accelerator, in which data obtained via an input / output unit such as a NIC is explicitly offloaded from the CPU to the accelerator. In the Look-Aside accelerator, the CPU offloads part of the processing to the accelerator. In a Look-Aside accelerator, the CPU manages the state.

[0028] As shown in FIG. 1, the accelerator state control system 1000 includes a server 200 (signal processing device), a remote offload server 210, an antenna device 220, and a post-processing device 230. The accelerator state control system 1000 also includes an accelerator state control device 100 that controls the state of the accelerator 12 when specific processing of the application 1 is offloaded to the accelerator 12 for calculation processing.

[0029] [Server 200] Server 200 is a distributed unit in 5G signal processing. The server 200 includes hardware (HW) 10 and software 20.

[0030] Hardware 10 The hardware 10 includes a CPU (Central Processing Unit) 11, multiple accelerators (high performance) 12-1 and 12-2 with different processing capabilities, an accelerator 12, an input / output unit 13, and a remote offload input / output unit (client) (NIC) 14.

[0031] <cpu11> The CPU 11 executes the processing of the application 1 and also executes the software of each functional unit in the server 200 .

[0032] <Accelerator 12> The accelerator 12 is a calculation accelerator device such as an FPGA / GPU. The accelerator 12 is a computing machine specialized for a specific process that is installed in the server 200. The accelerator 12 may be connected to the CPU 11 via a bus in the form of an ASIC-equipped accelerator, an FPGA-equipped accelerator, a GPU, or the like.

[0033] This embodiment uses a "heterogeneous performance configuration" that allows the use of a plurality of accelerators with different processing capabilities. The plurality of accelerators with different processing capabilities are accelerator (high performance) 12-1 and accelerator (low performance) 12-2.

[0034] <Input / output section 13> The input / output unit 13 is an input / output mechanism such as a NIC (Network Interface Card), and performs data input / output with external devices (the antenna device 220 and the post-processing device 230). The input / output unit 13 also has an interface that notifies the application 1 of the current amount of data input.

[0035] <Remote offload input / output unit 14> The remote offload input / output unit (client) (NIC) 14 and the remote offload input / output unit (server) (NIC) 14 are network interface devices typified by NICs, and are functional units that perform communication between servers.

[0036] "Software 20" The software 20 includes an application 1 and an accelerator state control device 100 that controls the state of the accelerator.

[0037] <Application 1> Application 1 is a program that performs signal processing and runs on CPU 11. Dedicated processing that is not suitable for a CPU, such as some parallel computation processing, is offloaded to accelerator 12 (accelerator (high performance) 12-1, accelerator (low performance) 12-2, accelerator (high performance) 12-3). For example, application 1 calls a set of functions (API) defined as a standard and offloads some of the processing to accelerator 12.

[0038] Input / Output The application 1 receives, as input, data to be processed from the input / output unit 13. As output, the application 1 passes calculated data to the input / output unit 13.

[0039] Modifications In this embodiment, the input / output unit 13, the CPU 11, and the accelerator 12 are configured as separate hardware components, but they may also be integrated into a dedicated hardware configuration. In addition to the so-called Look-Aside type accelerator application form in which "data obtained via an input / output unit 13 such as a NIC is explicitly offloaded from the CPU 11 to the accelerator 12" as in this embodiment, a so-called In-line type accelerator application form may also be used in which "NIC, accelerator, and CPU 11" are integrated into hardware, and processing is completed within the same hardware after data is received by the NIC.

[0040] [Accelerator state control device 100] The accelerator state control device 100 includes a computing device performance collection and recording unit 110, a remote offload latency collection and recording unit 120 (latency recording unit), a computing device allocation determination unit 130, a data processing deadline determination unit 140, a traffic volume and processing deadline prediction unit 150, a function proxy execution unit 160, a computing device allocation unit 170, and a remote offload unit 180. The arithmetic unit performance collection and recording unit 110, remote offload latency collection and recording unit 120, and arithmetic unit allocation determination unit 130 constitute an allocation determination function unit 101. The data processing deadline determination unit 140 and traffic volume and processing deadline prediction unit 150 constitute a prediction function unit 102. The function proxy execution unit 160 and arithmetic unit allocation unit 170 constitute an allocation function unit 103.

[0041] <Computing device performance collection and recording unit 110> The processor performance collection and recording unit 110 collects and records the performance of each processor (CPU 11, accelerator (high performance) 12-1, accelerator (low performance) 12-2). Performance information includes throughput, processing latency, and power consumption.

[0042] The computing device performance collection and recording unit 110 stores accelerator information for each host based on static settings input by an operator. The computing device performance collection and recording unit 110 holds performance information for each computing device based on an identifier that uniquely identifies the computing device. Configuration example An example of the database configuration of the recording device is shown in an example of a DB table 300 (FIG. 4) of the computing device performance collection and recording unit 110. Input / Output The computing device performance collection and recording unit 110 receives as input the conditions for the accelerator required, such as specific performance and a host identifier, and returns as output a list of accelerators that match the input conditions.

[0043] Modifications The computing device performance collection and recording unit 110 may be configured to automatically collect information using an external configuration management tool or a command for acquiring device configuration information.

[0044] <Remote Offload Latency Collection and Recording Unit 120> The remote offload latency collection and recording unit 120 collects and records the communication latency (latency) that occurs during remote offload between a signal processing device equipped with an accelerator (here, from the server 200 to another server, the remote offload server 210). The remote offload latency collection and recording unit 120 stores the communication latency between the remote offload server 210 and the offload source server 200 in a latency table 310 shown in FIG. 5, which will be described later. Configuration example An example of the database configuration of the recording device is shown in the example of a DB table 300 of the computing device performance collection and recording unit 110.

[0045] Input / Output The remote offload latency collection and recording unit 120 receives host information of a specific combination as input, and calculates and responds to the latency from the host information of the combination received as input as output.

[0046] Modifications The remote offload latency collection and recording unit 120 may automatically collect information and update the latency. Specifically, a latency measurement function (not shown) installed in each host may periodically measure communication delays to other hosts and update the information in the remote offload latency collection and recording unit 120.

[0047] <Calculation device allocation determination unit 130> The computing device allocation determination unit 130 calculates the amount of data corresponding to the processing deadline based on the traffic volume and processing deadline after a predetermined time has elapsed, as predicted by the traffic volume and processing deadline prediction unit 150, and the performance information of the accelerator 12 recorded in the computing device performance collection and recording unit 110, and determines an accelerator that satisfies the performance based on the amount of data. The arithmetic unit allocation determining unit 130 determines an arithmetic unit that satisfies the performance requirements based on the traffic volume after a certain time has elapsed and the processing deadline, and allocates it to the arithmetic unit allocating unit 170 . The arithmetic unit allocation decision unit 130 receives the traffic volume after a certain time has elapsed and the processing deadline from the traffic volume / processing deadline prediction unit 150. Based on this performance requirement, the arithmetic unit allocation decision unit 130 queries the arithmetic unit performance collection and recording unit 110 and the remote offload latency collection and recording unit 120 to obtain a list of accelerators. Based on this information, the arithmetic unit allocation decision unit 130 obtains a list of local accelerators and remote offload destination accelerators.

[0048] Configuration example For the remote offload destination accelerator 12, the offload latency is added to the accelerator processing time. From the list, the combination of accelerators that meets the performance requirements and has the lowest power consumption is selected and notified to the arithmetic unit allocation unit 170.

[0049] Input / Output The arithmetic unit allocation decision unit 130 receives as input the traffic volume after a certain time has elapsed and the proportion of the processing deadline, and returns as output a list of accelerators that match the input conditions.

[0050] Modifications The arithmetic unit allocation determining unit 130 may be configured to automatically collect information using an external configuration management tool or a command for acquiring device configuration information.

[0051] <Data processing deadline determination unit 140> The data processing deadline determination unit 140 identifies the processing deadline for each piece of input data and notifies each functional unit of the deadline. The data processing deadline determination unit 140 receives input data from the input / output unit 13, and identifies the processing deadline by referring to the header information at the beginning of the data. In the example of RAN, the data processing deadline is identified by referring to the corresponding eCPRI (enhanced Common Public Radio Interface) protocol header and identifying session information.

[0052] Input / Output The data processing deadline determination unit 140 receives input data from the input / output unit 13 as an input, and notifies the traffic volume and processing deadline ratio to the traffic volume / processing deadline prediction unit 150 as an output.

[0053] <Traffic volume and processing deadline prediction unit 150> The traffic volume / processing deadline prediction unit 150 predicts the traffic volume and processing deadline after a certain time has elapsed from the ratio of the current and past traffic volumes and processing deadlines. The traffic volume / processing deadline prediction unit 150 receives the traffic volume and the processing deadline ratio from the data processing deadline determination unit 140, and calculates the volume of each traffic type by multiplying the input traffic volume by the ratio of each processing deadline. The traffic volume / processing deadline prediction unit 150 predicts whether the traffic volume of each deadline will be increasing or decreasing.

[0054] Input / Output The traffic volume / processing deadline prediction unit 150 receives as input the current traffic volume and processing deadline ratio of the input data, and as output notifies the arithmetic unit allocation determination unit 130 of the predicted traffic volume and processing deadline after a certain period of time has elapsed.

[0055] Modifications The traffic volume and processing deadline prediction unit 150 may predict the traffic volume and processing deadline in the RAN system based on the current traffic trends, as well as the time-of-day trends at the relevant traffic generation point and the occurrence of events in the vicinity where people gather. Specifically, one possible method is to predict that traffic volume from base stations along train lines will be high between the first and last trains and low at other times.Another method is to predict increases in traffic in advance based on information about events (such as fireworks displays) that attract large crowds near base stations at certain locations.

[0056] <Function proxy execution unit 160> The function proxy execution unit 160 provides the application with the same interface as the functions provided by the existing accelerator access library, and actually executes the functions on behalf of the application. The function proxy execution unit 160 is provided as a library for the application and is either statically linked or dynamically loaded and called at runtime. The same interface refers to functions with the same function name and the same argument format.

[0057] Input / Output <<When requesting processing>> The function proxy execution unit 160 receives the function name and arguments from the application 1 as input, and notifies the arithmetic unit allocation unit 170 of the function name and arguments as output.

[0058] <<When the processing result is returned>> The function proxy execution unit 160 receives the processing result from the arithmetic unit allocation unit 170 as input, and notifies the application 1 of the processing result as output.

[0059] <Arithmetic device distribution section 170> The arithmetic unit allocation unit 170 allocates input data to the arithmetic units that have been allocated in advance. The arithmetic unit allocation unit 170 selects an accelerator that satisfies the processing performance based on the processing deadline of the input data determined by the data processing deadline determination unit 140 and the judgment result of the arithmetic unit allocation judgment unit 130, and allocates the processing to the selected accelerator. Specifically, the arithmetic unit allocating unit 170 selects an arithmetic unit that satisfies the processing performance based on the processing deadline information included in each input data, and allocates the processing to it. At this time, the arithmetic unit allocating unit 170 inquires about the processing deadline information of each data item from the data processing deadline determining unit 140, and determines the data processing deadline.

[0060] Input / Output <<When requesting processing>> The arithmetic unit allocating unit 170 receives as input a list of available arithmetic units from the arithmetic unit allocation determining unit 130, and also receives data to be processed from the function proxy executing unit 160. The arithmetic unit allocator 170 sends the data to be processed to one of the CPU 11, the accelerator 12, and the remote offload unit 180 as output. The arithmetic unit allocator 170 inputs input data to the data processing deadline determiner 140 and receives the processing deadline for the data from the data processing deadline determiner 140 .

[0061] <<Processing result response>> The arithmetic unit allocation unit 170 receives processing results from the CPU 11, accelerator 12, and remote offload input / output unit 14 as inputs, and notifies the function proxy execution unit 160 of the processing results as outputs.

[0062] Modifications The arithmetic unit allocation unit 170 allocates accelerators based on processing deadline information and traffic volume, but other priority information may also be used. Specifically, priority information may include securing accelerators for maintenance that are necessary for the continuous operation of the system.

[0063] In this embodiment, the calculation results of each arithmetic unit (remote offload latency collection and recording unit 120, accelerator 12, remote offload input / output unit 14) are sent to the function proxy execution unit 160 via the arithmetic unit allocation unit 170, but it is also possible for each arithmetic unit (remote offload latency collection and recording unit 120, accelerator 12, remote offload input / output unit 14) to send the calculation results directly to the function proxy execution unit 160.

[0064] <Remote Offloading Unit 180> The remote offload unit 180 converts the input function name and arguments into data as an L2 frame and its payload that can be transmitted by the NIC. The data format of this embodiment is shown in FIG.

[0065] Input / Output <When off-roading> The remote offload unit 180 receives the "function name and arguments" from the arithmetic unit allocation unit 170 as input, and passes the "transmission data" to the remote offload input / output unit 14 as output.

[0066] When responding The remote offload unit 180 receives "processing result data" from the remote offload input / output unit 14 as input, and passes the processing result data to the arithmetic unit allocation unit 170 as output.

[0067] Modifications The data format can be not only an L2 frame, but also data with L3 and L4 headers. The packet format can include not only the function name and arguments, but also an ID that can uniquely identify the accelerator to be used. Also, if the argument size is large, a function for dividing it into multiple packets may be provided.

[0068] [Remote Offload Server 210] The remote offload server 210 includes hardware (HW) 10 and software 20 .

[0069] Hardware 10 The hardware 10 includes a CPU 11, an accelerator (remote) (high performance) 12-3, and a remote offload input / output unit (server) (NIC) 14.

[0070] <cpu11> The CPU 11 executes the processing of the application 1 and also executes the software of each functional unit in the remote offload server 210 .

[0071] <Accelerator 12> The accelerator (remote) (high performance) 12-3 is a calculation accelerator device such as an FPGA / GPU. The accelerator (remote) (high performance) 12-3 is a computing device specialized for specific processing, mounted on the remote offload server 210. The accelerator (remote) (high performance) 12-3 can be connected to the CPU 11 via a bus in the form of an ASIC-mounted accelerator, an FPGA-mounted accelerator, a GPU, or the like.

[0072] This embodiment uses a "heterogeneous performance configuration" that allows the use of multiple accelerators with different processing capabilities. The multiple accelerators with different processing capabilities are an accelerator (high performance) 12-1 and an accelerator (low performance) 12-2 mounted on the server 200, and an accelerator (remote) (high performance) 12-3 mounted on the remote offload server 210.

[0073] "Software 20" The software 20 includes a remote offload receiving unit 211 . The remote offload receiving unit 211 offloads the data to be processed received via the network to the accelerator (remote) 12-3 and returns the result.

[0074] Input / Output <When off-roading> The remote offload receiving unit 211 receives data in the format shown in FIG. 6 as input, and performs processing offloading to the accelerator (remote) 12-3 as output.

[0075] When responding The remote offload receiving unit 211 receives an offload result from the accelerator (remote) 12-3 as an input, and returns a processing result as data in the format of FIG. 6 as an output.

[0076] [Antenna device 220] The antenna device 220 is an antenna and a transceiver unit that wirelessly communicates with a terminal (UE: User Equipment) (hereinafter, the term "antenna device" refers collectively to the antenna, the transceiver unit, and its power supply unit). Transmitted and received data is connected to a signal processing device (server 200) of a base station (BBU: Base Band Unit) via, for example, a dedicated cable.

[0077] The antenna device 220 includes an antenna device data input / output unit 221. The antenna device data input / output unit 221 is a functional unit that sends a signal generated by the antenna device 220 to the server 200, and is realized in the form of an NIC or the like.

[0078] [Post-processing device 230] The post-processing device 230 is a centralized unit in 5G signal processing. The post-processing device 230 includes a post-processing device data input / output unit 231. The post-processing device data input / output unit 231 is a functional unit that receives the signal processing results processed by the server 200, and is realized in the form of a NIC or the like.

[0079] <Other embodiments> In this embodiment, the input / output unit 13, the CPU 11, and the accelerator 12 are configured as separate hardware components, but the CPU 11, the accelerator 12, and the accelerator arithmetic circuit program 12a may be integrated into dedicated hardware. In other words, in addition to the so-called Look-Aside type accelerator application form (sequence of Figures 11A-11C) in which "data obtained via an input / output unit 13 such as a NIC is explicitly offloaded from the CPU 11 to the accelerator 12" as shown in Figure 1, a so-called In-line type accelerator application form (sequence of Figures 12A-12C) in which "NIC, accelerator, and CPU" are integrated into hardware as described later in Figure 2, and processing is completed within the same hardware after data is received by the NIC" may also be used. Furthermore, the CPU 11 and the accelerator 12 may be mounted on a single chip, such as in the form of an SoC (System on Chip).

[0080] [Accelerator application form of accelerator state control device] Fig. 2 is a schematic configuration diagram of an accelerator state control system 1000A according to an embodiment of the present invention. Fig. 2 shows an in-line accelerator application form. Components that are the same as those in Fig. 1 are assigned the same reference numerals, and explanations of overlapping parts will be omitted. The accelerator state control device 100A of the server 200A of the in-line accelerator application mode shown in Fig. 2 does not have the bidirectional signal line connecting the input / output unit 13 and the accelerator 12 that is present in the accelerator state control device 100 of the server 200 of Fig. 1. Moreover, the accelerator state control device 100A of the server 200 of the in-line accelerator application mode shown in Fig. 2 has a new bidirectional signal line connecting the input / output unit 13 and the arithmetic unit allocation unit 170 added. The server 200A, which uses an in-line accelerator, copies data directly from the NIC to the accelerator, which then performs calculations autonomously like a dedicated circuit.

[0081] [Placement of accelerator state control device] Variations in the arrangement of the accelerator state control device in the accelerator state control system will be described. The accelerator state control system 1000 in Fig. 1 is an example in which the accelerator state control device 100 is arranged in software 20 of a server 200. Some of the functions of the accelerator state control device 100 can also be installed in a separate housing outside the server 200, as exemplified below.

[0082] 3 is a schematic diagram showing variations in the arrangement of the accelerator state control device of the accelerator state control system. In the following figures, the same components as those in FIG. 1 are designated by the same reference numerals, and explanations of overlapping parts will be omitted. The variation shown in Figure 3 is an example in which the controller function unit, consisting of the computing device performance collection and recording unit 110, remote offload latency collection and recording unit 120, computing device allocation judgment unit 130, data processing deadline judgment unit 140, and traffic volume and processing deadline prediction unit 150, is housed in a separate housing. As shown in FIG. 3, the accelerator state control system 1000B includes an accelerator state control device 100B installed outside the server 200 in a separate housing. The software 20 of the server 200 includes an application 1, a function proxy execution unit 160, and an arithmetic unit allocation unit 170. The accelerator state control device 100B has the controller function unit installed outside the server 200 and has the same functions as the accelerator state control devices 100 and 100A in FIGS.

[0083] As shown in FIG. 3, by independently deploying some or all of the functions of the accelerator state control device in a separate housing outside the server 200, it is possible to accommodate the deployment of functions to a RAN Intelligent Controller (RIC) in a RAN (Radio Access Network).

[0084] Furthermore, by placing the controller function unit externally, the input volume can be predicted based on the input volume obtained from multiple server machines (function 1), which has the advantage of improving the accuracy of traffic prediction for function 1. For example, in a mobile phone wireless system, if the traffic volume in the processing area handled by a certain server machine increases, it is expected that the input volume in nearby processing areas will also fluctuate with a delay.

[0085] Furthermore, it becomes possible to operate a single accelerator state control device for multiple servers 200. This reduces costs and improves maintainability of the accelerator state control device. Furthermore, modifications to the server side are unnecessary or can be reduced, making it possible to apply it in a general-purpose manner.

[0086] [DB table of the computing device performance collection and recording unit 110] FIG. 4 is a diagram showing an example of the DB table 300 of the computing device performance collecting and recording unit 110. As shown in FIG. As shown in Fig. 4, DB table 300 holds, for each piece of installed host information, an accelerator identifier (CPU, FPGA, ASIC), ACC performance (throughput), ACC performance (processing latency), and ACC performance (power consumption). For example, installed host information "Host-1 (192.168.0.1: server URL)" has an accelerator identifier of "FPGA-1," an ACC performance (throughput) of "10.0 Gbps," an ACC performance (processing latency) of "5.0 μs," and an ACC performance (power consumption) of "120.0 W." Each ACC performance is recorded in association with the installed host information, and by specifying the installed host information, the ACC performance of the host can be known.

[0087] [Latency table of the remote offload latency collection and recording unit 120] FIG. 5 is a diagram showing an example of the latency table 310 of the remote offload latency collection and recording unit 120. As shown in FIG. 5, the latency table 310 holds (records) source host information, destination host information, and latency. For example, when source host information "Host-1 (192.168.0.1: server URL)" connects to destination host information "Host-2 (192.168.0.2)," the latency (connection latency / communication latency) is 30 μs.

[0088] [Data structure of remote offload unit 180] FIG. 6 is a diagram showing an example of the configuration of the ACC function and argument data packet 320 of the remote offload unit 180. As shown in FIG. As shown in FIG. 6, the ACC function and argument data packet 320 is formatted with an L2 frame (0 to 14 bytes), a function ID (up to 34 bytes), a final data bit (up to 42 bytes), argument 1 (up to 46 bytes), and argument 2 (up to 50 bytes). The ACC function / argument data packet 320 has a data structure suitable for parsing in an FPGA circuit by making each piece of data have a fixed length and a fixed position.

[0089] The control bit adds control information to the packet. The ACC function / argument data packet 320 has a function for dividing the packet into multiple packets, for example, when the argument size is large. In this case, the last divided packet has control data added to the "control bit" to notify that it is the last packet. The packet format shown in Figure 6 may include an L3 header and an L4 header. In addition to the function name and arguments, an ID that can uniquely identify the accelerator to be used may also be included.

[0090] [Example of calculation of available ACC list from Host-1] FIG. 7 is a diagram showing an example of calculation of the available ACC list 330 from Host-1. As shown in Fig. 7, the available ACC list 330 is created based on the DB table 300 of the computing device performance collection and recording unit 110 shown in Fig. 4 and the latency table 310 of the remote offload latency collection and recording unit 120 shown in Fig. 5. The available ACC list 330 lists the ACC performance (throughput), ACC performance (processing latency), and ACC performance (power consumption) when a host uses another host. For example, when Host-1 uses Host-2, the ACC performance (processing latency) is "40.0 μs = 10.0 μs + 30 μs (remote latency)," which is an important indicator when Host-1 uses Host-2.

[0091] The arithmetic unit allocation determination unit 130 selects a combination of accelerators that meets the performance requirements and has the lowest power consumption from the list in the DB table 300 of the arithmetic unit performance collection and recording unit 110 shown in Fig. 4, and notifies the arithmetic unit allocation unit 170. However, if the accelerator is located remotely, particularly via a network, the remote latency is also taken into consideration. Using this available ACC list 330, the arithmetic unit allocation determination unit 130 determines an arithmetic unit that meets the performance requirements while also taking remote latency into consideration, and allocates it to the arithmetic unit allocation unit 170.

[0092] The operation of the accelerator state control system 1000 configured as described above will now be described. First, the operations of the arithmetic unit allocation determining unit 130 and the traffic volume / processing deadline predicting unit 150 will be described. [Operation 1 of the arithmetic unit allocation determination unit 130 and the traffic volume / processing deadline prediction unit 150] Fig. 8 is a flowchart showing operation 1 of the arithmetic unit allocation determining unit 130 and the traffic volume / processing deadline predicting unit 150. Fig. 8 shows the case where the traffic volume or the proportion of traffic with a high processing deadline increases.

[0093] In step S11, the traffic volume / processing deadline prediction unit 150 acquires the ratio of the input traffic volume to the length of the processing deadline. In step S12, the traffic volume / processing deadline prediction unit 150 multiplies the input traffic volume by the rate of each processing deadline to calculate the volume of each traffic type.

[0094] In step S13, the traffic volume / processing deadline prediction unit 150 determines whether the total volume of traffic or the volume of traffic with a short processing deadline has increased a certain number of times or more consecutively. If the total amount of traffic or the amount of traffic with a short processing deadline has not increased a certain number of times in succession (S12: No), the process returns to step S11.

[0095] If the total amount of traffic or the amount of traffic with short processing deadlines has increased a certain number of times in succession (S12: Yes), in step S14 the computing device performance collection and recording unit 110 issues a list of available computing devices (DB table 300 in FIG. 4) (hereinafter, "issuing" refers to extracting information and responding).

[0096] In step S15, the arithmetic unit allocation decision unit 130 determines whether the predicted traffic volume is greater than the current processing capacity. If the predicted traffic volume is larger than the current processing capacity (S15: Yes), in step S16, the arithmetic unit allocation decision unit 130 determines whether the predicted "traffic volume with a short processing deadline" is higher than the current processing capacity.

[0097] If the predicted "traffic volume with a short processing deadline" is higher than the current processing capacity (S16: Yes), in step S17, the calculation device allocation judgment unit 130 selects and reassigns a calculation device with higher traffic performance and real-time performance than the current situation, and proceeds to step S20.

[0098] If the predicted "traffic volume with a short processing deadline" is not higher than the current processing capacity (S16: No), in step S18 the calculation device allocation judgment unit 130 selects and reassigns a calculation device with higher traffic performance and similar or better real-time performance than the current situation, and then proceeds to step S20.

[0099] On the other hand, if the traffic volume predicted in step S15 above is equal to or less than the current processing capacity (S15: No), the traffic volume will not increase, and it is determined that the "proportion of traffic with high processing deadlines" is high. In step S19, the calculation device allocation judgment unit 130 selects and reassigns a calculation device with the same or better traffic performance and higher real-time performance than the current situation, and proceeds to step S20.

[0100] In step S20, the arithmetic unit allocation determining unit 130 notifies the arithmetic unit allocating unit 170 of the selection result, and then ends the processing of this flow.

[0101] [Operation 2 of the arithmetic unit allocation determination unit 130 and the traffic volume / processing deadline prediction unit 150] 9 is a flowchart showing operation 2 of the arithmetic unit allocation determining unit 130 and the traffic volume / processing deadline predicting unit 150. FIG. 9 shows the case where the traffic volume or the proportion of traffic with a high processing deadline decreases.

[0102] In step S21, the traffic volume / processing deadline prediction unit 150 acquires the input traffic volume / processing deadline ratio.

[0103] In step S22, the traffic volume / processing deadline prediction unit 150 determines whether the total traffic volume or the ratio of traffic with high latency requirements has decreased a certain number of times in succession.

[0104] If the total amount of traffic or the proportion of traffic with high latency requirements has not decreased for a certain number of consecutive times (S22: No), the process returns to step S21.

[0105] If the total traffic volume or the proportion of traffic with high latency requirements has decreased for a certain number of consecutive times or more (S22: Yes), in step S23, the computing device performance collection and recording unit 110 issues a list of available computing devices (DB table 300 in Figure 4).

[0106] In step S24, the arithmetic unit allocation decision unit 130 determines whether the predicted traffic volume is smaller than the current processing capacity. If the predicted traffic volume is smaller than the current processing capacity (S24: Yes), in step S25, the arithmetic unit allocation decision unit 130 determines whether the predicted "traffic volume with a short processing deadline" is lower than the current processing capacity.

[0107] If the predicted "proportion of traffic with short processing deadlines" is lower than the current processing capacity (S25: Yes), in step S26, the calculation device allocation judgment unit 130 selects and reassigns a calculation device with higher traffic performance and lower real-time performance than the current situation, and proceeds to step S29.

[0108] If the predicted "proportion of traffic with short processing deadlines" is not lower than the current processing capacity (S25: No), in step S27 the calculation device allocation judgment unit 130 selects and reassigns a calculation device that has lower traffic performance than the current situation but similar or better real-time performance, and then proceeds to step S29.

[0109] On the other hand, if the traffic volume predicted in step S24 is equal to or greater than the current processing capacity (S24: No), it is determined that the traffic volume has not decreased and that the "proportion of traffic with high latency requirements" has decreased, and in step S28 the arithmetic unit allocation judgment unit 130 selects and reassigns an arithmetic unit with the same or better traffic performance but lower real-time performance than the current situation, and proceeds to step S29.

[0110] In step S29, the arithmetic unit allocation determining unit 130 notifies the arithmetic unit allocating unit 170 of the selection result, and then ends the processing of this flow.

[0111] [Calculation Unit Allocation (ACC Allocation)] FIG. 10 is a flowchart showing the arithmetic unit allocation (ACC allocation). In step S31, the input / output unit 13 inputs and outputs data.

[0112] In step S32, the data processing deadline determination unit 140 determines the processing deadline for each piece of input data and notifies each functional unit. The data processing deadline determination unit 140 receives input data from the input / output unit, references the header information at the beginning of the data, and determines the processing deadline.

[0113] In step S33, the traffic volume / processing deadline prediction unit 150 predicts the traffic volume and processing deadline after a certain time has elapsed from the ratio of the current and past traffic volumes and processing deadlines. The traffic volume / processing deadline prediction unit 150 receives the traffic volume and latency requests from the data processing deadline determination unit 140, and predicts whether the ratio of the traffic and latency requests is on the rise.

[0114] In step S34, the arithmetic unit allocation unit 170 determines an arithmetic unit that satisfies the performance requirements based on the traffic volume after a certain time has elapsed and the processing deadline, and allocates the arithmetic unit to the arithmetic unit allocating unit 170.

[0115] In step S35, the arithmetic unit allocation unit 170 allocates the input data to the pre-allocated arithmetic units. Based on the processing deadline information included in each input data, the arithmetic unit allocation unit 170 selects an arithmetic unit that satisfies the processing performance, allocates the processing, and ends the processing of this flow.

[0116] [Input data processing] 11A to 11C are flowcharts showing input data processing, which correspond to the Look-Aside accelerator application mode. 11A-11C are one flow, but for convenience of illustration, they are connected using [A], [B], and [C] as connectors.

[0117] 11A, the antenna device data input / output unit 221 of the antenna device 220 sends a signal generated by the antenna device 220 to the server 200 in step S41.

[0118] In step S42, the input / output unit 13 inputs and outputs data to and from the external device (antenna device 220). In step S43, the application 1 accepts the data to be processed from the input / output unit 13 and passes the calculated data to the input / output unit 13.

[0119] In step S44, the function proxy execution unit 160 receives the function name and arguments from the application as input, and notifies the arithmetic unit allocation unit 170 of the function name and arguments as output. In step S45, the arithmetic unit allocating unit 170 accepts the processing target data from the function proxy executing unit 160, and sends the processing target data to either the CPU 11, the accelerator 12, or the accelerator [remote] 12-3 of the remote offload server.

[0120] In step S46, the arithmetic unit allocating unit 170 determines whether the allocation destination is one of the following: If the allocation destination is a CPU, the CPU 11 executes the software in step S47 of FIG. 11C, and the process proceeds to step S59. If the destination is accelerator 1 (accelerator 12-1), in step S48 of FIG. 11C, the accelerator [performance: high] 12-1 executes a process specialized for a specific process, and the process proceeds to step S59.

[0121] If the destination is accelerator 2 (accelerator 12-2), in step S49 of FIG. 11C, the accelerator [performance: low] 12-2 executes a process specialized for a specific process, and the process proceeds to step S59. If the destination is the accelerator [remote] (accelerator 12-3), the process proceeds to step S50 in FIG. 11B.

[0122] In FIG. 11B, in step S50, the remote offload unit 180 receives the "function name and arguments" as input from the arithmetic unit allocator 170, and passes the "transmission data" to the remote offload input / output unit 14 as output.

[0123] In step S51, the remote offload input / output unit [client] 14 communicates with the remote offload server. In step S52, the remote offload input / output unit [server] 14 performs communication between servers.

[0124] In step S53, the remote offload receiving unit 211 receives data in the format shown in FIG. 6 as input, and performs processing offloading to the accelerator [remote] 12-3 as output. In step S54, the accelerator [remote] 12-3 performs a calculation specialized for a specific process. In step S55, the remote offload request receiving unit 211 receives the offload result from the accelerator [remote] and returns the processing result as data in the format of FIG.

[0125] In step S56, the remote offload input / output unit [server] 14 performs communication between servers. In step S57, the remote offload input / output unit [client] 14 communicates with the remote offload server. In step S58, the remote offload unit 180 receives the "processing result data" as input from the remote offload input / output unit 14, and passes the processing result data as output to the arithmetic unit allocating unit 170, and then proceeds to step S59 in FIG. 11C.

[0126] In step S59 of FIG. 11C, the function proxy execution unit 160 receives the processing result as input from the arithmetic unit allocation unit 170, and notifies the application of the processing result as output. In step S60, the arithmetic unit allocation unit 170 receives processing results from the CPU, accelerator 12, and remote offload input / output unit 14 as inputs, and notifies the function proxy execution unit 160 of the processing results as outputs.

[0127] In step S61, the application 1 receives data to be processed from the input / output unit 13 as input, and passes the calculated data to the input / output unit 13 as output. In step S62, the post-processing device data input / output unit 231 of the post-processing device 230 receives the signal processing result processed by the server, and the processing of this flow ends.

[0128] 12A-12C are flowcharts showing input data processing. Figures 12A-12C correspond to an in-line accelerator application form. The same steps as those in Figures 11A-11C are assigned the same step numbers. 12A-12C show one flow, but for convenience of illustration, they are connected using [A], [B], and [C] as connectors.

[0129] 12A, in step S41, the antenna device data input / output unit 221 of the antenna device 220 sends a signal generated by the antenna device 220 to the server 200. In step S42, the input / output unit 13 inputs and outputs data to and from the external device (antenna device 220).

[0130] In step S45, the arithmetic unit allocating unit 170 accepts the processing target data from the function proxy executing unit 160, and sends the processing target data to either the CPU 11, the accelerator 12, or the accelerator [remote] 12-3 of the remote offload server. In step S46, the arithmetic unit allocating unit 170 determines whether the allocation destination is one of the following: If the allocation destination is a CPU, the CPU 11 executes the software in step S47 of FIG. 12C, and the process proceeds to step S59.

[0131] If the destination is accelerator 1 (accelerator 12-1), in step S48 of FIG. 12C, the accelerator [performance: high] 12-1 executes a process specialized for a specific process, and the process proceeds to step S59. If the destination is accelerator 2 (accelerator 12-2), in step S49 of FIG. 12C, the accelerator [performance: low] 12-2 executes a process specialized for a specific process, and the process proceeds to step S59. If the destination is the accelerator [remote] (accelerator 12-3), the process proceeds to step S50 in FIG. 12B.

[0132] In FIG. 12B, in step S50, the remote offload unit 180 receives the "function name and arguments" as input from the arithmetic unit allocator 170, and passes the "transmission data" to the remote offload input / output unit 14 as output. In step S51, the remote offload input / output unit [client] 14 communicates with the remote offload server. In step S52, the remote offload input / output unit [server] 14 performs communication between servers. In step S53, the remote offload receiving unit 211 receives data in the format shown in FIG. 6 as input, and performs processing offloading to the accelerator [remote] 12-3 as output.

[0133] In step S54, the accelerator [remote] 12-3 performs a calculation specialized for a specific process. In step S55, the remote offload request receiving unit 211 receives the offload result from the accelerator [remote] and returns the processing result as data in the format of FIG. In step S56, the remote offload input / output unit [server] 14 performs communication between servers.

[0134] In step S57, the remote offload input / output unit [client] 14 communicates with the remote offload server. In step S58, the remote offload unit 180 receives the "processing result data" as input from the remote offload input / output unit 14, and passes the processing result data as output to the arithmetic unit allocating unit 170, and then proceeds to step S59 in FIG. 12C.

[0135] In step S59 of FIG. 12C, the function proxy execution unit 160 receives the processing result as input from the arithmetic unit allocation unit 170, and notifies the application of the processing result as output. In step S60, the arithmetic unit allocation unit 170 receives processing results from the CPU, accelerator 12, and remote offload input / output unit 14 as inputs, and notifies the function proxy execution unit 160 of the processing results as outputs.

[0136] In step S61, the application 1 receives data to be processed from the input / output unit 13 as input, and passes the calculated data to the input / output unit 13 as output. In step S62, the post-processing device data input / output unit 231 of the post-processing device 230 receives the signal processing result processed by the server, and the processing of this flow ends.

[0137] [Hardware configuration] The accelerator state control device 100 (FIG. 1) of the accelerator state control systems 1000, 1000A (FIGS. 1 and 2) according to the above embodiments is realized by a computer 900 configured as shown in FIG. 13, for example. FIG. 13 is a hardware configuration diagram showing an example of a computer 900 that realizes the functions of the accelerator state control device 100. The accelerator state control device 100 includes a CPU 901, a RAM 902, a ROM 903, a HDD 904, an accelerator 905, an input / output interface (I / F) 906, a media interface (I / F) 907, and a communication interface (I / F) 908. The accelerator 905 corresponds to the accelerator 12 in FIGS.

[0138] The accelerator 905 is an accelerator (device) 12 (FIGS. 1 and 2) that processes at least one of data from the communication I / F 908 and data from the RAM 902 at high speed. Note that the accelerator 905 may be of a type that returns the execution results to the CPU 901 or RAM 902 after executing processing from the CPU 901 or RAM 902 (look-aside type). On the other hand, the accelerator 905 may be of a type that performs processing between the communication I / F 908 and the CPU 901 or RAM 902 (in-line type).

[0139] The accelerator 905 is connected to an external device 915 via a communication I / F 908. The input / output I / F 906 is connected to an input / output device 916. The media I / F 907 reads and writes data from and to a recording medium 917.

[0140] The CPU 901 operates based on a program stored in the ROM 903 or the HDD 904, and controls each part of the accelerator state control device 100, 100A shown in Figures 1 and 2 by executing a program (also called an application or an app for short) loaded into the RAM 902. This program can also be distributed via a communication line or recorded on a recording medium 917 such as a CD-ROM. The ROM 903 stores a boot program executed by the CPU 901 when the computer 900 is started, programs that depend on the hardware of the computer 900, and the like.

[0141] The CPU 901 controls an input / output device 916, which is made up of input units such as a mouse and a keyboard, and output units such as a display and a printer, via an input / output I / F 906. The CPU 901 acquires data from the input / output device 916 via the input / output I / F 906, and outputs generated data to the input / output device 916. Note that a GPU (Graphics Processing Unit) or the like may be used as a processor together with the CPU 901.

[0142] The HDD 904 stores programs executed by the CPU 901 and data used by the programs. The communication I / F 908 receives data from other devices via a communication network (e.g., a network) and outputs the data to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network.

[0143] The media I / F 907 reads a program or data stored in the recording medium 917 and outputs it to the CPU 901 via the RAM 902. The CPU 901 loads a program related to a target process from the recording medium 917 onto the RAM 902 via the media I / F 907, and executes the loaded program. The recording medium 917 is an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase Change Rewritable Disc), a magneto-optical recording medium such as an MO (Magneto Optical disc), a magnetic recording medium, a conductive memory tape medium, a semiconductor memory, or the like.

[0144] For example, when the computer 900 functions as the accelerator state control device 100 (FIG. 1) configured as one device according to this embodiment, the CPU 901 of the computer 900 executes a program loaded onto the RAM 902 to realize the functions of the accelerator state control device 100. The HDD 904 also stores data in the RAM 902. The CPU 901 reads and executes a program related to a target process from the recording medium 917. Alternatively, the CPU 901 may read a program related to a target process from another device via a communication network. 3 is installed outside the server 200, this accelerator state control device 100A is also realized by a computer 900 having a configuration as shown in FIG.

[0145] [effect] As described above, the accelerator state control device 100, 100A, 100B (FIGS. 1 to 3) has a plurality of accelerators 12 with different processing performance, and controls the state of the accelerators when a specific process of an application 1 is offloaded to the accelerators 12 for computational processing. When data with different processing deadlines is input, the accelerator state control device 100, 100A, 100B includes: a recording unit (computing unit performance collection and recording unit 110) that collects and records performance information of the accelerators 1; a prediction unit (traffic volume and processing deadline prediction unit 150) that predicts the traffic volume and processing deadline after a predetermined time has elapsed based on the ratio of the current and past traffic volumes and processing deadlines; and a judgment unit (computing unit allocation judgment unit 130) that calculates the data volume corresponding to the processing deadline based on the traffic volume and processing deadline after the predetermined time has elapsed predicted by the prediction unit and the accelerator performance recorded in the recording unit, and judges an accelerator that satisfies the performance based on the data volume.

[0146] As described in the problem to be solved, existing technology 1 (static allocation) has a fixed amount of accelerator resources and does not satisfy <Requirement 2: scalability>. Existing technology 2 (scaling out using function proxies) does not consider differences in the performance of individual accelerators and therefore does not satisfy <Requirement 1: meeting the processing deadline for each data item>. Therefore, existing technology 1 has poor versatility due to its fixed scale, and existing technology 2 has a fixed percentage of responsiveness that makes it unsuitable for processing requiring low latency. In contrast, the accelerator state control device 100 according to this embodiment uses a heterogeneous accelerator configuration that can utilize multiple different accelerators, and allocates and offloads accelerators based on the processing deadline for each data item. This allows the accelerator state control device 100 to achieve both versatility and low latency, which existing technology 1 and existing technology 2 could not achieve.

[0147] Therefore, the accelerator state control devices 100, 100A, and 100B (FIGS. 1 to 3) can dynamically allocate accelerators and satisfy [Requirement 2: scalability]. Furthermore, during computation, the accelerator state control devices 100, 100A, and 100B select from the allocated accelerators, based on the processing deadline for each piece of data, an accelerator that meets performance and minimizes power consumption, and offloads the selected accelerator, thereby satisfying [Requirement 1: Satisfying responsiveness for each piece of data]. As a result, the accelerator state control device 100 can reduce the computational resources used while ensuring responsiveness in response to fluctuations in the amount of data corresponding to each processing deadline.

[0148] The accelerator state control devices 100, 100A, 100B (FIGS. 1 to 3) are characterized by comprising a data processing deadline determination unit 140 that identifies and notifies the processing deadline of input data, and an allocation unit (arithmetic unit allocation unit 170) that selects an accelerator that satisfies the processing performance based on the processing deadline of the input data determined by the data processing deadline determination unit 140 and the judgment result of the judgment unit (arithmetic unit allocation judgment unit 130), and allocates processing to the selected accelerator.

[0149] In this way, the arithmetic unit allocation unit 170 selects from the allocated accelerators an accelerator that satisfies the performance and minimizes power consumption based on the processing deadline for each data item, and offloads the selected accelerator, thereby satisfying [Requirement 1: Satisfying the responsiveness of each data item]. Therefore, the accelerator state control device 100 allocates the optimal accelerator, thereby achieving power savings.

[0150] The accelerator state control devices 100, 100A, and 100B (FIGS. 1 to 3) include a latency recording unit (remote offload latency collection and recording unit 120) that measures and records the latency that occurs in remote offloading between signal processing devices (server 200, remote offload server 210) equipped with accelerators, and a judgment unit (arithmetic unit allocation judgment unit 130) calculates the amount of data corresponding to the processing deadline based on the latency recorded in the latency recording unit and the accelerator performance recorded in the recording unit (arithmetic unit performance collection and recording unit 110), and judges an accelerator that meets the performance based on the data amount.

[0151] For example, the recording unit (processing device performance collection and recording unit 110) records access source host information, access destination host information, and latency (connection latency) in a latency table 310 shown in FIG. 5. When selecting an accelerator that meets the conditions, the judgment unit (processing device allocation judgment unit 130) refers to the latency table 310 for a remote accelerator, compares the pre-recorded latency with the accelerator performance, and allocates the optimal accelerator. The judgment unit also incorporates the latency during remote offloading into the parameters for its judgment, thereby enabling the allocation of a more optimal accelerator from the perspective of the entire system, which cannot be measured by accelerator performance alone. As a result, [Requirement 2: scalability] and [Requirement 1: satisfying responsiveness for each data] can be achieved at a higher level.

[0152] The accelerator state control system 1000, 1000A, 1000B (FIGS. 1 to 3) has a plurality of accelerators 12 with different processing performance, and includes an accelerator state control device 100, 100A, 100B (FIGS. 1 to 3) that controls the state of the accelerators when specific processing of an application 1 is offloaded to the accelerators 12 for computational processing. The accelerator state control device 100 collects and records performance information of the accelerators 1 when data having different processing deadlines is input. a prediction unit (traffic volume / processing deadline prediction unit 150) that predicts the traffic volume and processing deadline after a predetermined time has elapsed from the ratio of the current and past traffic volumes and processing deadlines; and a judgment unit (arithmetic unit allocation judgment unit 130) that calculates the data volume corresponding to the processing deadline based on the traffic volume and processing deadline after the predetermined time has elapsed predicted by the prediction unit and the accelerator performance recorded in the recording unit, and judges an accelerator that satisfies the performance based on the data volume.

[0153] By doing this, in accelerator state control systems 1000, 1000A, 1000B having multiple accelerators 12 with different processing performance and equipped with accelerator state control devices 100, 100A, 100B that control the state of the accelerators when specific processing of application 1 is offloaded to the accelerators 12 for computational processing, it is possible to reduce the computational resources used while ensuring responsiveness in response to fluctuations in the amount of data corresponding to each processing deadline.

[0154] Furthermore, among the processes described in the above embodiments and modifications, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using a known method.In addition, the information including the processing procedures, control procedures, specific names, various data, and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified. Furthermore, the components of each device shown in the figure are conceptual functional components and do not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of each device is not limited to that shown in the figure, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc.

[0155] Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described configurations, functions, etc. may also be implemented by software that causes a processor to interpret and execute programs that implement the respective functions. Information on the programs, tables, files, etc. that implement the respective functions may be stored in a memory, a recording device such as a hard disk or a solid-state drive (SSD), or a recording medium such as an integrated circuit (IC) card, a secure digital (SD) card, or an optical disc. [Explanation of symbols]

[0156] 1 Application (APL) 10. Hardware 11 CPU 12, 12-1, 12-2, 12-3 Accelerator 13 Input / output section 14 Remote offload input / output unit 20 Software 100, 100A, 100B Accelerator state control device 110 Computing device performance collection and recording unit (recording unit) 120 Remote offload latency collection and recording unit (latency recording unit) 130 Calculation device allocation determination unit 140 Data processing deadline determination unit 150 Traffic volume and processing deadline prediction unit (prediction unit) 160 Function proxy execution unit 170 Arithmetic device distribution section (distribution section) 180 Remote Offloading Department 200 Servers (accelerator-equipped servers) (signal processing devices) 210 Remote offload server (accelerator-equipped server) (signal processing device) 220 Antenna Equipment 221 Antenna device data input / output unit 230 Post-processing device 231 Post-processing device data input / output unit 1000, 1000A, 1000B Accelerator State Control System

Claims

1. An accelerator state control device has a plurality of accelerators with different processing performances, and controls the state of the accelerators when specific processing of an application is offloaded to the accelerators for computation, When data with different processing deadlines is input, a recording unit that collects and records performance information of the accelerator; a prediction unit that predicts a traffic volume and a processing deadline after a predetermined time has elapsed based on a ratio of current and past traffic volumes and processing deadlines; a determination unit that determines a data volume corresponding to the processing deadline based on the traffic volume and the processing deadline after a predetermined time has elapsed, which are predicted by the prediction unit, and the performance of the accelerator recorded in the recording unit, and determines an accelerator that satisfies the performance based on the data volume. An accelerator state control device comprising:

2. a data processing deadline determination unit that identifies and notifies a processing deadline for input data; and an allocating unit that selects an accelerator that satisfies processing performance based on the processing deadline of the input data determined by the data processing deadline determining unit and the determination result of the determining unit, and allocates processing to the selected accelerator.

2. The accelerator state control device according to claim 1.

3. a latency recording unit that collects and records latency occurring in remote offloading between the signal processing devices equipped with the accelerator; The determination unit determines the amount of data corresponding to the processing deadline based on the latency recorded in the latency recording unit and the performance of the accelerator recorded in the recording unit, and determines an accelerator that satisfies the performance based on the amount of data.

2. The accelerator state control device according to claim 1.

4. An accelerator state control system has a plurality of accelerators with different processing performances, and is equipped with an accelerator state control device that controls the states of the accelerators when specific processing of an application is offloaded to the accelerators for computational processing, The accelerator state control device When data with different processing deadlines is input, a recording unit that collects and records performance information of the accelerator; a prediction unit that predicts a traffic volume and a processing deadline after a predetermined time has elapsed based on a ratio of current and past traffic volumes and processing deadlines; a determination unit that determines a data volume corresponding to the processing deadline based on the traffic volume and the processing deadline after a predetermined time has elapsed, which are predicted by the prediction unit, and the accelerator performance recorded in the recording unit, and determines an accelerator that satisfies the performance based on the data volume. An accelerator state control system comprising:

5. An accelerator state control method for an accelerator state control device that has a plurality of accelerators with different processing performances and controls the state of the accelerators when specific processing of an application is offloaded to the accelerators for computation, comprising: The accelerator state control device When data with different processing deadlines is input, collecting and recording accelerator performance information; a step of predicting a traffic volume and a processing deadline after a predetermined time has elapsed based on a ratio of current and past traffic volumes and processing deadlines; and determining a data volume corresponding to the processing deadline based on the predicted traffic volume and processing deadline after the lapse of a predetermined time and the recorded performance of the accelerator, and determining the accelerator that satisfies the performance based on the data volume.

1. A method for controlling an accelerator state, comprising:

6. An accelerator state control method for an accelerator state control system having a plurality of accelerators with different processing performances, the accelerator state control system controlling the states of the accelerators when specific processing of an application is offloaded to the accelerators for computation, comprising: The accelerator state control device When data with different processing deadlines is input, collecting and recording accelerator performance information; a step of predicting a traffic volume and a processing deadline after a predetermined time has elapsed based on a ratio of current and past traffic volumes and processing deadlines; and determining a data volume corresponding to the processing deadline based on the predicted traffic volume and processing deadline after the lapse of a predetermined time and the recorded performance of the accelerator, and determining an accelerator that satisfies the performance based on the data volume.

1. A method for controlling an accelerator state, comprising:

7. a computer having a plurality of accelerators with different processing performances, and configured as an accelerator state control device for controlling the state of the accelerators when specific processing of an application is offloaded to the accelerators for arithmetic processing; When data with different processing deadlines is input, procedures for collecting and recording accelerator performance information; a step of predicting a traffic volume and a processing deadline after a predetermined time has elapsed from a ratio of current and past traffic volumes and processing deadlines; a step of determining a data volume corresponding to the processing deadline based on the predicted traffic volume and processing deadline after a predetermined time has elapsed and the recorded performance of the accelerator, and determining an accelerator that satisfies the performance based on the data volume; A program to execute.

Images