Network device and network speed measurement method

Abstract

The invention provides a network device and a network speed measurement method. The network device comprises a network interface hardware circuit, a storage device and a processor. The network interface hardware circuit is used for receiving a plurality of data packets sent by another network device from a network. The network interface hardware circuit comprises a counter and an active packet loss circuit. The counter is used for counting a plurality of data packets during network speed measurement, and the plurality of data packets comprise a plurality of first data packets and a plurality of second data packets. The active packet loss circuit is used for actively discarding a plurality of second data packets during network speed measurement. The storage device is used for storing program codes. The processor is used for loading and executing the program code so as to carry out the following operations: reading the data packet count values of the counter at different time points to calculate the data packet receiving quantity of the network device in the time interval between the different time points during the network speed measurement period.

Description

Technical Field

[0001] The present invention relates to network speed measurement, and in particular to a network device and a related network speed measurement method that uses hardware to count all received data packets and actively discard some data packets to reduce the burden on a processor (especially a processor with limited computing power), while meeting the demand for high-speed network speed measurement. Background Art

[0002] The Transmission Control Protocol (TCP) is a transport layer protocol. Network devices at both ends of TCP communicate with each other to ensure data accuracy and control transmission rates. For example, TCP uses acknowledgment and retransmission mechanisms to ensure the accuracy and reliability of TCP data packets transmitted across the network. This reduces overall transmission efficiency but ensures that TCP data packets are delivered accurately from the sender to the receiver. However, for some applications, this feature isn't essential. For example, network speed measurement applications don't actually care about the correctness of data content. As network speeds continue to increase, traditional TCP-based network speed measurement applications may encounter bottlenecks and severely underestimate the user's actual network speed.

[0003] The User Datagram Protocol (UDP) is another transport layer protocol. Both TCP and UDP are transport layer protocols, and the primary difference between them lies in whether they provide reliable transmission. TCP offers high reliability, while UDP prioritizes efficiency and is indifferent to packet loss. Therefore, UDP-based network speed measurement applications can be used as an alternative to traditional network speed measurement applications. However, for network devices using processors with limited computing power, having the processor parse each UDP packet received for downlink speed measurement consumes significant processor and memory resources. Even if the downlink speed measurement packet parsing task can fully occupy the processor's operating time, the processor's limited computing power means that the maximum network rate measured by the downlink speed measurement will still be far lower than the actual network rate, thus failing to meet the needs of high-speed network speed measurement. Summary of the Invention

[0004] One of the objectives of the present application is to provide a network device and a network speed testing method for reducing the burden of a processor, especially a processor with limited computing power, by counting all received data packets and actively discarding part of the data packets through hardware, while satisfying the requirement of high-speed network speed testing.

[0005] In one embodiment of the present application, a network device is disclosed. The network device comprises a network interface hardware circuit, a storage device, and a processor. The network interface hardware circuit is configured to receive a plurality of data packets transmitted by another network device from a network. The network interface hardware circuit comprises a counter and an active packet discarding circuit. The counter is configured to count the plurality of data packets during a network speed test, wherein the plurality of data packets comprise a plurality of first data packets and a plurality of second data packets. The active packet discarding circuit is configured to actively discard the plurality of second data packets from the plurality of data packets during the network speed test. The storage device is configured to store program codes. The processor is configured to load and execute the program codes to read the packet count values of the counter at different time points during the network speed test to calculate a number of data packets received by the network device in a time interval between the different time points.

[0006] In one embodiment of the present application, a network speed testing method is disclosed. The network speed testing method comprises: receiving a plurality of data packets from a network through a network interface hardware circuit, comprising: counting the plurality of data packets during a network speed test using a counter, wherein the plurality of data packets comprise a plurality of first data packets and a plurality of second data packets; and actively discarding the plurality of second data packets from the plurality of data packets during the network speed test; and executing program codes to read the packet count values of the counter at different time points during the network speed test to calculate a number of data packets received in a time interval between the different time points.

[0007] During a network speed test, the processor in the network device of the present application does not need to parse all data packets successfully received by the network interface hardware circuit, so that the processor does not need to consume a large amount of processor resources and memory resources when performing data packet parsing. In addition, the network interface hardware circuit in the network device of the present application sets a counter to count all data packets successfully received by the network interface hardware circuit during the network speed test, so that the processor can calculate the number of data packets received by reading the packet count values of the counter. BRIEF DESCRIPTION OF DRAWINGS

[0008] Figure 1 A schematic diagram of the network device of one embodiment of the present application.

[0009] Figure 2A schematic diagram of the data packet format that complies with the TR-471 speed measurement protocol.

[0010] Figure 3 Schematic diagram of data packet exchange between the sender and receiver according to the TR-471 speed measurement protocol.

[0011] Figure 4 Schematic diagram of an operation for calculating the number of dropped packets according to an embodiment of the present invention.

[0012]

Explanation of symbols

[0013] 100, 102: Network device

[0014] 101: Wide Area Network

[0015] 112: Storage device

[0016] 114: Processor

[0017] 116: Network interface hardware circuit

[0018] 118:Linux kernel module

[0019] 120: Data packet receiving driver module

[0020] 122: Active packet loss circuit

[0021] 124: Counter

[0022] 130: Receive ring buffer

[0023] 302: Payload Protocol Data Unit

[0024] 304: Status Feedback Protocol Data Unit

[0025] 402:GDM Hardware

[0026] 404:OBUDP software module

[0027] PKT: Data Packet

[0028] PKT_1: first data packet

[0029] PKT_2: Second data packet

[0030] PROG: Program code

[0031] T(n), T(n+1): time point

[0032] TI(n), TI(n+1), TI(n+2): trial interval

[0033] GDM_RX_OK_CNT(n), GDM_RX_OK_CNT(n+1): Packet count value

[0034] lpduSeqNo(n), lpduSeqNo(n+1): sequence number DETAILED DESCRIPTION

[0035] Certain words are used in the specification and claims to refer to specific components. Those skilled in the art will understand that hardware manufacturers may use different terms to refer to the same component. This specification and claims do not use the difference in name as a way to distinguish components, but rather use the difference in the function of the components as the criterion for distinction. The words "include" and "including" mentioned throughout the specification and claims are open-ended terms and should be interpreted as "including but not limited to". In addition, the word "couple" or "coupled" herein includes any direct and indirect electrical connection means. Therefore, if the text describes a first device coupled to a second device, it means that the first device can be directly electrically connected to the second device, or indirectly electrically connected to the second device through other devices and connection means.

[0036] Figure 1 Schematic diagram of a network device according to an embodiment of the present invention. The network device 100 can exchange data with another network device 102 through a wide area network (WAN) 101. For example, the network device 100 can act as a client, and the network device 102 can act as a server. Therefore, the network device 100 can request the network device 102 to send a data packet to the network device 100 for downlink speed measurement. In this embodiment, the network device 100 can be an optical network unit (ONU), but the present invention is not limited thereto. Any network device that adopts the network speed measurement solution of the present invention falls within the scope of the present invention. The network device 100 includes a storage device 112, a processor 114, and a network interface hardware circuit 116. Please note that Figure 1Only components relevant to the present invention are shown; in practice, network device 100 may include other components to implement other functions. Storage device 112, which may be a memory or any other device capable of data storage, is used to store program code PROG. For example, program code PROG may include program code for an operating system (OS). In this embodiment, program code PROG may comprise multiple software modules, including (but not limited to) a Linux kernel module 118 and a packet receiving driver module 120. Processor 114 is used to load and execute program code PROG to control the operation of network device (e.g., client) 100. For example, processor 114 may be a general-purpose processor, and Linux kernel module 118 supports the TR-471 speed measurement protocol (a UDP-based speed measurement protocol). Therefore, processor 114 can execute program code PROG (including Linux kernel module 118 and packet receiving driver module 120) to perform software control-related operations in the network speed measurement solution of the present invention.

[0037] The network interface hardware circuit 116 is used to handle hardware control operations in the network speed measurement solution of the present invention. For example, the network interface hardware circuit 116 may be a network card, which is used to receive multiple data packets PKT sent from another network device (e.g., a server) 102 from the wide area network 101 for downlink speed measurement. In this embodiment, the network interface hardware circuit 116 is a purely hardware-implemented functional block and can additionally support the hardware functions required by the network speed measurement solution of the present invention. For example, the network interface hardware circuit 116 includes an active packet loss circuit 122 and a counter 124. Counter 124 is used to count the number of data packets PKT successfully received by the network interface hardware circuit 116 during a network speed measurement (e.g., a downlink speed measurement). For example, each time the network interface hardware circuit 116 successfully receives a data packet PKT from the wide area network 101, the packet count value GDM_RX_OK_CNT maintained by the counter 124 is incremented (i.e., GDM_RX_OK_CNT = GDM_RX_OK_CNT + 1).

[0038] In this embodiment, the active packet loss circuit 122 can actively discard some of the multiple data packets PKT successfully received by the network interface hardware circuit 116. For example, the multiple data packets PKT include multiple first data packets PKT_1 and multiple second data packets PKT_2. During the network speed measurement (such as downlink speed measurement), the active packet loss circuit 122 will actively discard multiple second data packets PKT_2 in the multiple data packets PKT (for example, N data packets PKT_2 will be discarded for every M data packets PKT, where M>N and N≥1). In addition, in this embodiment, each data packet PKT can be a UDP data packet, including a UDP header and UDP payload data. In addition, each data packet PKT will carry a load protocol data unit (Load Protocol Data Unit, Load PDU) in a data packet format that complies with the TR-471 speed measurement protocol, such as Figure 2 As shown, the UDP payload data of the UDP data packet includes a payload protocol data unit (which includes a payload header and payload data).

[0039] Regarding the multiple first data packets PKT_1 that are not actively discarded by the active packet discard circuit 122, the network interface hardware circuit 116 will write the multiple first data packets (UDP data packets that are not actively discarded) PKT_1 one by one into a data packet register (not shown) through direct memory access (DMA). In addition, the network interface hardware circuit 116 will also write the packet descriptor of each first data packet (UDP data packet that is not actively discarded) PKT_1 into the receive ring buffer (RX ring buffer) 130, wherein the packet descriptor of the first data packet (UDP data packet that is not actively discarded) PKT_1 will record information about the actual storage address of this first data packet (UDP data packet that is not actively discarded) PKT_1 in the memory. The Linux kernel module 118 can subsequently read the packet descriptor of the first data packet (UDP data packet that has not been actively discarded) PKT_1 from the receiving ring buffer 130 through the data packet receiving driver module 120, and obtain the first data packet (UDP data packet that has not been actively discarded) PKT_1 from the memory according to the storage address information provided by the data packet descriptor, and perform packet parsing on this first data packet (UDP data packet that has not been actively discarded) PKT_1.

[0040] In this embodiment, the processor 114 is a processor with limited computing power, such as an ARM processor operating at 1.2 Gigahertz (GHz). Because the packet parsing work of the processor 114 is quite resource-intensive, the processor 114 is unable to parse enough packets in the required time to test the actual rate of the network. To solve this problem, the network device 100 of the present application can count all the received packets and actively discard some of the packets through the network interface hardware circuit 116, to reduce the burden on the processor 114 and meet the high-speed network speed testing requirements. Specifically, by limiting the speed of the receive ring buffer 130, the active packet discarding circuit 122 actively discards most of the packets during network speed testing, which reduces the processor load and memory load and improves the ability to test the downstream speed. Further details of the network speed testing scheme of the present application will be described below.

[0041] As mentioned above, the Linux kernel module 118 supports the TR-471 speed testing protocol, which is a UDP-based speed testing protocol. According to the TR-471 speed testing protocol, when performing downstream speed testing, the network device (client) 100 is the receiver, and the other network device (server) 102 is the sender. Please refer to Figure 3 , Figure 3 A schematic diagram of the packet exchange between the sender and the receiver according to the TR-471 speed testing protocol is shown in FIG. 3. The network device (sender) 102 sends a plurality of load protocol data units 302 in each trial interval (TI, hereinafter referred to as TI) according to the transmission rate (in bits per second (bps)) set for the TI. In addition, the network device (receiver) 100 parses each received load protocol data unit 302 to count the number of dropped packets, out-of-order, round trip time (RTT), and other information, and writes these statistical information into a status feedback protocol data unit (Status Feedback PDU) 304 at the end of each TI and returns it to the network device (sender) 102. The network device (sender) 102 will subsequently adjust the transmission rate to be used in the next TI according to the statistical information carried by the status feedback protocol data unit 304.

[0042] According to the TR-471 speed measurement protocol, the sending rate adjustment method is as follows: if there is no packet loss in the current transmission time interval (TI), the sending rate of the next TI will be increased. Conversely, if there is packet loss in the current TI, the sending rate of the next TI will be decreased. For example, if the current sending rate is below 1GHz and there is no packet loss, the sending rate will increase by 10Mbps each time. If the current sending rate is below 1GHz and there is packet loss, the sending rate will decrease by 30Mbps each time. If the current sending rate is above 1GHz and there is no packet loss, the sending rate will increase by 100Mbps each time. If the current sending rate is above 1GHz and there is packet loss, the sending rate will decrease by 100Mbps each time. Traditionally, the number of received data packets (i.e., the number of payload protocol data units (PDUs) that comply with the TR-471 speed measurement protocol) needs to be counted by the receiving processor itself. In other words, the receiving processor needs to parse each received data packet (i.e., the payload protocol data unit (PDU) carried by the UDP data packet) to count the number of dropped packets. However, this packet parsing work consumes a lot of processor and memory resources.

[0043] In this embodiment, the program code executed by the processor 114 (e.g., the Linux kernel module 118) only needs to parse multiple first data packets (UDP data packets that have not been actively discarded) PKT_1, and does not need to parse all data packets PKT (including PKT_1 and PKT_2) successfully received by the network interface hardware circuit 116. In this way, the processor 114 does not consume a large amount of processor resources and memory resources when parsing multiple first data packets (UDP data packets that have not been actively discarded) PKT_1. According to the TR-471 speed measurement protocol, Figure 2 The "lpduSeqNo" field in the payload header shown is used to record the sequence number of the payload protocol data unit. The program code executed by the processor 114 (for example, the Linux kernel module 118) can obtain the corresponding sequence number by parsing the "lpduSeqNo" field in each first data packet (UDP data packet that has not been actively discarded) PKT_1. In this way, the number of data packets sent by the network device (transmitter) 102 to the network device (receiver) 100 during the downlink speed test can be obtained by the sequence number of the payload protocol data unit obtained by the processor 114 performing the data packet parsing work.

[0044] As described above, at the end of each TI, the network device (receiving end) 100 needs to report the status feedback protocol data unit to the network device (transmitting end) 102, so that the network device (transmitting end) 102 can dynamically adjust the sending rate to be used in the next TI based on the statistical information (especially the number of packet drops) carried by the status feedback protocol data unit. For the network device (receiving end) 100, in order to obtain the information on the number of packet drops, in addition to knowing the number of data packets sent by the network device (transmitting end) 102 through the processor 114 performing the data packet parsing work, it is also necessary to know the number of data packets received by the network device (receiving end) 100 itself. In this embodiment, the network interface The counter 124 of the hardware circuit 116 counts all data packets PKT successfully received by the network interface hardware circuit 116. Therefore, the program code executed by the processor 114 (such as the Linux kernel module 118) can also read the data packet count value of the counter 124 at different time points to calculate the number of data packets received by the network device (receiving end) 100 itself. Finally, the number of packet drops can be calculated based on the number of data packets sent by the network device (sending end) 102 (which is calculated by the sequence number obtained by executing data packet parsing by the software module) and the number of data packets received by the network device (receiving end) 100 (which is calculated by the count value provided by the hardware).

[0045] See also Figure 4 , Figure 4 Schematic diagram of the operation of calculating the number of dropped packets according to an embodiment of the present invention. The operations related to hardware control in the network speed measurement solution of the present invention can be implemented by GDM hardware 402, and the operations related to software control in the network speed measurement solution of the present invention can be implemented by OBUDP software module 404. Figure 1 In the illustrated architecture, the counter 124 may be implemented by the GDN hardware 402 to record the number of packets received by the network device (receiver) 100, and the Linux kernel module 118 may include the program code of the OBUDP software module 404 to count the number of packets sent by the network device (sender) 102. The OBUDP software module 404 parses the payload header of the payload protocol data unit carried in the last UDP packet in each TI to obtain the corresponding sequence number, such as Figure 4As shown, the OBUDP software module 404 parses the sequence number of the payload protocol data unit carried in the last UDP packet in the previous test interval TI(n) (i.e., the sequence number lpduSeqNo(n) corresponding to the time point T(n)) and the sequence number of the payload protocol data unit carried in the last UDP packet in the current test interval TI(n+1) (i.e., the sequence number lpduSeqNo(n+1) corresponding to the time point T(n+1)). Then, the OBUDP software module 404 calculates the number of data packets sent by the network device (transmitter) 102 in the current test interval TI(n+1) based on the sequence numbers lpduSeqNo(n) and lpduSeqNo(n+1) obtained from the end times of the two consecutive test intervals TI(n) and TI(n+1), respectively (e.g., SendTxCnt(n+1)=lpduSeqNo(n+1)-lpduSeqNo(n)).

[0046] In addition, the OBUDP software module 404 obtains the packet count value GDM_RX_OK_CNT(n) corresponding to the time point T(n) and the packet count value GDM_RX_OK_CNT(n+1) corresponding to the time point T(n+1) from the GDM hardware 402 (i.e., the counter hardware). Then, the OBUDP software module 404 calculates the number of packets received by the network device (receiver) 100 in the current test interval TI(n+1) rxCnt(n+1) based on the packet count values ​​GDM_RX_OK_CNT(n) and GDM_RX_OK_CNT(n+1) obtained by the GDM hardware 402 (i.e., the counter hardware) at the end times of two consecutive test intervals TI(n) and TI(n+1), respectively (e.g., rxCnt(n+1)=GDM_RX_OK_CNT(n+1)−GDM_RX_OK_CNT(n)).

[0047] After calculating the number of packets sent SendTxCnt(n+1) and the number of packets received rxCnt(n+1) in the current test interval TI(n+1), the OBUDP software module 404 can calculate the number of dropped packets DropCnt(n+1) in the current test interval TI(n+1) (for example, DropCnt(n+1)=SendTxCnt(n+1)-rxCnt(n+1)), and write the number of dropped packets DropCnt(n+1) in the current test interval TI(n+1) into the status feedback protocol data unit (for example, Figure 3 The state feedback protocol data unit 304 is reported to the network device (sender) 102, and the network device (sender) 102 subsequently responds to the state feedback protocol data unit (eg Figure 3 The information carried by the status feedback protocol data unit 304 (such as the number of dropped packets DropCnt(n+1) in the current test interval TI(n+1)) is used to dynamically adjust the sending rate to be used in the next test interval TI(n+2).

[0048] The above descriptions are merely preferred embodiments of the present invention. All equivalent changes and modifications made according to the claims of the present invention should fall within the scope of the present invention.

Claims

1. A network device comprising: A network interface hardware circuit is used to receive a plurality of data packets sent by another network device from a network, wherein the network interface hardware circuit comprises: a counter, configured to count the plurality of data packets during the network speed test, wherein the plurality of data packets include a plurality of first data packets and a plurality of second data packets; and an active packet dropping circuit, configured to actively drop the plurality of second data packets from the plurality of data packets during the network speed test; a storage device for storing program code; as well as A processor is used to load and execute the program code to perform the following operations: During the network speed test, the data packet count values ​​of the counter at different time points are read to calculate the number of data packets received by the network device in the time interval between the different time points. 2 . The network device of claim 1 , wherein each of the plurality of data packets is a User Datagram Protocol (UDP) data packet.

3. The network device as claimed in claim 2, wherein the network speed measurement adopts TR-471 speed measurement protocol. The network device as claimed in claim 1 , wherein the network device is an optical network unit.

5. The network device of claim 1 , wherein the processor further executes the program code to perform the following operations: During the network speed measurement, the number of data packets sent by the other network device in the time interval between the different time points is calculated using the multiple first data packets, and the number of dropped packets is calculated based on the number of data packets sent and the number of data packets received.

6. A network speed measurement method, comprising: Receive multiple data packets from the network through the network interface hardware circuit, including: During the network speed test, a counter is used to count the plurality of data packets, wherein the plurality of data packets include a plurality of first data packets and a plurality of second data packets; and During the network speed test, actively discarding the plurality of second data packets among the plurality of data packets; and Execute the program code to do the following: During the network speed test, the data packet count values ​​of the counter at different time points are read to calculate the number of data packets received in the time interval between the different time points.

7. The network speed measurement method as claimed in claim 6, wherein each of the plurality of data packets is a User Datagram Protocol data packet.

8. The network speed measurement method as claimed in claim 7, wherein the network speed measurement adopts TR-471 speed measurement protocol.

9. The network speed measurement method as claimed in claim 6, wherein the network speed measurement method is performed by an optical network unit.

10. The network speed measurement method according to claim 6, further comprising: Execute this program code to perform the following operations: During the network speed test, the number of data packets sent in the time interval between the different time points is calculated using the multiple first data packets, and the number of dropped packets is calculated based on the number of data packets sent and the number of data packets received.

Images