Knowledge base

ByteBlower GUI 2.19.0

Cancelable ByteBlower Endpoints

ByteBlower Endpoints used to go into "Silent Mode" while a test scenario was running. Not anymore! You can now configure the scenario heartbeat interval, and maintain connectivity with each Wireless Endpoint: 

This new feature will allow you to cancel a test without needing to stop the BEP app manually. This is very useful when working remotely and executing longer test durations!

Changelog 2.19.0

  • Added more TCP Roundtrip statistics in the HTML, CSV and JSON report. New values include the average latency and Time To First Byte (TTFB). More information about these metrics is on our support website.
  • The GUI has more accurate TCP graphs by using the average TCP RTT instead of a sampled value.
  • The size of the FrameBlasting frame can now be changed immediately from the size column at the left side of the Frame View.
  • To make it easier to get started immediately, ByteBlower Systems are now refreshed on startup. This happens in the background.
  • Small UI improvements in the Frame Blasting View to make it more visible where to edit the FrameBlasting settings.
  • You can now immediately start a PCAP capture when launching a test-run.
  • Tests with Wireless Endpoints are now cancelable using the GUI. No need to push the "Abort" button anymore on each Wireless Endpoint.
  • The CLT return values have been updated and documented.
  • In the report graphs, the RSSI axis does not show decimals anymore.
  • RSSI information has been added to the CSV report.
  • The GUI became unresponsive when setting big Frame Repeat values.
Bug fixes
  • JSON reports of tests canceled during the configuration phase had a nullpointer exception in the background.

Server 2.19.0 (20/10/2022)


  • The ByteBlower MeetingPoint now supports stopping a ByteBlower Endpoint from the ByteBlower API or ByteBlower GUI. 
    This feature allows the user to stop a ByteBlower Endpoint app in a way it was already possible with a classic ByteBlower Port.

New Features

  • Adding support for ByteBlower Endpoints who keep communicating during the test.
  • Adding support to stop a ByteBlower Endpoint during the test.  In order for this feature to work, the ByteBlower API or ByteBlower GUI must be configured so the ByteBlower Endpoint keeps communicating during the test.  This feature requires a ByteBlower API or ByteBlower GUI updated to version 2.19.0 or higher and a ByteBlower Endpoint running at least 2.19.0.


  • Adding iPadOS 15 as a supported platform.
    Note: In order not to break existing scripts, iPadOS is announced as iOS towards the customer.


  • The ByteBlower MeetingPoint could crash when a ByteBlower API disconnected when a ByteBlower Endpoint was executing specific API calls. 
    These calls are used when:
    • Preparing a ByteBlower Endpoint for test execution
    • Starting a test on a ByteBlower Endpoint
    • Gathering results for an executed test.


  • The ByteBlower 5100 Linux kernel is updated from Debian version 4.19.0-18 to 2.19.0-21
  • The ByteBlower 3100 and ByteBlower 3200 server network interface drivers are updated so they don't lose network connectivity under high traffic loads.
  • The ByteBlower 5100 system can now update the firmware for the used traffic interfaces.

Changelog 2.19.0 (20/10/2022)


You can download the latest version at


    • The API now allows the user to configure continuous communication between the ByteBlower Endpoint and ByteBlower MeetingPoint.  Therefore 2 new methods are added to the WirelessEndpoint object:
      • ScenarioHeartbeatIntervalGet() which allows to read the currently configured Scenario Heartbeat interval.
      • ScenarioHeartbeatIntervalSet(nanoseconds) which allows to set the interval on which the ByteBlower Endpoint should try to communicate with the ByteBlower MeetingPoint.
        A value of 0 disables continuous communication between the ByteBlower Endpoint and the ByteBlower MeetingPoint, which is the behaviour as per pre 2.19.0.
    • The API can now stop a running test on the ByteBlower Endpoint. 
      Therefore one new method is added to the WirelessEndpoint object:
      • Stop().
        In order for this feature to work, the ScenarioHeartbeatInterval parameter must be set to a value other than 0 (disabled) and the ByteBlower Endpoint and ByteBlower MeetingPoint must be running software version 2.19.0 or higher.


    • The ByteBlower TCL API did not have Scenario.Duration.Set method available on the WirelessEndpoint object.

    Changelog for ByteBlower Endpoint 2.19

    The ByteBlower Endpoint can be downloaded through our setup pages: 

    For Android, iOS and iPadOS, the app is also available through their respective app stores.

    Changelog 2.19.0 (20/10/2022)


    The ByteBlower Endpoint can now be stopped from the ByteBlower GUI and the ByteBlower API.  
    This feature allows the user to stop the ByteBlower Endpoint from the GUI the way it was already possible to stop a ByteBlower Port mid-test.  This new addition can be particularly useful if a longer duration test has been configured and needs to be terminated for any reason.

    This feature requires a ByteBlower Server updated to ByteBlower 2.19.0 and a ByteBlower GUI on version 2.19.0.

    New features

    • The ByteBlower Endpoint can now continue communicating with the ByteBlower MeetingPoint during the test.  When enabled, this allows the user to stop the ByteBlower Endpoint through the ByteBlower API or the ByteBlower GUI when running a test.  A future use-case for this continuous communication is getting real-time results while the ByteBlower Endpoint test is running.
    • Allowing the ByteBlower Endpoint to receive a stop command through the API.  Stopping the ByteBlower Endpoint through the API triggers the same behaviour as hitting the "Abort" button on the ByteBlower Endpoint user interface.
    • Allowing the user to configure a dedicated management interface.  This interface will be used for all communication with the ByteBlower MeetingPoint and allows out-of-band communication with the ByteBlower MeetingPoint.


    • The ByteBlower Endpoint settings are now available through the very recognizable cog-wheel on the top-right of the start page. 
    • The MeetingPoint information on the main page is now provided when available, no need to hit that Refresh link anymore.
    • Adding support for Debian 11 (Bullseye) and Ubuntu 22.04 (Jammy) as a platform to run the ByteBlower Endpoint on.

    Bug Fixes

    • When using a dedicated traffic interface or dedicated management interface, the ByteBlower Endpoint could use the wrong local IPv6 address to reach the other side. 

    Older versions


    This article is intended for those working towards highly accurate latency measurements. For purely functional or even throughput tests, the default macOS configuration is sufficient.

    Step 1 disable OS-default time sync

    The screen below is reachable from the Settings dialog. Disable "Set date and time automatically". This functionality will be done by Chrony.

    Step 2 Install and configure software

    We recommend installing Chrony from homebrew. This is a more modern NTP application that incorporates advanced synchronization methods that work better compared to the default ones.

    To get started, install

    Next configure chrony. To this end create the file  /etc/chrony.conf with following contents.

    server <NTP server address> maxpoll 6 iburst

    Starting chrony goes as follows.

    mkdir /var/run/chrony

    The following command allows to check whether the time-sync works:

    excentis@macos-bigsur-m1-1 ~ % chronyc sources
    MS Name/IP address         Stratum Poll Reach LastRx Last sample
    ^* debian.lab.byteblower.ex>     2   6   377    59    -22us[  -25us] +/-  495us

    The '^*' indicates that the server has been selected as time references. The following statiscs provide more info of the last time sync. 

    Starting Wireless Endpoint

    The Wireless Endpoint can be used in the same way as before.

    The latest binaries are available on the setup pages.

    Caveats and Expected performance

    • Avoid using the Wired interface for test traffic.
      Large network loads on this interface introduce delays and make the time-synchronization more difficult.
    • macOS is not a realtime operating system. The OS occasionally adds large (40ms +) delays.

    Setup Overview

    This article focuses on the ideal setup to measure the latency of a network. More so than functional or even throughput testing, this type of test requires special care for proper time synchronization between a ByteBlower Endpoint and ByteBlower server.

    To ensure this sync, we recommend the setup as shown in the picture below. From left to right we see the "ByteBlower Server", the device under test (a Wi-Fi Access Point) and the ByteBlower Endpoint ('Golden Client'). The network switch at the bottom of the image is used only to connect the management interfaces.

    Two types of network traffic flow through this setup

    • The test-traffic is shown in blue. It is send between between ByteBlower server and Golden client. This traffic loads the device under test.

    • The management traffic is shown in black. This traffic goes over a separate interfaces and is Wired Ethernet. As shown in image, ideally a single switch ties everything together.

    In the above image, both the ByteBlower server and Golden Client are synchronized to a common reference clock. This enables accurate latency measurements.

    The Golden client

    The golden client is the reference system for performing latency measurements with the Wireless Endpoint. In the sections below describe how to install Linux, Wireless Endpoints and configure the PTP-timesync.

    Installing the OS

    Just like the Time synchronization system, Debian is chosen as base OS for the Golden client. It's a popular Linux distribution with a long history that will stay relevant for the time being. The guide below has been tested on Debian 10.

    The ISO image for the Linux installer is available from the link below. A common approach is to copy this binary on onto a USB stick and create boot from this USB stick. Several tools are available for performing this step, balena is one that is available on a large number of platforms.

    This Low latency WEP client does not require a desktop environment. If you’re comfortable with managing such a headless system, the desktop can be omitted. For Intel NUC platform both headless and desktop should work well, no large performance differences are expected.

    Installing the Wireless Endpoint

    The wireless Endpoint is available in the Excentis repository. Adding this repository to the system makes it keep the application up to date. The steps below add this repository to the system and next install the software.

    # Add our Excentis Repository to the system.
    wget -qO - | sudo apt-key add - 
    sudo add-apt-repository "deb [arch=amd64] $(lsb_release -cs) main"
    # Finally install the Wireless Endpoint
    sudo apt-get update
    sudo apt-get install byteblower-wireless-endpoint

    WEP configuration

    The following configuration launches the Wireless Endpoint immediately at startup. It defines a systemd service. The contents should be saved to following file

    • /etc/systemd/user/byteblower_wep.service
    Description=Sync the Clock on the NIC to improve PTP accuracy
    ExecStart=byteblower-wireless-endpoint -t <Wi-Fi NIC> <MeetingPoint address>

    The above configuration uses two parameters that depend on the actual configuration:

    • The name of the Wi-Fi network interface, for example wlo1. The name can be found with the command ip link.
    • The network address of the MeetingPoint.

    After saving the above file, the service is enabled with the following command. This is ensures that the Wireless Endpoint is launched on each subsequent startup.

    • systemd enable byteblower_wep.service

    Since the Wireless Endpoint runs in the background, no GUI is launched. To see the current status, you can either of the following command:

    • systemctl status byteblower_wep
    • journalctl --unit=byteblower_wep --since "1 hour"

    The top command prints out the current status, the bottom one show the log messages of the last hour.

    PTP on Golden client

    As detailed at the start, it is important for the ByteBlower server and Wireless Endpoint to be synchronized to the same time-reference. On local networks one can use the Precision-Time-Protocol. This offers the most reliable time-sync.

    To configure PTP on Linux, following two packages are required.

    • sudo apt install linuxptp chrony

    LinuxPTP takes care of the PTP configuration. Chrony organizes the overall time synchronization. In case when the PTP clock becomes unavailable it will fall back to other time sources.

    Configuring the timesync software

    The timesync is configured in the following file. It needs to be edited as a root user.

    • /etc/linuxptp/timemaster.conf
    # Configuration file for timemaster
    [ntp_server ntp-server.local]
    minpoll 4
    maxpoll 4
    [ptp_domain 5]
    interfaces enp0s3
    ntp_program chronyd
    include /etc/chrony/chrony.conf
    path /usr/sbin/chronyd
    path /usr/sbin/phc2sys
    path /usr/sbin/ptp4l

    The above configuration has two important configuration parameters:

    • The name of the Wired network interface (NIC) to use for the PTP time synchronization. In the above example uses enp0s3. Like for the Wi-Fi NIC, the name is found with ip link.
    • The domain of the PTP clock. The example uses domain 5. This is configuration value, it depends on the time-synchronzation setup in the lab.

    This timesmaster is enabled with systemctl enable timemaster.

    When all goes well, systemctl status timemaster should display the following information.

    root@goldenclient:/home/excentis# systemctl status timemaster
    ● timemaster.service - Synchronize system clock to NTP and PTP time sources
         Loaded: loaded (/lib/systemd/system/timemaster.service; enabled; vendor preset: enabled)
         Active: active (running) since Fri 2022-09-16 18:00:26 CEST; 1s ago
           Docs: man:timemaster
       Main PID: 1196 (timemaster)
          Tasks: 4 (limit: 18710)
         Memory: 1.4M
            CPU: 11ms
         CGroup: /system.slice/timemaster.service
                 ├─1196 /usr/sbin/timemaster -f /etc/linuxptp/timemaster.conf
                 ├─1197 /usr/sbin/chronyd -n -f /var/run/timemaster/chrony.conf
                 ├─1198 /usr/sbin/ptp4l -l 5 -f /var/run/timemaster/ptp4l.0.conf -H -i enp2s0
                 └─1199 /usr/sbin/phc2sys -l 5 -a -r -R 1.00 -z /var/run/timemaster/ptp4l.0.socket -t [6:enp2s0] -n 6 -E ntpshm -M 0
    sep 16 18:00:26 goldenclient timemaster[1196]: [270.829] process 1197 started: /usr/sbin/chronyd -n -f /var/run/timemaster/chrony.conf
    sep 16 18:00:27 goldenclient ptp4l[1198]: [272.255] [6:enp2s0] port 1: new foreign master ecf4bb.fffe.426fea-1

    In addition to the above, more information about the actual timesync is available with chronyc.

    root@goldenclient:/home/excentis# chronyc sources
    MS Name/IP address         Stratum Poll Reach LastRx Last sample
    #* PTP0                          0   2   377     5    +42ns[  +69ns] +/-   50us

    Example Test results

    The results below show example results attainable with the Wireless Endpoint and a proper Time Synchronization master. It contains the latency results between the same two hosts, Golden Client to a ByteBlower 4100, but over different media

    • The top graph show traffic over the Wi-Fi link. At regular intervals the network traffic experiences high latencies.
    • The bottom graph is the wired Ethernet link. It demonstrates a well-performing golden client operating in a minimal delay network. Typical latency accuracy is well below 1 ms.

    Creating a Time-synchronization master

    This article is written for those interested in latency, especially those using the Wireless Endpoint or across multiple ByteBlower Servers. The quality of the latency measurements strongly depends on having a high-quality time reference.

    This is especially visible in the one-way latency measurements of ByteBlower server and Wireless Endpoint. Yet this tool provides invaluable information on network under test. With FrameBlasting you receive throughput and latency information for each direction and for each traffic-flow.

    • This makes any asymmetry in either direction clearly visible.
    • It allows you to evaluate the active queue management (AQM) behaviour.
    • With sufficient Endpoints, individual hops can be characterized.

    Yet measuring such latency values across distributed setups poses a particular challenge. To this end this text explains how to set up a qualitative time synchronization that solves these difficulties.

    Why time-synchronization for latency measurements?

    Latency of the traffic is the time-interval between transmitting the packet and next receiving somewhere else. Measuring this duration requires a sufficient fine timestamp to of each. In case of a single system, with a single clock, this calculation is straightforward. It is in shown in the picture below.

    The time-axis at the center represents the clock on the ByteBlower Server. The packet is transmitted at the left side of the figure, it passes through the “Network under Test” and is received further down the time-axis.