Method, device and equipment for solving network-on-chip congestion
By statistically analyzing and predicting traffic in the on-chip network, dynamically generating tokens, and configuring steady-state and burst traffic token buckets, the problem of congestion control schemes in existing technologies being unable to dynamically adjust priorities is solved, thereby improving the network throughput and congestion resistance under high-load traffic scenarios.
Patent Information
- Application Number
- CN202511587179.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-31
- Publication Date
- 2026-02-17
AI Technical Summary
Existing on-chip network congestion control schemes cannot dynamically adjust priorities, resulting in low efficiency under high traffic conditions and an inability to adapt to dynamic changes in traffic, leading to a precipitous drop in performance.
By statistically analyzing the actual transmission traffic within each sampling window and combining it with historical traffic data to predict the transmission traffic of the next sampling window, a corresponding number of tokens are generated and added to the steady-state traffic token bucket. Token generation is dynamically adjusted to adapt to traffic changes. Independent steady-state and shared burst traffic token buckets are configured to achieve dynamic traffic control.
Dynamically reducing or increasing token generation in on-chip networks improves throughput and congestion resistance in high-load traffic scenarios, ensuring that the network saves resources under low load and effectively regulates traffic under high load to avoid congestion spread.
Smart Images
Figure CN121547404A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data transmission technology, and in particular to methods, apparatus and devices for resolving on-chip network congestion. Background Technology
[0002] With the widespread adoption of multi-core processors and heterogeneous computing chips, Network-on-Chip (NoC) is gradually replacing traditional bus architectures and becoming the mainstream solution for core interconnection within chips. NoC supports high-parallel data transmission through a combination of routing nodes, links, and switches, significantly improving system bandwidth and scalability.
[0003] Due to NoC's fixed routing algorithm and limited bandwidth, congestion often occurs on local links and may spread to the global network through the routing path, resulting in a precipitous drop in performance.
[0004] Congestion control schemes in related technologies, such as round-robin arbitration, static priority allocation, and fixed-bandwidth token bucket mechanisms, can alleviate congestion to some extent, but they have some limitations. For example, round-robin arbitration cannot dynamically adjust priorities, resulting in inefficiency under high traffic conditions; static priority allocation cannot adapt to dynamic changes in traffic. Summary of the Invention
[0005] This application provides methods, apparatus, and devices for resolving on-chip network congestion, thereby addressing at least the technical problems of congestion control schemes in the related art, such as the inability to dynamically adjust priorities, low efficiency under high traffic conditions, and inability to adapt to dynamic changes in traffic.
[0006] This application provides a method for resolving on-chip network congestion, including: The actual transmission traffic used for transmitting data packets in the target transmission direction within each sampling window is statistically analyzed and recorded. The target transmission direction is any one of the transmission directions to which the data packet to be transmitted is sent. Based on the actual transmission traffic within the current sampling window and the historical transmission traffic counted by the historical sampling windows within the current statistical window to which the current sampling window belongs, the transmission traffic consumed within the current statistical window is determined. The current statistical window includes multiple historical sampling windows adjacent to the current sampling window as well as the current sampling window. Based on the transmission traffic consumed in the current statistical window and the transmission traffic consumed in the previous statistical window, the transmission traffic consumed in the next sampling window of the current sampling window is predicted, and the predicted transmission traffic consumption of the next sampling window is obtained. Generate tokens based on the predicted transmission traffic consumption. The token is added to the target steady-state traffic token bucket corresponding to the target transmission direction, so that the token in the target steady-state traffic token bucket can be used to transmit the data packet to be transmitted in the target transmission direction within the time period corresponding to the next sampling window.
[0007] This application also provides an apparatus for resolving on-chip network congestion, comprising: The statistics module is used to count the actual transmission traffic of data packets in the target transmission direction within each sampling window; The recording module is used to record the actual transmission flow of data packets in the target transmission direction within each sampling window. The target transmission direction is any one of the transmission directions to which the data packet to be transmitted is sent. The determination module is used to determine the transmission traffic consumed in the current statistical window based on the actual transmission traffic in the current sampling window and the historical transmission traffic counted by the historical sampling windows in the current statistical window to which the current sampling window belongs. The current statistical window includes multiple historical sampling windows adjacent to the current sampling window and the current sampling window. The acquisition module is used to predict the transmission traffic consumed in the next sampling window based on the transmission traffic consumed in the current statistical window and the transmission traffic consumed in the previous statistical window, and to obtain the predicted transmission traffic consumed in the next sampling window. The generation module is used to generate tokens based on the predicted transmission traffic consumption. The addition module is used to add tokens to the target steady-state traffic token bucket corresponding to the target transmission direction, so that the tokens in the target steady-state traffic token bucket can be used to transmit the data packets to be transmitted in the target transmission direction within the time period corresponding to the next sampling window.
[0008] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described methods for resolving on-chip network congestion.
[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described methods for resolving on-chip network congestion.
[0010] This application utilizes the fact that each individual sampling window is the basic unit of traffic statistics. Therefore, it statistically records the actual transmission traffic used to transmit data packets in the target transmission direction within each sampling window. Furthermore, by statistically analyzing each individual sampling window during the statistical process, it is beneficial to determine the transmission traffic consumed within the current statistical window based on the actual transmission traffic within the current sampling window and the historical transmission traffic statistically analyzed from the historical sampling windows within the current statistical window to which the current sampling window belongs. The reason for determining the transmission traffic consumed within the current statistical window is to predict the transmission traffic of the next sampling window using the transmission traffic consumed within the current statistical window and the transmission traffic consumed within the previous statistical window, thereby determining the predicted transmission traffic consumption and generating a corresponding number of tokens. The token is then added to the target steady-state traffic token bucket corresponding to the target transmission direction. This token is used to transmit the data packet to be transmitted in the target transmission direction within the time period corresponding to the next sampling window. Therefore, based on the prediction of the transmission traffic consumed in the next sampling window, a corresponding number of tokens are generated as the transmission traffic changes dynamically. This achieves dynamic reduction of token generation when the on-chip network is under low load, thereby saving the resource consumption of token generation. When the on-chip network is under high load, the generation of tokens is dynamically increased, thereby improving the throughput and congestion resistance of the on-chip network in high-load traffic scenarios. Attached Figure Description
[0011] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0012] Figure 1 A schematic diagram of an on-chip network topology provided in an embodiment of this application; Figure 2 A flowchart illustrating a method for resolving on-chip network congestion provided in an embodiment of this application; Figure 3 This is a schematic diagram of a sliding window provided in an embodiment of this application; Figure 4 A flowchart illustrating another method for resolving on-chip network congestion provided in an embodiment of this application; Figure 5 A schematic diagram illustrating a process for determining predicted transmission traffic volume, provided as an embodiment of this application; Figure 6 A schematic diagram illustrating another process for determining the predicted transmission traffic volume provided in an embodiment of this application; Figure 7 A flowchart illustrating a congestion solution provided in an embodiment of this application; Figure 8 A flowchart illustrating a flow regulation scheme provided in an embodiment of this application; Figure 9 A block diagram of an apparatus for resolving on-chip network congestion provided for embodiments of this application; Figure 10 A block diagram of an electronic device provided for an embodiment of this application. Detailed Implementation
[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.
[0014] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.
[0015] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0016] With the widespread adoption of multi-core processors and heterogeneous computing chips, NoC (No-Chip) architecture is gradually replacing traditional bus architectures and becoming the mainstream solution for core interconnection within chips. NoC supports high-parallel data transmission through a combination of routing nodes, links, and switches, significantly improving system bandwidth and scalability.
[0017] Due to NoC's fixed routing algorithm and limited bandwidth, congestion often occurs on local links and may spread to the global network through the routing path, resulting in a precipitous drop in performance.
[0018] For example in Figure 1In the illustrated on-chip network topology, the upper boxes represent target terminal nodes, the lower boxes represent source terminal nodes, and the middle circles represent routing nodes. When source terminal nodes 20 and 24 frequently send data to target terminal node 11, the target terminal node's receiving bandwidth limitation will consume a significant amount of internal buffer resources within the routing nodes. When the buffer is exhausted, it will further pressure the preceding routing nodes, ultimately reducing the actual available bandwidth of all source terminal nodes in the entire interconnection network to no more than the receiving bandwidth of target terminal node 11. Therefore, congestion control logic needs to be introduced into the on-chip network.
[0019] Congestion control schemes in related technologies, such as round-robin arbitration, static priority allocation, and fixed-bandwidth token bucket mechanisms, can alleviate congestion to some extent, but they have some limitations. For example, round-robin arbitration cannot dynamically adjust priorities, resulting in inefficiency under high traffic conditions; static priority allocation cannot adapt to dynamic changes in traffic.
[0020] To address the aforementioned problems, embodiments of this application provide a method for resolving on-chip network congestion, as detailed below. Figure 2 As shown, the method includes the following steps: Step S201: Calculate and record the actual transmission traffic used to transmit data packets in the target transmission direction within each sampling window.
[0021] The target transmission direction is any one of the transmission directions to which the data packet to be transmitted is sent.
[0022] Specifically, the sampling window is the basic time unit for traffic statistics. It counts and records the actual transmission traffic from the source terminal node to any intermediate routing node within each basic time unit, such as... Figure 1 As shown, taking the transmission of data packets from source terminal node 21 to target terminal node 11 as an example, since source terminal node 21 needs to transmit data packets to target terminal node 11, the transmission direction at this time is: source terminal node 21 — routing node C0 — routing node B0 — routing node A0 — target terminal node 11.
[0023] In this scenario, the source terminal node 21 can transmit data packets to the target terminal node 11 through different routing nodes. Therefore, the transmission direction of data packets from the source terminal node 21 to the target terminal node is not limited to one. As another example, the source terminal node 21 can transmit data packets to the target terminal node 11 through the following transmission direction: source terminal node 21 — routing node C0 — routing node B1 — routing node A0 — target terminal node 11.
[0024] Figure 3 As shown, Figure 3This is a schematic diagram of a sliding window. Statistical window 0 consists of n sampling windows, and the time of a single sampling window is t. Therefore, by statistically analyzing the actual transmission traffic of data packets in the target transmission direction within each sampling window, we can calculate the actual transmission traffic per unit time. Statistically analyzing the actual transmission traffic within each sampling window provides the statistical conditions for subsequently determining the historical transmission traffic within multiple historical sampling windows.
[0025] Step S202: Determine the transmission traffic consumed in the current statistical window based on the actual transmission traffic in the current sampling window and the historical transmission traffic counted by the historical sampling windows in the current statistical window to which the current sampling window belongs.
[0026] The current statistical window includes multiple historical sampling windows adjacent to the current sampling window as well as the current sampling window.
[0027] Specifically, such as Figure 3 As shown, the statistical window includes the current sampling window and multiple historical sampling windows. Taking statistical window 1 as an example, in statistical window 1, the current sampling window is t(n), and the historical sampling windows are any one of sampling windows t(1) to t(n-1), and from... Figure 3 As can be seen, the historical sampling windows are arranged sequentially. Therefore, by statistically analyzing the transmission traffic in the current sampling window and multiple historical sampling windows within the statistical window, the actual transmission traffic within the current sampling window and the historical transmission traffic within multiple historical sampling windows can be determined. Then, by summing the actual transmission traffic and the multiple historical transmission traffic, the transmission traffic consumed within the current statistical window can be determined.
[0028] Step S203: Based on the transmission traffic consumed in the current statistical window and the transmission traffic consumed in the previous statistical window, predict the transmission traffic consumed in the next sampling window of the current sampling window, and obtain the predicted transmission traffic consumed in the next sampling window.
[0029] Specifically, such as Figure 3 As shown, statistical window 0 consists of sampling window t(0) to sampling window (n-1), and sampling window 1 consists of sampling window t(1) to sampling window t(n). The transmission traffic of statistical window 0 and the transmission traffic consumed by statistical window 1 are averaged respectively, that is, the transmission traffic corresponding to the statistical window is divided by the number of sampling windows to determine the average transmission traffic of a single sampling window.
[0030] Combination Figure 3In a specific example, to predict the transmission traffic consumption of sampling window t(n+1), based on the above method, the average transmission traffic P(n-1) of a single sampling window of statistical window 0 is determined, and the average transmission traffic P(n) of a single sampling window of statistical window 1 is determined. Then, the predicted transmission traffic consumption P(n+1) of sampling window t(n+1) is determined using the predicted transmission traffic consumption formula, as shown in the following formula:
[0031] In the above formula, by determining the average transmission traffic of a single sampling window of the statistical window based on the transmission traffic consumed by the current statistical window (statistical window 1 in the example above) and the previous statistical window (statistical window 0 in the example above), the difference between the average transmission traffic consumed by the current statistical window and the previous statistical window can be determined. It is known that data transmission occurs over time. Since the closer two things are in time, the higher the likelihood of correlation, influence, or similarity between them, to ensure the strongest correlation between the predicted data and the sampling window to be predicted, thereby improving prediction accuracy, the actual transmission traffic of the next sampling window is determined by summing the difference between the average transmission traffic of a single sampling window of the current statistical window and the average transmission traffic consumed by a single sampling window of the previous statistical window.
[0032] Step S204: Generate a token based on the predicted transmission traffic consumption.
[0033] Specifically, tokens are generated at the end of each sampling window, and the number of tokens generated corresponds to the predicted transmission traffic consumption. Therefore, the number of tokens generated is dynamically adjusted based on the predicted transmission traffic consumption, allowing the token count to change relatively evenly. This not only saves token resources but also ensures more accurate and stable traffic control in the event of a large influx of sudden traffic into the transmission path, since the number of tokens generated is determined based on the predicted transmission traffic consumption.
[0034] Step S205: Add the token to the target steady-state flow token bucket corresponding to the target transmission direction, so as to use the token in the target steady-state flow token bucket to transmit the data packet to be transmitted in the target transmission direction within the time period corresponding to the next sampling window.
[0035] Specifically, an independent steady-state traffic token bucket is configured for each output direction, and the target direction is any direction of each output direction. The target steady-state traffic token bucket is the steady-state traffic token bucket in the target direction. Since data packets need to be transmitted in the target transmission direction, a number of tokens corresponding to the data transmission size of the data packet needs to be consumed. Therefore, at the beginning of the time period corresponding to the next sampling window, the number of tokens in the target steady-state token bucket needs to be replenished to make up for the token consumption in the time period corresponding to the previous sampling window.
[0036] In the above method, since each individual sampling window is the basic unit of traffic statistics, the actual transmission traffic used to transmit data packets in the target transmission direction within each sampling window is counted and recorded. Furthermore, counting each individual sampling window during the statistical process helps determine the transmission traffic consumed within the current statistical window based on the actual transmission traffic within the current sampling window and the historical transmission traffic counted from the historical sampling windows within the current statistical window to which the current sampling window belongs. The reason for determining the transmission traffic consumed within the current statistical window is to predict the transmission traffic of the next sampling window by using the transmission traffic consumed in the current statistical window and the transmission traffic consumed in the previous statistical window, thus determining the predicted transmission traffic consumption and generating the corresponding number of tokens. The token is then added to the target steady-state traffic token bucket corresponding to the target transmission direction. This token is used to transmit the data packet to be transmitted in the target transmission direction within the time period corresponding to the next sampling window. Therefore, based on the prediction of the transmission traffic consumed in the next sampling window, a corresponding number of tokens are generated as the transmission traffic changes dynamically. This achieves dynamic reduction of token generation when the on-chip network is under low load, thereby saving the resource consumption of token generation. When the on-chip network is under high load, the generation of tokens is dynamically increased, thereby improving the throughput and congestion resistance of the on-chip network in high-load traffic scenarios.
[0037] In an optional example, a corresponding number of tokens needs to be consumed during the transmission of data packets, based on the size of the data packets. This is necessary because data packet sizes vary; consuming a corresponding number of tokens for each data packet size during transmission not only saves token resources but also reduces the burden of token generation. Therefore, based on the foregoing embodiments, the method may further include the following steps, as detailed in the following examples. Figure 4 As shown, it includes: Step S401: When a target data packet to be transmitted to the target transmission direction is received at any time, the number of target tokens to be consumed for transmitting the target data packet is determined according to the size of the target data packet.
[0038] Step S402: Based on the target transmission direction, read the tokens corresponding to the target token quantity from the target steady-state traffic token bucket.
[0039] Step S403: Use the token to transmit the target data packet to the target transmission direction.
[0040] In a specific example, the data transmission size corresponding to one token is 512 bits. Assuming the current transmitted data packet size is 1024 bits, twice the size of 512 bits, then this current transmitted data packet requires two tokens for transmission, meaning the target token count is 2. If the current transmitted data packet size is not a multiple of 512 bits, such as 1034 bits, the 1024 bits will be transmitted using two tokens, and the remaining 10 bits will be transmitted using one token. Therefore, a 1034-bit data packet will be transmitted using three tokens. Based on the target transmission direction of the data packet, the corresponding number of tokens for the size of the currently transmitted data packet (two tokens) is read from the target steady-state traffic token bucket for that target transmission direction. Afterward, two tokens are consumed from the target steady-state traffic token bucket for that target transmission direction, and the currently transmitted data packet is transmitted to the target transmission direction.
[0041] In the above method, since different data packets have different sizes, the number of tokens corresponding to the size of the data packet is consumed during the transmission of the data packet. This not only saves token resources, but also reduces the burden of token generation.
[0042] In an optional example, the target steady-state traffic token bucket generates a corresponding number of tokens based on the predicted amount of transmission traffic consumed. However, during actual data packet transmission, there may be situations where the actual data packet transmission volume exceeds the predicted transmission traffic consumption. Therefore, when the tokens in the target steady-state traffic token bucket are exhausted, tokens in the burst traffic token bucket are consumed to ensure the stability of the data packet transmission process. This also avoids the backpressure problem that can easily occur when the tokens in the steady-state traffic token bucket are depleted. Specifically, this includes the following steps: Step S501: When the number of tokens in the target steady-state flow token bucket is less than the target number of tokens, determine the token quantity difference.
[0043] Step S502: Borrow a number of tokens from the pre-configured burst traffic token pool, corresponding to the difference in the number of tokens, to transmit the target data packet.
[0044] Specifically, when the number of tokens in the target steady-state token bucket is insufficient to supply the transmission of the current data packet, the difference is determined based on the remaining number of tokens in the target steady-state token bucket and the number of tokens required to be consumed corresponding to the size of the current data packet. Then, based on the determined difference, the corresponding number of tokens is consumed from the burst traffic token bucket to transmit the data packet.
[0045] In a specific example, the target steady-state token bucket has only 2 tokens remaining, but the current data packet size requires 8 tokens. Clearly, the remaining tokens in the target steady-state token bucket are insufficient to support the transmission of the current data packet. Therefore, 6 more tokens need to be consumed from the burst traffic token bucket to support the transmission of the current data packet. The burst traffic token bucket is shared across all output directions and employs a "borrow-return" mechanism. Burst traffic (in the above example, burst traffic refers to data packets whose tokens in the target steady-state token bucket cannot fully support the current data packet transmission) must first exhaust the steady-state traffic tokens before consuming tokens from the burst traffic token bucket. This combined token consumption method ensures the stability of the data packet transmission process, avoids backpressure problems that can easily occur when the steady-state traffic token bucket is exhausted, and improves the on-chip network's dynamic response capability to large volumes of traffic.
[0046] In an optional example, after a data packet consumes tokens from the steady-state traffic token bucket, it still needs to consume tokens corresponding to the difference in the burst traffic token bucket. If the burst traffic token bucket does not limit token consumption, the transmission of a single data packet may exhaust all tokens at once, leading to packet backlog, backpressure, or even packet loss in subsequent data packet transmissions, thus compromising the stability of burst transmission. Therefore, limiting the token consumption of a single data packet in the burst traffic token bucket ensures the overall efficient operation of the network. When the token difference exceeds a preset threshold, it also includes: Step a1: Send the first prompt message to the target data packet initiator.
[0047] The first prompt message is used to indicate that data packets should not be transmitted to the target direction until it is determined that the borrowed tokens have been replenished and there are remaining tokens in the target steady-state flow token bucket, at which point step a2 is performed.
[0048] In a specific example, such as Figure 1 As shown, taking the transmission of data packets from source terminal node 21 to target terminal node 11 as an example, since source terminal node 21 needs to transmit data packets to target terminal node 11, the transmission direction at this time is: source terminal node 21 — routing node C0 — routing node B0 — routing node A0 — target terminal node 11.
[0049] In this transmission direction, the originator of the target data packet is either the source terminal node 21 or the routing node C0. If the difference in the number of tokens in this transmission direction reaches a preset threshold, the source terminal node 21 or the routing node C0 is restricted from sending data to this output direction into the current routing node. For example, if the preset threshold is 10, and the difference in the number of tokens is 12, a first prompt message is sent to the originator of the target data packet to prohibit the continued transmission of data packets in the target transmission direction.
[0050] In one conceivable scenario, assuming a prolonged and large volume of burst traffic, when the burst exhausts the token bucket, a first warning message is sent to the originator of the target data packet, preventing it from continuing to transmit data packets in the target direction. Alternatively, newly arrived data packets might trigger a rate-limiting mechanism. For example, in loss-tolerant scenarios, such as distributed deep learning training, packets could be dropped directly to quickly control traffic. Or, in loss-sensitive but latency-acceptable scenarios, such as sophisticated numerical simulations, newly arrived packets could be temporarily queued to await new token generation. Another approach is to mark data packets with low priority, prioritizing unmarked data to balance resource utilization while limiting traffic and preventing excessive data packet flow from overwhelming the on-chip network.
[0051] Step a2: Send a second prompt message to the originating end of the target data packet. The second prompt message is used to indicate that data packets can be transmitted in the target transmission direction.
[0052] Specifically, at the start of the next sampling window, a corresponding number of tokens are generated based on the predicted transmission traffic. These generated tokens are first used to replenish the token capacity of the burst traffic token bucket. Only after replenishing the burst traffic token bucket will the remaining tokens be added to the corresponding target steady-state traffic token bucket. Therefore, when the burst traffic token bucket reaches its upper limit, the remaining tokens will be added to the target steady-state traffic token bucket. At this point, the target steady-state traffic token bucket will contain at least one token. Thus, sending a second cue message to the target data packet initiator allows the data packet to begin transmission in the target direction.
[0053] In the above method, limiting the upper limit of the token quantity difference ensures that the number of tokens required for a single data packet transmission will not consume too much of the overall capacity of the token bucket during burst traffic. By limiting the large amount of tokens occupied by a single data packet through a preset quantity threshold, the token bucket resources are prevented from being exhausted during burst traffic, further enhancing the throughput and congestion resistance of the on-chip network in high-load traffic scenarios.
[0054] In an optional example, considering the different influences of the transmission traffic of historical sampling windows and the transmission traffic of the current sampling window on the predicted transmission traffic consumption of the next sampling window, the weight of sampling windows closer to the current time is increased during the statistical process, while the weight of sampling windows farther from the current time is decreased. The weighted average result is then used as the transmission traffic of the current statistical window, thereby improving the accuracy of the prediction. Based on the actual transmission traffic within the current sampling window and the historical transmission traffic statistically analyzed from the historical sampling windows within the current statistical window to which the current sampling window belongs, the transmission traffic consumed within the current statistical window is determined, specifically including: Step b1: Determine the total historical transmission traffic based on the historical transmission traffic counted separately from the multiple historical sampling windows included in the current statistical window.
[0055] Step b2 involves performing a weighted operation on the actual transmission traffic and the sum of historical transmission traffic within the current sampling window, followed by a summation operation to obtain the transmission traffic consumed within the current statistical window.
[0056] Specifically, such as Figure 3 As shown, assuming the current time is the sampling window t(n), then in statistical window 1, the historical sampling window is from t(1) to t(n-1). For detailed descriptions, please refer to the steps above; they will not be repeated here. Figure 5 The process of determining the predicted transmission traffic consumption shown can be achieved by increasing the weight of sampling window t(n) and decreasing the weight of t(1) to t(n-1) in statistical window 1. After the weighting operation, the actual transmission traffic in the current sampling window and the historical transmission traffic are summed to obtain the transmission traffic consumed in the current statistical window.
[0057] In the above method, when predicting the transmission traffic of the next sampling window, since the influence of the transmission traffic of historical sampling windows and the current sampling window on the prediction result differs, the sampling window closer to the current time is given a higher weight during the statistical process, while the weight of sampling windows far from the current time is reduced. Then, the transmission traffic of all sampling windows is calculated by weighted average, and the result is used as the transmission traffic of the current statistical window. In the end, this method improves the accuracy of the transmission traffic prediction for the next sampling window. Furthermore, based on this transmission traffic and the formula for predicting the transmission traffic consumption, conditions can be provided for determining the predicted transmission traffic consumption.
[0058] In an optional example, since there are overlapping sampling windows between adjacent statistical windows, setting the number of overlapping sampling windows allows the statistical process to better adapt to different network traffic characteristics. Therefore, a preset number of overlapping sampling windows exists between adjacent statistical windows.
[0059] Specifically, the proportion of overlapping sampling windows in the total statistical window is called the sliding window overlap ratio. Since the preset number of overlapping sampling windows between two adjacent statistical windows can be set, the sliding window overlap ratio can also be changed accordingly based on the change in the preset number of overlapping sampling windows. When the preset number of overlapping sampling windows is large, i.e., when the sliding window overlap ratio is large, the two adjacent statistical windows will share more historical traffic data, which can effectively smooth traffic fluctuations between adjacent windows and avoid sudden changes in statistical results due to single sampling deviations. When the preset number of overlapping sampling windows is small, i.e., when the sliding window overlap ratio is small, the proportion of independent data between the two adjacent statistical windows is higher, which can capture the latest trend of network traffic changes more quickly and reduce the interference of old data on the current statistical results.
[0060] In the above method, by flexibly adjusting the preset number of overlapping sampling windows, the statistical process can be better adapted to different network traffic characteristics, further avoiding adverse effects on Internet performance.
[0061] In an optional example, since there is usually an error between the predicted traffic consumption and the actual traffic, a correction coefficient is introduced to reduce the error in subsequent predictions and make the predicted traffic consumption data for the next sampling window more accurate. Based on this, the method predicts the traffic consumption for the next sampling window based on the traffic consumption in the current statistical window and the traffic consumption in the previous statistical window. After obtaining the predicted traffic consumption for the next sampling window, the method further includes: Step c1: Obtain the actual transmission traffic consumed by the next sampling window.
[0062] Step c2: Determine the correction coefficient based on the predicted and actual transmission traffic of the next sampling window.
[0063] Step c3: Based on the correction coefficient, the predicted transmission traffic consumption for the next sampling window is predicted and corrected.
[0064] This is used to generate tokens for the time period corresponding to the next sampling window based on the corrected predicted consumption of transmission traffic.
[0065] Specifically, such as Figure 6 Another process for determining the predicted transmission traffic consumption is shown, in such a way... Figure 5As shown, after the weighting operation, the predicted transmission traffic consumption for the next sampling window is compared with the actual transmission traffic for the next sampling window. By determining the error between the predicted and actual transmission traffic consumption for the next sampling window, a correction coefficient is determined. Then, by multiplying this correction coefficient by the predicted transmission traffic consumption for the next sampling window, the predicted transmission traffic consumption for the next sampling window can be predicted. Through this process of determining the predicted transmission traffic consumption, the predicted transmission traffic consumption for the next sampling window is corrected, reducing prediction errors and thus achieving more accurate and stable traffic control.
[0066] In an optional example, if the remaining tokens are not cleared, each time a new token is added, the steady-state flow token bucket will accumulate unused tokens from the previous round, causing the total number of tokens actually available for transmission to exceed the token limit of a sampling window. Therefore, before adding tokens to the target steady-state flow token bucket corresponding to the target transmission direction, the method further includes: Step d: Clear the remaining tokens in the target steady-state flow token bucket.
[0067] Specifically, since the target steady-state traffic token bucket has a token limit, when the target steady-state traffic token bucket receives a generated token, the remaining tokens generated in the previous sampling window are not allowed to be used in the current sampling window. Therefore, it is necessary to clear the remaining tokens in the target steady-state traffic token bucket.
[0068] In the above method, the remaining tokens in the token bucket are cleared before adding a new token to the steady-state traffic token bucket. This prevents excessive data traffic caused by the accumulation of remaining tokens, thereby improving the throughput and congestion resistance of the on-chip network under high-load traffic scenarios and ensuring the accuracy of the token bucket's control over steady-state traffic. Clearing the remaining tokens before each new token addition ensures that the token quantity in the bucket is always replenished from 0 to the preset limit, ensuring that the transmittable traffic in each cycle strictly matches the steady-state rate standard and preventing historical redundant tokens from disrupting traffic stability.
[0069] In one optional example, a congestion solution is provided, such as Figure 7 As shown, Figure 7 The flowchart for a congestion solution is shown below: 1. Token replenishment: Triggers the token generation and replenishment process, the cycle of which is dynamically adjusted by the prediction module (e.g., traffic prediction results based on sliding window statistics).
[0070] 2. Token and Token Limit Generation: Based on the predicted transmission traffic consumption, dynamically determine the number of tokens that can be replenished in the current period and the token limit.
[0071] 3. Replenish tokens: Distribute the generated tokens to the steady-state or burst token bucket.
[0072] 4. Check for overdraft: If there is a burst of traffic overdraft in the current output direction (i.e., tokens in the burst traffic token bucket have been consumed and not fully returned), proceed to the overdraft handling branch ("Yes" branch); otherwise proceed to the remaining token allocation branch ("No" branch).
[0073] 5. Overdraft handling ("Yes" branch): Prioritize the repayment of overdraft tokens: Deduct the tokens corresponding to the overdraft amount from the replenished tokens to replenish the burst traffic token bucket, ensuring that burst traffic does not affect the resource allocation of subsequent steady-state traffic. Update the overdraft status of the burst traffic token bucket and mark the repaid portion.
[0074] 6. Check remaining tokens ("No" branch): Determine if there are any tokens remaining after replenishing tokens and repaying the overdraft.
[0075] 7. Add a steady-state flow token bucket ("Yes" branch): On-demand allocation: Distribute the remaining tokens to the steady-state token buckets in each output direction according to the number of tokens corresponding to the predicted transmission traffic consumption.
[0076] Discard redundant tokens: If the number of tokens to be replenished exceeds the predicted limit, the remaining tokens in the current steady-state flow token bucket are discarded directly to avoid token hoarding.
[0077] 8. Data Injection: New data packets enter the routing node, ready for traffic classification and transmission.
[0078] 9. Check if the steady-state token is non-zero: When tokens are plentiful ("Yes" branch): Allow packets to consume steady-state tokens and transmit directly, ensuring low latency.
[0079] When tokens are insufficient ("No" branch): trigger the burst traffic handling mechanism.
[0080] 10. Burst Traffic Handling ("Yes" branch): Check the overdraft threshold to determine whether the current surge in flow exceeds the preset overdraft threshold.
[0081] If the burst traffic does not exceed the threshold ("No" branch), a token is borrowed from the shared burst token bucket to support short-term excess traffic transmission.
[0082] 11. Trigger flow control ("Yes" branch): If the sudden traffic exceeds the threshold, a flow control signal is immediately sent to the source node or upstream router to prevent further data injection and congestion spread.
[0083] In the above embodiments, traffic prediction dynamically adjusts the token replenishment cycle and quantity, ensuring that token supply accurately matches actual demand. Furthermore, by prioritizing handling sudden traffic overdrafts, allocating remaining tokens to the steady-state bucket on demand, and discarding redundant tokens, it ensures that steady-state traffic resources are not overwhelmed by sudden overdrafts, while also preventing token hoarding and waste. During subsequent data transmission, steady-state tokens are prioritized to ensure low latency; the sudden token bucket is only activated when steady-state tokens are insufficient. When the tokens in the sudden token bucket exceed their limit, flow control is triggered promptly. This satisfies short-term sudden transmission demands while preventing congestion spread, ultimately ensuring efficient and stable traffic transmission across the entire routing node. This approach achieves flexible response to sudden traffic surges, effectively prevents network congestion, and balances efficient resource utilization with transmission stability. In an optional embodiment, a flow regulation scheme is provided, such as Figure 8 As shown, Figure 8 The flowchart for a flow regulation scheme is shown below: In a specific example, such as Figure 1 As shown, taking the transmission of data packets from source terminal node 21 to target terminal node 11 as an example, since source terminal node 21 needs to transmit data packets to target terminal node 11, the transmission direction at this time is: source terminal node 21 — routing node C0 — routing node B0 — routing node A0 — target terminal node 11. The data packet will be input from source terminal node 21, and then the path will be calculated through routing node C0 to calculate the target direction, that is, the target direction of routing node C0 is "routing node B0 — routing node A0 — target terminal node 11".
[0084] The data packet is then stored in the dynamic buffer of routing node B0. Simultaneously, sending the data packet consumes tokens from the steady-state traffic token bucket in the aforementioned target direction. If the number of tokens in the steady-state traffic token bucket is insufficient to support the transmission of the data packet, tokens need to be borrowed from the burst traffic token bucket, i.e., the number of tokens in the burst traffic token bucket is consumed for transmission. When the number of tokens consumed in the burst traffic token bucket reaches the overdraft threshold, i.e., the preset threshold, the transmission of the data packet by the source terminal node 21 or routing node C0 is prohibited.
[0085] Once everything is ready, routing node B0 retrieves data packets from the dynamic cache and transmits them to the target terminal node 11. During data transmission, the steady-state output traffic prediction module predicts the output traffic for the next sampling window based on the output traffic, determines the predicted transmission traffic consumption, and determines the corresponding token generation quantity (i.e., the token limit) based on this predicted transmission traffic consumption. The generated tokens are then added to the steady-state traffic token bucket. If the transmission of this data packet consumes tokens from the burst traffic token bucket, the generated tokens must first be used to replenish the burst traffic token bucket, and then the remaining tokens are added to the steady-state traffic token bucket.
[0086] In the above embodiments, independent steady-state traffic management is introduced. This involves configuring a dedicated token bucket for the output direction and dynamically replenishing tokens based on a prediction module to ensure long-term stability of steady-state traffic. A shared token bucket for burst traffic is used for all output directions, employing a "borrow-return" mechanism. This allows short-term excess traffic to occupy the shared buffer, but limits long-term occupation through an overdraft threshold to prevent resource exhaustion. By determining the predicted transmission traffic consumption, the number of tokens generated is dynamically adjusted to ensure more even token replenishment and reduce performance fluctuations. Furthermore, a burst traffic management mechanism linking overdraft thresholds and flow control is used. An overdraft threshold is set for each output direction; directions with smaller steady-state bandwidth are allowed higher burst overdraft amounts to maximize buffer resource utilization. Overdraft triggers flow control signals, which in turn restrict data injection from the source node or upstream routing to prevent congestion propagation.
[0087] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.
[0088] Embodiments of this application also provide an apparatus for resolving on-chip network congestion, see details below. Figure 9 As shown, the device includes: The statistics module 901 is used to count the actual transmission traffic of data packets in the target transmission direction within each sampling window. The target transmission direction is any one of the transmission directions to which the data packet to be transmitted is sent. The recording module 902 is used to record the actual transmission flow of data packets in the target transmission direction within each sampling window. The determination module 903 is used to determine the transmission traffic consumed in the current statistical window based on the actual transmission traffic in the current sampling window and the historical transmission traffic counted by the historical sampling windows in the current statistical window to which the current sampling window belongs. The current statistical window includes multiple historical sampling windows adjacent to the current sampling window and the current sampling window. The acquisition module 904 is used to predict the transmission traffic consumed in the next sampling window of the current sampling window based on the transmission traffic consumed in the current statistical window and the transmission traffic consumed in the previous statistical window, and to obtain the predicted transmission traffic consumed in the next sampling window. The generation module 905 is used to generate tokens based on the predicted transmission traffic consumption; The addition module 906 is used to add the token to the target steady-state flow token bucket corresponding to the target transmission direction, so as to use the token in the target steady-state flow token bucket to transmit the data packet to be transmitted in the target transmission direction within the time period corresponding to the next sampling window.
[0089] In an optional example, the determining module 903 is also used to determine the number of target tokens to be consumed for transmitting the target data packet based on the size of the target data packet when the target data packet to be transmitted is received at any time in the target transmission direction. The reading module is used to read tokens corresponding to the target number of tokens from the target steady-state traffic token bucket according to the target transmission direction; The transmission module is used to transmit the target data packet to the target transmission direction using a token.
[0090] In an optional example, the device also includes: The first determining submodule is used to determine the token quantity difference when the number of tokens in the target steady-state flow token bucket is less than the target number of tokens; The borrowing submodule is used to borrow a number of tokens from the pre-configured burst traffic token pool, corresponding to the difference in the number of tokens, for the purpose of transmitting the target data packet.
[0091] In an optional example, when the token quantity difference exceeds a preset quantity threshold, the borrowing submodule includes: The first sending unit is used to send the first prompt information to the initiator of the target data packet.
[0092] The first prompt message indicates that data packets should not be transmitted further in the target direction until the borrowed tokens are replenished and there are remaining tokens in the target steady-state flow token bucket. The borrowing submodule also includes: The second sending unit sends a second prompt message to the target data packet initiator. The second prompt message is used to indicate that data packets can be transmitted in the target transmission direction subsequently.
[0093] In an optional example, module 903 includes: The second determination submodule is used to determine the total historical transmission traffic based on the historical transmission traffic counted separately by multiple historical sampling windows included in the current statistical window; The summation submodule is used to perform weighted operations on the actual transmission traffic and the sum of historical transmission traffic within the current sampling window, and then perform a summation operation. The Get submodule is used to obtain the transmission traffic consumed within the current statistics window.
[0094] In an optional example, the device also includes: The clear module is used to clear the remaining tokens in the target steady-state flow token bucket.
[0095] For a description of the features of the apparatus for resolving on-chip network congestion provided in this application, please refer to the relevant description of the method for resolving on-chip network congestion, which will not be repeated here.
[0096] Embodiments of this application also provide an electronic device, such as... Figure 10 As shown, the system includes a memory 10 and a processor 20. The memory 10 stores a computer program, and the processor 20 is configured to run the computer program to perform the steps in any of the above-described embodiments of the method for resolving on-chip network congestion.
[0097] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the method for resolving on-chip network congestion.
[0098] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.
[0099] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the method for resolving on-chip network congestion.
[0100] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0101] The foregoing has provided a detailed description of a method, apparatus, and device for resolving on-chip network congestion. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of these embodiments are only intended to aid in understanding the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the scope of protection of the claims.
Claims
1. A method for resolving on-chip network congestion, characterized in that, The method includes: The actual transmission traffic of the target transmission direction for transmitting data packets within each sampling window is statistically analyzed and recorded. The target transmission direction is any one of the transmission directions to which the data packet to be transmitted is sent. Based on the actual transmission traffic within the current sampling window and the historical transmission traffic counted by the historical sampling windows within the current statistical window to which the current sampling window belongs, the transmission traffic consumed within the current statistical window is determined. Each current statistical window includes multiple historical sampling windows adjacent to the current sampling window and the current sampling window itself. Based on the transmission traffic consumed in the current statistical window and the transmission traffic consumed in the previous statistical window, the transmission traffic consumed in the next sampling window of the current sampling window is predicted, and the predicted transmission traffic consumed in the next sampling window is obtained. Generate a token based on the predicted transmission traffic consumption; The token is added to the target steady-state traffic token bucket corresponding to the target transmission direction, so that the token in the target steady-state traffic token bucket can be used to transmit the data packet to be transmitted in the target transmission direction within the time period corresponding to the next sampling window.
2. The method according to claim 1, characterized in that, The method further includes: Upon receiving a target data packet to be transmitted to the target transmission direction at any time, the number of target tokens to be consumed in transmitting the target data packet is determined based on the size of the target data packet. Based on the target transmission direction, read the tokens corresponding to the target token quantity from the target steady-state traffic token bucket; The target data packet is transmitted to the target transmission direction using the token.
3. The method according to claim 2, characterized in that, The method further includes: When the number of tokens in the target steady-state flow token bucket is less than the target number of tokens, the token quantity difference is determined; Borrow a number of tokens from the pre-configured burst traffic token pool, corresponding to the difference in the number of tokens, to transmit the target data packet.
4. The method according to claim 3, characterized in that, When the difference in the number of tokens is greater than a preset threshold, the method further includes: A first prompt message is sent to the target data packet initiator to indicate that data packets should not be transmitted further in the target transmission direction until the borrowed tokens are replenished and there are remaining tokens in the target steady-state flow token bucket. Then, a second prompt message is sent to the target data packet initiator to indicate that data packets can be transmitted in the target transmission direction.
5. The method according to any one of claims 1-4, characterized in that, The step of determining the transmission traffic consumed in the current statistical window based on the actual transmission traffic within the current sampling window and the historical transmission traffic counted by the historical sampling windows within the current statistical window to which the current sampling window belongs, specifically includes: The total historical transmission traffic is determined based on the historical transmission traffic counted separately for each of the multiple historical sampling windows included in the current statistical window; After performing a weighted operation on the actual transmission traffic within the current sampling window and the sum of the historical transmission traffic respectively, a summation operation is then performed to obtain the transmission traffic consumed within the current statistical window.
6. The method according to any one of claims 1-4, characterized in that, There is a preset number of overlapping sampling windows between two adjacent statistical windows.
7. The method according to claim 5, characterized in that, After predicting the transmission traffic consumed in the next sampling window based on the transmission traffic consumed in the current statistical window and the transmission traffic consumed in the previous statistical window, and obtaining the predicted transmission traffic consumption for the next sampling window, the method further includes: Obtain the actual transmission traffic consumed by the next sampling window; The correction factor is determined based on the predicted transmission traffic consumption of the next sampling window and the actual transmission traffic. Based on the correction coefficient, the predicted transmission traffic consumption for the next sampling window is predicted and corrected, so as to generate a token within the time period corresponding to the next sampling window based on the corrected predicted transmission traffic consumption.
8. The method according to claim 5, characterized in that, Before adding the token to the target steady-state traffic token bucket corresponding to the target transmission direction, the method further includes: Clear the remaining tokens in the target steady-state flow token bucket.
9. An apparatus for resolving on-chip network congestion, characterized in that, The device includes: The statistics module is used to count the actual transmission traffic of data packets in the target transmission direction within each sampling window. The target transmission direction is any one of the transmission directions to which the data packet to be transmitted is sent. The recording module is used to record the actual transmission flow of data packets in the target transmission direction within each sampling window; The determination module is used to determine the transmission traffic consumed in the current statistical window based on the actual transmission traffic in the current sampling window and the historical transmission traffic counted by the historical sampling windows in the current statistical window to which the current sampling window belongs. The current statistical window includes multiple historical sampling windows adjacent to the current sampling window and the current sampling window itself. The acquisition module is used to predict the transmission traffic consumed in the next sampling window of the current sampling window based on the transmission traffic consumed in the current statistical window and the transmission traffic consumed in the previous statistical window, and to obtain the predicted transmission traffic consumed in the next sampling window. The generation module is used to generate tokens based on the predicted transmission traffic consumption. The addition module is used to add the token to the target steady-state traffic token bucket corresponding to the target transmission direction, so as to use the token in the target steady-state traffic token bucket to transmit the data packet to be transmitted in the target transmission direction within the time period corresponding to the next sampling window.
10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the method for resolving on-chip network congestion as described in any one of claims 1 to 8 when executing the computer program.