Calculate Finish Times Weighted Fair Queueing

Calculate the precise finish times for packets in a Weighted Fair Queueing (WFQ) system, considering packet sizes, weights, and service rates.

WFQ Finish Time Inputs

Calculation Results

Formula Used:
1. Packet Service Time (PST) = (Packet Size / Service Rate) * 1,000,000 (to convert seconds to microseconds)
2. Normalized Packet Size (NPS) = Packet Size / Weight
3. Virtual Start Time (VST) = max(Previous Virtual Finish Time, Current Virtual Start Time of Queue) – This is simplified in this calculator to VST = Previous Virtual Finish Time for a single flow context.
4. Virtual Finish Time (VFT) = VST + NPS
5. Actual Finish Time (AFT) = VFT * (Total Weight / Flow Weight) – This is simplified in this calculator to AFT = VFT, assuming a single flow or a simplified model where total weight is implicitly handled by the service rate.
*Note: This calculator provides a simplified model focusing on individual flow finish times. A full WFQ implementation involves a global virtual time and queue state.*

WFQ Finish Time Data Table

WFQ Packet Scheduling Simulation

Packet #	Packet Size (Bytes)	Flow Weight	Service Rate (Mbps)	Prev VFT (μs)	PST (μs)	NPS	VST (μs)	VFT (μs)	AFT (μs)

What is Weighted Fair Queueing (WFQ)?

Weighted Fair Queueing (WFQ) is a sophisticated packet scheduling algorithm used in computer networks to provide differentiated Quality of Service (QoS). Unlike simple First-Come, First-Served (FCFS) or strict priority queues, WFQ aims to allocate network bandwidth proportionally among different traffic flows based on assigned weights. Each flow receives a share of the bandwidth that is proportional to its weight relative to the total weight of all active flows. This ensures that high-priority traffic receives preferential treatment without completely starving lower-priority traffic.

Who should use it: Network administrators, engineers, and researchers involved in network design, performance optimization, and QoS implementation. It's particularly relevant for networks carrying diverse traffic types, such as voice, video, and data, where guaranteeing certain performance levels for specific applications is crucial. Understanding WFQ helps in configuring routers and switches to manage traffic effectively.

Common misconceptions:

• WFQ guarantees absolute bandwidth: WFQ guarantees *proportional* bandwidth, not a fixed amount. If the total network load is low, all flows might receive more than their weighted share. If the load exceeds capacity, flows will receive bandwidth according to their weights, but the absolute amount might be less than desired.
• WFQ is the same as strict priority: While WFQ prioritizes flows with higher weights, it doesn't completely block lower-weighted flows. Strict priority would starve lower-priority queues if a higher-priority queue is active. WFQ ensures fairness even under congestion.
• WFQ is simple to implement: WFQ requires maintaining per-flow state, calculating virtual finish times, and managing a complex scheduling logic, making it more resource-intensive than simpler algorithms.

Weighted Fair Queueing Finish Time Formula and Mathematical Explanation

The core idea behind WFQ is to simulate a hypothetical bit-by-bit round-robin scheduler. Instead of scheduling packets directly, WFQ assigns a "virtual finish time" to each packet. The packet with the earliest virtual finish time is scheduled next. This virtual finish time is calculated based on the packet's size, its assigned weight, and the system's current virtual time.

The calculation for a packet belonging to a specific flow involves several steps:

1. Calculate Packet Service Time (PST): This is the time it would take to transmit the packet at the flow's allocated service rate.
   PST = (Packet Size / Service Rate)
   To work with microseconds (μs) commonly used in network scheduling, we convert:
   PST (μs) = (Packet Size (Bytes) * 8 bits/Byte) / (Service Rate (bits/sec)) * 1,000,000 μs/sec
   Or, if Service Rate is in Mbps:
   PST (μs) = (Packet Size (Bytes) * 8) / (Service Rate (Mbps) * 1,000,000) * 1,000,000
PST (μs) = (Packet Size * 8) / Service Rate (Mbps)
2. Calculate Normalized Packet Size (NPS): This adjusts the packet size by the flow's weight. A larger weight means a smaller normalized size, indicating it consumes less "virtual" resources per bit.
   NPS = Packet Size / Weight
3. Determine Virtual Start Time (VST): This represents the earliest time the scheduler could *start* processing this packet in the virtual time domain. It's the maximum of the previous packet's virtual finish time for this flow and the current virtual time of the scheduler (which is often approximated by the virtual finish time of the last packet scheduled globally or for this flow). For simplicity in a single-flow context, we often use the previous virtual finish time.
   VST = max(Previous Virtual Finish Time, Current Queue Virtual Time)
   In our calculator's simplified model for a single flow:
   VST = Previous Virtual Finish Time
4. Calculate Virtual Finish Time (VFT): This is the core WFQ metric. It's the time the packet would finish in the virtual system.
   VFT = VST + NPS
5. Calculate Actual Finish Time (AFT): This converts the virtual finish time back to real time. It depends on the total weight of all active flows. The formula is:
   AFT = VFT * (Total Weight / Flow Weight)
   However, a more practical implementation often relates the service rate directly. If the service rate is correctly allocated based on weights (e.g., Flow Service Rate = Total Rate * (Flow Weight / Total Weight)), the AFT can be simplified. In many WFQ variants (like Stochastic Fair Queueing – SFQ, or simplified WFQ models), the virtual finish time itself is used as the primary scheduling metric, or the conversion is implicitly handled by the rate allocation. For this calculator, we'll focus on the VFT as the primary scheduling indicator and provide a simplified AFT calculation assuming the service rate already reflects the weight proportion.
   Simplified AFT (for this calculator's context): The virtual finish time (VFT) is often the key metric. If we need a real-time finish, and assuming the service rate is correctly provisioned, the VFT can be directly related. A common approach is to consider the VFT as the primary scheduling decision point. For this calculator, we'll present VFT and a simplified AFT.
   Simplified AFT (μs) = VFT (μs) (This assumes the service rate is correctly provisioned per flow based on weights, effectively making VFT the dominant factor in scheduling order).

Variables Table

Variable	Meaning	Unit	Typical Range
Packet Size	Size of the data packet	Bytes	64 – 1500 (Ethernet MTU) or larger (Jumbo Frames)
Flow Weight (W)	Relative priority assigned to a traffic flow	Unitless	0.01 – 1000+ (depends on system configuration)
Service Rate (R)	Maximum data rate allocated to the flow	Mbps (Megabits per second)	1 – 10000+ (depends on network link capacity)
Previous Virtual Finish Time (PVFT)	Virtual finish time of the previously scheduled packet for this flow	Microseconds (μs)	0 – Varies greatly
PST	Packet Service Time	Microseconds (μs)	Calculated based on size and rate
NPS	Normalized Packet Size	Bytes / Unitless	Calculated based on size and weight
VST	Virtual Start Time	Microseconds (μs)	Depends on PVFT
VFT	Virtual Finish Time	Microseconds (μs)	Calculated based on VST and NPS
AFT	Actual Finish Time	Microseconds (μs)	Calculated based on VFT and weights
Queue Size	Maximum number of packets the queue can hold	Packets	10 – 10000+

Practical Examples (Real-World Use Cases)

Example 1: High-Priority VoIP Call

A VoIP call requires low latency and jitter. A network administrator configures the VoIP flow with a high weight.

• Scenario: A single packet from a VoIP flow needs scheduling.
• Inputs:
  • Packet Size: 100 Bytes
  • Flow Weight: 50
  • Service Rate: 10 Mbps
  • Previous Virtual Finish Time: 1500 μs
  • Queue Size: 1000 Packets
• Calculations:
  • PST = (100 * 8) / 10 = 80 μs
  • NPS = 100 / 50 = 2 Bytes
  • VST = 1500 μs
  • VFT = 1500 + 2 = 1502 μs
  • AFT = 1502 μs (Simplified)
• Interpretation: This VoIP packet, despite its small size, gets a high priority due to its weight. Its virtual finish time is only slightly later than the previous packet's finish time, ensuring it's scheduled quickly. The actual finish time reflects this prompt scheduling.

Example 2: Bulk Data Transfer

A large file transfer is less sensitive to latency but needs a fair share of bandwidth. It's assigned a moderate weight.

• Scenario: A packet from a bulk data flow.
• Inputs:
  • Packet Size: 1500 Bytes
  • Flow Weight: 10
  • Service Rate: 100 Mbps
  • Previous Virtual Finish Time: 1500 μs
  • Queue Size: 1000 Packets
• Calculations:
  • PST = (1500 * 8) / 100 = 120 μs
  • NPS = 1500 / 10 = 150 Bytes
  • VST = 1500 μs
  • VFT = 1500 + 150 = 1650 μs
  • AFT = 1650 μs (Simplified)
• Interpretation: This larger packet has a significantly higher normalized size (150 Bytes) compared to the VoIP packet (2 Bytes). Even though its virtual start time is the same, its virtual finish time is much later (1650 μs vs 1502 μs). This indicates it will be scheduled after the VoIP packet and other flows with earlier virtual finish times, ensuring fair, albeit delayed, bandwidth allocation.

How to Use This WFQ Finish Time Calculator

This calculator helps you understand the scheduling behavior of Weighted Fair Queueing for individual packets. Follow these steps:

1. Input Packet Details: Enter the size of the packet in Bytes.
2. Specify Flow Characteristics: Input the Flow Weight assigned to this traffic type and the Service Rate (in Mbps) allocated to this flow.
3. Enter Previous State: Provide the Previous Virtual Finish Time (μs) for this flow. If this is the very first packet being considered for this flow, use 0.
4. Set Queue Limit: Input the maximum Queue Size (in packets) to check for potential overflow conditions (though this calculator primarily focuses on finish times, not queue drops).
5. Calculate: Click the "Calculate Finish Time" button.
6. Review Results:
   • Packet Service Time (PST): How long it takes to transmit the packet at its allocated rate.
   • Normalized Packet Size (NPS): Packet size adjusted by flow weight.
   • Virtual Start Time (VST): The earliest virtual time the packet can begin processing.
   • Virtual Finish Time (VFT): The calculated virtual completion time. This is a key metric for WFQ scheduling order.
   • Actual Finish Time (AFT): The estimated real-time finish time (simplified).
7. Interpret: Compare the VFT and AFT values. Lower values indicate earlier scheduling. The difference between VFTs of consecutive packets helps understand the fairness and latency characteristics.
8. Reset: Use the "Reset Defaults" button to return all fields to their initial values.
9. Copy: Use the "Copy Results" button to copy the calculated values for documentation or sharing.

Key Factors That Affect WFQ Results

Several factors influence the calculated finish times and the overall performance of a WFQ system:

• Flow Weights: This is the most direct factor. Higher weights grant flows earlier virtual finish times and thus quicker scheduling, especially under congestion. A flow with weight 20 will generally be served twice as fast as a flow with weight 10, assuming equal packet sizes and service rates.
• Packet Size: Larger packets inherently take longer to transmit (higher PST). In WFQ, they also have a larger Normalized Packet Size (NPS), pushing their Virtual Finish Time (VFT) further out. This means smaller packets generally get scheduled sooner than larger packets within the same flow, contributing to lower jitter.
• Service Rate Allocation: The configured service rate (R) for each flow directly impacts the Packet Service Time (PST). A higher service rate means a shorter PST, which can indirectly affect VFT if the scheduler is highly utilized. Crucially, the *total* service rate available on the link limits how quickly absolute finish times can occur.
• Network Congestion: WFQ's primary benefit is managing congestion. When the total traffic demand exceeds the link capacity, WFQ ensures that bandwidth is distributed proportionally. The virtual finish times become critical differentiators in deciding which packet gets transmitted next. Without congestion, WFQ behaves similarly to FCFS for each flow.
• Number of Active Flows: The total weight (sum of weights of all active flows) is used in the conversion from VFT to AFT. More active flows, especially those with high weights, can increase the total weight, potentially affecting the absolute finish times.
• Queue Management Policies: While this calculator focuses on finish times, real-world WFQ implementations must handle queue overflows. If a queue reaches its maximum size, incoming packets might be dropped. The queue size parameter is a critical input for understanding potential packet loss, which affects the *effective* delivery time.
• Scheduler Overhead: The computational cost of calculating VFTs and managing per-flow states introduces some delay. This overhead is not explicitly modeled in this simplified calculator but is a factor in real systems.
• Time Synchronization: Accurate timestamps are crucial for calculating service rates and virtual times. Clock drift between network devices can impact the effectiveness of WFQ.

Frequently Asked Questions (FAQ)

Q1: What is the difference between WFQ and Strict Priority Queueing?

Strict Priority Queueing serves packets from the highest priority queue first, potentially starving lower-priority queues. WFQ provides proportional bandwidth allocation based on weights, ensuring that even low-priority traffic receives a share of the bandwidth, preventing starvation.

Q2: Can WFQ guarantee zero latency?

No. WFQ aims to provide fair and proportional bandwidth, which helps minimize latency and jitter, especially under congestion. However, it does not guarantee zero latency, as packet processing, queuing delays, and transmission times always exist.

Q3: How do I determine the right weights for my traffic flows?

Weights are typically assigned based on application requirements. Real-time applications like VoIP and video conferencing usually get higher weights due to their sensitivity to delay and jitter. Bulk data transfers might receive lower weights. Network administrators often use a combination of experimentation and QoS policies to set appropriate weights. Consider using our WFQ Finish Time Calculator to test different weight scenarios.

Q4: What happens if the sum of flow service rates exceeds the link capacity?

This is the scenario where WFQ is most beneficial. The algorithm ensures that the available bandwidth is distributed proportionally according to the weights. If the total bandwidth is 100 Mbps and flows have weights 10, 20, and 70 (total 100), they will receive approximately 10 Mbps, 20 Mbps, and 70 Mbps respectively. If the total demand is 150 Mbps, the proportions would still be maintained (e.g., 15, 30, 105 Mbps if the link could support it, but capped by the link's actual capacity).

Q5: Is WFQ suitable for all types of network traffic?

WFQ is excellent for traffic requiring differentiated services. However, for applications demanding extremely low latency and jitter (like real-time gaming or critical control systems), strict priority or specialized algorithms like Weighted Round Robin (WRR) with careful configuration might be considered, though WFQ offers better fairness.

Q6: How does the 'Previous Virtual Finish Time' affect the calculation?

The 'Previous Virtual Finish Time' (PVFT) sets the baseline for the current packet's Virtual Start Time (VST). The VST is the maximum of PVFT and the current scheduler virtual time. This ensures that a flow's packets are processed in order and that the scheduler doesn't fall behind. A higher PVFT means the current packet's VFT will also be pushed later.

Q7: What does a 'Normalized Packet Size' of 0.5 mean?

A Normalized Packet Size (NPS) of 0.5 means that this packet, relative to its flow's weight, consumes 0.5 units of the virtual resource. If another packet has an NPS of 1.0, it consumes twice the virtual resource and will therefore have a later virtual finish time, assuming they start at the same virtual time.

Q8: Does this calculator account for packet drops?

This calculator primarily focuses on the theoretical finish times based on WFQ logic. It includes a 'Queue Size' input for context but does not explicitly model packet drops due to queue overflow. In a real network, exceeding the queue size would lead to packet loss, impacting the effective throughput and latency.