Beeks Analytics for Markets uses certain abstracted higher-level configuration concepts to drive the creation of the lower-level configuration of the VMX-Capture and VMX-Analysis components.

Visibility Points

As mentioned in How is data captured? , Beeks Analytics for Markets has the concept of one or more Visibility Points. These are the points in your network at which traffic is observed and captured.

By providing a consistent framework that enables us to understand where in the network a particular analytics metric is recorded, we can reliably organise conversation endpoints into either an Internal Group or an External Group.

Grouping Conversation endpoints into Internal Groups and External Groups

The benefit of this kind of grouping is that is provides an easy reference point for understanding multiple wiretime metrics.

To take an example, consider the following set of metrics:

You might conclude that the volume of data from External Group A causes the loss to occur, perhaps by overwhelming the network connection of that particular Dedicated Server for a period of time.

Internal Groups and Internal Entities

A ‘group’ is just a collection of one or more IP addresses or network ranges. In this document, we typically refer to External Groups and Internal Entities, as often the internal entities are well understood and it is confusing to think of them as ‘groups’.

In a Proximity Cloud or Exchange Cloud deployment, each Internal Entity will be an individual Dedicated Server.

Switchport and IP Address Details for Internal and External Groups

Each Internal Group or External Group will be defined by one or more switchports, and each switchport has an IP address or IP network associated. Virtual (e.g. bonded, NAT IP addresses presented by network devices) interfaces can be defined as well as physical switchports.

The switchport aggregator level is useful if you want to synthetically create ‘per port’ traffic statistics from the data collected by Beeks Analytics (for example, where an external venue publishes multicast market data to you over multiple switchports, and you want to traffic the multicast statistics for each port independently). Where it isn’t important to collect this information, the switchport is normally recorded as ‘multi’, but other designations can be used in the configuration to assist with grouping Internal Entities or External Groups in different ways.

Beeks Analytics for Markets can breakdown traffic per switchport if these are defined correctly in the configuration.

External Group Details

In addition to the switchport and IP address/network details above, switchports for External Groups can have other information configured for them:

• Multicast IPs. These are defined by IP address. These allow extra UDP statistics to be calculated for each of these IP addresses. Not needed where the multicast address is part of a multicast data feed (see below).

• TCP Gateways. These are defined by IP address and by TCP ports/port ranges. These allow extra TCP statistics to be calculated for each of the gateways that are defined in this way.

• Trading Gateways. These are defined by IP address and by optional TCP ports/port ranges. A Trading Gateway will have decodable messages which will allow App-to-Wire latency and Order Latency calculations to be performed for it, in addition to the underlying TCP and IP metrics.

• Feeds. These are multicast market data feeds. A multicast feed will have decodable messages which will allow App-to-Wire latency and gap detection calculations to be performed for it, in addition to the underlying UDP and IP metrics.

About the Tx and Rx directions

With the Beeks Analytics for Markets template, Tx messages are sent from an Internal Entity to an External Entity. Rx messages are sent from an External Entity to an Internal Entity.