An online hardware experiment double-layer scheduling method
By adopting a two-layer scheduling method for online hardware experiments, the problem of insufficient utilization of remote hardware experiment resources was solved, and efficient resource scheduling and flexible management of experimental tasks were achieved, thereby improving teaching efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-10-26
- Publication Date
- 2026-03-24
AI Technical Summary
Existing remote hardware experimental platforms suffer from resource limitations and operating environment issues, resulting in underutilization of experimental resources and impacting teaching effectiveness.
A two-layer scheduling method for online hardware experiments is adopted, which achieves efficient resource utilization through schedulers on cloud data center servers and hardware resources. The first-layer scheduler allocates tasks according to resource status and monitors and migrates them in real time during the experiment. The second-layer scheduler manages the running order and time slice allocation of multiple tasks.
This enables efficient use of hardware experimental resources, provides effective services to more users, and improves teaching effectiveness.
Smart Images

Figure CN115658306B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The application belongs to the field of online hardware experiment teaching, and relates to an online hardware experiment double-layer scheduling method. BACKGROUND
[0002] The demand for hardware talents is increasing in today's society. The quality of hardware talent cultivation is closely related to the education level of hardware courses in colleges and universities, so only the innovation of hardware teaching methods can promote the development of hardware education in the new era. Although there are many deployment schemes of remote experiment platforms at present, the overall system cannot guarantee efficient operation and the resources cannot be fully utilized due to the actual running environment and limited experimental resources, which hinders the arrangement of teachers' teaching tasks and affects the actual teaching effect to some extent. Considering the above factors, a technical method and system that can meet the above pain points are needed to ensure the effective implementation of hardware teaching in colleges and universities. SUMMARY
[0003] The application provides an online hardware experiment double-layer scheduling method and system, which can realize efficient utilization and flexible scheduling of online hardware experiment resources and meet the needs of more users to perform hardware experiments online.
[0004] According to the design scheme provided by the application, an online hardware experiment double-layer scheduling method is provided, which includes the following contents:
[0005] A user establishes a remote connection relationship with a cloud computer room server through the Internet;
[0006] The cloud computer room server starts a first-layer scheduler, and executes a corresponding first-layer scheduling strategy through the scheduler. The first-layer scheduler allocates an experiment task to the most suitable hardware resource according to the running state parameters of the current hardware experiment resource to deploy an experiment environment. During the experiment running, the first-layer scheduler monitors the state of each experiment running in real time. If the response time of a certain experiment task is too long, and the allocated resource is insufficient to meet the smooth running, the scheduler will be responsible for scheduling the experiment task to more suitable hardware resources for continuous execution.
[0007] The hardware resource starts a second-layer scheduler, which is responsible for managing the running order of multiple experiment tasks running on the hardware resource. The scheduler allocs a time slice to each experiment task. When the time slice of a certain task is used up, the scheduler saves the state information of the task during the running period to a storage unit, and suspends the task to wait for the allocation of the next time slice, while providing running conditions for other ready tasks.
[0008] Further, the application also provides an online hardware experiment double-layer scheduling system for coordinating the orderly progress of the resource scheduling work of hardware resources and cloud room servers, comprising: an experiment user end, a cloud room server connected with users through the Internet, and a board card resource cluster in communication connection with the cloud room server; wherein
[0009] The user establishes a connection with the cloud room server through the Internet, uploads an experiment configuration file to the server after the connection is established, applies for idle resources from the board card resource cluster, and sends the experiment configuration file to the board card resources, and the board card automatically configures the development board experiment element according to the pin constraint condition determined in the configuration file. With the increase of the number of online experiment users, a single hardware resource will be responsible for running multiple experiment tasks, maintaining a second-layer task scheduling queue, and allocating time slices to each running task and synchronously running the experiment state generated by the task to a storage unit, so as to restore the experiment environment when the subsequent experiment task is scheduled.
[0010] As preferred, step two comprises:
[0011] Sub-step two one, performing availability screening of experiment resources:
[0012] The cloud server confirms the online experiment board card through a heartbeat mechanism, saves network resources by carrying a Request identifier in a heartbeat request, and simultaneously carries the request resource amount of an experiment. After receiving the network request, the experiment board card responds according to the remaining resource amount of the board card. If the remaining resources are insufficient to support a student experiment, the board card side responds to the refusal, indicating that the resources are currently unavailable. If the resources are sufficient, the response is accepted;
[0013] The cloud server collects the response messages of each experiment board card, filters out the experiment board cards with accepted signals, and enters sub-step two two. If there is no experiment board card with an accepted signal in the first stage, the task is added to the scheduling waiting queue. The scheduler re-schedules at a preset time T interval ;
[0014] Sub-step two two, performing optimal selection of available experiment resources;
[0015] First, the weighted value of each running attribute of the hardware board card is calculated. The attribute weighted value is calculated as follows:
[0016]
[0017] Wherein, Score is the value obtained after weighting, n is the number of parameters referred to by the scheduler, c i is the weight value of parameter i, and p i is the original value of parameter i;
[0018] After the weighting calculation, the board card is selected according to the weighted value to perform the experimental task in the environment deployment: the weighting coefficient in the weighting calculation is determined by the AHP hierarchical analysis method, and c ij is set as the importance of parameter i to j, and satisfies c ij The 1-9 scale method is usually used for judgment;
[0019] The parameter scale matrix M is constructed, and the components ω i are solved as follows:
[0020]
[0021]
[0022] After solving, the ω i corresponding to the weight value c i of parameter i is obtained.
[0023] As preferred, step two further comprises:
[0024] The first layer scheduler performs the preloading action of the target board card when determining to execute the migration action;
[0025] The first layer scheduler notifies the target board card obtained through the two-stage screening and generates an empty task in the target board card, and sets the migration countdown time t trans The resource amount occupied by the empty task is consistent with the resource amount occupied by the ordinary experimental task;
[0026] The target board card returns the first layer scheduler Pre-Located signal after the empty task generation is successfully completed, indicating that the environment has been preloaded, and the first layer scheduler performs the overall migration of the experimental resources after receiving the signal. After receiving the experimental resources, the target board card replaces the empty task with the real experimental task, and after replacing the task, returns the first layer scheduler Located signal. The first layer scheduler performs the task cleaning work on the original board card after receiving the signal;
[0027] If the target board card fails to generate an empty task, it returns the scheduler Rejected signal, indicating that the board card currently creates a new task with an error and is not suitable for scheduling experimental tasks. The scheduler receives the signal and switches to the next target board card to repeat the task transfer work until the task transfer is completed.
[0028] If there is no other available board card, the migration task is saved in the queue, waiting for the subsequent available resources to appear;
[0029] If the first layer scheduler fails to receive the Pre-Located signal sent by the target board card, it waits for a preset waiting time interval t interval and then requests the target board card again, waits for the target board card to return a signal, and if the first layer scheduler fails to receive the Pre-Located signal for three times, the scheduler gives up the board card and switches to the next target board card for migration work;
[0030] If there is no other available board card, the migration task is saved in the queue and waits for the subsequent available resources; at this time, the original target board card is cleared by the preset countdown time t trans , and the empty task is cleared by the board card after the countdown to ensure the availability of resources.
[0031] As a preferred, the second layer scheduler in step three is responsible for managing multiple experimental tasks running on the same board card:
[0032] The scheduler allocates a time slice to the task in the running state, and when the time slice expires, the task is suspended, and at the same time, the hardware state generated by the task is recorded in the board card storage unit;
[0033] After that, the task is arranged at the end of the queue by the second layer scheduler to wait for the next scheduling, and at the same time, the second layer scheduler selects the task at the head of the queue, allocates a time slice to it, and restores the hardware state of the task before it is suspended to the hardware resources. After the hardware state recovery stage ends, the task is in the running state.
[0034] As a preferred, step three further includes:
[0035] When the first layer scheduler determines to require the task on a hardware board card to be transferred to other resources for running, the first layer scheduler transmits a task transfer instruction to the second layer scheduler through the external interface of the hardware board card;
[0036] When the second layer scheduler receives the instruction, it immediately removes the task in the task queue, and if the task is in the running state, the scheduler immediately stops the task and returns the hardware state generated by the task to the first layer scheduler, and then the task at the head of the task queue starts running;
[0037] The first layer scheduler receives the hardware state corresponding to the task and transfers the task to the selected hardware board card;
[0038] The second layer scheduler running on the selected board card receives the transferred task and saves the hardware state carried by the task in the hardware storage unit, and then adds the task to the task queue to wait for the scheduling and running of the second layer scheduler.
[0039] The application further provides an online hardware experiment double-layer scheduling system for coordinating the orderly progress of resource scheduling work of hardware resources and cloud computer room servers, comprising: an experiment user end, a cloud computer room server connected with users through the Internet, and a board card resource cluster in communication connection with the cloud computer room server; wherein,
[0040] The user establishes a connection with the cloud computer room server through the Internet, uploads an experiment configuration file to the server after the connection is established, applies for idle resources from the board card resource cluster by the cloud computer room server, and sends the experiment configuration file to the board card resources, and the board card automatically configures the development board experiment element according to the pin constraint condition determined in the configuration file. With the increase of the number of online experiment users, a single hardware resource will be responsible for running multiple experiment tasks, maintaining a second layer task scheduling queue, and allocating time slices for each runtime task and synchronously running the experiment state generated by the task into a storage unit, so as to restore the experiment environment when the subsequent experiment task is scheduled.
[0041] The application has the advantages that the user establishes a connection with the cloud server through the Internet and performs experiment operation on a remote device, truly realizes remote configuration of hardware devices, meets the requirements of remote experiment, and through the execution of the online hardware experiment double-layer scheduling strategy, the experiment system can provide effective services for a larger user group, meets the purpose of efficient use of experiment resources, and has good practical application prospect. BRIEF DESCRIPTION OF DRAWINGS
[0042] Figure 1 The figure is a flowchart of the online hardware experiment double-layer scheduling system in the embodiment.
[0043] Figure 2 The figure is a structural diagram of the online hardware experiment double-layer scheduling system in the embodiment. DETAILED DESCRIPTION
[0044] The technical solutions of the application will be further described in detail below with reference to specific embodiments and in combination with the drawings.
[0045] Embodiment 1
[0046] As shown in Figure 1 and Figure 2 , the embodiment of the application provides an online hardware experiment double-layer scheduling method and system, which comprises the following contents:
[0047] The embodiment of the application provides an online hardware experiment double-layer scheduling method and system, which comprises the following contents:
[0048] S101, the user end establishes a remote connection relationship with the cloud computer room server through the Internet;
[0049] S102, the cloud room server starts a first layer scheduler, and executes a corresponding first layer scheduling strategy through the scheduler, the first layer scheduler allocates an experiment task to the most suitable hardware resource according to the running state parameter of the current hardware experiment resource, and deploys an experiment environment on the hardware resource;
[0050] S103, the hardware resource receives the experiment task distributed by the cloud server, and automatically configures the development board experiment element according to the pin constraint condition determined in the experiment task configuration file. At the same time, the hardware resource starts a second layer scheduler, and the second layer scheduler is responsible for managing the running order of multiple experiment tasks running on the hardware resource.
[0051] The user initiates a request to establish a connection to the back-end cloud server through the front-end page, after the connection is established, the user transmits the user unique identifier, hardware configuration file and hardware operation sequence to the server through the external interface of the server, wherein the user unique identifier is used to confirm that the request originates from the user and provide exclusive service for the user; the hardware configuration file specifies the pin constraint condition of the hardware resource, which is used for automatic configuration of the component state information of the hardware resource; the hardware operation sequence is the operation instruction transmitted to the server by the user online interactive operation, which is used for the server to parse the instruction and translate it into actual hardware instruction to execute on the hardware resource.
[0052] After the cloud server confirms the connection, it packages the user's experiment resource and user unique identifier into an experiment task object, and at the same time, the cloud server starts the first layer scheduling work, which is divided into two stages:
[0053] The first stage carries out availability screening of the experiment resource, the cloud server confirms the online of the experiment board through the heartbeat mechanism, in order to save network resources, a Request identifier is carried in a heartbeat request, and the request resource amount of an experiment is also carried. After receiving the network request, the board card responds according to the remaining resource amount of the board card, if the remaining resource is insufficient to support a student experiment, the board card side responds to refuse, indicating that the resource is currently unavailable, if the resource is sufficient, the response is accepted. The cloud server collects the response messages of each experiment board, and filters out the experiment boards with accepted response signals to enter the second stage of screening. If there is no experiment board with accepted response signal in the first stage, the task is added to the scheduling waiting queue, and the scheduler re-schedules at a preset time T interval .
[0054] The second stage carries out optimal selection of available experiment resources. The server first calculates the weighted value of each running attribute of the hardware board, and the attribute weighted value is calculated as follows:
[0055]
[0056] Where Scpre is the weighted value, n is the number of parameters referenced by the scheduler, and c i p represents the weight of parameter i. i This is the original value of parameter i. After the weighted calculation is completed, the server selects the optimal board for the experimental task environment deployment based on the weighted value. The weighting coefficients in the weighted calculation are determined by the AHP (Analytic Hierarchy Process), and c is set to... ij Let i be the importance of parameter i with respect to j, and satisfy the following condition: c ij The 1-9 scale method is usually used for discrimination, as shown in the table below:
[0057]
[0058] Construct the parameter scaling matrix M based on the table above, and then extract the eigenvector components ω from the matrix. i The following solution is performed:
[0059]
[0060]
[0061] The ω obtained after solving i That is, the weight c corresponding to parameter i. i .
[0062] For the hardware configuration file uploaded by the user, the server first backs it up to the storage module, and then transfers the file to the selected hardware board through the external interface on the hardware board, configures the chip pin constraint scheme of the development board, and loads the basic environment for the user's experiment.
[0063] To address the discrepancy between user request rates and cloud server processing rates, the implementation example sets up a task queue in the first-level scheduling to store unprocessed experimental tasks.
[0064] The first-level scheduler monitors the response status of experimental tasks in real time and reschedules tasks with untimely service responses to suitable hardware resources for continued experimentation. Specifically, the first-level scheduler is responsible for migrating experimental tasks to other boards for execution when the following conditions are met:
[0065] t i >T threshold .
[0066] Among them, t i T represents the response time of experimental task i. threshold This represents the maximum response time for all preset experimental tasks. When the response time of a task exceeds this preset value, the first-level scheduler is responsible for migrating the task to the selected hardware board.
[0067] When experimental tasks are assigned to the board, the second-level scheduler manages multiple experimental tasks running on the same board. The scheduler allocates time slices to tasks in a running state. Within a time slice, the task runs normally in the hardware environment. When the time slice expires, the task is suspended, and the hardware state generated by the task is recorded in the board's storage unit. Afterward, the second-level scheduler places the task at the end of the queue to await the next scheduling. Simultaneously, the second-level scheduler selects the task at the head of the queue, allocates a time slice to it, and restores the hardware state of the task from the storage unit before it was suspended to the hardware resources. After the hardware state restoration phase is completed, the task is in a running state.
[0068] When the first-level scheduler determines that a task on a certain hardware board needs to be transferred to another resource, it transmits a task transfer instruction to the second-level scheduler through the hardware board's external interface. Upon receiving the instruction, the scheduler immediately removes the task from the task queue. If the task is already running, the scheduler immediately stops the task, returns the task's hardware state to the first-level scheduler, and then the task at the head of the task queue begins execution.
[0069] After receiving the hardware status corresponding to the task, the first-level scheduler carries the status and transfers the task to the selected hardware board.
[0070] The second-level scheduler running on the selected board receives the transferred task and saves its hardware state to its local hardware storage unit. Then, it adds the task to the task queue to wait for the second-level scheduler to schedule and run it.
[0071] To ensure a smooth transfer of experimental tasks, the first-level scheduler preloads the target board before deciding to execute the migration action. The scheduler then notifies the high-quality boards selected through the two-stage screening to generate an empty task and sets a migration countdown timer t. trans The resource usage of an empty task is consistent with that of a regular experimental task. After the destination board successfully generates an empty task, it returns a Pre-Located signal to the first-level scheduler, indicating that the environment has been pre-loaded. Upon receiving this signal, the first-level scheduler performs the overall migration of experimental resources. After receiving the experimental resources, the destination board replaces the empty task with a real experimental task. After the task replacement is completed, it returns a Located signal to the first-level scheduler. Upon receiving this signal, the scheduler performs the task cleanup on the original board.
[0072] If a high-quality board fails to generate an empty task, a "Rejected" signal is returned to the scheduler, indicating that the board is currently experiencing an error in creating a new task and is not suitable for scheduling the experimental task. Upon receiving this signal, the scheduler switches to the next high-quality board and repeats the task transfer process until the transfer is complete. If no other available boards are available, the migration task is saved in a queue, waiting for subsequent available resources to become available.
[0073] If the scheduler fails to receive the Pre-Located signal from the destination board, it will wait for a preset time interval t. interval The scheduler then requests the destination board again and waits for a return signal. If the scheduler fails to receive the Pre-Located signal more than three times, it abandons the board and switches to the next available high-quality board for the migration. If no other available boards are available, the migration task is kept in a queue, waiting for subsequent available resources to become available. At this point, the original high-quality board is still inactive due to the preset countdown time t. trans Empty tasks are cleared by the board after the timer ends to ensure resource availability.
Claims
1. A two-layer scheduling method for online hardware experiments, characterized in that, include: Step 1: The user establishes a remote connection with the cloud data center server via the Internet; After confirming the connection, the cloud server starts the first-level scheduler. Step 2: The cloud data center server starts the first-level scheduler and executes the corresponding first-level scheduling strategy through the scheduler. The first-level scheduler allocates experimental tasks to hardware resources for experimental environment deployment based on the current running status parameters of the hardware experimental resources. During the experimental operation, the first-level scheduler monitors the status of each experimental operation in real time. If the response time of a certain experimental task is too long or the allocated resources are insufficient to meet its smooth operation, the experimental task is scheduled to other hardware resources to continue execution. Sub-step 21: Screening for the availability of experimental resources: The cloud server confirms the online status of the experimental board through a heartbeat mechanism. To save network resources, a Request identifier is carried in each heartbeat request, along with the amount of resources requested for one experiment. After receiving the network request, the experimental board responds according to the remaining resources on the board. If the remaining resources are insufficient to support one student experiment, the board responds with a rejection, indicating that the resource is currently unavailable. If the resources are sufficient, the board responds with an acceptance. The cloud server collects response messages from each experimental board, filters out those boards that have received a response signal, and proceeds to sub-step two. If no experimental board receives a response signal in the first stage, the task is added to the scheduling waiting queue, and the scheduler will complete the task within a preset time. Then rescheduling will be performed; Sub-step 22 involves making the optimal selection of available experimental resources; First, calculate the weighted values of each operating attribute of the hardware board. The weighted values are calculated as follows: ; in, The weighted value is the result of the weighting. The number of parameters referenced by the scheduler. Let i be the weight of parameter i. This is the original value of parameter i; After completing the weighted calculation, the boards are selected for the experimental task environment deployment based on the weighted values. The weighting coefficients in the weighted calculation are determined by the Analytic Hierarchy Process (AHP). Let i be the importance of parameter i with respect to j, and satisfy... , The 1-9 scale method is usually used for discrimination; Constructing the parameter scaling matrix And perform eigenvector component analysis on the matrix. The following solution is performed: ; ; The result after solving That is, the weight corresponding to parameter i. ; Step 3: The hardware resources start the second-level scheduler. The second-level scheduler is responsible for managing the running order of multiple experimental tasks running on the hardware resources, allocating time slices for each experimental task, and when a task's time slice is used up, the second-level scheduler saves the status information of the task during its operation to the storage unit and suspends the task to wait for the next time slice allocation, while providing running conditions for other ready tasks.
2. The online hardware experiment two-layer scheduling method according to claim 1, characterized in that, In step one, the user initiates a connection request to the backend cloud server through the front-end page. After the connection is established, the user transmits their unique identifier, hardware configuration file, and hardware operation sequence to the server through the server's external interface. Among them, the user's unique identifier is used by the server to confirm that the request originated from that user and to provide dedicated service to that user; The hardware configuration file specifies the pin constraints of hardware resources and is used for the automated configuration of component status information of hardware resources. The hardware operation sequence consists of operation instructions transmitted to the server by the user's online interactive operation. The server parses the instructions and converts them into actual hardware instructions for execution on hardware resources. After confirming the connection, the cloud server packages the user's experimental resources and the user's unique identifier into an experimental task object. At the same time, the cloud server begins to execute the first-level scheduling policy through the first-level scheduler.
3. The online hardware experiment two-layer scheduling method according to claim 1, characterized in that, Step two also includes: When determining to perform a migration action, the first-level scheduler first performs a preloading action on the destination board; The first-level scheduler notifies the target board obtained through the two-stage screening and generates an empty task on the target board, setting a migration countdown timer. The amount of board resources used by an empty task is the same as that used by a normal experimental task; After the target board successfully generates an empty task, it returns a Pre-Located signal to the first-level scheduler, indicating that the environment has been preloaded. After receiving this signal, the first-level scheduler performs the overall migration of experimental resources. After the target board receives the experimental resources, it replaces the empty task with a real experimental task. After the task replacement is completed, it returns a Located signal to the first-level scheduler. After receiving this signal, the first-level scheduler performs the task clearing work on the original board. If the target board fails to generate an empty task, a Rejected signal is returned to the scheduler, indicating that the board is currently experiencing an error in creating a new task and is not suitable for scheduling the experimental task. After receiving this signal, the scheduler switches to the next target board and repeats the task transfer process until the task transfer is completed. If no other boards are available, the migration task will be kept in the queue and will wait for subsequent available resources to become available. If the first-level scheduler fails to receive the Pre-Located signal from the destination board, it will wait for a preset time interval. Then, the system requests the target board again and waits for the target board to return a signal. If the first-level scheduler fails to receive the Pre-Located signal more than 3 times, the scheduler will abandon the board and switch to the next target board for the transfer operation. If no other boards are available, the migration task will be saved in the queue, waiting for subsequent available resources to become available; at this time, the original target board will be affected by the preset countdown timer. Empty tasks are cleared by the board after the timer ends to ensure resource availability.
4. The online hardware experiment two-layer scheduling method according to claim 1, characterized in that, In step three, the second-level scheduler is responsible for managing multiple experimental tasks running on the same board: The scheduler allocates time slices to tasks that are in the running state. When the time slice expires, the task is suspended. At the same time, the hardware state generated by the task is recorded in the board's storage unit. Subsequently, the task is placed at the end of the queue by the second-level scheduler to await the next scheduling. At the same time, the second-level scheduler selects the task at the head of the queue, allocates a time slice to it, and restores the hardware state of the task in the storage unit before it was suspended to the hardware resources. After the hardware state restoration phase is completed, the task is in the running state.
5. The online hardware experiment two-layer scheduling method according to claim 1, characterized in that, Step three also includes: When the first-level scheduler determines that a task on a certain hardware board needs to be transferred to other resources, the first-level scheduler transmits the task transfer instruction to the second-level scheduler through the external interface of the hardware board. When the second-level scheduler receives the instruction, it immediately removes the task from the task queue. If the task is in a running state, the scheduler immediately stops the task and returns the hardware state generated by the task to the first-level scheduler. After that, the task at the head of the task queue begins to run. After receiving the hardware status corresponding to the task, the first-level scheduler carries the status and transfers the task to the selected hardware board. The second-level scheduler running on the selected board receives the transferred task and saves its hardware state to its local hardware storage unit. Then, it adds the task to the task queue to wait for the second-level scheduler to schedule and run it.
Citation Information
Patent Citations
Resource state information-based grid task scheduling processor and grid task scheduling processing method
CN101957780A
Virtual container based big data storage and management method
CN105045656A