Internet Protocol (IP)
Beeks Analytics for Markets monitors all incoming or outgoing network data for this group's IP address, as seen at the visibility point. This includes any multicast subscription or publication.
The table below describes the timeseries metrics for the IP protocol in Aggregators for Beeks Analytics for Markets.
Metric name | Directions | Description |
|---|---|---|
Conversations | n/a | The number of IP pairs that are observed at this Visibility Point. |
Packets per second (pkt/s) | Tx or Rx | The rate at which IP data is being observed at the Visibility Point. The rate is calculated and recorded every 10 seconds. |
Bandwidth | Tx or Rx | The rate at which IP packets are being observed at the Visibility Point. Multicast data will only be included in the bandwidth for a particular Internal Entity if the Internal Entity is explicitly listed as a subscriber to that multicast group. For an External Group, the received rate will also include any multicast traffic sent to a multicast group which this entity is recorded to be publishing to. The rate is calculated and recorded every 10 seconds. |
Tx or Rx | The rate at which IP data is being sent by this entity, including network processing overhead (network protocol headers, retransmissions, etc). The microburst detection rate in Beeks Analytics is calculated using a configurable time window, referred to as microburst granularity. In Beeks Analytics for Markets this microburst granularity is set by default to 1 millisecond. The maximum microburst rate seen over each 10 second period is measured and recorded. |
Of the above, the ‘Conversations’ metric is not displayed in the Beeks Portal. The ‘Conversations’ metric for IP traffic is only available directly in Beeks Analytics.
These IP metrics are available in the following Aggregators:
Aggregator | Aggregator Levels |
|---|---|
IP Stats | /VP/ExtGroup:IntEntity |
IP DS Stats | /VP/Int Entity |
IP ExtGrp Stats | /VP/ExtGroup/Probe Name |
The Beeks Portal will display IP metrics per External Group or per Internal Entity, but cannot provide other breakdowns.
User Datagram Protocol (UDP)
Beeks Analytics for Markets monitors all incoming or outgoing network data that’s delivered using the UDP protocol, as seen at the visibility point. UDP is a connection-less protocol that does not confirm message delivery or ordering.
The table below describes the metrics for the UDP protocol in Aggregators for Beeks Analytics for Markets.
Metric name | Description |
|---|---|
Convs | A network conversation is traffic between two specific endpoints. In this case, a UDP conversation is all the traffic between two IP addresses on the same UDP ports. Note that messages do not need to be observed in both directions in order for it to be recorded as a conversation. |
Packets per second | See definition for IP above. |
Bandwidth | See definition for IP above. |
Microburst | See definition for IP above. |
Of the above, the ‘Packets per second' and ‘microburst’ metrics are displayed in the Beeks Portal. The other UDP metrics are only available directly in Beeks Analytics.
These UDP metrics are available in the UDP Stats Aggregator, which has the levels /VP/ExtGroup/Switchport.
UDP metrics are only recorded in one direction - received (i.e. Rx) from External Groups - see Beeks Analytics for Markets Configuration Template for more detail.
Dashboards for viewing IP and UDP Metrics
Within VMX-Explorer for a Beeks Analytics for Markets deployment, the above IP and UDP Aggregators are most commonly viewed within the Traffic Stats set of dashboards. An example Traffic Stats dashboard and associated navigation is described in the User Guide for VMX-Explorer.
Microburst granularity in Beeks Analytics
The most common miroburst granularity used within Beeks Analytics is 1ms. However, multiple other microburst granularities are recorded as standard and are made available. These other microburst windows are:
1ms
10ms
100ms
1 second
Beeks Analytics is flexible if different microburst calculation measurements are required. Beeks Analytics supports custom microburst windows - the minimum configurable microburst granularity is 1 nanosecond.
However, in practice, windows smaller than a few microseconds are generally not meaningful for detecting microbursts.
Beeks Analytics supports custom microburst windows - the minimum configurable microburst granularity is 1 nanosecond.
However, in practice, windows smaller than a few microseconds are generally not meaningful for detecting microbursts.
This is due to physical limits such as serialization delay—the time it takes to transmit a packet onto the wire.
For example, transmitting a 1,500-byte packet at 10 Gbps takes roughly 1.2 microseconds. At 100 Gbps, it’s still about 120 nanoseconds. So a 1 ns measurement window may show zero or full utilization depending on whether it captures even a fraction of a single frame—making the data too volatile or misleading for practical use.
Different time windows (granularities) are better suited to different networking use cases. Here’s a table showing how various microburst measurement windows (granularity) relate to common network monitoring goals, including link utilization, buffer impact, and latency sensitivity:
Granularity | Typical Use Case | Strengths | Limitations | Example Scenario |
|---|---|---|---|---|
>10 ms | Long-term link utilization, SNMP counters | Low noise, good for trending | Too coarse to detect short bursts or latency spikes | Monitoring 5-minute interface utilization |
50-100 ms | Long-term link utilization where early detection of sustained increases in traffic | Smooths out micro-spikes to reveal persistent increases in usage | Too coarse for detecting microbursts or short-term buffering/latency impacts | Forecasting WAN links used by market data. Can help with capacity planning and proactive QoS adjustments. |
1–10 ms | General microburst detection, switch buffer pressure | Captures common burst durations, manageable data volume | May miss very short spikes | Detecting bursts impacting trading or storage systems |
100–999 µs | High-frequency trading (HFT), latency-sensitive buffering | Sensitive to short-lived bursts, good for edge congestion | More data to store/process; may still miss packet-level bursts | Diagnosing packet drops on NIC queues |
10–99 µs | Packet-level burst visibility, buffer tuning | Matches typical packet inter-arrival times at high speed | High resolution needed, risk of "overreacting" to noise | Analyzing jitter in multicast market data |
1–9 µs | NIC-level buffering, serialization-level analysis | Extremely precise, shows intra-packet timing variation | Requires extremely accurate timestamps, can be noisy | Tuning hardware interrupt coalescing |
<1 µs (e.g. 1 ns) | Research/debugging, wire-speed edge timing | Shows maximum theoretical precision | Not meaningful for burst analysis; single packet dominates view | Debugging timing on FPGA-based network stacks. |
Key Concepts:
Serialization delay: Affects how meaningful very short windows are. For example, a full Ethernet frame at 10 Gbps takes ~1.2 µs to transmit—shorter windows might capture only part of a packet.
Buffering behavior: Buffers work over microsecond timeframes, so granularity of 10–1000 µs is typically best for correlating with packet drops.
Utilization smoothing: Windows longer than 10 ms average out spikes, useful for trending but not suitable for burst detection.