8. General Test Configuration Panel

This panel controls the test options that are common for all tests. The various sections in the panel are described below.

../_images/general_test_config_panel.png

Fig. 8.1 General Test Configuration Panel

8.1. Frame Sizes

This section allows you to specify the frame sizes to be used by the various tests. The available frame size options are divided into two groups, the Fixed Sizes Per Trial and the Varying Sizes Per Trial.

As the name indicates the Fixed Sizes Per Trial group uses a single frame size per trial. It is possible to specify multiple frame sizes which will cause the test to be repeated for each frame size. The Varying Sizes Per Trial group will use many frame sizes for each trial. This is controlled by the hardware.

Note

Note that when calculating bit rates the average frame size will be used.

Note

Also note that the Errored Frames Filtering test will not used the frame size setting as it uses its own frame size setup as part of the test.

8.2. Overall Test Port Rate

This section allow you to specify the overall rate used by the tests. You can specify the rate using one of the following methods:

  • A fraction (percentage) of the physical port speed

  • A frame-rate (Fps) value

  • A bit-rate (Bps) value at either layer 1 or layer 2.

Below the controls you can see the resulting percentages or rates for all selected port types.

Note

Note that the Address Caching Capacity and Address Learning Rate tests do not use the overall test port rate as they utilize their own rate definition. The Congestion Control and Forward Pressure tests also do not use the overall test port rate as these tests are always performed at port line speed.

8.3. Misc. Options

  • Use Micro-TPLD if needed

    The normal Xena test payload (TPLD) section takes up 20 bytes and is used for various purposes, such as latency measurements, loss and misordering monitoring, payload integrity, etc. Due to this test payload it may be impossible to make room for protocol headers such as IPv4+UDP for smaller frame sizes (e.g. ~64 byte).

    By enabling this option you permit Xena2889 to use the smaller micro-TPLD if needed by the current frame size. The consequence of this will be that realtime monitoring of packet loss is no longer possible.

    Note that Xena2889 will only use the micro-TPLD for a test run if the current frame size requires it. If you for instance use the default IEEE packet size distribution you may encounter that the micro-TPLD is only used for 64 byte packets but not for the other packet sizes.

  • TID Alloc.Scope

    Determines how Xena2889 allocates test payload identifier (TID) values.

    • Configuration Scope: Allocates a unique TID value for each stream created. This option ensures that only packets intended for a given port is taken into account. The downside is that for large configurations you may quickly run out of TID values due to hardware constraints.

    • Rx Port Scope: Allocate TIDs so that all streams received on any given port have a unique TID. TID values are reused between ports. This allow for larger configurations but the test is no longer able to detect if packets are mis-delivered by the DUT.

    • Source Port ID: Allocate TIDs so that all streams from a given port is set equal to the port index in the configuration. This is a slight variation of the previous method.

  • Latency Mode

    Specifies the way the latency value is calculated. Refer to the description of P_LATENCYMODE in the CLI document for a description of the various values.

  • Toggle Sync State

    If checked the sync state for all selected ports will be toggled off and on at the start of each test trial. This is done to ensure that the DUTs MAC-tables are cleared at the start of each test.

    Note that the Address Caching Capacity and Address Learning Rate tests do not use this option as they use their own definition.

  • Sync State Off Period

    The number of seconds to keep the port sync state off.

  • Delay After Sync On

    Defines how long time Xena2889 will wait after the reset before it continues with the test.

8.4. Port Scheduling

If the Use Port Sync. Start option is checked the Start button will activate a synchronized port start mechanism for the ports - if the chassis firmware version supports this feature.

The Port Stagger Steps property delays start of traffic generation on one port relative to pressing Start button. The delay is programmed in steps of 64 microseconds. The Port Stagger function works between ports on test modules installed in the same chassis.

  • The 1st port will not be delayed.

  • The 2nd port will be delayed with the Port Stagger Steps.

  • The 3rd port will be delayed with the Port Stagger Steps * 2.

  • The 4th port will be delayed with the Port Stagger Steps * 3 etc.

The maximum value of Port Stagger Steps for a port is 31250. Therefore the programmed Port Stagger Steps must not exceed 31250/(number of ports).

Note

This requires that Use Port Sync. Start has been checked.

The Resulting Delta is Port Stagger Steps * 64 microseconds

Important

Please observe that on Z800 module (Freya), you will need to uncheck the Use Port Sync. Start box to get Xena2889 to complete.

8.5. Reset and Error Handling

If Stop on LOS is enabled, Xena2544 will abort the test if a port loses the sync state during test.

When a Xena2544 test is started, the selected ports will be reset to ensure a known starting point for the test. The Delay After Reset parameter defines how long time Xena2544 will wait after the reset before it continues with the test.

If Port Reset is enabled, Xena2544 will reset the test ports when starting the test.