WO2024028990A1 - アクセラレータ状態制御装置、アクセラレータ状態制御システム、アクセラレータ状態制御方法およびプログラム - Google Patents

アクセラレータ状態制御装置、アクセラレータ状態制御システム、アクセラレータ状態制御方法およびプログラム Download PDF

Info

Publication number
WO2024028990A1
WO2024028990A1 PCT/JP2022/029707 JP2022029707W WO2024028990A1 WO 2024028990 A1 WO2024028990 A1 WO 2024028990A1 JP 2022029707 W JP2022029707 W JP 2022029707W WO 2024028990 A1 WO2024028990 A1 WO 2024028990A1
Authority
WO
WIPO (PCT)
Prior art keywords
accelerator
processing
performance
data
state control
Prior art date
Application number
PCT/JP2022/029707
Other languages
English (en)
French (fr)
Inventor
奨悟 斎藤
廣 名取
育生 大谷
圭 藤本
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to PCT/JP2022/029707 priority Critical patent/WO2024028990A1/ja
Publication of WO2024028990A1 publication Critical patent/WO2024028990A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]

Definitions

  • the present invention relates to an accelerator state control device, an accelerator state control system, an accelerator state control method, and a program.
  • ACC Advanced Driver Assistance Function
  • GPU Graphics Processing Unit
  • ASIC Application Specific Integrated Circuit
  • vRAN virtual radio access network
  • FEC Forward Error Correction processing
  • a computer (hereinafter referred to as an accelerator-equipped server) is equipped with hardware for general-purpose processing (CPU) and hardware specialized for specific calculations (accelerator), and the accelerator is connected to a general-purpose processor running software.
  • CPU general-purpose processing
  • accelerator hardware specialized for specific calculations
  • the accelerator is connected to a general-purpose processor running software.
  • a configuration is adopted in which some calculation processing is offloaded to the system.
  • NWs networks
  • FIG. 14 is a diagram illustrating a computer system.
  • the server 50 includes a CPU 11 on the hardware 10, a plurality of accelerators (performance: high) 12-1 and accelerators (performance: low) 12-2 with different processing capacities, and an input/output unit 13. and an application (hereinafter referred to as APL as appropriate) 1 of software 20 that runs on the CPU 11 on the server 50.
  • APL application
  • the application 1 calls a standard defined function group (API) and offloads some processing to the accelerator 12.
  • API standard defined function group
  • a configuration in which a plurality of accelerators with different processing capabilities can be used is referred to as a "hetero-performance configuration.”
  • FIG. 14 there is a heterostructure of an accelerator (performance: high) 12-1 with high processing capacity and an accelerator (performance: low) 12-2 with low processing capacity. Note that when the accelerator (performance: high) 12-1 and the accelerator (performance: low) 12-2 are not distinguished, they are collectively referred to as the accelerator 12.
  • Accelerator 12 is a calculation accelerator device such as FPGA/GPU.
  • the accelerator 12 has an accelerator calculation circuit or program, and performs calculations using the accelerator calculation circuit or program.
  • the input/output unit 13 receives input data and outputs it.
  • the server 50 receives input data from the outside, performs arithmetic processing within the server, and then outputs the data to the outside.
  • the server 50 has assumptions regarding input data. (1) The amount of input data varies over time. For example, sudden traffic occurs when an event occurs in a RAN (Radio Access Network). (2) Each input data has a different processing deadline. For example, the processing deadline is the same for URLLC (Ultra-Reliable and Low Latency Communications) traffic (ultra-low latency) and eMBB (enhanced Mobile Broadband) traffic (low to medium) in 5G NR. (latency requirements). There is also a mix of URLLC traffic (ultra-low latency) and eMBB traffic (low to medium latency requirements) in 5G NR.
  • URLLC Ultra-Reliable and Low Latency Communications
  • eMBB enhanced Mobile Broadband
  • FIG. 15 is a diagram illustrating changes in the amount of input data to the server 50 and the details of the processing deadline.
  • the solid line in FIG. 15 indicates the total traffic amount, and the broken line in FIG. 15 indicates the traffic amount with a short processing deadline.
  • areas where the amount of traffic is prominent are sudden traffic.
  • An example of sudden traffic is caused by an event that increases traffic in a certain area of the RAN system (for example, a fireworks festival).
  • the requirements for satisfying the processing deadline of each input data for input data whose amount changes over time are as follows.
  • ⁇ Requirement 1 [Meeting each data processing deadline]
  • processing on the server must be completed within a certain amount of time from input so as to meet each deadline.
  • ⁇ Requirement 2 [Scalability] Processing performance can be scaled according to the amount of input traffic.
  • FIG. 16 is a diagram illustrating static accelerator allocation according to existing technology 1 (non-patent document 1). Components that are the same as those in FIG. 14 are given the same reference numerals.
  • the server 50 is equipped with a CPU 11 and a plurality of accelerators (performance: high) 12-1 and accelerators (performance: low) 12-2 with different processing capacities on the hardware 10. It includes an application 1 of software 20 that runs on a CPU 11 on a server 50.
  • the server 50 fixedly allocates accelerators to traffic of a certain amount and a certain processing deadline ratio (double line a in FIG. 18).
  • fixed allocation is performed in which the accelerator (performance: high) 12-1 is fixedly allocated to the application 1.
  • the processing deadline for each input data is designed on the assumption that it is a constant value.
  • FIG. 17 is a diagram illustrating fluctuations in the amount of input data in existing technology 1.
  • the solid line in FIG. 17 indicates the total traffic amount, and the broken line in FIG. 17 indicates the traffic amount for which the system can ensure responsiveness.
  • the amount of traffic (dashed line in FIG. 17) for which the system can ensure responsiveness is constant.
  • accelerators are statically allocated according to the maximum amount of traffic during normal times. Therefore, when the amount of input data suddenly increases, the processing capacity is insufficient (white arrow b in FIG. 17).
  • Non-Patent Document 1 a technology for realizing the scale of ACC using a function proxy in an accelerator-equipped server.
  • FIG. 18 is a diagram illustrating the implementation of the ACC scale using the function proxy of existing technology 2. Components that are the same as those in FIG. 14 are given the same reference numerals.
  • the software 20 of the server 50 includes proxy software 2.
  • the proxy software 2 includes a function proxy 3 and an accelerator I/O control unit 4 that performs input/output control for the accelerator using the function proxy 3.
  • the server 50 dynamically allocates accelerators by scaling out using the function proxy 3 of the ACC utilization function (double line c in FIG. 18).
  • proxy software 2 dynamically allocates the processing of application 1 to accelerator (performance: high) 12-1 or accelerator (performance: low) 12-2.
  • FIG. 19 is a diagram illustrating a processing deadline in existing technology 2.
  • the solid line in FIG. 19 shows the total traffic amount
  • the broken line in FIG. 19 shows the traffic amount with a short processing deadline
  • the double line in FIG. 19 shows the traffic amount that can ensure responsiveness.
  • the white arrow c in FIG. 19 there is a moment when the allocated ACC cannot meet the deadline. In particular, when the proportion of traffic that requires low-latency processing increases, responsiveness cannot be satisfied.
  • Existing technologies 1 and 2 have the following problems.
  • Existing technology 1 static allocation
  • ⁇ Requirement 2 Scalability>.
  • Existing technology 2 scaling out using function proxies
  • ⁇ Requirement 1 Meeting the processing deadline of each data>.
  • the present invention was made in view of this background, and the present invention aims to improve usage while ensuring responsiveness in response to fluctuations in the amount of data corresponding to each processing deadline in a server equipped with an accelerator with a heterogeneous configuration.
  • the goal is to reduce the computational resources needed to
  • 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 accelerator when offloading specific processing of an application to the accelerator for arithmetic processing.
  • a recording unit that collects and records performance information of the accelerator, and a predetermined time elapsed from the ratio of the current and past traffic amount to the processing deadline.
  • a prediction unit that predicts a subsequent traffic amount and processing deadline; a prediction unit that predicts the traffic amount and the processing deadline after a predetermined time period predicted by the prediction unit; and the performance of the accelerator recorded in the recording unit.
  • a determination unit that determines the amount of data corresponding to the processing deadline and determines an accelerator that satisfies the performance based on the amount of data.
  • FIG. 1 is a schematic configuration diagram of an accelerator state control system according to an embodiment of the present invention.
  • 1 is a schematic configuration diagram of an accelerator state control system according to an embodiment of the present invention.
  • FIG. 2 is a schematic configuration diagram showing variations in the arrangement of accelerator state control devices of an accelerator state control system according to an embodiment of the present invention. It is a figure showing an example of the DB table of the accelerator state control device of the accelerator state control system concerning an embodiment of the present invention. It is a figure showing an example of the latency table of the accelerator state control device of the accelerator state control system concerning an embodiment of the present invention. It is a figure showing an example of an ACC function/argument data packet composition of an accelerator state control device of an accelerator state control system concerning an embodiment of the present invention.
  • FIG. 6 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.
  • 3 is a flowchart showing operation 1 of the arithmetic device allocation determination section and the traffic amount/processing deadline prediction section of the accelerator state control device of the accelerator state control system according to the embodiment of the present invention.
  • 12 is a flowchart showing operation 2 of the arithmetic unit allocation determination section and the traffic amount/processing deadline prediction section of the accelerator state control device of the accelerator state control system according to the embodiment of the present invention.
  • It is a flowchart which shows arithmetic unit allocation (ACC allocation) of an accelerator state control device of an accelerator state control system concerning an embodiment of the present invention.
  • FIG. 1 is a hardware configuration diagram showing an example of a computer that implements the functions of an accelerator state control system according to an embodiment of the present invention.
  • FIG. 1 is a diagram illustrating a computer system.
  • FIG. 3 is a diagram illustrating changes in the amount of input data to the server and the breakdown of processing deadlines.
  • FIG. 2 is a diagram illustrating static accelerator allocation according to existing technology 1 (non-patent document 1).
  • FIG. 2 is a diagram illustrating changes in the amount of input data in existing technology 1;
  • FIG. 7 is a diagram illustrating implementation of ACC scale using a function proxy according to existing technology 2;
  • FIG. 6 is a diagram illustrating a processing deadline in existing technology 2.
  • FIG. 1 is a schematic configuration diagram of an accelerator state control system according to an embodiment of the present invention.
  • FIG. 1 is an example in which the present invention is applied to a look-aside type accelerator that "explicitly offloads data obtained through an input/output unit such as a NIC from the CPU to the accelerator.”
  • the CPU offloads part of the processing to the accelerator.
  • the state of the look-aside type accelerator is managed by the CPU.
  • the accelerator state control system 1000 includes a server 200 ([signal processing device]), a remote offload server 210, an antenna device 220, and a downstream processing device 230. Further, the accelerator state control system 1000 includes an accelerator state control device 100 that controls the state of the accelerator 12 when offloading specific processing of the application 1 to the accelerator 12 for calculation processing.
  • the server 200 is a distributed unit in 5G signal processing.
  • the server 200 includes hardware (HW) 10 and software 20.
  • the hardware 10 includes a CPU (Central Processing Unit) 11, a plurality of accelerators (performance: high) 12-1, accelerators (performance: low) 12-2, an accelerator 12, and an input/output unit 13 with different processing capacities. , and a remote offload input/output unit (client) (NIC) 14.
  • CPU Central Processing Unit
  • NIC remote offload input/output unit
  • the CPU 11 executes the processing of the application 1 and also executes the software of each functional unit in the server 200.
  • Accelerator 12 is a calculation accelerator device such as FPGA/GPU.
  • the accelerator 12 is a computing machine installed in the server 200 and specialized for specific processing. Examples of the form of connection to the CPU 11 via a bus include an ASIC-equipped accelerator, an FPGA-equipped accelerator, and a GPU.
  • This embodiment uses a "performance heterogeneous configuration" that can utilize multiple accelerators with different processing capabilities.
  • the plurality of accelerators with different processing capabilities are accelerator (performance: high) 12-1 and accelerator (performance: low) 12-2.
  • 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 (antenna device 220 and subsequent processing device 230).
  • the input/output unit 13 also has an interface that notifies the application 1 of the current amount of data input.
  • NIC remote offload input/output unit
  • server remote offload input/output unit 14
  • NIC remote offload input/output unit 14
  • NICs network interface devices represented by NICs, and have the function of communicating between servers. Department.
  • the software 20 includes an application 1 and an accelerator state control device 100 that controls the state of the accelerator.
  • the application 1 is a program that performs signal processing, and operates on the CPU 11.
  • dedicated processing that is not suitable for the CPU, such as some parallel calculation processing, use the accelerators 12 (accelerator (high performance) 12-1, accelerator (performance: low) 12-2, accelerator (performance: high) 12-3).
  • the application 1 calls a group of functions (API) defined as a standard and offloads some processing to the accelerator 12.
  • API group of functions
  • the application 1 receives processing target data from the input/output unit 13 as input. As output, the calculated data is passed to the input/output unit 13.
  • the input/output unit 13, the CPU 11, and the accelerator 12 are configured as separate hardware, but they may be integrated into a dedicated hardware form.
  • a so-called Look-Aside type accelerator application form in which "data obtained through the 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 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.
  • the accelerator state control device 100 includes a processing device performance collection/recording section 110, a remote offload latency collection/recording section 120 (latency recording section), a processing device allocation judgment section 130, a data processing deadline judgment section 140, It includes a traffic amount/processing deadline prediction section 150, a function proxy execution section 160, an arithmetic device distribution section 170, and a remote offload section 180.
  • the arithmetic device performance collection/recording section 110, remote offload latency collection/recording section 120, and arithmetic device allocation judgment section 130 constitute the allocation judgment function section 101.
  • the data processing deadline determination section 140 and the traffic amount/processing deadline prediction section 150 constitute the prediction function section 102.
  • the function proxy execution section 160 and the arithmetic device distribution section 170 constitute the distribution function section 103.
  • the computing device performance collection/recording unit 110 collects and records the performance of each computing device (CPU 11, accelerator (performance: high) 12-1, accelerator (performance: low) 12-2). Performance information includes throughput, processing latency, and power consumption.
  • the computing device performance collection/recording unit 110 stores accelerator information of each host based on static settings input by an operator.
  • the computing device performance collection/recording unit 110 has performance information for each computing device based on an identifier for uniquely identifying each computing device.
  • - Configuration Example An example of the database configuration of the recording device is shown in the example of the DB table 300 (FIG. 4) of the arithmetic device performance collection/recording unit 110.
  • - Input/Output The computing device performance collection/recording unit 110 accepts necessary accelerator conditions such as specific performance and host identifier as input, and responds with a list of accelerators that match the input conditions as output. .
  • the computing device performance collection/recording unit 110 may automatically collect information using an external configuration management tool or a command for acquiring device configuration information.
  • the remote offload latency collection/recording unit 120 collects communication latency (latency) that occurs during remote offloading between a signal processing device equipped with an accelerator (here, a remote offloading server 210 that is a separate server from the server 200). Collect and record.
  • the remote offload latency collection/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 the DB table 300 of the arithmetic device performance collection/recording unit 110.
  • the remote offload latency collection/recording unit 120 receives a specific combination of host information as input, calculates latency from the combination of host information received as input, and responds as output.
  • the remote offload latency collection/recording unit 120 may be configured to automatically collect information and update latency. Specifically, a latency measurement function (not shown) installed in each host may measure communication delays to other hosts at regular intervals and update information in the remote offload latency collection/recording unit 120.
  • the processing unit allocation determination unit 130 calculates the traffic volume and processing deadline after a predetermined period of time predicted by the traffic volume/processing deadline prediction unit 150, and the performance information of the accelerator 12 recorded in the processing unit performance collection/recording unit 110. Based on this, the amount of data corresponding to the processing deadline is determined, and an accelerator that satisfies the performance is determined based on the amount of data.
  • the computing device allocation determining unit 130 determines a computing device that satisfies the performance based on the traffic amount after a certain period of time and the processing deadline, and allocates it to the computing device allocating unit 170.
  • the arithmetic unit allocation determination unit 130 receives the traffic amount after a certain period of time and its processing deadline from the traffic amount/processing deadline prediction unit 150. Based on this performance request, the computing device allocation determining section 130 queries the computing device performance collecting/recording section 110 and the remote offload latency collecting/recording section 120 to obtain a list of accelerators. Based on this information, the processing unit allocation determination unit 130 obtains a list of local accelerators and remote offload destination accelerators.
  • the arithmetic device allocation determination unit 130 receives as input the traffic amount and the processing deadline ratio after a certain period of time has elapsed, and responds with a list of accelerators that match the input conditions as output.
  • the arithmetic unit allocation determination unit 130 may automatically collect information using an external configuration management tool or a command for acquiring device configuration information.
  • the data processing deadline determining unit 140 identifies the processing deadline of each input data and notifies each functional unit.
  • the data processing deadline determination unit 140 receives input data from the input/output unit 13, refers to the header information at the beginning of the input data, and identifies the processing deadline.
  • the processing deadline for the data is identified by referring to the eCPRI (enhanced common public radio interface) protocol header and identifying the session information.
  • the data processing deadline determination section 140 receives input data from the input/output section 13 as an input, and sends the traffic amount and processing deadline to the traffic amount/processing deadline prediction section 150 as an output. Notify the percentage.
  • the traffic amount/processing deadline prediction unit 150 predicts the traffic amount and processing deadline after a certain period of time has elapsed from the ratio of the current and past traffic amounts and processing deadlines.
  • the traffic amount/processing deadline prediction unit 150 receives the ratio between the traffic amount and the processing deadline from the data processing deadline determination unit 140, and multiplies the input traffic amount by the ratio of each processing deadline. Calculate the amount of traffic type.
  • the traffic amount/processing deadline prediction unit 150 predicts whether the traffic amount for each deadline is increasing or decreasing.
  • the traffic volume/processing deadline prediction unit 150 receives the current traffic volume and processing deadline ratio of input data as input, and outputs the predicted traffic volume and processing deadline after a certain period of time has elapsed as output. , and notifies the arithmetic unit allocation determination unit 130.
  • the traffic amount/processing deadline prediction unit 150 predicts the traffic amount and processing deadline in the RAN system by using a method of predicting based on current traffic trends, as well as a method based on the time zone at the relevant traffic generation point. Predictions may be made based on trends and the occurrence of events where people gather in the vicinity. Specifically, a method can be considered that predicts that the amount of traffic from base stations along train lines will be high during the period from the first train to the last train, and low at other times. Alternatively, an increase in traffic may be predicted in advance based on information about events (such as fireworks festivals) where people gather near a base station at a certain point.
  • events such as fireworks festivals
  • the function proxy execution unit 160 provides the application with the same interface as the function provided by the existing accelerator access library, and executes the actual function on behalf of the application.
  • the function proxy execution unit 160 is provided as a library for an application, and is 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.
  • the function proxy execution unit 160 receives the function name and arguments from the application 1 as input, and notifies the arithmetic unit distribution unit 170 of the function name and arguments as output.
  • the function proxy execution unit 160 receives the processing result from the arithmetic device distribution unit 170 as an input, and notifies the application 1 of the processing result as an output.
  • the arithmetic device distribution unit 170 distributes input data to pre-allocated arithmetic devices.
  • the processing unit allocation unit 170 selects and selects an accelerator that satisfies the processing performance based on the input data processing deadline determined by the data processing deadline determination unit 140 and the determination result of the calculation unit allocation determination unit 130.
  • the processing is distributed to the accelerators.
  • the arithmetic device allocating unit 170 selects an arithmetic device that satisfies the processing performance based on the processing deadline information included in each input data, and allocates the processing.
  • the arithmetic device allocation section 170 inquires of the data processing deadline determination section 140 about the processing deadline information of each data, and determines the data processing deadline.
  • the arithmetic device allocation section 170 receives as input a list of available arithmetic devices from the arithmetic device allocation determination section 130 and also receives processing target data from the function proxy execution section 160.
  • the arithmetic device distribution section 170 sends the processing target data to either the CPU 11, the accelerator 12, or the remote offload section 180 as output.
  • the arithmetic device distribution section 170 inputs input data to the data processing deadline determination section 140 and receives the processing deadline of the corresponding data from the data processing deadline determination section 140 .
  • the arithmetic unit distribution unit 170 receives processing results from the CPU 11, the accelerator 12, and the remote offload input/output unit 14 as input, and notifies the function proxy execution unit 160 of the processing results as output.
  • the arithmetic unit distribution unit 170 distributes accelerators based on processing deadline information and traffic volume, other priority information may be used. Specifically, the priority information includes securing accelerators for maintenance necessary for continuous operation of the system.
  • each calculation device (remote offload latency collection/recording unit 120, accelerator 12, remote offload input/output unit 14) is sent to the function proxy execution unit via the calculation device distribution unit 170.
  • each arithmetic device (remote offload latency collection/recording unit 120, accelerator 12, remote offload input/output unit 14) may directly respond to the function proxy execution unit 160.
  • 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 the embodiment is shown in FIG.
  • the remote offload unit 180 receives the “function name/argument” from the arithmetic unit distribution unit 170 as input, and passes the “transmission data” to the remote offload input/output unit 14 as output.
  • the remote offload unit 180 receives “processing result data” from the remote offloading input/output unit 14 as an input, and passes the processing result data to the arithmetic device distribution unit 170 as an output.
  • the data format may be not only an L2 frame but also data with L3 and L4 headers added.
  • the packet format may include not only the function name and arguments but also an ID that can uniquely identify the accelerator to be used. Furthermore, if the argument size is large, a function of dividing into multiple packets may be provided.
  • the remote offload server 210 includes hardware (HW) 10 and software 20.
  • the hardware 10 includes a CPU 11, an accelerator (remote) (high performance) 12-3, and a remote offload input/output unit (server) (NIC) 14.
  • NIC remote offload input/output unit
  • 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.
  • the accelerator (remote) (performance: high) 12-3 is a calculation accelerator device such as FPGA/GPU.
  • the accelerator (remote) (performance: high) 12-3 is a computing machine that is installed in the remote offload server 210 and is specialized for specific processing. Examples of the form of connection to the CPU 11 via a bus include an ASIC-equipped accelerator, an FPGA-equipped accelerator, and a GPU.
  • This embodiment uses a "performance heterogeneous configuration" that can utilize multiple accelerators with different processing capabilities.
  • the plurality of accelerators with different processing capacities are accelerator (performance: high) 12-1 installed in the server 200, accelerator (performance: low) 12-2, and accelerator (remote) installed in the remote offload server 210 ( Performance: High) 12-3.
  • the software 20 includes a remote offload reception unit 211.
  • the remote offload reception unit 211 offloads the processing target data received via the network to the accelerator (remote) 12-3, and responds with the result.
  • the remote offload reception unit 211 receives data in the format shown in FIG. 6 as input, and performs processing offload to the accelerator (remote) 12-3 as output.
  • the remote offload reception unit 211 receives the offload result from the accelerator (remote) 12-3 as an input, and responds with the processing result as an output as data in the format shown in FIG.
  • the antenna device 220 is an antenna and a transmitting/receiving unit that wirelessly communicates with a terminal (UE: User Equipment) (hereinafter, the “antenna device” refers to the antenna, the transmitting/receiving unit, and its power supply unit).
  • UE User Equipment
  • the transmitted and received data is connected to a signal processing device (server 200) of a base station (BBU: Base Band Unit) by, for example, a dedicated cable.
  • BBU Base Band Unit
  • the antenna device 220 includes an antenna device data input/output section 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 a NIC or the like.
  • the post-processing device 230 is a Centralized Unit in 5G signal processing.
  • the subsequent processing device 230 includes a subsequent 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.
  • the input/output unit 13, the CPU 11, and the accelerator 12 are configured as separate hardware, but the CPU 11, the accelerator 12, and the accelerator calculation circuit/program 12a may be integrated into a dedicated hardware form.
  • the so-called In- A line type accelerator application mode sequences in FIGS. 12A-12C
  • the CPU 11 and the accelerator 12 may be mounted on a single chip, such as a system on chip (SoC).
  • SoC system on chip
  • 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 application form of an in-line type accelerator. Components that are the same as those in FIG. 1 are denoted by the same reference numerals, and explanations of overlapping parts will be omitted.
  • the accelerator state control device 100A of the server 200A in the in-line accelerator application form shown in FIG. The line doesn't exist.
  • the accelerator state control device 100A of the server 200 in the in-line accelerator application mode shown in FIG. The server 200A in which an in-line type accelerator is applied copies data directly from the NIC to the accelerator.
  • the accelerator performs calculations autonomously like a dedicated circuit.
  • An accelerator state control system 1000 in FIG. 1 is an example in which an accelerator state control device 100 is placed in software 20 of a server 200. Part of the functions of the accelerator state control device 100 can be installed in a separate housing outside the server 200, as exemplified below.
  • FIG. 3 is a schematic configuration diagram showing variations in the arrangement of the accelerator state control device of the accelerator state control system.
  • the variation shown in FIG. 3 includes a processing device performance collection/recording section 110, a remote offload latency collection/recording section 120, a processing device allocation judgment section 130, a data processing deadline judgment section 140, and a traffic amount/processing deadline estimation section.
  • the controller function section consisting of 150 is housed in a separate housing.
  • the accelerator state control system 1000B includes an accelerator state control device 100B installed in a separate housing outside the server 200.
  • the software 20 of the server 200 includes an application 1, a function proxy execution section 160, and an arithmetic device distribution section 170.
  • the accelerator state control device 100B has the controller function section installed outside the server 200, and has the same functions as the accelerator state control devices 100 and 100A shown in FIGS. 1 and 2.
  • FIG. It can support function deployment to RIC (RAN Intelligent Controller).
  • the input amount can be predicted based on the input amount obtained from multiple server machines (Function 1), which has the advantage of increasing the traffic prediction accuracy of Function 1. .
  • server machines Faction 1
  • the amount of traffic in a processing area handled by a certain server machine increases, it is assumed that the amount of input in nearby processing areas will also fluctuate with a delay.
  • FIG. 4 is a diagram showing an example of the DB table 300 of the arithmetic device performance collection/recording unit 110.
  • the DB table 300 holds accelerator identifiers (CPU, FPGA, ASIC), ACC performance (throughput), ACC performance (processing latency), and ACC performance (power consumption) for each installed host information.
  • the installed host information "Host-1 (192.168.0.1: Server URL)” is the accelerator identifier "FPGA-1”, ACC performance (throughput) "10.0 Gbps”, ACC performance (processing latency) "5.0 ⁇ s”, ACC Performance (power consumption) is 120.0 W.
  • Each ACC performance is recorded in association with the installed host information, and by specifying the installed host information, each ACC performance of the host can be known.
  • FIG. 5 is a diagram showing an example of the latency table 310 of the remote offload latency collection/recording unit 120.
  • the latency table 310 holds (records) access source host information, access destination host information, and latency. For example, if the access source host information "Host-1 (192.168.0.1: server URL)" connects to the access destination host information "Host-2 (192.168.0.2)", the latency (connection latency/communication latency) will be "30 ⁇ s”. ”.
  • FIG. 6 is a diagram showing a configuration example of the ACC function/argument data packet 320 of the remote offload unit 180.
  • the ACC function/argument data packet 320 includes an L2 frame (0 to 14 bytes), a function ID (to 34 bytes), a final data bit (to 42 bytes), an argument 1 (to 46 bytes), and an argument 2 (to 50byte).
  • the ACC function/argument data packet 320 has a data structure suitable for parsing in an FPGA circuit by setting each data to a fixed length and a fixed position.
  • the control bit adds control information to the packet.
  • the ACC function/argument data packet 320 has a function of dividing into multiple packets, for example, when the argument size is large. At this time, control data for notifying the final packet is added to the "control bit" of the last divided packet.
  • the packet format shown in FIG. 6 may include an L3 header and an L4 header in the header.
  • an ID that can uniquely identify the accelerator to be used may be included.
  • FIG. 7 is a diagram showing an example of calculating the available ACC list 330 from Host-1.
  • the available ACC list 330 includes the DB table 300 of the computing device performance collection/recording unit 110 shown in FIG. 4 and the latency table 310 of the remote offload latency collection/recording unit 120 shown in FIG. Created based on
  • the available ACC list 330 can list ACC performance (throughput), ACC performance (processing latency), and ACC performance (power consumption) when a host uses another host.
  • the computing unit allocation determining unit 130 selects a combination of accelerators that satisfies performance and consumes the least amount of power from the list in the DB table 300 of the computing unit performance collection/recording unit 110 shown in FIG. Notice. However, if the relevant accelerator is located remotely via a network, remote latency is also taken into consideration. Using this available ACC list 330, the computing device allocation determining unit 130 determines a computing device that satisfies the performance while also considering remote latency, and allocates it to the computing device allocating unit 170.
  • FIG. 8 is a flowchart showing operation 1 of the arithmetic unit allocation determination section 130 and the traffic volume/processing deadline prediction section 150.
  • FIG. 8 is the case when the traffic volume or the proportion of traffic with high processing deadlines increases.
  • step S11 the traffic amount/processing deadline prediction unit 150 obtains the ratio of the input traffic amount/processing deadline length.
  • the traffic amount/processing deadline prediction unit 150 multiplies the input traffic amount by the ratio of each processing deadline to calculate the amount of each traffic type.
  • step S13 the traffic amount/processing deadline prediction unit 150 determines whether the total amount of traffic or the amount of traffic with a short processing deadline has increased continuously for a predetermined number of times or more. If the total amount of traffic or the amount of traffic with a short processing deadline has not increased continuously for a certain number of times or more (S12: No), the process returns to step S11.
  • the processing unit performance collection/recording unit 110 determines that the processing unit performance can be used in step S14.
  • a list of computing devices (DB table 300 in FIG. 4) is issued (hereinafter, "disbursement” refers to extracting information and responding).
  • step S15 the arithmetic unit allocation determining unit 130 determines whether the predicted traffic amount is larger than the current processing capacity. If the predicted traffic amount is larger than the current processing capacity (S15: Yes), in step S16 the arithmetic unit allocation determination unit 130 determines that the predicted “traffic amount with a short processing deadline” is larger than the current processing capacity. Determine whether the value is higher than that.
  • step S17 the arithmetic unit allocation determination unit 130 determines that the traffic performance is higher than the current one and the real-time performance is higher than the current processing capacity. A calculation device with a high value is selected and re-payout is performed, and the process proceeds to step S20.
  • step S18 the arithmetic unit allocation determination unit 130 determines that the traffic performance is higher than the current one and that the real-time An arithmetic device with similar or better performance is selected and paid out again, and the process proceeds to step S20.
  • step S15 the traffic volume predicted in step S15 is less than the current processing capacity (S15: No), the traffic volume does not increase and the "proportion of traffic with a high processing deadline" is high.
  • step S19 the arithmetic device allocation determining unit 130 selects and re-distributes a computing device that has the same or better traffic performance and higher real-time performance than the current situation, and proceeds to step S20.
  • step S20 the computing device allocation determining unit 130 notifies the computing device allocating unit 170 of the selection result, and ends the processing of this flow.
  • FIG. 9 is a flowchart showing operation 2 of the arithmetic unit allocation determination section 130 and the traffic amount/processing deadline prediction section 150.
  • FIG. 9 shows the case where the traffic volume or the proportion of traffic with high processing deadlines decreases.
  • step S21 the traffic amount/processing deadline prediction unit 150 obtains the input traffic amount/processing deadline ratio.
  • step S22 the traffic amount/processing deadline prediction unit 150 determines whether the total amount of traffic or the proportion of traffic with high latency requirements has decreased continuously for a certain number of times or more.
  • step S23 the arithmetic device performance collection/recording unit 110 determines whether the available A list of computing devices (DB table 300 in FIG. 4) is issued.
  • step S24 the arithmetic unit allocation determining unit 130 determines whether the predicted traffic amount is smaller than the current processing capacity. If the predicted traffic amount is smaller than the current processing capacity (S24: Yes), in step S25 the arithmetic unit allocation determination unit 130 determines that the predicted “traffic amount with a short processing deadline” is smaller than the current processing capacity. Determine whether or not the value is lower.
  • step S26 the arithmetic unit allocation determination unit 130 determines that the traffic performance is higher than the current one and the real-time performance is higher than the current processing capacity. After selecting the arithmetic device with the lowest value and paying out again, the process proceeds to step S29.
  • step S27 the arithmetic unit allocation determination unit 130 determines that the traffic performance is lower than the current one and that real-time An arithmetic device with similar or better performance is selected and paid out again, and the process proceeds to step S29.
  • step S24 if the traffic volume predicted in step S24 is greater than or equal to the current processing capacity (S24: No), the traffic volume does not decrease and the "proportion of traffic with high latency requests" decreases. If so, in step S28, the arithmetic device allocation determining unit 130 selects and re-distributes the arithmetic device with the same or higher traffic performance and lower real-time performance than the current one, and proceeds to step S29.
  • step S29 the computing device allocation determining unit 130 notifies the computing device allocating unit 170 of the selection result, and ends the processing of this flow.
  • FIG. 10 is a flowchart showing arithmetic unit allocation (ACC allocation).
  • the input/output unit 13 inputs and outputs data.
  • step S32 the data processing deadline determining unit 140 identifies the processing deadline of each input data and notifies each functional unit.
  • the data processing deadline determination unit 140 receives input data from the input/output unit, refers to the header information at the beginning of the input data, and identifies the processing deadline.
  • step S33 the traffic amount/processing deadline prediction unit 150 predicts the traffic amount and processing deadline after a certain period of time has elapsed from the ratio of the current and past traffic amounts and processing deadlines.
  • the traffic amount/processing deadline prediction unit 150 receives the traffic amount and latency request from the data processing deadline determination unit 140, and predicts whether the proportions of traffic and latency requests are each on an increasing trend.
  • step S34 the arithmetic device allocation unit 170 determines the arithmetic device that satisfies the performance based on the traffic amount after a certain period of time and the processing deadline, and allocates it to the arithmetic device allocation unit 170.
  • step S35 the arithmetic device distribution unit 170 distributes the input data to the pre-assigned arithmetic devices. Based on the processing deadline information included in each input data, the arithmetic device allocating unit 170 selects an arithmetic device that satisfies the processing performance, allocates the processing, and ends the processing of this flow.
  • FIGS. 11A-11C are flowcharts illustrating input data processing. 11A-11C correspond to Look-Aside type accelerator applications. Note that although FIGS. 11A to 11C are one flow, for convenience of illustration, they are connected using [A], [B], and [C] as connectors.
  • the antenna device data input/output unit 221 of the antenna device 220 sends the signal generated by the antenna device 220 to the server 200 in step S41.
  • step S42 the input/output unit 13 inputs and outputs data to and from an external device (antenna device 220).
  • step S43 the application 1 receives the data to be processed from the input/output unit 13, and passes the calculated data to the input/output unit 13.
  • step S44 the function proxy execution unit 160 receives the function name and arguments from the application as input, and notifies the arithmetic unit distribution unit 170 of the function name and arguments as output.
  • step S45 the processing unit distribution unit 170 receives the processing target data from the function proxy execution unit 160, and transfers the processing target data to either the CPU 11, the accelerator 12, or the accelerator [remote] 12-3 of the remote offload server. Send.
  • step S46 the arithmetic device distribution unit 170 determines whether the distribution destination is one of the following. If the distribution destination is the CPU, the CPU 11 executes the software in step S47 of FIG. 11C and proceeds to step S59. If the allocation destination is accelerator 1 (accelerator 12-1), in step S48 of FIG. 11C, accelerator [performance: high] 12-1 executes a process specialized for a specific process, and proceeds to step S59.
  • accelerator 1 accelerator 12-1
  • step S48 of FIG. 11C accelerator [performance: high] 12-1 executes a process specialized for a specific process, and proceeds to step S59.
  • step S49 of FIG. 11C accelerator [performance: low] 12-2 executes a process specialized for a specific process, and proceeds to step S59. If the distribution destination is the accelerator [remote] (accelerator 12-3), the process advances to step S50 in FIG. 11B.
  • step S50 the remote offload section 180 receives the "function name/argument" from the arithmetic unit distribution section 170 as input, and passes "transmission data" to the remote offload input/output section 14 as output.
  • step S51 the remote offload input/output unit [client] 14 performs communication between the remote offload servers.
  • step S52 the remote offload input/output unit [server] 14 performs communication between servers.
  • step S53 the remote offload reception unit 211 receives the data in the format shown in FIG. 6 as input, and performs processing offload to the accelerator [remote] 12-3 as output.
  • step S54 the accelerator [remote] 12-3 performs calculations specialized for specific processing.
  • step S55 the remote offload reception unit 211 receives the offload result from the accelerator [remote], and responds with the processing result as data in the format shown in FIG.
  • step S56 the remote offload input/output unit [server] 14 performs communication between servers.
  • step S57 the remote offload input/output unit [client] 14 performs communication between the remote offload servers.
  • step S58 the remote offload section 180 receives "processing result data" from the remote offloading input/output section 14 as an input, passes the processing result data to the arithmetic device distribution section 170 as an output, and then passes the processing result data to the processing device distribution section 170 as an output. Proceed to S59.
  • step S59 of FIG. 11C the function proxy execution unit 160 receives the processing result from the arithmetic unit distribution unit 170 as an input, and notifies the application of the processing result as an output.
  • step S60 the arithmetic device distribution unit 170 receives processing results from the CPU, accelerator 12, and remote offload input/output unit 14 as input, and notifies the function proxy execution unit 160 of the processing results as output.
  • step S61 the application 1 receives processing target data from the input/output unit 13 as input, and passes the calculated data to the input/output unit 13 as output.
  • step S62 the downstream processing device data input/output unit 231 of the downstream processing device 230 receives the signal processing result processed by the server, and ends the processing of this flow.
  • 12A-12C are flowcharts illustrating input data processing. 12A-12C correspond to in-line accelerator applications. The same step numbers are given to the same processes as in FIGS. 11A to 11C. Note that although FIGS. 12A to 12C are one flow, for convenience of illustration, they are connected using [A], [B], and [C] as connectors.
  • the antenna device data input/output unit 221 of the antenna device 220 sends the signal generated by the antenna device 220 to the server 200 in step S41.
  • the input/output unit 13 inputs and outputs data to and from an external device (antenna device 220).
  • step S45 the processing unit distribution unit 170 receives the processing target data from the function proxy execution unit 160, and transfers the processing target data to either the CPU 11, the accelerator 12, or the accelerator [remote] 12-3 of the remote offload server. Send.
  • step S46 the arithmetic device distribution unit 170 determines whether the distribution destination is one of the following. If the distribution destination is the CPU, the CPU 11 executes the software in step S47 of FIG. 12C and proceeds to step S59.
  • step S48 of FIG. 12C accelerator [performance: high] 12-1 executes a process specialized for a specific process, and proceeds to step S59.
  • accelerator 2 accelerator [performance: low] 12-2 executes a process specialized for a specific process, and proceeds to step S59.
  • the distribution destination is the accelerator [remote] (accelerator 12-3), the process advances to step S50 in FIG. 12B.
  • step S50 the remote offload section 180 receives the "function name/argument" from the arithmetic device distribution section 170 as input, and passes "transmission data" to the remote offload input/output section 14 as output.
  • step S51 the remote offload input/output unit [client] 14 performs communication between the remote offload servers.
  • step S52 the remote offload input/output unit [server] 14 performs communication between servers.
  • step S53 the remote offload reception unit 211 receives the data in the format shown in FIG. 6 as input, and performs processing offload to the accelerator [remote] 12-3 as output.
  • step S54 the accelerator [remote] 12-3 performs calculations specialized for specific processing.
  • step S55 the remote offload reception unit 211 receives the offload result from the accelerator [remote], and responds with the processing result as data in the format shown in FIG.
  • step S56 the remote offload input/output unit [server] 14 performs communication between servers.
  • step S57 the remote offload input/output unit [client] 14 performs communication between the remote offload servers.
  • step S58 the remote offload section 180 receives "processing result data" from the remote offloading input/output section 14 as an input, passes the processing result data to the arithmetic device distribution section 170 as an output, and then passes the processing result data to the processing device distribution section 170 as an output. Proceed to S59.
  • step S59 of FIG. 12C the function proxy execution unit 160 receives the processing result from the arithmetic unit distribution unit 170 as an input, and notifies the application of the processing result as an output.
  • step S60 the arithmetic device distribution unit 170 receives processing results from the CPU, accelerator 12, and remote offload input/output unit 14 as input, and notifies the function proxy execution unit 160 of the processing results as output.
  • step S61 the application 1 receives processing target data from the input/output unit 13 as input, and passes the calculated data to the input/output unit 13 as output.
  • step S62 the downstream processing device data input/output unit 231 of the downstream processing device 230 receives the signal processing result processed by the server, and ends the processing of this flow.
  • the accelerator state control device 100 (FIG. 1) of the accelerator state control system 1000, 1000A (FIGS. 1 and 2) according to the above embodiments is realized, for example, by a computer 900 having a configuration as shown in FIG. 13.
  • FIG. 13 is a hardware configuration diagram showing an example of a computer 900 that implements 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, an 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.
  • Accelerator 905 corresponds to accelerator 12 in FIGS. 1 and 2.
  • 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.
  • the accelerator 905 may be of a type (look-aside type) that returns the execution result to the CPU 901 or the RAM 902 after executing processing from the CPU 901 or the RAM 902.
  • a type (in-line type) that is inserted between the communication I/F 908 and the CPU 901 or the RAM 902 and performs processing may be used.
  • 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 the input/output device 916.
  • the media I/F 907 reads and writes data from the recording medium 917.
  • the CPU 901 operates based on a program stored in the ROM 903 or HDD 904, and executes the program (also called an application or an abbreviation thereof) read into the RAM 902, thereby controlling the accelerator state control device shown in FIGS. 1 and 2. Controls each part of 100 and 100A.
  • 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 depending on the hardware of the computer 900, and the like.
  • the CPU 901 controls an input/output device 916 including an input unit such as a mouse and a keyboard, and an output unit 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.
  • a GPU Graphics Processing Unit
  • GPU Graphics Processing Unit
  • 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 (for example, NW (Network)) and outputs it to the CPU 901, and also outputs data generated by the CPU 901 to other devices via the communication network. Send to.
  • NW Network
  • the media I/F 907 reads the 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 target processing 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 disk), a magneto-optical recording medium such as an MO (Magneto Optical disk), a magnetic recording medium, a conductive memory tape medium, or a semiconductor memory. It is.
  • 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 controls the accelerator state by executing a program loaded on the RAM 902.
  • the functions of the control device 100 are realized.
  • data in the RAM 902 is stored in the HDD 904 .
  • the CPU 901 reads a program related to target processing from the recording medium 917 and executes it.
  • the CPU 901 may read a program related to target processing from another device via a communication network.
  • the accelerator state control device 100A is similarly realized by a computer 900 having a configuration as shown in FIG. 16.
  • the accelerator state control device 100, 100A has a plurality of accelerators 12 with different processing performance and controls the state of the accelerator when offloading the specific processing of the application 1 to the accelerator 12 for arithmetic processing.
  • 100B (FIGS. 1 to 3), and when data with a mixture of different processing deadlines is input, a recording unit (processing device performance collection/recording unit 110) collects and records performance information of the accelerator 1.
  • a prediction unit (traffic volume/processing deadline prediction unit 150) that predicts the traffic volume and processing deadline after a predetermined period of time from the ratio of the current and past traffic volume and processing deadline; Based on the traffic volume after a predetermined period of time, the processing deadline, and the performance of the accelerator recorded in the recording unit, calculate the amount of data corresponding to the processing deadline, and select an accelerator that satisfies the performance based on the amount of data.
  • a determining unit (computing device allocation determining unit 130) that makes a determination is provided.
  • existing technology 1 static allocation
  • existing technology 2 scaling out using function proxies
  • existing technology 2 does not take into account differences in the performance of individual accelerators, and therefore does not satisfy ⁇ Requirement 1: Meeting the processing deadline of each data>.
  • existing Technology 1 has a fixed scale and therefore has poor versatility
  • Existing Technology 2 is not suitable for processing that requires low latency because the rate at which responsiveness can be ensured is fixed.
  • the accelerator state control device 100 uses accelerators with a heterogeneous performance configuration that can utilize a plurality of different accelerators, and allocates accelerators based on the processing deadline of each data. , to offload. Thereby, the accelerator state control device 100 can achieve both versatility and low latency, which could not be achieved with existing technology 1 and existing technology 2.
  • the accelerator state control devices 100, 100A, and 100B (FIGS. 1 to 3) can realize dynamic accelerator payout and satisfy [Requirement 2: Scalability].
  • the accelerator state control devices 100, 100A, and 100B select an accelerator that satisfies performance and minimizes power consumption from the assigned accelerators based on the processing deadline for each data, and offloads the accelerator. By doing so, [Requirement 1: Satisfaction of responsiveness of each data] can be satisfied.
  • the accelerator state control device 100 can reduce the amount of calculation resources used while ensuring responsiveness in response to fluctuations in the amount of data corresponding to each processing deadline.
  • the allocation unit selects an accelerator that satisfies the processing performance and allocates the processing to the selected accelerator. 170).
  • the arithmetic unit allocation unit 170 selects an accelerator that satisfies performance and minimizes power consumption from the allocated accelerators based on the processing deadline for each data, and offloads the accelerator. This satisfies [Requirement 1: Satisfaction of responsiveness of each data]. Therefore, since the accelerator state control device 100 allocates the optimal accelerator, it is possible to save power.
  • the accelerator state control devices 100, 100A, 100B (FIGS. 1 to 3) measure and record the latency that occurs during remote offloading between signal processing devices (server 200, remote offloading server 210) equipped with accelerators.
  • the determining unit (computing device allocation determining unit 130) is configured to record the latency recorded in the latency recording unit and the recording unit (computing device performance collecting/recording unit 110). ), the amount of data corresponding to the processing deadline is determined, and an accelerator that satisfies the performance is determined based on the amount of data.
  • the recording unit (computing device performance collection/recording unit 110) records access source host information, access destination host information, and latency (connection latency) in a latency table 310 shown in FIG.
  • the determining unit (processing unit allocation determining unit 130) refers to the latency table 310 for remote accelerators, compares the pre-recorded latency with the performance of the accelerator, and selects the optimal accelerator. Assign accelerators. Since the determination unit also takes into account the latency during remote offloading as a parameter, it is possible to allocate 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: Satisfaction of responsiveness of each data] can be achieved at a higher level.
  • Accelerator state control devices 100, 100A, and 100B (Figs. 1 to 1) have a plurality of accelerators 12 with different processing performance and control the states of the accelerators when offloading specific processing of application 1 to the accelerators 12 for arithmetic processing.
  • a recording unit processing device performance collection/recording unit 110
  • a prediction unit that predicts the traffic volume and processing deadline after a predetermined period of time based on the ratio of current and past traffic volumes and processing deadlines.
  • the processing deadline is calculated based on the traffic volume and processing deadline after a predetermined period of time predicted by the prediction unit, and the performance of the accelerator recorded in the recording unit.
  • a determining unit (computing unit allocation determining unit 130) that determines the amount of data corresponding to the data amount and determines an accelerator that satisfies the performance based on the amount of data.
  • the accelerator state control device 100 has a plurality of accelerators 12 with different processing performance, and controls the state of the accelerator when offloading specific processing of the application 1 to the accelerator 12 for arithmetic processing.
  • the accelerator state control systems 1000, 1000A, and 1000B including the accelerator state control systems 100A and 100B it is possible to reduce the computational resources used while ensuring responsiveness in accordance with fluctuations in the amount of data corresponding to each processing deadline.
  • each of the above-mentioned configurations, functions, processing units, processing means, etc. may be partially or entirely realized by hardware, for example, by designing an integrated circuit.
  • each of the above-mentioned configurations, functions, etc. may be realized by software for a processor to interpret and execute a program for realizing each function.
  • Information such as programs, tables, files, etc. that realize each function is stored in memory, storage devices such as hard disks, SSDs (Solid State Drives), IC (Integrated Circuit) cards, SD (Secure Digital) cards, optical disks, etc. It can be held on a recording medium.
  • APL Application (APL) 10 Hardware 11 CPU 12, 12-1, 12-2, 12-3 Accelerator 13 Input/output section 14 Input/output section for remote offloading 20
  • Software 100, 100A, 100B Accelerator state control device 110 Computing device performance collection/recording section (recording section) 120 Remote offload latency collection/recording unit (latency recording unit) 130 Arithmetic unit allocation determination unit 140 Data processing deadline determination unit 150 Traffic amount/processing deadline prediction unit (prediction unit) 160 Function proxy execution unit 170 Arithmetic unit distribution unit (distribution unit) 180 Remote offload section 200 Server (server with accelerator) (signal processing device) 210 Remote offload server (server with accelerator) (signal processing device) 220 Antenna device 221 Antenna device data input/output section 230 Post-processing device 231 Post-processing device data input/output section 1000, 1000A, 1000B Accelerator state control system

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

処理性能の異なる複数のアクセラレータ（１２）を有し、アプリケーション（１）の特定処理をアクセラレータ（１２）にオフロードして演算処理する際に、アクセラレータの状態を制御するアクセラレータ状態制御装置（１００）であって、異なる処理デッドラインが混在するデータが入力される場合において、アクセラレータ（１２）の性能情報を収集し、記録する演算装置性能収集・記録部（１１０）と、現在と過去のトラヒック量と処理デッドラインの割合から所定時間経過後のトラヒック量および処理デッドラインを予測するトラヒック量・処理デッドライン予測部（１５０）と、予測した所定時間経過後のトラヒック量および処理デッドラインと、記録されたアクセラレータ（１２）の性能とをもとに、処理デッドラインに対応するデータ量を求め、データ量をもとに性能を満たすアクセラレータを判断する演算装置割当判断部（１３０）と、を備える。

Description

アクセラレータ状態制御装置、アクセラレータ状態制御システム、アクセラレータ状態制御方法およびプログラム
　本発明は、アクセラレータ状態制御装置、アクセラレータ状態制御システム、アクセラレータ状態制御方法およびプログラムに関する。
　プロセッサの種別に応じて、得意（処理能力が高い）とするワークロードが異なる。汎用性の高いＣＰＵ（Central Processing Unit）に対し、ＣＰＵが苦手（処理能力が低い）とする並列度の高いワークロードを、高速かつ高効率に演算可能なＦＰＧＡ（Field Programmable Gate Array）／（以下の説明において、「／」は「または」を表記する）ＧＰＵ（Graphics Processing Unit）／ＡＳＩＣ（Application Specific Integrated Circuit）等のアクセラレータ（以下、適宜ＡＣＣという）がある。これらの異種プロセッサを組み合わせ、ＣＰＵの苦手とするワークロードをＡＣＣへオフロードして演算することで、総合的な演算時間や演算効率を向上させるオフロード技術の活用が進んでいる。
　ｖＲＡＮ（virtual Radio Access Network）等ではＣＰＵのみでは性能が足りず要件を満たせない場合に、ＦＰＧＡやＧＰＵなどの高速演算可能なアクセラレータに一部の処理をオフロードすることが行われている。
　ＡＣＣオフロードが行われる具体的ワークロードとしては、ｖＲＡＮにおける符号化／復号化処理（ＦＥＣ：Forward Error Correction処理）、音声や映像のメディア処理、暗号化／復号化処理等が代表例として挙げられる。
　計算機システムにおいて、計算機（以下、アクセラレータ搭載サーバ）上に、汎用処理に対応したハードウェア（ＣＰＵ）と特定の演算に特化したハードウェア（アクセラレータ）を搭載し、ソフトウェアの動作する汎用プロセッサからアクセラレータに対し一部の演算処理をオフロードする構成をとることがある。
　また、クラウドコンピューティングの進展に伴い、ユーザサイトに配備されたクライアントマシンから、ネットワーク（ＮＷ）を介して遠隔サイト（ユーザ近傍に位置するデータセンタなど）のサーバに対し、一部の演算量の大きな処理をオフロードすることで、クライアントマシンを単純な構成とすることが広まりつつある。
　図１４は、計算機システムを説明する図である。図１４中の矢印は、データの流れを示している。
　図１４に示すように、サーバ５０は、ハードウェア１０上にＣＰＵ１１と、処理能力の異なる複数のアクセラレータ（性能：高）１２－１，アクセラレータ（性能：低）１２－２と、入出力部１３と、を搭載し、サーバ５０上のＣＰＵ１１上で動作するソフトウェア２０のアプリケーション（以下、適宜ＡＰＬという）１を備える。
　アプリケーション１は、標準として規定された関数群（ＡＰＩ）を呼び出し、アクセラレータ１２への一部処理のオフロードを行う。
　本明細書において、処理能力の異なる複数のアクセラレータを利用可能な構成を、「性能のヘテロ構成」と呼ぶ。図１４では、処理能力の高いアクセラレータ（性能：高）１２－１と、処理能力の低いアクセラレータ（性能：低）１２－２とのヘテロ構成である。なお、アクセラレータ（性能：高）１２－１と、アクセラレータ（性能：低）１２－２とを区別しない場合は、アクセラレータ１２と総称する。
　アクセラレータ１２は、ＦＰＧＡ／ＧＰＵ等の計算アクセラレータデバイスである。アクセラレータ１２は、アクセラレータ演算回路またはプログラムを有し、アクセラレータ演算回路またはプログラムを用いて演算を行う。
　入出力部１３は、入力データを受け付け、出力する。
　サーバ５０は、外部からの入力データを受け付け、サーバ内部で演算処理を行った後に、外部に出力する。
　サーバ５０は、入力データに関して、前提がある。
（１）入力データの量は、時系列で変動する。例えば、ＲＡＮ（Radio Access Network）における、イベント発生時の突発トラヒックなどである。
（２）入力データは、それぞれ異なる処理デッドラインを持つ。例えば、処理デッドラインは、5G NRにおける、URLLC（Ultra-Reliable and Low Latency Communications：超高信頼低遅延）トラヒック（超低レイテンシ）やeMBB（enhanced Mobile Broadband：高速大容量）トラヒック（低～中程度のレイテンシ要件）において決められている。また、5G NRにおける、URLLCトラヒック（超低レイテンシ）とeMBBトラヒック（低～中程度のレイテンシ要件）の混在がある。
　図１５は、サーバ５０の入力データの量と、処理デッドラインの内訳の変動を説明する図である。図１５の実線は、総トラヒック量を示し、図１５の破線は、処理デッドラインの短いトラヒック量を示す。また、図１５中、トラヒック量が突出したところは、突発トラヒックである。突発トラヒックの一例として、ＲＡＮシステムにおける、一部エリアのトラヒックが増加するイベントなどに起因（例えば、花火大会など）する。
　サーバ５０において、時系列で量の変動する入力データに対し、各入力データの処理デッドラインを満たす要件は、下記である。
・要件１：[データそれぞれの処理デッドラインの充足]
　異なる処理デッドラインが混在する入力データにおいて、それぞれのデッドラインを満たすよう、入力から一定時間内にサーバでの処理が完了すること。
・要件２：[スケール性]
　入力トラヒックの量に応じて、処理性能がスケール（拡縮）できること。
　アクセラレータ搭載サーバにおいて、一定の量および一定の処理デッドラインの割合のトラヒックを対象に、アクセラレータを割り当てる技術には下記がある。
［処理デッドラインの割合のトラヒックを対象にしたアクセラレータの割当て］
　まず、アクセラレータ搭載サーバにおいて、処理デッドラインの割合のトラヒックを対象に、アクセラレータを固定的に割り当てる技術について述べる（非特許文献１）。
［既存技術１］
　図１６は、既存技術１（非特許文献１)の静的なアクセラレータの割り付けを説明する図である。図１４と同一構成部分には同一符号を付している。
　図１６に示すように、サーバ５０は、ハードウェア１０上にＣＰＵ１１と、処理能力の異なる複数のアクセラレータ（性能：高）１２－１，アクセラレータ（性能：低）１２－２と、を搭載し、サーバ５０上のＣＰＵ１１上で動作するソフトウェア２０のアプリケーション１を備える。
　サーバ５０は、一定の量および一定の処理デッドラインの割合のトラヒックを対象に、アクセラレータを固定的に割り当てる（図１８の二重線ａ）。図１６では、アクセラレータ（性能：高）１２－１をアプリケーション１に固定的に割当てる固定割り付けを行う。
　入力データそれぞれの処理デッドラインは、一定値を前提に設計されている。
　既存技術１では、下記要件を満たす／満たさない特徴がある。
　<要件１：データそれぞれの処理デッドラインの充足>
　入力データそれぞれの処理デッドラインは、一定値を前提に設計されているので、入力データは一定値を超えることがないので、「データそれぞれの処理デッドラインの充足」を条件付きで満たす。
　<要件２：スケール性>
　リソース量は一定であり、アクセラレータのスケールアウト／スケールインの（「スケール性」を満たさない。
　図１７は、既存技術１における、入力データ量の変動を説明する図である。図１７の実線は、総トラヒック量を示し、図１７の破線は、システムが応答性を確保できるトラヒック量を示す。
　図１７に示すように、システムが応答性を確保できるトラヒック量（図１７の破線）は一定である。
　既存技術１では、通常時のトラヒック最大量にあわせて、アクセラレータが静的に割り当てられる。このため、突発的な入力データ量の増大時、処理能力が不足する（図１７の白抜矢印ｂ）。
　次に、アクセラレータ搭載サーバにおいて、関数プロキシによりＡＣＣのスケールを実現する技術について述べる（非特許文献１）。
［既存技術２］
　図１８は、既存技術２の関数プロキシによるＡＣＣのスケールの実現を説明する図である。図１４と同一構成部分には同一符号を付している。
　図１８に示すように、サーバ５０は、ソフトウェア２０がプロキシソフトウェア２を備える。プロキシソフトウェア２は、関数プロキシ３と、その関数プロキシ３によりアクセラレータに対する入出力制御を行うアクセラレータＩ／Ｏ制御部４と、有する。
　サーバ５０は、ＡＣＣ利用関数の関数プロキシ３を用いたスケールアウトにより、アクセラレータを動的に割り当てる（図１８の二重線ｃ）。図１８では、プロキシソフトウェア２は、アプリケーション１の処理をアクセラレータ（性能：高）１２－１またはアクセラレータ（性能：低）１２－２に動的に割当てる。
　既存技術２では、下記要件を満たす／満たさない特徴がある。
　<要件１：データそれぞれの処理デッドラインの充足>
　ＡＣＣ性能を考慮しないため、トラヒックのうち、低レイテンシ処理が必要なトラヒックの割合が増加すると、応答性を満たさない。
　<要件２：スケール性>
　　トラヒック量に応じたスケールアウトが可能である。
　図１９は、既存技術２における、処理デッドラインを説明する図である。図１９の実線は、総トラヒック量を示し、図１９の破線は、処理デッドラインの短いトラヒック量を示し、図１９の二重線は、応答性を確保できるトラヒック量を示す。
　図１９の白抜矢印ｃに示すように、割り当てたＡＣＣがデッドラインを守れない瞬間がある。特に、低レイテンシ処理が必要なトラヒックの割合が増加すると、応答性を満たさない。
"16.2. SR-IOV デバイスを使用した PCI デバイスの割り当て Red Hat Enterprise Linux 7 | Red Hat Customer Portal",［online］,［令和４年７月６日検索］,インターネット〈URL:https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-pci_devices-pci_passthrough〉
　既存技術１，２は、下記課題がある。
　既存技術１（静的割り付け）は、アクセラレータのリソース量が一定であり、<要件２：スケール性>を満たさないという課題がある。
　既存技術２（関数プロキシによるスケールアウト）は、アクセラレータ個々の性能の違いを考慮しないため、<要件１：データそれぞれの処理デッドラインの充足>を満たさないという課題がある。
　このような背景を鑑みて本発明がなされたのであり、本発明は、ヘテロな構成のアクセラレータ搭載サーバにおいて、各処理デッドラインに対応するデータ量の変動に応じ、応答性を担保しつつ、使用する演算リソースの低減を実現することを課題とする。
　前記した課題を解決するため、本発明は、処理性能の異なる複数のアクセラレータを有し、アプリケーションの特定処理をアクセラレータにオフロードして演算処理する際に、アクセラレータの状態を制御するアクセラレータ状態制御装置であって、異なる処理デッドラインが混在するデータが入力される場合において、前記アクセラレータの性能情報を収集し、記録する記録部と、現在と過去のトラヒック量と処理デッドラインの割合から所定時間経過後のトラヒック量および処理デッドラインを予測する予測部と、前記予測部が予測した所定時間経過後の前記トラヒック量および前記処理デッドラインと、前記記録部に記録された前記アクセラレータの性能とをもとに、前記処理デッドラインに対応するデータ量を求め、当該データ量をもとに性能を満たすアクセラレータを判断する判断部と、を備えることを特徴とするアクセラレータ状態制御装置とした。
　本発明によれば、各処理デッドラインに対応するデータ量の変動に応じ、応答性を担保しつつ、使用する演算リソースの低減を実現することができる。
本発明の実施形態に係るアクセラレータ状態制御システムの概略構成図である。 本発明の実施形態に係るアクセラレータ状態制御システムの概略構成図である。 本発明の実施形態に係るアクセラレータ状態制御システムのアクセラレータ状態制御装置の配置のバリエーションを示す概略構成図である。 本発明の実施形態に係るアクセラレータ状態制御システムのアクセラレータ状態制御装置のＤＢテーブルの一例を示す図である。 本発明の実施形態に係るアクセラレータ状態制御システムのアクセラレータ状態制御装置のレイテンシテーブルの一例を示す図である。 本発明の実施形態に係るアクセラレータ状態制御システムのアクセラレータ状態制御装置のＡＣＣ関数・引数データパケット構成例を示す図である。 本発明の実施形態に係るアクセラレータ状態制御システムのHost-1からの利用可能ＡＣＣリストの算出例を示す図である。 本発明の実施形態に係るアクセラレータ状態制御システムのアクセラレータ状態制御装置の演算装置割当判断部およびトラヒック量・処理デッドライン予測部の動作１を示すフローチャートである。 本発明の実施形態に係るアクセラレータ状態制御システムのアクセラレータ状態制御装置の演算装置割当判断部およびトラヒック量・処理デッドライン予測部の動作２を示すフローチャートである。 本発明の実施形態に係るアクセラレータ状態制御システムのアクセラレータ状態制御装置の演算装置割当（ＡＣＣ割当）を示すフローチャートである。 本発明の実施形態に係るアクセラレータ状態制御システムの入力データ処理を示すフローチャートである。 本発明の実施形態に係るアクセラレータ状態制御システムの入力データ処理を示すフローチャートである。 本発明の実施形態に係るアクセラレータ状態制御システムの入力データ処理を示すフローチャートである。 本発明の実施形態に係るアクセラレータ状態制御システムの入力データ処理を示すフローチャートである。 本発明の実施形態に係るアクセラレータ状態制御システムの入力データ処理を示すフローチャートである。 本発明の実施形態に係るアクセラレータ状態制御システムの入力データ処理を示すフローチャートである。 本発明の実施形態に係るアクセラレータ状態制御システムの機能を実現するコンピュータの一例を示すハードウェア構成図である。 計算機システムを説明する図である。 サーバの入力データの量と、処理デッドラインの内訳の変動を説明する図である。 既存技術１（非特許文献１)の静的なアクセラレータの割り付けを説明する図である。 既存技術１における、入力データ量の変動を説明する図である。 既存技術２の関数プロキシによるＡＣＣのスケールの実現を説明する図である。 既存技術２における、処理デッドラインを説明する図である。
　以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）におけるアクセラレータ状態制御システム等について説明する。
（実施形態）
［概要］
　図１は、本発明の実施形態に係るアクセラレータ状態制御システムの概略構成図である。図１は、「ＮＩＣ等の入出力部を介して得たデータを、ＣＰＵからアクセラレータに対し明示的にオフロードする」Look-Aside型のアクセラレータに適用した例である。Look-Aside型は、ＣＰＵが処理の一部をアクセラレータへオフロードする。Look-Aside型のアクセラレータは、ＣＰＵが状態を管理する。
　図１に示すように、アクセラレータ状態制御システム１０００は、サーバ２００（[信号処理装置]）と、遠隔オフロード用サーバ２１０と、アンテナ装置２２０と、後段処理装置２３０と、を備える。
　また、アクセラレータ状態制御システム１０００は、アプリケーション１の特定処理をアクセラレータ１２にオフロードして演算処理する際に、アクセラレータ１２の状態を制御するアクセラレータ状態制御装置１００を備える。
［サーバ２００］
　サーバ２００は、５Ｇ信号処理におけるDistributed Unitである。
　サーバ２００は、ハードウェア（ＨＷ）１０と、ソフトウェア２０と、を備える。
《ハードウェア１０》
　ハードウェア１０は、ＣＰＵ（Central Processing Unit）１１と、処理能力の異なる複数のアクセラレータ（性能：高）１２－１，アクセラレータ（性能：低）１２－２と、アクセラレータ１２と、入出力部１３と、遠隔オフロード用入出力部（クライアント）（ＮＩＣ）１４と、を有する。
 <ＣＰＵ１１>
　ＣＰＵ１１は、アプリケーション１の処理を実行するとともに、サーバ２００における、各機能部のソフトウェアを実行する。
 <アクセラレータ１２>
　アクセラレータ１２は、ＦＰＧＡ／ＧＰＵ等の計算アクセラレータデバイスである。アクセラレータ１２は、サーバ２００に搭載された、特定の処理に特化した演算機である。ＣＰＵ１１とバスを介して接続する形態としては、ＡＳＩＣ搭載型アクセラレータ、ＦＰＧＡ搭載型アクセラレータ、ＧＰＵ等の形態がある。
　本実施形態は、処理能力の異なる複数のアクセラレータを利用可能な「性能のヘテロ構成」を用いる。処理能力の異なる複数のアクセラレータは、アクセラレータ（性能：高）１２－１，アクセラレータ（性能：低）１２－２である。
 <入出力部１３>
　入出力部１３は、ＮＩＣ（Network Interface Card）などの入出力機構であり、外部装置（アンテナ装置２２０や後段処理装置２３０）とのデータ入出力を行う。また、入出力部１３は、アプリケーション１に対して、現在のデータ入力量を通知するインターフェイスを持つ。
 <遠隔オフロード用入出力部１４>
　遠隔オフロード用入出力部（クライアント）（ＮＩＣ）１４および遠隔オフロード用入出力部（サーバ）（ＮＩＣ）１４は、ＮＩＣなどに代表されるネットワークインタフェース装置であり、サーバ間の通信を行う機能部である。
《ソフトウェア２０》
　ソフトウェア２０は、アプリケーション１と、アクセラレータの状態を制御するアクセラレータ状態制御装置１００と、を有する。
 <アプリケーション１>
　アプリケーション１は、信号処理を行うプログラムであり、ＣＰＵ１１上で動作する。一部の並列演算処理など、ＣＰＵに適さない専用処理については、アクセラレータ１２（アクセラレータ（性能：高）１２－１，アクセラレータ（性能：低）１２－２，アクセラレータ（性能：高）１２－３）にオフロードを行う。例えば、アプリケーション１は、標準として規定された関数群（ＡＰＩ）を呼び出し、アクセラレータ１２への一部処理のオフロードを行う。
・入出力
　アプリケーション１は、入力として、入出力部１３から処理対象データを受け付ける。出力として、演算したデータを入出力部１３に渡す。
・変形例
　本実施形態では、入出力部１３とＣＰＵ１１とアクセラレータ１２は、ハードウェアとして分かれた構成を示したが、これらが一体化した専用ハードウェアの形態でもよい。
　また、本実施形態のように、「ＮＩＣ等の入出力部１３を介して得たデータを、ＣＰＵ１１からアクセラレータ１２に対し明示的にオフロードする」所謂Look-Aside型のアクセラレータ適用形態に加えて、「ＮＩＣ・アクセラレータ・ＣＰＵ１１」が一体化したハードウェアで、ＮＩＣでのデータ受信後に同一ハードウェア内で処理が完結する、いわゆるIn-line型のアクセラレータ適用形態でもよい。
［アクセラレータ状態制御装置１００］
　アクセラレータ状態制御装置１００は、演算装置性能収集・記録部１１０と、遠隔オフロードレイテンシ収集・記録部１２０（レイテンシ記録部）と、演算装置割当判断部１３０と、データ処理デッドライン判別部１４０と、トラヒック量・処理デッドライン予測部１５０と、関数代理実行部１６０と、演算装置振分部１７０と、遠隔オフロード部１８０と、を備える。
　上記演算装置性能収集・記録部１１０、遠隔オフロードレイテンシ収集・記録部１２０、および演算装置割当判断部１３０は、割当判断機能部１０１を構成する。上記データ処理デッドライン判別部１４０およびトラヒック量・処理デッドライン予測部１５０は、予測機能部１０２を構成する。上記関数代理実行部１６０および演算装置振分部１７０は、振分機能部１０３を構成する。
 <演算装置性能収集・記録部１１０>
　演算装置性能収集・記録部１１０は、各演算装置（ＣＰＵ１１、アクセラレータ（性能：高）１２－１，アクセラレータ（性能：低）１２－２）の性能を収集し、記録する。性能情報としては、スループットや処理レイテンシ、消費電力が挙げられる。
　演算装置性能収集・記録部１１０は、オペレータによる静的な設定投入により、各ホストのアクセラレータ情報を保存する。演算装置性能収集・記録部１１０は、各演算装置を一意に識別するための識別子をもとに、それぞれの性能情報を持つ。
・構成例
　記録装置のデータベース構成例を、演算装置性能収集・記録部１１０のＤＢテーブル３００（図４）の例に示す。
・入出力
　演算装置性能収集・記録部１１０は、入力として、特定の性能やホストの識別子など、必要となるアクセラレータの条件を受け付け、出力として、入力された条件に合致するアクセラレータの一覧を応答する。
・変形例
　演算装置性能収集・記録部１１０は、外部の構成管理ツールや、機器構成情報を取得するコマンドを利用して、自動的に情報収集を行う形態でもよい。
 <遠隔オフロードレイテンシ収集・記録部１２０>
　遠隔オフロードレイテンシ収集・記録部１２０は、アクセラレータを搭載した信号処理装置（ここでは、サーバ２００から別サーバである遠隔オフロード用サーバ２１０）間の、遠隔オフロードにおいて生じる通信レイテンシ（レイテンシ）を収集し、記録する。遠隔オフロードレイテンシ収集・記録部１２０は、後記図５に示すレイテンシテーブル３１０に、遠隔オフロード用サーバ２１０とオフロード元であるサーバ２００の通信レイテンシを保持する。
・構成例
　記録装置のデータベース構成例を、演算装置性能収集・記録部１１０のＤＢテーブル３００の例に示す。
・入出力
　遠隔オフロードレイテンシ収集・記録部１２０は、入力として、特定の組み合わせのホスト情報を受け付け、出力として、入力で受け付けた組合せのホスト情報から、レイテンシを計算し、応答する。
・変形例
　遠隔オフロードレイテンシ収集・記録部１２０は、自動的に情報収集を行い、レイテンシをアップデートする形態でもよい。具体的には、各ホストに搭載したレイテンシ測定機能（図示省略）が、一定周期で他ホストへの通信遅延を測定し、遠隔オフロードレイテンシ収集・記録部１２０の情報をアップデートする形態でもよい。
 <演算装置割当判断部１３０>
　演算装置割当判断部１３０は、トラヒック量・処理デッドライン予測部１５０が予測した所定時間経過後のトラヒック量と処理デッドラインと、演算装置性能収集・記録部１１０に記録されたアクセラレータ１２の性能情報をもとに、処理デッドラインに対応するデータ量を求め、データ量をもとに性能を満たすアクセラレータを判断する。
　演算装置割当判断部１３０は、一定時間経過後のトラヒック量と処理デッドラインをもとに、性能を充足する演算装置を判断し、演算装置振分部１７０に割り当てる。
　演算装置割当判断部１３０は、トラヒック量・処理デッドライン予測部１５０から、一定時間経過後のトラヒック量と、その処理デッドラインを受け取る。演算装置割当判断部１３０は、この性能要求をもとに、演算装置性能収集・記録部１１０と遠隔オフロードレイテンシ収集・記録部１２０とに問い合わせを行い、アクセラレータの一覧を得る。演算装置割当判断部１３０は、これらの情報をもとに、ローカルのアクセラレータと、遠隔オフロード先のアクセラレータのリストを得る。
・構成例
　遠隔オフロード先のアクセラレータ１２については、アクセラレータ処理時間に、オフロードのレイテンシを加算する。上記一覧から、性能を満たしつつ最も消費電力の小さなアクセラレータの組み合わせを選び、演算装置振分部１７０に通知する。
・入出力
　演算装置割当判断部１３０は、入力として、一定時間経過後の、トラヒック量と、その処理デッドラインの割合を受け付け、出力として、入力された条件に合致するアクセラレータの一覧を応答する。
・変形例
　演算装置割当判断部１３０は、外部の構成管理ツールや、機器構成情報を取得するコマンドを利用して、自動的に情報収集を行う形態でもよい。
 <データ処理デッドライン判別部１４０>
　データ処理デッドライン判別部１４０は、入力データそれぞれの処理デッドラインを識別したうえで、各機能部に通知する。
　データ処理デッドライン判別部１４０は、入出力部１３から、入力データを受け取り、その先頭のヘッダ情報を参照し、処理デッドラインを識別する。ＲＡＮにおける例では、該当のeCPRI（enhanced Common Public Radio Interface）プロトコルヘッダを参照し、セッション情報を識別することで、該当のデータの処理デッドラインを識別する。
・入出力
　データ処理デッドライン判別部１４０は、入力として、入出力部１３から、入力データを受け取り、出力として、トラヒック量・処理デッドライン予測部１５０に対し、トラヒックの量と、処理デッドラインの割合を通知する。
 <トラヒック量・処理デッドライン予測部１５０>
　トラヒック量・処理デッドライン予測部１５０は、一定時間経過後のトラヒック量と処理デッドラインを、現在と過去のトラヒック量と処理デッドラインの割合から予測する。
　トラヒック量・処理デッドライン予測部１５０は、データ処理デッドライン判別部１４０から、トラヒック量と処理デッドラインの割合を受け取り、入力トラヒック量に対し、各処理デッドラインの割合を乗算することで、各トラヒック種別の量を算出する。
　トラヒック量・処理デッドライン予測部１５０は、各デッドラインのトラヒック量が、それぞれ増加傾向か減少傾向かを予測する。
・入出力
　トラヒック量・処理デッドライン予測部１５０は、入力として、入力データの現在のトラヒック量と処理デッドラインの割合を受け取り、出力として、予測した一定時間経過後のトラヒック量と処理デッドラインを、演算装置割当判断部１３０に通知する。
・変形例
　トラヒック量・処理デッドライン予測部１５０は、ＲＡＮシステムにおけるトラヒック量および処理デッドラインの予測は、現在のトラヒックの推移から予測する方法のほかに、該当のトラヒック発生地点での時間帯による推移や、周辺での人が集合するイベントの発生をもとに、予測してもよい。
　具体的には、電車沿線の基地局からのトラヒック量は、始発～終電までの時間に多く、それ以外の時間は少ないと予測するなどの手法が考えられる。また、一定の地点における基地局周辺での人が集まるイベント（花火大会など）の情報をもとに、事前にトラヒックの増加を予測する方法でもよい。
 <関数代理実行部１６０>
　関数代理実行部１６０は、既存のアクセラレータへのアクセス用ライブラリが提供する関数と、同一のインターフェイスをアプリケーションに提供し、代理で実際の関数実行を行う。関数代理実行部１６０は、提供形態としては、アプリケーションに対するライブラリとして提供され、静的にリンクされるか、あるいは実行時に動的にロードされ呼び出される。同一のインターフェイスとは、同一の関数名・同一の引数形式の関数を指す。
・入出力
《処理依頼時》
　関数代理実行部１６０は、入力として、アプリケーション１から、関数名と引数を受け取り、出力として、演算装置振分部１７０に対して、関数名と引数を通知する。
《処理結果応答時》
　関数代理実行部１６０は、入力として、演算装置振分部１７０から、処理結果を受け取り、出力として、処理結果を、アプリケーション１に通知する。
 <演算装置振分部１７０>
　演算装置振分部１７０は、入力データを、事前に割り当てられた演算装置に対し振り分ける。
　演算装置振分部１７０は、データ処理デッドライン判別部１４０が判別した入力データの処理デッドラインと、演算装置割当判断部１３０の判断結果をもとに、処理性能を満たすアクセラレータを選択し、選択したアクセラレータに処理を振り分ける。
　具体的には、演算装置振分部１７０は、各入力データに含まれる処理デッドライン情報をもとに、処理性能を満たす演算装置を選択し、処理を振り分ける。この時、演算装置振分部１７０は、データ処理デッドライン判別部１４０に対して各データの処理デッドライン情報の問い合わせを行い、データ処理デッドラインを判別する。
・入出力
《処理依頼時》
　演算装置振分部１７０は、入力として、演算装置割当判断部１３０から、利用可能な演算装置のリストを受け付けるとともに、関数代理実行部１６０から、処理対象データを受け付ける。
　演算装置振分部１７０は、出力として、ＣＰＵ１１、アクセラレータ１２、遠隔オフロード部１８０のいずれかに、処理対象データを送付する。
　演算装置振分部１７０は、データ処理デッドライン判別部１４０に対し、入力データを入力し、データ処理デッドライン判別部１４０から該当データの処理デッドラインを受け付ける。
《処理結果応答》
　演算装置振分部１７０は、入力として、ＣＰＵ１１、アクセラレータ１２、遠隔オフロード用入出力部１４から、処理結果を受け取り、出力として、処理結果を関数代理実行部１６０に通知する。
・変形例
　演算装置振分部１７０は、処理デッドライン情報およびトラヒック量をもとにアクセラレータを振り分けているが、このほかの優先度情報を用いてもよい。具体的には、優先度情報は、システムの継続稼働に必要な、メンテナンス用のアクセラレータの確保などが挙げられる。
　本実施形態では、各演算装置（遠隔オフロードレイテンシ収集・記録部１２０，アクセラレータ１２，遠隔オフロード用入出力部１４）の演算結果等を、演算装置振分部１７０を介して関数代理実行部１６０に応答しているが、各演算装置（遠隔オフロードレイテンシ収集・記録部１２０，アクセラレータ１２，遠隔オフロード用入出力部１４）から直接関数代理実行部１６０に応答する形でもよい。
 <遠隔オフロード部１８０>
　遠隔オフロード部１８０は、入力された関数名・引数を、ＮＩＣによって送信可能なＬ２フレームおよびそのペイロードとしてデータ化する。実施形態のデータフォーマットを、図６に示す。
・入出力
《オフロード時》
　遠隔オフロード部１８０は、入力として、演算装置振分部１７０から「関数名・引数」を受け付け、出力として、遠隔オフロード用入出力部１４へ「送信データ」を渡す。
《応答時》
　遠隔オフロード部１８０は、入力として、遠隔オフロード用入出力部１４から、「処理結果データ」を受け付け、出力として、演算装置振分部１７０に、処理結果データを渡す。
・変形例
　データ形式は、Ｌ２フレームだけでなく、Ｌ３，Ｌ４ヘッダを付与したデータでもよい。パケットフォーマットには、関数名・引数だけでなく、利用するアクセラレータを一意に識別できるＩＤを含めてもよい。
　また、引数サイズが大きい場合には、複数パケットへの分割機能を具備してもよい。
［遠隔オフロード用サーバ２１０］
　遠隔オフロード用サーバ２１０は、ハードウェア（ＨＷ）１０と、ソフトウェア２０と、を備える。
《ハードウェア１０》
　ハードウェア１０は、ＣＰＵ１１と、アクセラレータ（遠隔）（性能：高）１２－３，と、遠隔オフロード用入出力部（サーバ）（ＮＩＣ）１４と、を有する。
 <ＣＰＵ１１>
　ＣＰＵ１１は、アプリケーション１の処理を実行するとともに、遠隔オフロード用サーバ２１０における、各機能部のソフトウェアを実行する。
 <アクセラレータ１２>
　アクセラレータ（遠隔）（性能：高）１２－３は、ＦＰＧＡ／ＧＰＵ等の計算アクセラレータデバイスである。アクセラレータ（遠隔）（性能：高）１２－３は、遠隔オフロード用サーバ２１０に搭載された、特定の処理に特化した演算機である。ＣＰＵ１１とバスを介して接続する形態としては、ＡＳＩＣ搭載型アクセラレータ、ＦＰＧＡ搭載型アクセラレータ、ＧＰＵ等の形態がある。
　本実施形態は、処理能力の異なる複数のアクセラレータを利用可能な「性能のヘテロ構成」を用いる。処理能力の異なる複数のアクセラレータは、サーバ２００に搭載されたアクセラレータ（性能：高）１２－１，アクセラレータ（性能：低）１２－２、遠隔オフロード用サーバ２１０に搭載されたアクセラレータ（遠隔）（性能：高）１２－３である。
《ソフトウェア２０》
　ソフトウェア２０は、遠隔オフロード受付部２１１を有する。
　遠隔オフロード受付部２１１は、ネットワークを介して受信した処理対象データを、アクセラレータ（遠隔）１２－３にオフロードし、結果を応答する。
・入出力
《オフロード時》
　遠隔オフロード受付部２１１は、入力として、図６の形式のデータを受信し、出力として、アクセラレータ（遠隔）１２－３に対し、処理オフロードを行う。
《応答時》
　遠隔オフロード受付部２１１は、入力として、アクセラレータ（遠隔）１２－３から、オフロード結果を受信し、出力として、図６の形式のデータとして、処理結果を応答する。
［アンテナ装置２２０］
　アンテナ装置２２０は、端末（ＵＥ：User Equipment）と無線通信するアンテナおよび送受信部である（以下、「アンテナ装置」は、アンテナと送受信部、その電源部を総称して呼称する）。送受信データは、例えば専用ケーブルにより基地局（ＢＢＵ：Base Band Unit）の信号処理装置（サーバ２００）に接続される。
　アンテナ装置２２０は、アンテナ装置データ入出力部２２１を備える。アンテナ装置データ入出力部２２１は、サーバ２００に対し、アンテナ装置２２０で生成された信号を送る機能部であり、ＮＩＣ等の形態で実現される。
［後段処理装置２３０］
　後段処理装置２３０は、５Ｇ信号処理におけるCentralized Unitである。
　後段処理装置２３０は、後段処理装置データ入出力部２３１を備える。後段処理装置データ入出力部２３１は、サーバ２００で処理した信号処理結果を受信する機能部であり、ＮＩＣ等の形態で実現される。
 <その他の実施形態>
　本実施形態では、入出力部１３とＣＰＵ１１、アクセラレータ１２はハードウェアとして分かれた構成であるが、ＣＰＵ１１、アクセラレータ１２およびアクセラレータ演算回路・プログラム１２ａが一体化した専用ハードウェアの形態でもよい。
　言い換えると、図１のように、「ＮＩＣ等の入出力部１３を介して得たデータを、ＣＰＵ１１からアクセラレータ１２に対し明示的にオフロードする」、いわゆるLook-Aside型のアクセラレータ適用形態（図１１Ａ－１１Ｃのシーケンス）に加えて、図２で後記する「ＮＩＣ・アクセラレータ・ＣＰＵ」が一体化したハードウェアで、ＮＩＣでのデータ受信後に同一ハードウェア内で処理が完結する」、いわゆるIn-line型のアクセラレータ適用形態（図１２Ａ－１２Ｃのシーケンス）でもよい。
　また、ＣＰＵ１１、アクセラレータ１２は、ＳｏＣ（System on Chip）の形態のように、単一のチップの中に搭載される形態でもよい。
［アクセラレータ状態制御装置のアクセラレータ適用形態］
　図２は、本発明の実施形態に係るアクセラレータ状態制御システム１０００Ａの概略構成図である。図２は、In-line型のアクセラレータ適用形態である。図１と同一構成部分には、同じ符号を付して重複箇所の説明を省略する。
　図２に示すIn-line型のアクセラレータ適用形態のサーバ２００Ａのアクセラレータ状態制御装置１００Ａは、図１のサーバ２００のアクセラレータ状態制御装置１００における、入出力部１３とアクセラレータ１２とを結ぶ双方向の信号線が、存在しない。また、図２に示すIn-line型のアクセラレータ適用形態のサーバ２００のアクセラレータ状態制御装置１００Ａは、新たに入出力部１３と演算装置振分部１７０とを結ぶ双方向の信号線が追加される。
　In-line型のアクセラレータ適用形態のサーバ２００Ａは、ＮＩＣから直接アクセラレータへデータをコピーする。アクセラレータが、専用回路のように自律的に演算を行う。
［アクセラレータ状態制御装置の配置］
　アクセラレータ状態制御システムのアクセラレータ状態制御装置の配置のバリエーションについて説明する。
　図１のアクセラレータ状態制御システム１０００は、アクセラレータ状態制御装置１００をサーバ２００のソフトウェア２０に配置した例である。アクセラレータ状態制御装置１００は、機能の一部を、サーバ２００外に別筐体で設置することも可能であり、以下に例示する。
　図３は、アクセラレータ状態制御システムのアクセラレータ状態制御装置の配置のバリエーションを示す概略構成図である。なお、以下の各図において、図１と同一構成部分には同一符号を付して重複箇所の説明を省略する。
　図３に示すバリエーションは、演算装置性能収集・記録部１１０、遠隔オフロードレイテンシ収集・記録部１２０、演算装置割当判断部１３０、データ処理デッドライン判別部１４０、およびトラヒック量・処理デットライン予測部１５０からなるコントローラ機能部を別筐体とした場合の例である。
　図３に示すように、アクセラレータ状態制御システム１０００Ｂは、サーバ２００外に別筐体で設置されたアクセラレータ状態制御装置１００Ｂを備える。
　サーバ２００のソフトウェア２０は、アプリケーション１と、関数代理実行部１６０と、演算装置振分部１７０と、を有する。
　アクセラレータ状態制御装置１００Ｂは、上記コントローラ機能部がサーバ２００外に設置され、図１および図２のアクセラレータ状態制御装置１００，１００Ａと同一の機能を有する。
　以上、図３に示すように、アクセラレータ状態制御装置の各機能の一部または全部を、サーバ２００外の別の筐体に独立して配備する形態をとることで、ＲＡＮ（Radio Access Network）におけるＲＩＣ（RAN Intelligent Controller）への機能配備に対応することができる。
　また、上記コントローラ機能部を外部に配置することで、複数のサーバマシンからの入力量取得（機能１）をもとに入力量を予測できるため、機能１のトラヒックの予測精度が上がるメリットがある。例えば、携帯電話の無線システムにおいて、あるサーバマシンが担当する処理エリアのトラヒック量が増大した場合、近傍の処理エリアの入力量も、それに遅れて変動すると想定される。
　また、複数のサーバ２００に対して、１つのアクセラレータ状態制御装置での運用が可能になる。これにより、コストの低減と、アクセラレータ状態制御装置のメンテナンス性を向上させることができる。また、サーバ側の改変を不要ないし軽減することができ、汎用的に適用することができる。
［演算装置性能収集・記録部１１０のＤＢテーブル］
　図４は、演算装置性能収集・記録部１１０のＤＢテーブル３００の一例を示す図である。
　図４に示すように、ＤＢテーブル３００は、搭載ホスト情報毎に、アクセラレータ識別子（ＣＰＵ，ＦＰＧＡ，ＡＳＩＣ）、ＡＣＣ性能（スループット）、ＡＣＣ性能（処理レイテンシ）、ＡＣＣ性能（消費電力）を保持する。例えば、搭載ホスト情報「Host-1(192.168.0.1：サーバＵＲＬ)」は、アクセラレータ識別子「ＦＰＧＡ－１」、ＡＣＣ性能（スループット）「10.0 Gbps」、ＡＣＣ性能（処理レイテンシ）「5.0μs」、ＡＣＣ性能（消費電力）「120.0 W」である。搭載ホスト情報に紐づけて、各ＡＣＣ性能が記録されており、搭載ホスト情報を指定することで当該ホストの各ＡＣＣ性能を知ることができる。
［遠隔オフロードレイテンシ収集・記録部１２０のレイテンシテーブル］
　図５は、遠隔オフロードレイテンシ収集・記録部１２０のレイテンシテーブル３１０の一例を示す図である。
　図５に示すように、レイテンシテーブル３１０は、アクセス元ホスト情報、アクセス先ホスト情報、レイテンシを保持（記録）する。例えば、アクセス元ホスト情報「Host-1(192.168.0.1：サーバＵＲＬ)」は、アクセス先ホスト情報「Host-2(192.168.0.2)」に接続した場合、レイテンシ（接続レイテンシ／通信レイテンシ）「30μs」である。
［遠隔オフロード部１８０のデータ構造］
　図６は、遠隔オフロード部１８０のＡＣＣ関数・引数データパケット３２０の構成例を示す図である。
　図６に示すように、ＡＣＣ関数・引数データパケット３２０は、Ｌ２フレーム(0～14byte)、関数ＩＤ(～34byte)、最終データビット(～42byte)、引数１(～46byte)、引数２(～50byte)でフォーマットされる。
　ＡＣＣ関数・引数データパケット３２０は、各データを固定長・固定位置とすることで、ＦＰＧＡの回路でのパースに適したデータ構造とする。
　制御ビットは、パケットの制御情報を付加する。ＡＣＣ関数・引数データパケット３２０は、例えば、引数サイズが大きい場合には、複数パケットへの分割機能を具備する。この際、分割した最後のパケットには、「制御ビット」に最終パケットを通知する制御用データを付与する。
　なお、図６に示すパケットフォーマットには、ヘッダにＬ３ヘッダ、Ｌ４ヘッダを含めてもよい。また、関数名・引数だけでなく、利用するアクセラレータを一意に識別できるＩＤを含めてもよい。
［Host-1からの利用可能ＡＣＣリストの算出例］
　図７は、Host-1からの利用可能ＡＣＣリスト３３０の算出例を示す図である。
　図７に示すように、利用可能ＡＣＣリスト３３０は、図４に示す演算装置性能収集・記録部１１０のＤＢテーブル３００と、図５に示す遠隔オフロードレイテンシ収集・記録部１２０のレイテンシテーブル３１０をもとに作成される。利用可能ＡＣＣリスト３３０は、ホストから他のホストを利用する場合に、ＡＣＣ性能（スループット）、ＡＣＣ性能（処理レイテンシ）、ＡＣＣ性能（消費電力）を一覧できる。例えば、Host-1からHost-2を利用する場合は、ＡＣＣ性能（処理レイテンシ）「40.0μs＝10.0μs＋30μs(遠隔化レイテンシ)」であり、Host-1がHost-2を利用する上で、重要な指標となる。
　演算装置割当判断部１３０は、図４に示す演算装置性能収集・記録部１１０のＤＢテーブル３００の一覧から、性能を満たしつつ最も消費電力の小さなアクセラレータの組み合わせを選び、演算装置振分部１７０に通知する。しかしながら、該当アクセラレータが、特にネットワークを経由した遠隔にある場合には、遠隔化レイテンシも考慮する。演算装置割当判断部１３０は、この利用可能ＡＣＣリスト３３０を用いて、遠隔化レイテンシも考慮しつつ、性能を充足する演算装置を判断し、演算装置振分部１７０に割り当てる。
　以下、上述のように構成されたアクセラレータ状態制御システム１０００の動作を説明する。
　まず、演算装置割当判断部１３０およびトラヒック量・処理デッドライン予測部１５０の動作について説明する。
［演算装置割当判断部１３０およびトラヒック量・処理デッドライン予測部１５０の動作１］
　図８は、演算装置割当判断部１３０およびトラヒック量・処理デッドライン予測部１５０の動作１を示すフローチャートである。図８は、トラフィック量または高い処理デッドラインをもつトラヒックの割合が増加する場合のである。
　ステップＳ１１でトラヒック量・処理デッドライン予測部１５０は、入力トラヒック量・処理デッドラインの長さの割合を取得する。
　ステップＳ１２でトラヒック量・処理デッドライン予測部１５０は、入力トラヒック量に対し、各処理デッドラインの割合を乗算し、各トラヒック種別の量を算出する。
　ステップＳ１３でトラヒック量・処理デッドライン予測部１５０は、トラヒックの合計量、もしくは短い処理デッドラインをもつトラヒックの量が、一定回数以上連続して、増加しているか否かを判別する。
　トラヒックの合計量、もしくは短い処理デッドラインをもつトラヒックの量が、一定回数以上連続して、増加していない場合（Ｓ１２：Ｎｏ）、ステップＳ１１に戻る。
　トラヒックの合計量、もしくは短い処理デッドラインをもつトラヒックの量が、一定回数以上連続して、増加している場合（Ｓ１２：Ｙｅｓ）、ステップＳ１４で演算装置性能収集・記録部１１０は、利用可能な演算装置一覧（図４のＤＢテーブル３００）の払出を行う（以下、「払出」とは、情報を取り出して応答することをいう）。
　ステップＳ１５で演算装置割当判断部１３０は、予測したトラヒック量が、現在の処理キャパシティより大きいか否かを判別する。
　予測したトラヒック量が、現在の処理キャパシティより大きい場合（Ｓ１５：Ｙｅｓ）、ステップＳ１６で演算装置割当判断部１３０は、予測した“短い処理デッドラインのトラヒックの量”が、現在の処理キャパシティより高いか否かを判別する。
　予測した“短い処理デッドラインのトラヒックの量”が、現在の処理キャパシティより高い場合（Ｓ１６：Ｙｅｓ）、ステップＳ１７で演算装置割当判断部１３０は、現状よりも、トラヒック性能が高く、リアルタイム性能の高い演算装置の選定および再払出を行いステップＳ２０に進む。
　予測した“短い処理デッドラインのトラヒックの量”が、現在の処理キャパシティより高くない場合（Ｓ１６：Ｎｏ）、ステップＳ１８で演算装置割当判断部１３０は、現状よりも、トラヒック性能が高く、リアルタイム性能が同様以上の演算装置の選定および再払出を行いステップＳ２０に進む。
　一方、上記ステップＳ１５で予測したトラヒック量が、現在の処理キャパシティ以下の場合（Ｓ１５：Ｎｏ）、トラヒック量は増加せず、“高い処理デッドラインを持つトラフィックの割合”が高いケースであると判断して、ステップＳ１９で演算装置割当判断部１３０は、現状よりも、トラヒック性能が同様以上で、リアルタイム性能が高い演算装置の選定および再払出を行いステップＳ２０に進む。
　ステップＳ２０で演算装置割当判断部１３０は、演算装置振分部１７０へ選定結果を通知して本フローの処理を終了する。
［演算装置割当判断部１３０およびトラヒック量・処理デッドライン予測部１５０の動作２］
　図９は、演算装置割当判断部１３０およびトラヒック量・処理デッドライン予測部１５０の動作２を示すフローチャートである。図９は、トラフィック量または高い処理デッドラインをもつトラヒックの割合が減少する場合のである。
　ステップＳ２１でトラヒック量・処理デッドライン予測部１５０は、入力トラヒック量・処理デッドライン割合を取得する。
　ステップＳ２２でトラヒック量・処理デッドライン予測部１５０は、トラヒックの合計量、もしくは高いレイテンシ要求をもつトラヒックの割合が、一定回数以上連続して、減少しているか否かを判別する。
　トラヒックの合計量、もしくは高いレイテンシ要求をもつトラヒックの割合が、一定回数以上連続して、減少していない場合（Ｓ２２：Ｎｏ）、ステップＳ２１に戻る。
　トラヒックの合計量、もしくは高いレイテンシ要求をもつトラヒックの割合が、一定回数以上連続して、減少している場合（Ｓ２２：Ｙｅｓ）、ステップＳ２３で演算装置性能収集・記録部１１０は、利用可能な演算装置一覧（図４のＤＢテーブル３００）の払出を行う。
　ステップＳ２４で演算装置割当判断部１３０は、予測したトラヒック量が、現在の処理キャパシティより小さいか否かを判別する。
　予測したトラヒック量が、現在の処理キャパシティより小さい場合（Ｓ２４：Ｙｅｓ）、ステップＳ２５で演算装置割当判断部１３０は、予測した“短い処理デッドラインのトラヒックの量”が、現在の処理キャパシティより低いか否かを判別する。
　予測した“短い処理デッドラインのトラヒックの割合”が、現在の処理キャパシティより低い場合（Ｓ２５：Ｙｅｓ）、ステップＳ２６で演算装置割当判断部１３０は、現状よりも、トラヒック性能が高く、リアルタイム性能の低い演算装置の選定および再払出を行いステップＳ２９に進む。
　予測した“短い処理デッドラインのトラヒックの割合”が、現在の処理キャパシティより低くない場合（Ｓ２５：Ｎｏ）、ステップＳ２７で演算装置割当判断部１３０は、現状よりも、トラヒック性能が低く、リアルタイム性能が同様以上の演算装置の選定および再払出を行いステップＳ２９に進む。
　一方、上記ステップＳ２４で予測したトラヒック量が、現在の処理キャパシティ以上の場合（Ｓ２４：Ｎｏ）、トラヒック量は：減少せず、“高いレイテンシ要求を持つトラフィックの割合”が減少しているケースであると判断して、ステップＳ２８で演算装置割当判断部１３０は、現状よりも、トラヒック性能が同様以上で、リアルタイム性能が低い演算装置の選定および再払出を行いステップＳ２９に進む。
　ステップＳ２９で演算装置割当判断部１３０は、演算装置振分部１７０へ選定結果を通知して本フローの処理を終了する。
［演算装置割当（ＡＣＣ割当）］
　図１０は、演算装置割当（ＡＣＣ割当）を示すフローチャートである。
　ステップＳ３１で入出力部１３は、データの入出力を行う。
　ステップＳ３２でデータ処理デッドライン判別部１４０は、入力データそれぞれの処理デッドラインを識別したうえで、各機能部に通知する。データ処理デッドライン判別部１４０は、入出力部から、入力データを受け取り、その先頭のヘッダ情報を参照し、処理デッドラインを識別する。
　ステップＳ３３でトラヒック量・処理デッドライン予測部１５０は、一定時間経過後のトラヒック量と処理デッドラインを、現在と過去のトラヒック量と処理デッドラインの割合から予測する。トラヒック量・処理デッドライン予測部１５０は、データ処理デッドライン判別部１４０から、トラヒック量とレイテンシ要求を受け取り、トラヒックおよびレイテンシ要求の割合が、それぞれ増加傾向か否かを予測する。
　ステップＳ３４で演算装置割当部１７０は、一定時間経過後のトラヒック量と処理デッドラインをもとに、性能を充足する演算装置を判断し、演算装置振分部１７０に割り当てる。
　ステップＳ３５で演算装置振分部１７０は、入力データを、事前に割り当てられた演算装置に対し振り分ける。演算装置振分部１７０は、各入力データに含まれる処理デッドライン情報をもとに、処理性能を満たす演算装置を選択し、処理を振り分けて本フローの処理を終了する。
［入力データ処理］
　図１１Ａ－１１Ｃは、入力データ処理を示すフローチャートである。図１１Ａ－１１Ｃは、Look-Aside型のアクセラレータ適用形態に対応する。
　なお、図１１Ａ－１１Ｃは、一つのフローであるが、図示の便宜上、[Ａ]，[Ｂ]，[Ｃ]を連結子として連結される。
　図１１Ａにおいて、ステップＳ４１でアンテナ装置２２０のアンテナ装置データ入出力部２２１は、サーバ２００に対し、アンテナ装置２２０で生成された信号を送る。
　ステップＳ４２で入出力部１３は、外部装置（アンテナ装置２２０）とのデータの入出力を行う。
　ステップＳ４３でアプリケーション１は、入出力部１３からの処理対象データを受け付け、演算したデータを入出力部１３に渡す。
　ステップＳ４４で関数代理実行部１６０は、入力としてアプリケーションから、関数名と引数を受け取り、出力として演算装置振分部１７０に対して、関数名と引数を通知する。
　ステップＳ４５で演算装置振分部１７０は、関数代理実行部１６０から処理対象データを受け付け、ＣＰＵ１１、アクセラレータ１２、遠隔オフロード用サーバのアクセラレータ[遠隔]１２－３のいずれかに、処理対象データを送付する。
　ステップＳ４６で演算装置振分部１７０は、振分先が下記のいずれかを判断する。
　振分先がＣＰＵの場合、図１１ＣのステップＳ４７でＣＰＵ１１は、ソフトウェアを実行してステップＳ５９に進む。
　振分先がアクセラレータ１（アクセラレータ１２－１）の場合、図１１ＣのステップＳ４８でアクセラレータ[性能：高]１２－１は、特定の処理に特化した処理を実行してステップＳ５９に進む。
　振分先がアクセラレータ２（アクセラレータ１２－２）の場合、図１１ＣのステップＳ４９でアクセラレータ[性能：低]１２－２は、特定の処理に特化した処理を実行してステップＳ５９に進む。
　振分先がアクセラレータ[遠隔]（アクセラレータ１２－３）の場合、図１１ＢのステップＳ５０に進む。
　図１１Ｂにおいて、ステップＳ５０で遠隔オフロード部１８０は、入力として演算装置振分部１７０から「関数名・引数」を受け付け、出力として遠隔オフロード用入出力部１４へ「送信データ」を渡す。
　ステップＳ５１で遠隔オフロード用入出力部[クライアント]１４は、遠隔オフロード用サーバ間の通信を行う。
　ステップＳ５２で遠隔オフロード用入出力部[サーバ]１４は、サーバ間の通信を行う。
　ステップＳ５３で遠隔オフロード受付部２１１は、入力として図６の形式のデータを受信し、出力としてアクセラレータ[遠隔]１２－３に対し、処理オフロードを行う。
　ステップＳ５４でアクセラレータ[遠隔]１２－３は、特定の処理に特化した演算を行う。
　ステップＳ５５で遠隔オフロード受付部２１１は、アクセラレータ [遠隔]から、オフロード結果を受信し、図６の形式のデータとして、処理結果を応答する。
　ステップＳ５６で遠隔オフロード用入出力部[サーバ]１４は、サーバ間の通信を行う。
　ステップＳ５７で遠隔オフロード用入出力部[クライアント]１４は、遠隔オフロード用サーバ間の通信を行う。
　ステップＳ５８で遠隔オフロード部１８０は、入力として遠隔オフロード用入出力部１４から、「処理結果データ」を受け付け、出力として演算装置振分部１７０に、処理結果データを渡して図１１ＣのステップＳ５９に進む。
　図１１ＣのステップＳ５９で関数代理実行部１６０は、入力として演算装置振分部１７０から、処理結果を受け取り、出力として処理結果を、アプリケーションに通知する。
　ステップＳ６０で演算装置振分部１７０は、入力としてＣＰＵ、アクセラレータ１２、遠隔オフロード用入出力部１４から、処理結果を受け取り、出力として処理結果を関数代理実行部１６０に通知する。
　ステップＳ６１でアプリケーション１は、入力として入出力部１３から処理対象データを受け付け、出力として演算したデータを入出力部１３に渡す。
　ステップＳ６２で後段処理装置２３０の後段処理装置データ入出力部２３１は、サーバで処理した信号処理結果を受信して本フローの処理を終了する。
　図１２Ａ－１２Ｃは、入力データ処理を示すフローチャートである。図１２Ａ－１２Ｃは、In-line型のアクセラレータ適用形態に対応する。図１１Ａ－１１Ｃと同一処理には同じステップ番号を付している。
　なお、図１２Ａ－１２Ｃは、一つのフローであるが、図示の便宜上、[Ａ]，[Ｂ]，[Ｃ]を連結子として連結される。
　図１２Ａにおいて、ステップＳ４１でアンテナ装置２２０のアンテナ装置データ入出力部２２１は、サーバ２００に対し、アンテナ装置２２０で生成された信号を送る。
　ステップＳ４２で入出力部１３は、外部装置（アンテナ装置２２０）とのデータの入出力を行う。
　ステップＳ４５で演算装置振分部１７０は、関数代理実行部１６０から処理対象データを受け付け、ＣＰＵ１１、アクセラレータ１２、遠隔オフロード用サーバのアクセラレータ[遠隔]１２－３のいずれかに、処理対象データを送付する。
　ステップＳ４６で演算装置振分部１７０は、振分先が下記のいずれかを判断する。
　振分先がＣＰＵの場合、図１２ＣのステップＳ４７でＣＰＵ１１は、ソフトウェアを実行してステップＳ５９に進む。
　振分先がアクセラレータ１（アクセラレータ１２－１）の場合、図１２ＣのステップＳ４８でアクセラレータ[性能：高]１２－１は、特定の処理に特化した処理を実行してステップＳ５９に進む。
　振分先がアクセラレータ２（アクセラレータ１２－２）の場合、図１２ＣのステップＳ４９でアクセラレータ[性能：低]１２－２は、特定の処理に特化した処理を実行してステップＳ５９に進む。
　振分先がアクセラレータ[遠隔]（アクセラレータ１２－３）の場合、図１２ＢのステップＳ５０に進む。
　図１２Ｂにおいて、ステップＳ５０で遠隔オフロード部１８０は、入力として演算装置振分部１７０から「関数名・引数」を受け付け、出力として遠隔オフロード用入出力部１４へ「送信データ」を渡す。
　ステップＳ５１で遠隔オフロード用入出力部[クライアント]１４は、遠隔オフロード用サーバ間の通信を行う。
　ステップＳ５２で遠隔オフロード用入出力部[サーバ]１４は、サーバ間の通信を行う。
　ステップＳ５３で遠隔オフロード受付部２１１は、入力として図６の形式のデータを受信し、出力としてアクセラレータ[遠隔]１２－３に対し、処理オフロードを行う。
　ステップＳ５４でアクセラレータ[遠隔]１２－３は、特定の処理に特化した演算を行う。
　ステップＳ５５で遠隔オフロード受付部２１１は、アクセラレータ [遠隔]から、オフロード結果を受信し、図６の形式のデータとして、処理結果を応答する。
　ステップＳ５６で遠隔オフロード用入出力部[サーバ]１４は、サーバ間の通信を行う。
　ステップＳ５７で遠隔オフロード用入出力部[クライアント]１４は、遠隔オフロード用サーバ間の通信を行う。
　ステップＳ５８で遠隔オフロード部１８０は、入力として遠隔オフロード用入出力部１４から、「処理結果データ」を受け付け、出力として演算装置振分部１７０に、処理結果データを渡して図１２ＣのステップＳ５９に進む。
　図１２ＣのステップＳ５９で関数代理実行部１６０は、入力として演算装置振分部１７０から、処理結果を受け取り、出力として処理結果を、アプリケーションに通知する。
　ステップＳ６０で演算装置振分部１７０は、入力としてＣＰＵ、アクセラレータ１２、遠隔オフロード用入出力部１４から、処理結果を受け取り、出力として処理結果を関数代理実行部１６０に通知する。
　ステップＳ６１でアプリケーション１は、入力として入出力部１３から処理対象データを受け付け、出力として演算したデータを入出力部１３に渡す。
　ステップＳ６２で後段処理装置２３０の後段処理装置データ入出力部２３１は、サーバで処理した信号処理結果を受信して本フローの処理を終了する。
［ハードウェア構成］
　上記実施形態に係るアクセラレータ状態制御システム１０００，１０００Ａ（図１、図２）のアクセラレータ状態制御装置１００（図１）は、例えば図１３に示すような構成のコンピュータ９００によって実現される。
　図１３は、アクセラレータ状態制御装置１００の機能を実現するコンピュータ９００の一例を示すハードウェア構成図である。
　アクセラレータ状態制御装置１００は、ＣＰＵ９０１、ＲＡＭ９０２、ＲＯＭ９０３、ＨＤＤ９０４、アクセラレータ９０５、入出力インターフェイス（Ｉ／Ｆ）９０６、メディアインターフェイス（Ｉ／Ｆ）９０７、および通信インターフェイス（Ｉ／Ｆ：Interface）９０８を有する。アクセラレータ９０５は、図１、図２のアクセラレータ１２に対応する。
　アクセラレータ９０５は、通信Ｉ／Ｆ９０８からのデータ、または、ＲＡＭ９０２からのデータの少なくとも一方のデータを高速に処理するアクセラレータ（デバイス）１２（図１、図２）である。なお、アクセラレータ９０５として、ＣＰＵ９０１またはＲＡＭ９０２からの処理を実行した後にＣＰＵ９０１またはＲＡＭ９０２に実行結果を戻すタイプ（Look-Aside型）を用いてもよい。一方、アクセラレータ９０５として、通信Ｉ／Ｆ９０８とＣＰＵ９０１またはＲＡＭ９０２との間に入って、処理を行うタイプ（In-line型）を用いてもよい。
　アクセラレータ９０５は、通信Ｉ／Ｆ９０８を介して外部装置９１５と接続される。入出力Ｉ／Ｆ９０６は、入出力装置９１６と接続される。メディアＩ／Ｆ９０７は、記録媒体９１７からデータを読み書きする。
　ＣＰＵ９０１は、ＲＯＭ９０３またはＨＤＤ９０４に格納されたプログラムに基づいて動作し、ＲＡＭ９０２に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、図１および図２に示すアクセラレータ状態制御装置１００，１００Ａの各部の制御を行う。そして、このプログラムは、通信回線を介して配布したり、ＣＤ－ＲＯＭ等の記録媒体９１７に記録して配布したりすることも可能である。
　ＲＯＭ９０３は、コンピュータ９００の起動時にＣＰＵ９０１によって実行されるブートプログラムや、コンピュータ９００のハードウェアに依存するプログラム等を格納する。
　ＣＰＵ９０１は、入出力Ｉ／Ｆ９０６を介して、マウスやキーボード等の入力部、および、ディスプレイやプリンタ等の出力部からなる入出力装置９１６を制御する。ＣＰＵ９０１は、入出力Ｉ／Ｆ９０６を介して、入出力装置９１６からデータを取得するともに、生成したデータを入出力装置９１６へ出力する。なお、プロセッサとしてＣＰＵ９０１とともに、ＧＰＵ（Graphics Processing Unit）等を用いてもよい。
　ＨＤＤ９０４は、ＣＰＵ９０１により実行されるプログラムおよび当該プログラムによって使用されるデータ等を記憶する。通信Ｉ／Ｆ９０８は、通信網（例えば、ＮＷ（Network））を介して他の装置からデータを受信してＣＰＵ９０１へ出力し、また、ＣＰＵ９０１が生成したデータを、通信網を介して他の装置へ送信する。
　メディアＩ／Ｆ９０７は、記録媒体９１７に格納されたプログラムまたはデータを読み取り、ＲＡＭ９０２を介してＣＰＵ９０１へ出力する。ＣＰＵ９０１は、目的の処理に係るプログラムを、メディアＩ／Ｆ９０７を介して記録媒体９１７からＲＡＭ９０２上にロードし、ロードしたプログラムを実行する。記録媒体９１７は、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto Optical disk）等の光磁気記録媒体、磁気記録媒体、導体メモリテープ媒体又は半導体メモリ等である。
　例えば、コンピュータ９００が本実施形態に係る一装置として構成されるアクセラレータ状態制御装置１００（図１）として機能する場合、コンピュータ９００のＣＰＵ９０１は、ＲＡＭ９０２上にロードされたプログラムを実行することによりアクセラレータ状態制御装置１００の機能を実現する。また、ＨＤＤ９０４には、ＲＡＭ９０２内のデータが記憶される。ＣＰＵ９０１は、目的の処理に係るプログラムを記録媒体９１７から読み取って実行する。この他、ＣＰＵ９０１は、他の装置から通信網を介して目的の処理に係るプログラムを読み込んでもよい。
　なお、図３に示すコントローラ機能部がサーバ２００外に設置された場合において、このアクセラレータ状態制御装置１００Ａについても同様に、図１６に示すような構成のコンピュータ９００によって実現される。
［効果］
　以上説明したように、処理性能の異なる複数のアクセラレータ１２を有し、アプリケーション１の特定処理をアクセラレータ１２にオフロードして演算処理する際に、アクセラレータの状態を制御するアクセラレータ状態制御装置１００，１００Ａ，１００Ｂ（図１～図３）であって、異なる処理デッドラインが混在するデータが入力される場合において、アクセラレータ１の性能情報を収集し、記録する記録部（演算装置性能収集・記録部１１０）と、現在と過去のトラヒック量と処理デッドラインの割合から所定時間経過後のトラヒック量および処理デッドラインを予測する予測部（トラヒック量・処理デッドライン予測部１５０）と、予測部が予測した所定時間経過後のトラヒック量と処理デッドラインと、記録部に記録されたアクセラレータの性能とをもとに、処理デッドラインに対応するデータ量を求め、データ量をもとに性能を満たすアクセラレータを判断する判断部（演算装置割当判断部１３０）と、を備える。
　解決課題で述べたように、既存技術１（静的割り付け）は、アクセラレータのリソース量が一定であり、<要件２：スケール性>を満たさない。既存技術２（関数プロキシによるスケールアウト）は、アクセラレータ個々の性能の違いを考慮しないため、<要件１：データそれぞれの処理デッドラインの充足>を満たさない。このため、既存技術１は、スケールが固定のため、汎用性が悪く、既存技術２は、応答性が確保できる割合が決まっているため、低レイテンシが求められる処理には向いていなかった。これに対して、本実施形態に係るアクセラレータ状態制御装置１００では、複数の異なるアクセラレータを利用可能な、性能のヘテロ構成のアクセラレータを用いて、各データの処理デッドラインをもとに、アクセラレータを割り当て、オフロードする。これにより、アクセラレータ状態制御装置１００は、既存技術１、既存技術２では実現できなかった汎用性や低レイテンシを両立することができる。
　よって、アクセラレータ状態制御装置１００，１００Ａ，１００Ｂ（図１～図３）は、動的なアクセラレータの払出を実現し、[要件２：スケール性]を満たすことができる。また、アクセラレータ状態制御装置１００，１００Ａ，１００Ｂは、演算時において、データごとの処理デッドラインをもとに、割り当てられたアクセラレータから、性能を満たし消費電力を最小限とするものを選び、オフロードすることで、[要件１：データそれぞれの応答性の充足]を満たすことができる。その結果、アクセラレータ状態制御装置１００は、各処理デッドラインに対応するデータ量の変動に応じ、応答性を担保しつつ、使用する演算リソースの低減を実現することができる。
　アクセラレータ状態制御装置１００，１００Ａ，１００Ｂ（図１～図３）において、入力データの処理デッドラインを識別して通知するデータ処理デッドライン判別部１４０と、データ処理デッドライン判別部１４０が判別した入力データの処理デッドラインと、判断部（演算装置割当判断部１３０）の判断結果をもとに、処理性能を満たすアクセラレータを選択し、選択したアクセラレータに処理を振り分ける振分部（演算装置振分部１７０）を備えることを特徴とする。
　このようにすることにより、演算装置振分部１７０が、データごとの処理デッドラインをもとに、割り当てられたアクセラレータから、性能を満たし、消費電力を最小限とするものを選び、オフロードすることで、[要件１：データそれぞれの応答性の充足]を満たす。よって、アクセラレータ状態制御装置１００は、最適なアクセラレータを割当てるので、省電力を図ることができる。
　アクセラレータ状態制御装置１００，１００Ａ，１００Ｂ（図１～図３）において、アクセラレータを搭載した信号処理装置（サーバ２００，遠隔オフロード用サーバ２１０）間の、遠隔オフロードにおいて生じるレイテンシを計測し、記録するレイテンシ記録部（遠隔オフロードレイテンシ収集・記録部１２０）を備え、判断部（演算装置割当判断部１３０）は、レイテンシ記録部に記録されたレイテンシと記録部（演算装置性能収集・記録部１１０）に記録されたアクセラレータの性能とをもとに、処理デッドラインに対応するデータ量を求め、当該データ量をもとに性能を満たすアクセラレータを判断する。
　例えば、記録部（演算装置性能収集・記録部１１０）は、図５に示すレイテンシテーブル３１０に、アクセス元ホスト情報、アクセス先ホスト情報、レイテンシ（接続レイテンシ）を記録している。判断部（演算装置割当判断部１３０）は、条件に合うアクセラレータを選択する際に、遠隔アクセラレータについてはレイテンシテーブル３１０を参照して、事前に記録したレイテンシと、アクセラレータの性能とを比較して最適なアクセラレータを割当てる。判断部は、遠隔オフロードする際のレイテンシをもパラメータに入れて判断するので、アクセラレータの性能だけでは計れないシステム全体から見た、より最適なアクセラレータを割当てることができる。その結果、[要件２：スケール性]および[要件１：データそれぞれの応答性の充足]をより高次元で達成することができる。
　処理性能の異なる複数のアクセラレータ１２を有し、アプリケーション１の特定処理をアクセラレータ１２にオフロードして演算処理する際に、アクセラレータの状態を制御するアクセラレータ状態制御装置１００，１００Ａ，１００Ｂ（図１～図３）を備えるアクセラレータ状態制御システム１０００，１０００Ａ，１０００Ｂ（図１～図３）であって、アクセラレータ状態制御装置１００は、異なる処理デッドラインが混在するデータが入力される場合において、アクセラレータ１の性能情報を収集し、記録する記録部（演算装置性能収集・記録部１１０）と、現在と過去のトラヒック量および処理デッドラインの割合から所定時間経過後のトラヒック量および処理デッドラインを予測する予測部（トラヒック量・処理デッドライン予測部１５０）と、予測部が予測した所定時間経過後のトラヒック量と処理デッドラインと、記録部に記録されたアクセラレータの性能とをもとに、処理デッドラインに対応するデータ量を求め、データ量をもとに性能を満たすアクセラレータを判断する判断部（演算装置割当判断部１３０）と、を備える。
　このようにすることにより、処理性能の異なる複数のアクセラレータ１２を有し、アプリケーション１の特定処理をアクセラレータ１２にオフロードして演算処理する際に、アクセラレータの状態を制御するアクセラレータ状態制御装置１００，１００Ａ，１００Ｂを備えるアクセラレータ状態制御システム１０００，１０００Ａ，１０００Ｂにおいて、各処理デッドラインに対応するデータ量の変動に応じ、応答性を担保しつつ、使用する演算リソースの低減を実現することができる。
　また、上記実施形態および変形例において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
　また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
　また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。
　１　アプリケーション（ＡＰＬ）
　１０　ハードウェア
　１１　ＣＰＵ
　１２，１２－１，１２－２，１２－３　アクセラレータ
　１３　入出力部
　１４　遠隔オフロード用入出力部
　２０　ソフトウェア
　１００，１００Ａ，１００Ｂ　アクセラレータ状態制御装置
　１１０　演算装置性能収集・記録部（記録部）
　１２０　遠隔オフロードレイテンシ収集・記録部（レイテンシ記録部）
　１３０　演算装置割当判断部
　１４０　データ処理デッドライン判別部
　１５０　トラヒック量・処理デッドライン予測部（予測部）
　１６０　関数代理実行部
　１７０　演算装置振分部（振分部）
　１８０　遠隔オフロード部
　２００　サーバ（アクセラレータ搭載サーバ）（信号処理装置）
　２１０　遠隔オフロード用サーバ（アクセラレータ搭載サーバ）（信号処理装置）
　２２０　アンテナ装置
　２２１　アンテナ装置データ入出力部
　２３０　後段処理装置
　２３１　後段処理装置データ入出力部
　１０００，１０００Ａ，１０００Ｂ　アクセラレータ状態制御システム

Claims (7)

  1. 　処理性能の異なる複数のアクセラレータを有し、アプリケーションの特定処理をアクセラレータにオフロードして演算処理する際に、アクセラレータの状態を制御するアクセラレータ状態制御装置であって、
    　異なる処理デッドラインが混在するデータが入力される場合において、
    　前記アクセラレータの性能情報を収集し、記録する記録部と、
    　現在と過去のトラヒック量と処理デッドラインの割合から所定時間経過後のトラヒック量および処理デッドラインを予測する予測部と、
    　前記予測部が予測した所定時間経過後の前記トラヒック量および前記処理デッドラインと、前記記録部に記録された前記アクセラレータの性能とをもとに、前記処理デッドラインに対応するデータ量を求め、当該データ量をもとに性能を満たすアクセラレータを判断する判断部と、を備える
    　ことを特徴とするアクセラレータ状態制御装置。
  2. 　入力データの処理デッドラインを識別して通知するデータ処理デッドライン判別部と、
    　前記データ処理デッドライン判別部が判別した入力データの前記処理デッドラインと、前記判断部の判断結果をもとに、処理性能を満たすアクセラレータを選択し、選択したアクセラレータに処理を振り分ける振分部と、を備える
    　ことを特徴とする請求項１に記載のアクセラレータ状態制御装置。
  3. 　前記アクセラレータを搭載した信号処理装置間の、遠隔オフロードにおいて生じるレイテンシを収集し、記録するレイテンシ記録部を備え、
    　前記判断部は、前記レイテンシ記録部に記録されたレイテンシと前記記録部に記録された前記アクセラレータの性能とをもとに、前記処理デッドラインに対応するデータ量を求め、当該データ量をもとに性能を満たすアクセラレータを判断する
    　ことを特徴とする請求項１に記載のアクセラレータ状態制御装置。
  4. 　処理性能の異なる複数のアクセラレータを有し、アプリケーションの特定処理をアクセラレータにオフロードして演算処理する際に、前記アクセラレータの状態を制御するアクセラレータ状態制御装置を備えるアクセラレータ状態制御システムであって、
    　前記アクセラレータ状態制御装置は、
    　異なる処理デッドラインが混在するデータが入力される場合において、
    　前記アクセラレータの性能情報を収集し、記録する記録部と、
    　現在と過去のトラヒック量と処理デッドラインの割合から所定時間経過後のトラヒック量および処理デッドラインを予測する予測部と、
    　前記予測部が予測した所定時間経過後の前記トラヒック量および前記処理デッドラインと、前記記録部に記録されたアクセラレータの性能とをもとに、前記処理デッドラインに対応するデータ量を求め、当該データ量をもとに性能を満たすアクセラレータを判断する判断部と、を備える
    　ことを特徴とするアクセラレータ状態制御システム。
  5. 　処理性能の異なる複数のアクセラレータを有し、アプリケーションの特定処理をアクセラレータにオフロードして演算処理する際に、アクセラレータの状態を制御するアクセラレータ状態制御装置のアクセラレータ状態制御方法であって、
    　前記アクセラレータ状態制御装置は、
    　異なる処理デッドラインが混在するデータが入力される場合において、
    　アクセラレータの性能情報を収集し、記録するステップと、
    　現在と過去のトラヒック量と処理デッドラインの割合から所定時間経過後のトラヒック量および処理デッドラインを予測するステップと、
    　予測した所定時間経過後のトラヒック量および処理デッドラインと、記録された前記アクセラレータの性能とをもとに、処理デッドラインに対応するデータ量を求め、当該データ量をもとに性能を満たす前記アクセラレータを判断するステップと、を実行する
    　ことを特徴とするアクセラレータ状態制御方法。
  6. 　処理性能の異なる複数のアクセラレータを有し、アプリケーションの特定処理をアクセラレータにオフロードして演算処理する際に、前記アクセラレータの状態を制御するアクセラレータ状態制御装置を備えるアクセラレータ状態制御システムのアクセラレータ状態制御方法であって、
    　前記アクセラレータ状態制御装置は、
    　異なる処理デッドラインが混在するデータが入力される場合において、
    　アクセラレータの性能情報を収集し、記録するステップと、
    　現在と過去のトラヒック量と処理デッドラインの割合から所定時間経過後のトラヒック量および処理デッドラインを予測するステップと、
    　予測した所定時間経過後の前記トラヒック量および前記処理デッドラインと、記録された前記アクセラレータの性能とをもとに、処理デッドラインに対応するデータ量を求め、当該データ量をもとに性能を満たすアクセラレータを判断するステップと、を実行する
    　ことを特徴とするアクセラレータ状態制御方法。
  7. 　処理性能の異なる複数のアクセラレータを有し、アプリケーションの特定処理をアクセラレータにオフロードして演算処理する際に、前記アクセラレータの状態を制御するアクセラレータ状態制御装置としてコンピュータに、
    　異なる処理デッドラインが混在するデータが入力される場合において、
    　アクセラレータの性能情報を収集し、記録する手順、
    　現在と過去のトラヒック量と処理デッドラインの割合から所定時間経過後のトラヒック量および処理デッドラインを予測する手順、
    　予測した所定時間経過後の前記トラヒック量および前記処理デッドラインと、記録された前記アクセラレータの性能とをもとに、処理デッドラインに対応するデータ量を求め、当該データ量をもとに性能を満たすアクセラレータを判断する手順、
    　を実行させるためのプログラム。
PCT/JP2022/029707 2022-08-02 2022-08-02 アクセラレータ状態制御装置、アクセラレータ状態制御システム、アクセラレータ状態制御方法およびプログラム WO2024028990A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/029707 WO2024028990A1 (ja) 2022-08-02 2022-08-02 アクセラレータ状態制御装置、アクセラレータ状態制御システム、アクセラレータ状態制御方法およびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/029707 WO2024028990A1 (ja) 2022-08-02 2022-08-02 アクセラレータ状態制御装置、アクセラレータ状態制御システム、アクセラレータ状態制御方法およびプログラム

Publications (1)

Publication Number Publication Date
WO2024028990A1 true WO2024028990A1 (ja) 2024-02-08

Family

ID=89848723

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/029707 WO2024028990A1 (ja) 2022-08-02 2022-08-02 アクセラレータ状態制御装置、アクセラレータ状態制御システム、アクセラレータ状態制御方法およびプログラム

Country Status (1)

Country Link
WO (1) WO2024028990A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110131580A1 (en) * 2009-11-30 2011-06-02 International Business Machines Corporation Managing task execution on accelerators
CN111061547A (zh) * 2019-10-24 2020-04-24 中国科学院计算技术研究所 一种异构系统的任务调度方法及系统
US20220035665A1 (en) * 2020-07-28 2022-02-03 Microsoft Technology Licensing, Llc Sharing of compute resources between the virtualized radio access network (vran) and other workloads

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110131580A1 (en) * 2009-11-30 2011-06-02 International Business Machines Corporation Managing task execution on accelerators
CN111061547A (zh) * 2019-10-24 2020-04-24 中国科学院计算技术研究所 一种异构系统的任务调度方法及系统
US20220035665A1 (en) * 2020-07-28 2022-02-03 Microsoft Technology Licensing, Llc Sharing of compute resources between the virtualized radio access network (vran) and other workloads

Similar Documents

Publication Publication Date Title
CN1610347B (zh) 在基于群集的系统内管理性能及资源利用率的方法和设备
US9442763B2 (en) Resource allocation method and resource management platform
US8484650B2 (en) Resource management system, resource information providing method and program for providing resource information relating to a plurality of resources
US10993127B2 (en) Network slice instance management method, apparatus, and system
US20120167081A1 (en) Application Service Performance in Cloud Computing
US8789050B2 (en) Systems and methods for transparently optimizing workloads
JP5000456B2 (ja) 資源管理システム、資源管理装置およびその方法
JP4984169B2 (ja) 負荷分散プログラム、負荷分散方法、負荷分散装置およびそれを含むシステム
CN110866167B (zh) 任务分配方法、装置、服务器和存储介质
CN111628887B (zh) 物联网切片资源分配系统、方法、电子设备及存储介质
KR20180124419A (ko) 분산형 클라우드 기반 어플리케이션 실행 시스템, 이에 적용되는 장치 및 장치의 동작 방법
KR102410586B1 (ko) 사물인터넷 엣지 컴퓨팅 환경을 위한 컨테이너 기반 동적 자원 분배 방법 및 장치
WO2022100365A1 (zh) 人工智能应用任务的管理方法、系统、设备及存储介质
US11838389B2 (en) Service deployment method and scheduling apparatus
CN114116173A (zh) 动态调整任务分配的方法、装置和系统
WO2024028990A1 (ja) アクセラレータ状態制御装置、アクセラレータ状態制御システム、アクセラレータ状態制御方法およびプログラム
JP7176633B2 (ja) 仮想化基盤制御装置、仮想化基盤制御方法および仮想化基盤制御プログラム
CN113765964A (zh) 一种分布式系统服务分发的方法和装置
KR101394365B1 (ko) 가상화 환경에서 프로세서를 할당하는 장치 및 방법
JP7360036B2 (ja) 情報処理装置、情報処理システム、情報処理方法およびプログラム
JP2022166934A (ja) 情報処理装置、過負荷制御プログラムおよび過負荷制御方法
CN113190361A (zh) 数据传输策略的调整方法、装置、设备及存储介质
JP6059259B2 (ja) 計算機システム及び計算機リソースの割当方法
US20190312925A1 (en) Time-based congestion discounting for i/o fairness control
KR101495767B1 (ko) 클라우드 컴퓨팅에서 중계자를 통한 데이터 분산 최적화 장치 및 그 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22953979

Country of ref document: EP

Kind code of ref document: A1