UDP Throughput Tests

UDP Traffic Generation = Bit Blasting

UDP traffic generation with Hawkeye is a way to generate bit blasting from Keysight performance endpoints.

The traffic rate defined and packet size will be generated from one side to the other.

UDP traffic is generated at layer 4 by Ixia endpoints/probes.

The data is sent through the operating system stack with packet sizes:

IP header : 20 byte
UDP header : 8 bytes
Layer 2 header : 14 to 18 bytes + 4 bytes checksum

All indications into Hawkeye are set at layer 4 (inside UDP header).

Even though the traffic generation is IP to IP (layer 4) inside UDP packets (layer 4) the result of the traffic generation can be considered as traffic blasting (aka RFC 2544 testing).

UDP Traffic Burstiness

Traffic generation from software based system can create some problems at high rates with traffic generation burstiness.

That means that traffic as sent from Ixia endpoint or probe can be generated with thoughout bitrate as requested, but with a non linear profile.

The following figure illustrates a traffic generated with bursts of traffic - typical behavior from a software based traffic generation tool like Hawkeye.

Network equipments like traffic shapers or rate controllers would remove any traffic going at higher rates than 100Mbps in the above example resulting into a problematic measurement of the available bit rate.

Hawkeye implements an algorithm that can be used to reduce dramatically this jitter and side effects measuring UDP flows in networks.

This optimization algorithm that uses very precise timers to reduce jitter between sent packets and when this algorithm is enabled, the datagrams are sent by Endpoint 1 use a lot more precise intervals than when the standard algorithm is in effect.

Enabling this Low Sender Jitter algorithm:

In the System Preferences > Administration > Preferences > Test Engine, there is a parameter lowsendjitter. This parameter will enable more accurate jitter calculations on the XR2000. This parameter, however, can only be enabled on systems only using the XR2000 endpoints as it invokes a math co-processor that may not be supported on other endpoint types.

UDP packet size and performances

The limitation of packets that can be sent per second typically depends upon the following factors:

the number of packets / second that Network interface card
CPU of the system can manage (usually based on # packets per second as well).

The total capacity of network cards and therefore Hawkeye endpoint software is limited by number of packets per second.

Large packets usually result into significannot bit rates capabilities.

Smaller packets will have less bit rate on the network, therefore it is expected the total amount of traffic endpoints will be able to generate are declining with the frame rate.

As an example for a network interface card able to generate packets at about line rate for max IP MTU (1500 bytes):

This is only an example and should be read to give guidance on expected throughput capabilities at different packet sizes and levels on an endpoint example. Real value would slightly differ from the table below depending on the endpoint type:

UNIT = BYTE			UNIT = Mbps
Packet size UDP	Packet size IP	packet size layer 2	Goodput rate	IP rate	layer 2 rate	packets / second
1460	1488	1506	958	976	988	82000
1300	1328	1346	853	871	883	82000
1000	1028	1046	656	674	686	82000
500	528	546	328	346	358	82000
200	228	246	131	150	161	82000
100	128	146	66	84	96	82000
64	92	110	42	60	72	82000
10	38	56	7	25	37	82000

Using the traffic buffering algorithm optimization can help generating more packets per second for powerful cpu endpoints (where bottleneck is in the network interface card): by way of sending more even traffic to the stack, Hawkeye probes optimize the packets that can be sent.

Endpoints support the use of very large frames. When you choose the packet size as optimized, a packet size of 64,000 bytes will be used. You must be aware that errors can occur when using this value. The required bit rate will result in 64k packets being sent. If the required bit rate is less than 64 Mbps, no packets will be sent and the test will timeout as an error.

Exceeding UDP Traffic Generation Capability

Hawkeye does not limit the bit rate and packet size generation for users therefore it is essential that users have some understanding of the limits of the probes they are using.

Generating too much traffic will result into packets drops at the traffic generator stack (packets are never sent to the network) or packets being lost at reception of the stack (packets are not counted as received by receiving endpoint/probe).

Each Stream is limited to a maximum rate of 4.19Gbps. To test rates higher than 4.19Gbps, please use one of the N Stream Tests.

UDP Throughput Tests Descriptions

	UDP throughput from -> to
Description	One UDP stream - generates throughput with defined packet size and bit rate - from E1 to E2.
Purpose	Send UDP packets (bit blasting) at defined rate to validate the capacity between endpoints.
Available Options	Generated Bitrate Packet Size DSCP setting
Metrics	Average Throughput (Mbps) from->to Loss (%) Total bytes lost
Advanced Information	This test will generate UDP packets from E1 to E2 based on requested throughput. Test sample Filesize will be computed according to the requested bit rate so that there should be approximately one timing record per second. Optimized packet size is udp size used to optimize the stack therefore pushing packet size bigger than MTU to get full MTU packets on the line. While it provides better results for throughput it can be sensitive to packet fragmentation on the network therefore providing lot of packet losses in some network conditions.
Results interpretation	The result in throughput is displayed at layer 4 level (with ethernet, IP and UDP headers). UDP packet generation is similar to bit blasting therefore will not autoadjust to available bandwidth. Some higher than capacity traffic generation can result into network equipments traffic congestion and therefore cause some service drops.
Potential Errors	If the configured bitrate is set too high compared to expected line capacity, this might result in the test not able to accomplish first measurement. This would result in an error with time out (unable to collect result). Small packet sizes are not able to generate as much throughput as large ones: at high traffic, it is possible that endpoints generate packet losses as they would be unable to generate the expected traffic rate. In case of use of UDP packet size optimized or 1460 packet size, be careful in case of low MTU or network fragmentation: this can cause packets to be fragmented therefore unexpected or higher than expected packet loss rates. It is recommended to use a lower UDP packet size (1300 for example) to validate there is no impact on test result. If there is unexpected loss this could be because of some bursty UDP traffic generation: make sure you have endpoints supporting the send low jitter option and enable in preferences/test engine in Hawkeye preferences. If results cannot be collected (some pairs did not complete error): Check that your E2 endpoint can open 10115 port toward E1 for management (this is needed for stream pairs). Check that port for traffic is opened (no firewall). Check that synchronization port between pairs is opened (management UDP 10115). Check that port in use is in range (see "preferences/Test Controller/Destination Port Conf Option" and "preferences/Test Controller/First Destination Port" so that correct destination port for test traffic is used.

	UDP throughput to -> from
Description	One UDP stream - generates throughput with defined packet size and bit rate - from E2 to E1 .
Purpose	See UDP throughput from -> to.
Available Options
Metrics
Advanced Information
Results interpretation
Potential Errors

	UDP throughput from -> to N streams
Description	Multiple UDP stream - generates throughput with defined bit rate in multiple streams from E1 to E2.
Purpose	Verify that a multiple UDP stream in one direction is going through. If several streams are configured (>3 typically), total throughput rates can exceed the single stream limit of 4.19Gbps.
Available Options	Generated Bitrate Packet Size DSCP setting
Metrics	Average Throughput (Mbps) from->to Loss (%) Total bytes lost
Advanced Information	This test will generate UDP packets from E1 to E2 based on requested throughput. Test sample Filesize will be computed according to the requested bit rate so that there should be approximately one timing record per second. Optimized packet size is udp size used to optimize the stack therefore pushing packet size bigger than MTU to get full MTU packets on the line. While it provides better results for throughput it can be sensitive to packet fragmentation on the network therefore providing lot of packet losses in some network conditions.
Results interpretation	The result in throughput is displayed at layer 4 level (with ethernet, IP and UDP headers). UDP packet generation is similar to bit blasting therefore will not autoadjust to available bandwidth. Some higher than capacity traffic generation can result into network equipments traffic congestion and therefore cause some service drops.
Potential Errors	If the configured bitrate is set too high compared to expected line capacity, this might result in the test not able to accomplish first measurement. This would result in an error with time out (unable to collect result). Small packet sizes are not able to generate as much throughput as large ones: at high traffic, it is possible that endpoints generate packet losses as they would be unable to generate the expected traffic rate. In case of use of UDP packet size optimized or 1460 packet size, be careful in case of low MTU or network fragmentation: this can cause packets to be fragmented therefore unexpected or higher than expected packet loss rates. It is recommended to use a lower UDP packet size (1300 for example) to validate there is no impact on test result. If there is unexpected loss this could be because of some bursty UDP traffic generation: make sure you have endpoints supporting the send low jitter option and enable in preferences/test engine in Hawkeye preferences. If results cannot be collected (some pairs did not complete error): Check that your E2 endpoint can open 10115 port toward E1 for management (this is needed for stream pairs). Check that port for traffic is opened (no firewall). Check that synchronization port between pairs is opened (management UDP 10115). Check that port in use is in range (see "preferences/Test Controller/Destination Port Conf Option" and "preferences/Test Controller/First Destination Port" so that correct destination port for test traffic is used. If the number of pairs is greater than available max number of pairs per license the test can be stuck in queue. The maximum number of simultaneous pairs (N value) each individual test can perform is also controlled by a parameter in theSystem Preferences > Max Concurrent Tests in GUI.

	UDP throughput to -> from N streams
Description	Multiple UDP stream - generates throughput with defined packet size and bit rate in multiple streams from E2 to E1.
Purpose	See UDP throughput from -> to N streams.
Available Options
Metrics
Advanced Information
Results interpretation
Potential Errors

	UDP throughput bidirectional
Description	Bidirectional UDP throughput -with defined packet size and bitrate. The UDP throughput is generated concurrently.
Purpose	Send UDP packets (bit blasting) at defined rate to validate the capacity between endpoints in both directions. Unlike TCP bidirectional, this measure is perfectly valid to measure both ways of communications simultaneously provided there is no max out of endpoint/probe performance.
Available Options	Per directions: Generated Bitrate Packet Size DSCP setting
Metrics	Per direction: Average Throughput (Mbps) from->to Loss (%) Total bytes lost
Advanced Information	This test combines UDP stream from E1 to E2 and from E2 to E1. The timing record per pair will be optimized to be one timing record per second. Note that performance of and endpoint sending and receiving is typically lower than endpoint dedicated to sending or receiving. We see typically 20 to 30% performance reduction when traffic is generated both ways as opposed to one way only.
Results interpretation	See UDPthroughput from-> to.
Potential Errors	See UDPthroughput from-> to.

	UDP throughput advanced
Description	UDP throughput between E1 and E2 with advanced parameter options.
Purpose	Send UDP packets (bit blasting) at defined rate to validate the capacity between endpoints in both directions. Advanced options allow to be more specific about what is required.
Available Options	Generated bitrate UDP send buffer size file size for timing record sockets size DSCP setting source/destination ports
Metrics	Throughput (Mbps) from->to Loss (%) from->to Total bytes lost to-->from
Advanced Information	This test will allow to fine tune the UDP stack according to some settings that are dedicated to the test; See Annex for complete UDP stack configuration documentation. Recommended value is filesize to be around 1 second of data transfer at expected throughput so in that case (factor 8 to take into account the bytes to bit ratio): filesize=thoughput (Mbps)*1000/8.
Results interpretation	See UDPthroughput from-> to.
Potential Errors	See UDPthroughput from-> to.

	Network Loss Performance
Description	Determines UDP loss quality metrics between two endpoints.
Purpose	Analyzes loss metrics for a UDP stream played in one direction.
Available Options	Target UDP throughput for one stream Test duration (sec) Specify which QOS (DSCP setting) to request between switches in network Packet size
Metrics	Metrics Loss (UDP bytes) Lost Datagrams (UDP packets) Max Loss burst Total Datagrams Rcvd Total Datagrams Sent
Advanced Information	Thresholds can be set for all above metrics.
Results interpretation	See Advanced Information.
Potential Errors	See XR2000 Error Description Guide.