VxWorks network transmission optimization method based on dynamic priority mapping and burst scheduling

Abstract

The invention relates to a VxWorks network transmission optimization method based on dynamic priority mapping and burst scheduling, and belongs to the technical field of embedded real-time operating system network communication. According to the method, a traditional thought of scheduling at a protocol stack high layer or a network equipment queue is abandoned, and dynamic scheduling is implemented in the last ring of a network card drive sending queue after a data packet is processed by a protocol stack. According to the method, a dynamic priority label based on a protocol and a system state is marked on a data packet, and a sending scheduling algorithm based on high-priority sudden preemption is designed, so that a high-priority UDP message can be sent in a queue jumping manner with extremely low delay, and the interference of TCP mass and continuous data transmission on a UDP real-time message is effectively isolated. According to the method, special hardware support is not needed, lightweight scheduling of the kernel mode is achieved, and the method is particularly suitable for VxWorks and other embedded systems with extremely high requirements for real-time performance.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of embedded real-time operating system network communication, and particularly relates to a VxWorks network transmission optimization method based on dynamic priority mapping and burst scheduling. BACKGROUND

[0002] In real-time systems such as VxWorks, UDP (User Datagram Protocol) and TCP (Transmission Control Protocol) are used in different scenarios due to their different characteristics. UDP is connectionless, unreliable but low-latency, and is often used in scenarios such as audio / video streaming, sensor data, real-time control instructions, etc. that require high timeliness. TCP is connection-oriented, reliable but has larger latency and jitter, and is used for file transfer, configuration update, etc. that require high reliability.

[0003] When these two types of traffic are mixed on the same network link, the congestion control mechanism of TCP (such as sliding window, slow start) will try to occupy all available bandwidth, and its continuous large data transmission will severely block the network interface. Traditional VxWorks network stack and network card driver use FIFO (First-In-First-Out) queue scheduling strategy, which causes UDP packets to have to wait in line, resulting in unacceptable latency and jitter, and destroying the determinism of real-time systems.

[0004] The prior art usually adopts the following solutions:

[0005] 1. Traffic Shaping: limit the sending rate of TCP and reserve bandwidth for UDP. The disadvantage is that it needs to be pre-configured with bandwidth, which is not flexible, and the total bandwidth utilization is low.

[0006] 2. Protocol stack QoS (such as DiffServ): set the ToS (Type of Service) field at the network layer. The disadvantage is that it needs the support of network devices (switches, routers) to take effect, and is often ineffective in closed embedded network environments.

[0007] 3. User-mode multi-queue network card: use hardware features to assign different priorities to different queues. The disadvantage is that it requires specific hardware support, which is costly and has poor universality.

[0008] These methods either have complex configurations, or rely on external environments, or have high hardware costs, and none of them provides a lightweight, universal and efficient solution at the kernel level of VxWorks. Therefore, there is an urgent need for a novel endogenous method to solve this problem from the bottom of the operating system. SUMMARY

[0009] (I) Technical problems to be solved

[0010] The technical problem this invention aims to solve is: to provide a VxWorks network transmission optimization method to address the following issues encountered when TCP and UDP messages are transmitted together in the VxWorks system:

[0011] 1. UDP messages suffer from unpredictable delays and jitter due to TCP traffic;

[0012] 2. Traditional solutions rely on hardware or external network equipment, resulting in high costs and poor versatility;

[0013] 3. When transmitting mixed messages, both real-time performance and fairness must be considered.

[0014] (II) Technical Solution

[0015] To address the aforementioned technical problems, this invention provides a VxWorks network transmission optimization method based on dynamic priority mapping and burst scheduling, comprising the following steps:

[0016] S1: Intercepts data packets, parses and identifies protocol types, and dynamically prioritizes data packets by monitoring network load in real time;

[0017] S2: Modify the network card driver's sending routine to reconstruct the first-in-first-out (FIFO) sending queue into multiple virtual sub-queues based on the priority assigned in step S1;

[0018] S3: In the driver transmit interrupt service routine (ISR) or transmit task, data packets are scheduled using a burst scheduling algorithm that combines "burst transmission" and "single packet round-robin".

[0019] The present invention also provides a network communication method for an embedded real-time operating system based on the aforementioned method.

[0020] (III) Beneficial Effects

[0021] This invention provides a VxWorks network transmission optimization method based on dynamic priority mapping and burst scheduling. It is a method to optimize the performance of UDP and TCP hybrid transmission in VxWorks system and significantly reduce the impact of TCP traffic on UDP real-time message transmission latency and jitter.

[0022] The innovation of this invention compared to traditional methods lies in:

[0023] 1. Innovative scheduling location: The scheduling point is set at the mBlk level between the protocol stack and the driver. This is the earliest time that the operating system kernel can fully identify the application data protocol type. Compared with scheduling at the application layer, socket layer or hardware queue, it is more low-level and efficient.

[0024] 2. Dynamic priority mechanism: A dynamic priority adjustment based on real-time traffic status is introduced to avoid the bandwidth idling problem caused by static priority setting, and intelligent resource utilization is achieved.

[0025] 3. Burst preemption scheduling algorithm: A scheduling strategy combining "burst" and "single packet round-robin" is proposed. It not only guarantees the low delay and certain burst throughput of high priority traffic, but also ensures the timeliness of preemption through mandatory checking after each transmission, and prevents any type of traffic from being completely starved by limiting the burst length and transmitting only one low priority packet each time, achieving an excellent balance between real-time performance and fairness.

[0026] 4. Soft implementation with high versatility: The present application is completely realized by software modifying the VxWorks kernel and driver, without relying on any specific hardware, and has good universality and portability, suitable for most VxWorks-based embedded network devices.

[0027] The present application is applicable to the field of industrial control, network devices and other embedded fields, and can significantly improve the reliable transmission of UDP messages in the mixed transmission of TCP and UDP messages in the VxWorks system. DETAILED DESCRIPTION

[0028] In order to make the purpose, content and advantages of the present application clearer, the specific embodiments of the present application are described in further detail below.

[0029] The present application provides a VxWorks network transmission optimization method based on dynamic priority mapping and burst scheduling, which realizes effective preemption of UDP over TCP at the network card driver level in the VxWorks system, ensures extremely low delay transmission of UDP messages, and maintains the availability and fairness of TCP connections.

[0030] Only by adopting the scheme of the present application can the technical problems existing in the mixed transmission of UDP / TCP messages in the current VxWorks system be effectively solved. The transmission method of mixed messages in the VxWorks system proposed by the present application tags the dynamic priority label at the last opportunity before the data leaves the protocol stack and enters the driver, and designs a fine "burst" scheduler to replace the simple FIFO queue, so that high priority data can almost interrupt the ongoing low priority data transmission flow without delay, effectively improving the real-time performance of UDP messages in a mixed traffic environment.

[0031] The VxWorks network transmission optimization method based on dynamic priority mapping and burst scheduling proposed by the present application comprises the following steps:

[0032] (1)Dynamic priority mapping. Intercept all outbound packets before the kernel network protocol stack finishes processing and the packet structure (mBlk / clBlk) is prepared to be sent to the network card driver, and assign a dynamic priority identifier to it according to its protocol type (UDP / TCP) and the real-time state of the VxWorks system;

[0033] The dynamic priority mapping specifically includes: by default, UDP packets are mapped to high priority, and TCP packets are mapped to low priority; at the same time, the system provides a selectable monitoring interface for monitoring network load, and when the system detects that the UDP traffic is long-term at a very low level, the priority of the TCP packet can be temporarily raised to avoid the idle waste of network bandwidth.

[0034] (2) Priority reconstruction of the sending queue. Modify the sending routine of the network card driver to reconstruct the original first-in-first-out (FIFO) sending queue into multiple virtual sub-queues based on the dynamic priority assigned in step one, wherein the high-priority queue is used to store real-time packets such as UDP;

[0035] (3) Burst preemption scheduling. In the driver sending interrupt service routine (ISR) or sending task, a burst scheduling algorithm is implemented: a number of data packets in the high-priority queue are continuously sent first to form a "burst"; only when it is detected that the high-priority queue is empty, the sending of data packets in the low-priority queue (such as TCP) is switched to, and after sending one low-priority data packet each time, the high-priority queue is checked again, thereby realizing the low-delay preemption of high-priority messages.

[0036] The steps of the method are specifically as follows:

[0037] S1: intercept the packet, parse and identify the protocol type, dynamically mark the priority of the packet by monitoring the network load in real time; specifically including:

[0038] S 11 : Intercept network protocol stack packets through hook function

[0039] (1) In the VxWorks kernel source code, the function for the network protocol stack to finally send the packet to the driver is the ipcom_drv_eth_output function, which, after completing the network layer processing, passes the network packet to the specific hardware driver through the xxxEndSend function (xxx represents the type of network card) called by the muxSend function;

[0040] (2) Before calling xxxEndSend function, create a new hook function, which is embedded at the end of the protocol stack processing flow. The hook function prototype is int priorityMark(struct mBlk *pMblk), all the data packets output from the network protocol stack will be processed by this hook function first; when the VxWorks kernel network protocol stack processing is completed, the data packet structure (mBlk / clBlk) is ready to be sent to the network card driver, that is, when any IP data packet (whether UDP or TCP) is built, the corresponding mBlk (message block) structure will be put into the sending queue of the network card driver, the hook function will be triggered;

[0041] (3) In the hook function, implement the protocol recognition and priority marking logic. The priority information can be stored in the pMblk->reserved field of the mBlk structure, which is a reserved or unused field.

[0042] S 12 : Analyze and identify the protocol type through the hook function

[0043] In the priorityMark function in step S 11 , the received parameter is the mBlk chain. mBlk is the standard structure in VxWorks to represent a data packet. The steps to analyze and identify the protocol type in the priorityMark function are as follows:

[0044] (1) Analyze the IP header. Extract the IP packet header from mBlk. This can be achieved by a fixed memory offset, because the beginning of the data buffer pointed to by the mBlk structure is the IP packet header;

[0045] (2) Identify the protocol type. Check the "protocol" field in the IP packet header. If the value of this "protocol" field is equal to 17, it indicates that this is a UDP data packet; if it is equal to 6, it indicates that this is a TCP data packet;

[0046] (3) Further analysis. If necessary, further analyze the UDP / TCP header to obtain the source / destination port number, so as to distinguish different data streams more finely.

[0047] S 13 : Dynamically mark data packet priority by real-time monitoring of network load

[0048] (1) By default, set the data packet priority. If it is identified as a UDP data packet from step S 12 , mark it as high priority; if it is identified as a TCP data packet from step S 12 , mark it as low priority. Marking method: in step S 11write the priority value (e.g. 1 for high, 0 for low) into the pMblk->reserved field;

[0049] (2) The rule of dynamically setting the priority of data packet. A simple counter and a timer are maintained in the VxWorks kernel. The counter is used to count the number of high priority (UDP) packets in a unit of time (e.g. the last 1 second), and the timer triggers a check every certain period (e.g. 1 second). If the check finds that the UDP packet counter is zero (or lower than a small threshold) for several consecutive periods (e.g. 3 periods), the system determines that the network is in an "idle" state.

[0050] When the system detects that the UDP network is in an "idle" state, the "bandwidth utilization mode" is enabled. In this mode, all TCP data packets output by the protocol stack are not marked as low priority, but as medium priority. As soon as a new UDP data packet arrives, the system immediately exits the "bandwidth utilization mode" and restores the default marking rule, while resetting the counter and starting the timer again.

[0051] After the priority marking, the priorityMark function passes the mBlk chain to the send queue management module.

[0052] S2: Modify the network card driver send routine, and restructure the original first-in-first-out (FIFO) send queue into multiple virtual sub-queues based on the dynamic priority assigned in step S1.

[0053] (1) Restructure the driver send queue and modify the data structure of the target network card driver. In the private control structure body (usually called END_OBJ or similar name) of the driver, instead of using a single send queue, two queue heads are defined: struct mBlk*highPrioQueue and struct mBlk*lowPrioQueue. These queues are logical queues implemented as linked lists in memory.

[0054] (2) Implement the data packet enqueue operation. Modify the data packet send function (usually xxSend or xxPacketSend) of the driver, which originally directly hangs the mBlk to be sent on the hardware-related send queue. The modification steps are as follows:

[0055] First, check the mBlk->reserved field passed in from step S1 to read the priority marked in step S1;

[0056] Then, according to the read priority value, this mBlk is hung to the tail of the corresponding highPrioQueue or lowPrioQueue by the queue operation function (such as lstAdd) of the VxWorks kernel.

[0057] According to the above steps, the data packets have been successfully separated into different logical queues according to the protocol type.

[0058] S3: In the driver sending interrupt service routine (ISR) or sending task, implement the scheduling strategy combining "burst" and "single packet round-robin";

[0059] S 31 : Round-robin scheduling

[0060] Round-robin scheduling is implemented by a burst scheduler module, which works in an infinite loop and executes the loop logic once every time it is triggered (such as the network card sending a "send complete" interrupt).

[0061] S 32 : Burst scheduling algorithm implementation

[0062] (1) Check the high priority queue. The burst scheduler module first checks whether the highPrioQueue is empty;

[0063] (2) Burst sending. If the highPrioQueue is not empty, the burst scheduler module enters "burst sending mode". It takes a data packet from the head of the highPrioQueue, and then calls the underlying hardware sending function (such as xxStartTx) to send this data packet directly to the network card hardware. A counter named burstCounter is incremented by 1 every time a data packet is sent.

[0064] The burst scheduler module continues to perform the burst sending process of step (2) above until one of the following two conditions occurs:

[0065] Case 1: The burstCounter reaches the preset micro-burst length (N). For example, N = 3, which means that 3 high-priority packets have been sent in succession;

[0066] Case 2: The highPrioQueue is emptied.

[0067] As long as any of the above conditions is met, this "burst" ends and the burstCounter is reset to zero.

[0068] (3) The second high priority check. After finishing one "burst", the burst scheduler module does not immediately process the low priority queue, but jumps back to the "check high priority queue" step of step (1) to check again whether the highPrioQueue has new data packets;

[0069] (4) The low priority service. Only when the burst scheduler module finds that the highPrioQueue is empty in the "check high priority queue" step, it will go down to check the lowPrioQueue;

[0070] (5) Single packet sending and immediate preemption. If the lowPrioQueue is not empty, the burst scheduler module only takes one data packet from it and sends it to the network card. After sending this one data packet, the burst scheduler module does not continue to send the next low priority packet, but immediately jumps back to the "check high priority queue" step to check the high priority queue again.

[0071] The above burst scheduling algorithm implements the "immediate preemption" mechanism: the maximum waiting time of any newly arrived high priority UDP packet is only the time required to send a maximum size low priority TCP packet, which is a very short and deterministic time window (about 120 μs).

[0072] S 33 : Parameter configuration

[0073] Burst length N: This is an adjustable kernel parameter, which represents the upper limit of the number of high priority data packets sent continuously, used to prevent a single UDP data stream from completely starving the TCP stream while ensuring UDP low latency, to ensure the fairness and throughput of the whole network. It can be defined in the VxWorks system configuration file config.h through #define, and adjusted according to the characteristics of the UDP stream in the actual application. The larger the value of N, the stronger the UDP burst throughput, but the delay of TCP may also increase. N = 1 to 5 is a typical value range.

[0074] It can be seen that the present application provides a method for reducing the influence of TCP message transmission on UDP message transmission for VxWorks real-time operating system. The core of the method is to abandon the traditional idea of scheduling at the high layer of protocol stack or network device queue, and instead implement dynamic scheduling at the last link when the data packet is processed by the protocol stack and is about to enter the network card driver sending queue. The method labels the data packet with dynamic priority based on the protocol and system state, and designs a sending scheduling algorithm based on high priority burst preemption, so that the high priority UDP message can be sent with extremely low delay "cutting in line", thereby effectively isolating the interference of TCP large and continuous data transmission on UDP real-time message. The present application does not require special hardware support, and realizes kernel-level lightweight scheduling, which is particularly suitable for embedded systems such as VxWorks which have extremely high real-time requirements.

[0075] The above is only the preferred embodiment of the present application, and it should be pointed out that for those skilled in the art, without departing from the technical principles of the present application, a number of improvements and modifications can be made, and these improvements and modifications should be considered as the protection scope of the present application.

Claims

1. A VxWorks network transmission optimization method based on dynamic priority mapping and burst scheduling, characterized in that, The method comprises the following steps: S1: intercepting a data packet, parsing and identifying a protocol type, dynamically marking a data packet priority by monitoring a network load in real time; S2: modifying a network card drive sending routine, and reconstructing a first-in first-out (FIFO) sending queue into a plurality of virtual sub-queues based on the priority assigned in step S1; S3: scheduling the data packet by a burst scheduling algorithm combining "burst sending" and "single packet rotation" in a drive sending interrupt service routine (ISR) or a sending task.

2. The method of claim 1, wherein, Step S1 specifically comprises: S 11 : Intercepting network stack packets through hooking functions In the VxWorks kernel source code, a function for finally delivering a data packet to a drive by a network protocol stack is an ipcom_drv_eth_output function, which delivers the data packet to a specific hardware drive by calling an xxxEndSend function through a muxSend function after completing network layer processing, and xxx represents a network card type; Before calling the xxxEndSend function, a hook function is created and embedded at the end of a protocol stack processing flow; the hook function prototype is int priorityMark(struct mBlk *pMblk), and all data packets output from the network protocol stack will first pass through the hook function processing; when the VxWorks kernel network protocol stack processing is completed and a data packet structure is prepared to be delivered to the network card drive, that is, when any IP data packet is completed and a corresponding mBlk structure is about to be put into a sending queue of the network card drive, the hook function is triggered; (3) protocol identification and priority marking logic is implemented in the hook function; priority information can be stored in a reserved or unused pMblk->reserved field of the mBlk structure; S 12 : Resolving and identifying protocol types through hook functions The steps of parsing and identifying a protocol type in the priorityMark function are as follows: (1) parsing an IP header: the IP header is extracted from the mBlk by a fixed memory offset; (2) identifying a protocol type: the "protocol" field in the IP header is viewed, if the value of the "protocol" field is equal to 17, it indicates that it is a UDP data packet; if it is equal to 6, it indicates that it is a TCP data packet; S 13 : dynamically marking packet priorities by monitoring network load in real time (1) By default, set the data packet priority: if it is identified as a UDP data packet from step S 12 , mark it as high priority; if it is identified as a TCP data packet from step S 12 , mark it as low priority; marking method: write the priority value in the pMblk->reserved field in step S 11 ; (2) dynamically setting a data packet priority rule: a simple counter and a timer are maintained in the VxWorks kernel; the counter is used to count the number of high-priority packets passed in a unit of time, and the timer triggers a check once every period; if it is found that the counter count value is zero in a plurality of continuous periods, it is determined that the current network is in an "idle" state; when the UDP network is in the "idle" state, a "bandwidth utilization mode" is enabled, in which all TCP data packets output by the protocol stack are not marked as low priority, but are marked as medium priority; as soon as a new UDP data packet arrives, the "bandwidth utilization mode" is exited, the default marking rule is restored, and the counter is cleared and timing is restarted.

3. The method of claim 2, wherein, Inside the priorityMark function in step S 11 The received parameter is the mBlk chain; mBlk is a standard structure in VxWorks to represent a data packet.

4. The method of claim 2, wherein, The beginning of a data buffer pointed to by the mBlk structure is the IP header.

5. The method of claim 2, wherein, Step S 12 After (2), further analysis is performed: further parsing of the UDP / TCP header, obtaining the source / destination port number, so as to distinguish different data streams.

6. The method of claim 2, wherein, Step S2 specifically comprises: (1) Reconstruct the driver send queue, modify the data structure of the network card driver: in the private control structure of the driver, define two queues: struct mBlk*highPrioQueue and struct mBlk*lowPrioQueue; these queues are logical queues, implemented by a linked list in memory; (2) Implement the data packet enqueue operation: modify the data packet sending function of the driver, and the modification steps are as follows: First, read the priority marked in step S1; then, according to the read priority, use the queue operation function of the VxWorks kernel to hang mBlk to the tail of the corresponding highPrioQueue or lowPrioQueue; At this point, the data packet has been successfully separated into different logical queues according to the protocol type.

7. The method of claim 2, wherein, In step S3, the burst scheduler implements the loop scheduling, and the burst scheduler works in an infinite loop, and executes the loop logic once every time it is triggered.

8. The method of claim 7, wherein, The burst scheduler executes the burst scheduling algorithm according to the following process: (1) Check the high priority queue: the burst scheduler first checks whether the highPrioQueue is empty; (2) Burst sending: if the highPrioQueue is not empty, the burst scheduler enters the "burst sending mode", it takes a data packet from the head of the highPrioQueue, and then calls the underlying hardware sending function to send the data packet directly to the network card hardware; a counter named burstCounter is incremented by 1 every time a data packet is sent; The burst scheduler continues to execute the burst sending process of step (2) until one of the following two conditions occurs: Case 1: the burstCounter reaches the preset burst length N, the burst length N represents the upper limit of the number of high priority data packets sent continuously; Case 2: the highPrioQueue is emptied; As long as any of the above conditions is met, the burstCounter is reset to zero; (3) Next high priority check: after completing a "burst sending", the burst scheduler jumps back to the "check high priority queue" step to check whether the highPrioQueue has new data packets again; (4) Low priority service: when the burst scheduler finds that the highPrioQueue is empty in the "check high priority queue" step, it checks the lowPrioQueue; (5) Single packet sending and immediate preemption: if the lowPrioQueue is not empty, the burst scheduler only takes one data packet from it and sends it to the network card; after sending this one data packet, the burst scheduler jumps back to the "check high priority queue" step to recheck the high priority queue.

9. The method of claim 8, wherein, The burst length N is an adjustable kernel parameter, defined by #define in the VxWorks system configuration file config.h.

10. An embedded real-time operating system network communication method based on the method of any one of claims 1 to 9.