> For the complete documentation index, see [llms.txt](https://documentation.2pintsoftware.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.2pintsoftware.com/stifler/3.1/operations-and-features/bandwidth-management/bandwidth-tuning-monitoring-and-control.md).
# Bandwidth tuning monitoring and control
## Overview
### Bandwidth Tuning
StifleR continuously monitors network conditions and can dynamically adjust client download bandwidth to maximize performance while minimizing the impact on other network traffic. Rather than relying on fixed bandwidth limits, Bandwidth Tuning allows StifleR to react to changing network conditions, ensuring that available bandwidth is used efficiently without degrading the user experience.
Bandwidth Tuning can respond to several network conditions, including increased latency, unusually low or high bandwidth utilization, LEDBAT-enabled content servers, and measured network capacity obtained through the StifleR Beacon. Depending on the selected configuration, StifleR can automatically increase or decrease client bandwidth to maintain optimal performance.
### Configuration Scope
Bandwidth Tuning is configured at two levels:
* **Server level** - Defines which Bandwidth Tuning features are available globally. These settings are configured using the **StifleR Config Editor**.
* **Network Group level** - Determines which of the globally enabled features apply to a specific Network Group. These settings are configured from the **StifleR Dashboard**.
A feature must be enabled at both levels before it becomes active for a Network Group.
### Available Bandwidth Tuning Features
The following Bandwidth Tuning options are available:
| Feature | Description |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Latency** | Monitors network latency and adjusts bandwidth when the configured latency threshold is exceeded or returns to normal. |
| **LowBandwidth** | Detects when bandwidth utilization is significantly below the configured target and attempts to increase throughput. |
| **HighBandwidth** | Detects when bandwidth utilization exceeds the configured target, typically indicating that bandwidth throttling is not being applied correctly. |
| **LEDBAT** | Enables LEDBAT++ congestion control, allowing higher bandwidth utilization while automatically yielding to higher priority network traffic. |
| **Beacon Measurement** | Uses the StifleR Beacon and iPerf3 to periodically measure the maximum available bandwidth for a Network Group and use that value when calculating bandwidth limits. |
By default, the StifleR Server enables **Latency**, **LEDBAT**, and **Beacon Measurement**.
### Bandwidth Tuning Values
Internally, StifleR stores Bandwidth Tuning options as bit flags, allowing multiple features to be enabled simultaneously.
| Feature | Value |
| ------------------ | ----- |
| Latency | 1 |
| LowBandwidth | 2 |
| HighBandwidth | 4 |
| LEDBAT | 8 |
| Beacon Measurement | 16 |
The values are additive. For example:
* **7** enables **Latency**, **LowBandwidth**, and **HighBandwidth** (1 + 2 + 4).
* **25** enables **Latency**, **LEDBAT**, and **Beacon Measurement** (1 + 8 + 16), which is the default server configuration.
The same values are used when configuring individual Network Groups. A feature must be enabled both globally and for the Network Group before StifleR applies it.
### Event Logging
Whenever a Bandwidth Tuning feature adjusts bandwidth or detects that a configured threshold has been exceeded, StifleR records the event in the Windows Event Log. These events can be used to verify that Bandwidth Tuning is functioning as expected and to assist with troubleshooting network performance.
***
## Latency Detection
Latency Detection allows StifleR to dynamically adjust client download bandwidth based on the network latency between the client and the download source. This helps maximize available bandwidth while preventing download traffic from negatively impacting interactive applications or other business-critical network traffic.
StifleR continuously measures the round-trip time (RTT) using ICMP ping requests. If the content source is located on the internal network, latency is measured directly to that server. For Internet-based content sources, latency is measured to the StifleR Server instead.
When the measured latency exceeds the configured **Latency Threshold**, StifleR gradually reduces the available download bandwidth. Once latency returns below the threshold for the configured recovery period, bandwidth is increased incrementally until the configured target bandwidth is reached.
### Configuration
To use Latency Detection:
1. Enable **Latency** in the server-level **Bandwidth Tuning** configuration.
2. Enable **Latency** for the required Network Group.
3. Configure the following Network Group settings:
* **TargetBandwidth** - The maximum bandwidth available to clients in the Network Group.
* **LatencyThreshold** - The latency value, in milliseconds, that triggers bandwidth adjustment.
Only when all three conditions are met will StifleR automatically tune bandwidth based on network latency.
### How Bandwidth Adjustment Works
Latency Detection does not immediately switch between bandwidth values. Instead, StifleR gradually adjusts the configured bandwidth to avoid sudden fluctuations in network utilization.
The rate at which bandwidth increases or decreases is controlled by several server configuration settings, including:
| Setting | Description |
| ---------------------------------- | ------------------------------------------------------------------------------------------- |
| **LatencyWarningDecreaseDuration** | Time that latency must remain above the configured threshold before bandwidth is reduced. |
| **LatencyWarningDecreaseFactor** | Controls how aggressively bandwidth is reduced when the threshold is exceeded. |
| **LatencyWarningIncreaseDuration** | Time that latency must remain below the threshold before bandwidth begins increasing again. |
| **LatencyWarningIncreaseFactor** | Controls how quickly bandwidth is restored toward the configured target. |
These settings are configured on the StifleR Server and apply globally to all Network Groups using Latency Detection.
### Example
The following example enables Latency Detection for a Network Group:
* **TargetBandwidth:** 700 Kbps
* **LatencyThreshold:** 70 ms
If the measured latency exceeds **70 ms**, StifleR begins reducing client bandwidth according to the configured decrease settings. Once latency remains below **70 ms** for the configured recovery period, bandwidth is gradually increased until the configured **TargetBandwidth** is reached.
This adaptive approach allows clients to make efficient use of available bandwidth while automatically responding to changing network conditions.
### WMI Configuration Example
The following commands configure a Network Group with a target bandwidth of **700 Kbps**, enable **Latency Detection**, and set the latency threshold to **70 milliseconds**.
```
wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set TargetBandwidth=700wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set BandwidthTuning=1wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set LatencyThreshold=70
```
Alternatively, the same settings can be configured from the **StifleR Dashboard**, which is the recommended approach for day-to-day administration.
***
## Low Bandwidth Detection
Low Bandwidth Detection monitors download throughput and identifies situations where clients consistently use significantly less bandwidth than the configured target. This can indicate that bandwidth is being unnecessarily restricted or that another component in the environment is limiting download performance.
Unlike Latency Detection, which responds to network conditions, Low Bandwidth Detection focuses on underutilization. When the measured bandwidth remains below the configured threshold, StifleR can automatically increase the available bandwidth in an attempt to achieve the desired throughput.
### Configuration
To enable Low Bandwidth Detection:
1. Enable **LowBandwidth** in the server-level **Bandwidth Tuning** configuration.
2. Enable **LowBandwidth** for the required Network Group.
3. Configure the **LowBandwidthThreshold** value for the Network Group.
Once enabled, StifleR continuously compares the current download throughput against the configured threshold and adjusts bandwidth when appropriate.
### Common Causes
Low Bandwidth Detection is most useful for identifying environments where download performance is lower than expected despite sufficient network capacity. Common causes include:
* Bandwidth limits configured too conservatively
* Server-side throttling
* Quality of Service (QoS) policies
* Misconfigured Group Policy settings
* External network restrictions
* Other infrastructure components limiting throughput
If Latency Detection is not reporting increased latency while Low Bandwidth Detection continues to trigger, the issue is typically related to configuration or infrastructure rather than network congestion.
### Recommendations
Low Bandwidth Detection should be thoroughly tested before being deployed in production environments. Increasing bandwidth too aggressively can lead to higher network utilization than intended, particularly on slower or shared links.
When used together with **Latency Detection**, StifleR can safely increase bandwidth when the network has available capacity while automatically reducing it if latency begins to rise. This combination generally provides more predictable results than using Low Bandwidth Detection on its own.
### Monitoring
Whenever the configured low bandwidth threshold is exceeded, StifleR records the event in the Windows Event Log. These events can be used to verify that bandwidth tuning is functioning correctly and to identify locations where download performance may be limited by external factors.
***
## High Bandwidth Detection
High Bandwidth Detection monitors download throughput and identifies situations where clients consume more bandwidth than the configured target. This typically indicates that the expected bandwidth limits are not being applied correctly, allowing clients to exceed the intended network usage.
Unlike Low Bandwidth Detection, which identifies underutilization, High Bandwidth Detection focuses on protecting the network by detecting unexpected increases in bandwidth consumption.
### Configuration
To enable High Bandwidth Detection:
1. Enable **HighBandwidth** in the server-level **Bandwidth Tuning** configuration.
2. Enable **HighBandwidth** for the required Network Group.
3. Configure the **HighBandwidthThreshold** value for the Network Group.
When enabled, StifleR continuously compares the current download throughput against the configured threshold. If the threshold is exceeded, the event is recorded and StifleR can adjust bandwidth according to the configured tuning settings.
### Common Causes
High Bandwidth Detection is primarily intended as a diagnostic feature. If clients consistently exceed the configured bandwidth target, it is usually an indication that bandwidth management is not functioning as expected.
Common causes include:
* Conflicting Group Policy settings
* Incorrect or missing BITS policies
* Insufficient permissions preventing policy application
* BITS policy corruption
* Inconsistent Windows updates or known BITS issues
* Other configuration issues preventing StifleR from enforcing the intended bandwidth limits
Investigating these conditions can help identify why clients are not respecting the configured bandwidth policy.
### Recommendations
High Bandwidth Detection is particularly useful for validating new deployments and troubleshooting environments where clients appear to consume more bandwidth than expected. Rather than serving as a replacement for bandwidth policies, it acts as an early warning mechanism that helps identify configuration or policy issues before they affect the wider network.
### Monitoring
Whenever the configured high bandwidth threshold is exceeded, StifleR records the event in the Windows Event Log. These events provide valuable diagnostic information and can assist in identifying misconfigured clients, policy conflicts, or other issues affecting bandwidth management.
***
## LEDBAT
StifleR supports Microsoft's Low Extra Delay Background Transport (LEDBAT) technology, allowing clients to make more efficient use of available network bandwidth while automatically yielding to higher-priority traffic. This enables background downloads to run at higher speeds without negatively impacting interactive applications or user activity.
When LEDBAT is enabled, StifleR can apply a separate bandwidth policy specifically for LEDBAT-enabled downloads. Because LEDBAT continuously adjusts its transmission rate based on network congestion, administrators can typically configure a higher target bandwidth than would be appropriate for standard BITS transfers.
### How It Works
When a client starts a BITS download, StifleR checks whether the content server supports LEDBAT. If LEDBAT is detected, StifleR applies the **LEDBAT Target Bandwidth** configured for the Network Group. For downloads from servers that do not support LEDBAT, the standard **Target Bandwidth** is used instead.
This allows organizations to take advantage of higher throughput when downloading from LEDBAT-enabled servers while maintaining standard bandwidth limits for all other content sources.
### Configuration
To enable LEDBAT support:
1. Enable **LEDBAT** in the server-level **Bandwidth Tuning** configuration.
2. Enable **LEDBAT** for the required Network Group.
3. Configure the **LEDBATTargetBandwidth** value for the Network Group.
4. Enable LEDBAT on the content server.
5. Configure the content server to return the following HTTP response header:
```
LEDBAT: true
```
The client automatically detects this header and applies the configured LEDBAT bandwidth policy.
### Recommended Deployment
LEDBAT is particularly beneficial for environments where clients download content from central Distribution Points or other IIS-based content servers. Since LEDBAT automatically backs off when foreground traffic is detected, administrators can safely configure a higher **LEDBAT Target Bandwidth** than the standard **Target Bandwidth**, improving download performance without increasing network congestion.
### Example
The following PowerShell example configures a Network Group to use a **LEDBAT Target Bandwidth** of **20 Mbps**:
```
Set-WmiInstance -Namespace root\StifleR ` -Class Subnets ` -Arguments @{ SubnetID = "192.168.4.0" LEDBATTargetBandwidth = 20480 }
```
Once configured:
* Downloads from LEDBAT-enabled content servers use the **LEDBAT Target Bandwidth**.
* Downloads from standard content servers continue to use the regular **Target Bandwidth**.
* LEDBAT automatically adjusts transmission rates to minimize the impact on foreground network traffic.
### Best Practices
* Enable LEDBAT on IIS content servers before configuring higher bandwidth limits.
* Configure the **LEDBAT Target Bandwidth** based on the available network capacity and deployment requirements.
* Continue using a standard **Target Bandwidth** for content sources that do not support LEDBAT.
* Validate LEDBAT functionality by confirming that the required HTTP response header is returned by the content server.
***
## Beacon Measurement
Beacon Measurement allows StifleR to actively determine the maximum available bandwidth for a Network Group rather than relying on a manually configured bandwidth limit. It uses the StifleR Beacon service and iPerf3 to perform scheduled bandwidth tests between clients and a designated Beacon server, providing an accurate representation of the available network capacity.
Unlike the other Bandwidth Tuning features, which continuously react to live network conditions, Beacon Measurement runs on a configurable schedule. The measured maximum bandwidth is stored for each Network Group and can be used to automatically calculate bandwidth limits as a percentage of the available capacity.
### How It Works
Only the **Red Leader** within a Network Group performs Beacon measurements. During a scheduled measurement, the Red Leader communicates with the configured StifleR Beacon server using iPerf3 to determine the maximum available upstream and downstream bandwidth.
After the test completes, the measured maximum downstream bandwidth is stored for the Network Group. If a newer measurement reports a higher maximum bandwidth, the stored value is updated. Lower measurements do not overwrite the existing value, preventing temporary network congestion from reducing the configured bandwidth baseline.
This measured bandwidth can then be used by StifleR when calculating the effective download throttle for clients within the Network Group.
### Bandwidth Calculation
Beacon Measurement allows bandwidth policies to be expressed as a percentage of the measured network capacity instead of a fixed bandwidth value.
For example:
* Measured maximum bandwidth: **100 Mbps**
* Configured percentage: **50%**
The resulting effective target bandwidth becomes **50 Mbps**.
This approach automatically adapts to different network speeds without requiring administrators to manually configure bandwidth limits for every location.
### Template Priority
The way Beacon measurements are applied depends on the selected template priority.
#### Beacon Measure Priority
When **Beacon Measure Priority** is selected, each successful bandwidth measurement automatically updates the effective bandwidth limit for the Network Group. As network capacity changes over time, StifleR adjusts the calculated target bandwidth accordingly.
#### Template Priority
When **Template Priority** is selected, Beacon measurements are still performed and recorded, but the fixed bandwidth values configured in the Network Group template continue to take precedence. In this mode, the measurement data is available for monitoring purposes but does not influence client throttling.
### Configuration Requirements
Beacon Measurement must be enabled in two locations before measurements will run:
* **Server-level Bandwidth Tuning**, which enables the StifleR Service to schedule bandwidth measurements.
* **Network Group Bandwidth Tuning**, which marks an individual Network Group as eligible for measurement.
If Beacon Measurement is disabled at either level, the Network Group is skipped without generating an error. This is the most common reason why measurements appear to be configured but never execute.
### Beacon Server
The StifleR Beacon service hosts the iPerf3 endpoint used during bandwidth measurements. It can be installed on any supported Windows server and is typically deployed close to the primary content source, such as a ConfigMgr Distribution Point or another central server that clients regularly access.
Although the Beacon service can be installed on the StifleR Server, this is not a requirement. There is no dependency between the two services, allowing the Beacon to be deployed wherever it best represents the available network path.
### Measurement Schedule
Beacon measurements are performed automatically by the Red Leader:
* When a new Network Group is created.
* When the first Red Leader is elected.
* Periodically thereafter according to the configured measurement schedule.
This allows StifleR to maintain an up-to-date view of the maximum available bandwidth without requiring manual intervention.
### Forcing a Measurement
For testing or troubleshooting purposes, a bandwidth measurement can be triggered manually using the `UpdateMaxBandwidth` WMI method.
#### WMIC
```
wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.26.0" call UpdateMaxBandwidth
```
#### PowerShell
```
$Subnet = Get-WmiObject -Namespace root\StifleR ` -Class Subnets ` -Filter "SubnetID='192.168.26.0'"Invoke-WmiMethod -Path $Subnet.__PATH -Name UpdateMaxBandwidth
```
### Best Practices
* Deploy the Beacon service as close as possible to the primary content source.
* Enable Beacon Measurement at both the server and Network Group levels.
* Use **Beacon Measure Priority** when you want bandwidth limits to adapt automatically to changing network conditions.
* Use **Template Priority** when bandwidth limits should remain fixed regardless of measured network capacity.
* Verify that only one Red Leader performs measurements for each Network Group, as this is the expected behavior.
***
## Automatic Latency Tuning
Automatic Latency Tuning enables StifleR to continuously optimize download bandwidth based on real-time network latency. Instead of applying a fixed bandwidth limit, StifleR dynamically adjusts client bandwidth to maintain an acceptable latency while maximizing the use of available network capacity.
This feature is particularly useful for networks where available bandwidth varies throughout the day or where maintaining a responsive user experience is more important than enforcing a fixed download rate.
### How It Works
StifleR continuously measures the round-trip latency between the client and the monitored endpoint.
* For **internal content sources**, latency is measured directly to the content server.
* For **Internet-based content sources**, latency is measured to the StifleR Server.
When latency exceeds the configured **Latency Threshold**, StifleR gradually reduces the available download bandwidth. Once latency returns below the threshold for the configured recovery period, bandwidth is incrementally increased until the configured **Target Bandwidth** is reached.
This continuous adjustment allows StifleR to maximize download performance while automatically responding to changing network conditions.
### Required Configuration
Automatic Latency Tuning requires the following Network Group settings:
| Setting | Description |
| -------------------- | ----------------------------------------------------------------------- |
| **TargetBandwidth** | The maximum bandwidth available for downloads. |
| **BandwidthTuning** | Must include the **Latency** option. |
| **LatencyThreshold** | The latency value, in milliseconds, that triggers bandwidth adjustment. |
These settings can be configured from the **StifleR Dashboard** or through WMI.
### Example Configuration
The following example configures a Network Group with:
* Target bandwidth: **700 Kbps**
* Latency monitoring enabled
* Latency threshold: **70 ms**
```
wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set TargetBandwidth=700wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set BandwidthTuning=1wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set LatencyThreshold=70
```
When latency exceeds **70 ms**, StifleR automatically reduces bandwidth. Once latency remains below the threshold for the configured recovery period, bandwidth is gradually restored until it reaches the configured target.
### Tuning Behaviour
Bandwidth adjustments are controlled by several server-side configuration settings, allowing administrators to determine how quickly StifleR responds to changing network conditions.
| Setting | Purpose |
| ---------------------------------- | -------------------------------------------------------------------------------- |
| **LatencyWarningDecreaseDuration** | Time latency must remain above the threshold before bandwidth is reduced. |
| **LatencyWarningDecreaseFactor** | Determines how aggressively bandwidth is reduced. |
| **LatencyWarningIncreaseDuration** | Time latency must remain below the threshold before bandwidth begins increasing. |
| **LatencyWarningIncreaseFactor** | Determines how aggressively bandwidth is restored toward the target value. |
These settings apply globally to all Network Groups using Automatic Latency Tuning and can be configured in the **StifleR Service** configuration.
### Recommendations
Automatic Latency Tuning is recommended for environments where network conditions fluctuate throughout the day. Rather than relying on static bandwidth limits, it allows StifleR to continuously balance download performance against network responsiveness, ensuring that background transfers make efficient use of available bandwidth without impacting interactive traffic.
***
## Server Configuration Options
Bandwidth Tuning behavior is controlled by several server-side configuration settings in the **StifleR Service** configuration. These settings determine how quickly StifleR reacts to changing network conditions and how aggressively bandwidth is increased or decreased.
The default values are suitable for most environments, but they can be adjusted to better match the characteristics of slower WAN links or high-speed LAN environments.
### Latency Adjustment Settings
#### LatencyWarningDecreaseDuration
Defines how long the measured latency must remain above the configured **Latency Threshold** before StifleR begins reducing the available bandwidth.
**Default:** `10000` milliseconds (10 seconds)
```
```
#### LatencyWarningDecreaseFactor
Controls how aggressively bandwidth is reduced when latency exceeds the configured threshold.
The configured **TargetBandwidth** is divided by this value during each adjustment cycle.
**Default:** `1.4`
```
```
For example, if the configured **TargetBandwidth** is **2000 Kbps**, the first reduction would lower the bandwidth to approximately **1428 Kbps**.
#### LatencyWarningIncreaseDuration
Defines how long latency must remain below the configured threshold before StifleR begins restoring bandwidth.
**Default:** `10000` milliseconds (10 seconds)
```
```
#### LatencyWarningIncreaseFactor
Determines how quickly bandwidth is restored after latency returns to an acceptable level.
Instead of immediately restoring the full bandwidth, StifleR gradually increases the available bandwidth during each adjustment cycle.
**Default:** `5`
```
```
For example, if:
* TargetBandwidth = **2000 Kbps**
* Current TunedBandwidth = **500 Kbps**
StifleR increases the bandwidth by:
```
TargetBandwidth / LatencyWarningIncreaseFactor
```
Result:
```
2000 / 5 = 400 Kbps
```
The new **TunedBandwidth** becomes **900 Kbps**, with additional increases occurring every adjustment interval until the configured target bandwidth is reached.
### Adjustment Cycle
By default, StifleR evaluates network latency every **10 seconds**.
If latency exceeds the configured threshold for longer than the configured decrease duration, bandwidth is gradually reduced. Once latency remains below the threshold for the configured recovery period, bandwidth is incrementally restored according to the configured increase factor.
This gradual adjustment prevents sudden bandwidth changes while allowing StifleR to maximize throughput without negatively affecting interactive network traffic.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://documentation.2pintsoftware.com/stifler/3.1/operations-and-features/bandwidth-management/bandwidth-tuning-monitoring-and-control.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.