2.20.2   (2023-04-03)

Fixes

When the Scenario Heartbeat interval was set after Prepare() was executed on

an Endpoint, the new Scenario Heartbeat interval value was not propagated to the Endpoint.

The MeetingPoint could mark an Endpoint as "unavailable" when a test longer

than 1 minute was running.

This could lead to the ByteBlower GUI stopping a scenario while the test was

(rightfully) still running

2.20.0   (2023-02-27)

New features 

• The server now provides latency histograms over time when using the latency distribution trigger. This allows to have latency histograms per configured measurement interval.   
  This feature is useful when measuring the QeD performance of a specific flow. 

Enhancements 

• The TPID (EtherType) of a VLAN tag can now be configured through the API. 
• Faster filtering for traffic containing multiple VLAN tags. 
• The ByteBlower 2100 and ByteBlower 4100 server series did not support 4 stacked VLAN tags as the other series did.  Now all systems have the same limit. 
• The MeetingPoint will now automatically query the ByteBlower Endpoint for the test results when the Endpoint returns after a test. 
• The MeetingPoint needed up to 5 seconds for initial registration of an Endpoint.  The MeetingPoint now temporarily lowers the communication interval so this procedure finishes earlier. 

• The MeetingPoint tagged unverified ByteBlower Endpoint platforms as “Unsupported”.  The tag is renamed to “Unverified”, which means Excentis did not have tested this platform. 

Bugs fixed 

• The MeetingPoint stopped accepting API calls when an “Unavailable” ByteBlower Endpoint was addressed.  This did not only influence the calling test, but also effected other tests and users with “Available” Endpoints.  The only remedy for this was restarting the ByteBlower MeetingPoint service on the ByteBlower server. 

For users of the API, it is important to note that the next major server release 2.21 will also require the API to be updated to 2.21

in order to use out-of-sequence detection. Upcoming changes in the server will make OoS detection incompatible with the current API.

In 2020, the decision was taken by the Python community to stop support for Python 2.x versions.

However, in order to make life easier for some of our customers,  we have continued supporting Python 2.7 for API users who may have chosen not to upgrade their Python environments.

However, we will stop supporting Python 2.7 after the next API release.

We are discontinuing support because it has now been three years since Python ended support for this version which means that most users have moved away from Python 2.x.

This will better help us develop and improve the Python API.

If you have any questions about this, please contact us at support.byteblower@excentis.com

We would like to inform our customers that ByteBlower 2100 and 4100 servers are no longer available.

This was decided due to declining interest in these systems and the alternative systems (5000 & 3000 series) we provide.

Even though they are no longer available for purchase we understand that some of our customers still use these systems, and therefore we will continue support until the end of 2024.

This means all software features that are released in this period will apply to both systems as well as the other series in our range.

If you have any questions about this, please contact us at support.byteblower@excentis.com 

2.20.0  (2023-02-14)

Enhancements:

Increased robustness of RFC-2544 for WEP​

• ​RFC2544 is a widely known benchmark. The ByteBlower GUI implements the throughput measurement.
• In the past, tests would more likely fail due to the stress the test places on the network.
• RFC-2544 places a heavy load on the system. For fail-safe tests it’s recommended to add route the WEP mgmt. traffic over a different interface like e.g., the golden client.

UI improvements in the ByteBlower server updater. 

When errors happen resuting in failed tests, we have implemented improved logging which makes the feedback of the server more visible.

• Improved logging of error-cases from the ByteBlower Server.​
• More efficient debugging as as a result.
• Some examples of error messages​
  • Code​
  • Improper license​
  • Broken updater that was fixed in later releases.

Improved default TCP setting.

• New default value for TCP Slow Start Threshold: 2147483647 (=Integer.MAX_VALUE) (=infinite). The old default was 65535 (=0xFFFF).
• OS behaviour is closer to infinite value.

​

CCDF Graph

An empty CCDF graph is now drawn in the ByteBlower report when all packets are below the latency measurement range. This can happen due to negative latencies of a Wireless Endpoint. See also our Golden client KB article to perform such tests. 

Changelog for 2.20.0 

New features 

• Adding latency histograms over time.  This can be used to visualise/verify the QeD performance of a specific application. 

Enhancements 

• Adding additional frameblasting interval statistics such as : 

• When was the first frame sent or received 
• When was time last frame sent or received 
• Minimum and maximum size of the frames received 

• Better latency measurements for cumulative snapshots.   
  The Endpoint now keeps track of the cumulative data itself instead of delegating this to the MeetingPoint. 

Fixes 

• Fixing crashes when a management/traffic interface was selected, but no IP address was available. 

Server 2.19.0 (20/10/2022)

Highlights

• 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.

Improvements

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

Fixes

• 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.

Misc

• 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)

Download

You can download the latest version at https://setup.byteblower.com/software.html.

Enhancements

• 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.

Fixes

• 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: https://setup.byteblower.com/wirelessendpoints.html 

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

Changelog 2.19.0 (20/10/2022)

Highlights

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.

Improvements

• 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

• ByteBlower Wireless Endpoint 2.16
• ByteBlower Wireless Endpoint 2.14
• ByteBlower Wireless Endpoint 2.13
• ByteBlower Wireless Endpoint 2.12

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

• Install homebrew with following one-liner. More steps will be listed as the installer proceeds.
  /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

• Next, install Chrony
brew install chrony

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
chronyd

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.