What does Microsoft mean by low / moderate / high / very high / extremely high Azure network bandwidth (part 5.1)

This article is part of a series of 5 where I am talking about the Microsoft Azure network bandwidth. For a better understanding please make sure you read also the other parts:

  1. What does Microsoft mean by low / moderate / high / very high / extremely high Azure network bandwidth (part 1)
  2. The isolated network setup (the environment used for network analysis) (part 2)
  3. The IOmeter benchmark tests who reproduce as close as possible the HTTP/HTTPS, SMB and MS SQL network traffic (part 3)
  4. The Azure Virtual Machines used to run the IOmeter benchmarks (part 4)
  5. Results and interpretations

Results for the 4096 B; 0% Read; 0% random (4096 Bytes transfer request size, 100% write distribution, 0% random distribution) benchmark

Frame size for a single network I/O operation => 14 bytes (ETH) + 20 bytes (IP) + 20 bytes (TCP) + 4096 bytes (TCP data) = 4150 bytes (1.30% protocol overhead and 98.70% data)
Packet size for a single network I/O operation => 20 bytes (IP) + 20 bytes (TCP) + 4096 bytes (TCP data) = 4136 bytes

 

Low vs Moderate vs High

what_does_microsoft_means_by_low_moderate_high_very_high_extremely_high_azure_network_bandwidth_47
In the above chart, we can see a comparison between Azure Low, Moderate and High network bandwidth adapters. From this chart we can see there is a clear difference in performance between them. Microsoft is not providing exact numbers what low, moderate or high network bandwidth means, but so far from the [4096 B; 0% Read; 0% random] IOmeter benchmark results, we can say:

  • Azure Low bandwidth performance is around ≈20 Mbps total (send & receive);
  • Azure Moderate bandwidth performance is around ≈500 Mbps total (send & receive);
  • Azure High bandwidth performance is around ≈1 Gbps total (send & receive);

We also have to pay attention to the average registered speed! In a stable network the average performance must not be that far away from the maximum recorded value. The maximum recorded speed can be reached just couple of times and can be exceptional (especially when software bandwidth management is involved), while in the majority of the time the registered speed is much lower. That’s why the average recorded speed is the one that most likely we will reach – so this is the actual value we should take into consideration in our network requirements.

Please note the numbers based on which this chart has been generated have been collected using Performance Monitor.

 

what_does_microsoft_means_by_low_moderate_high_very_high_extremely_high_azure_network_bandwidth_48

The above chart indicates the average write response time IOmeter recorded for the [4096 B; 0% Read; 0% random] I/Os. Especially when we discuss computer networks there is some variety of communication channels and each of it has its specifications. I did a lot of searches on this topic to find recommendations of what the response time should be (what is good and what is the point where the latency becomes problematic on Ethernet networks). Because the answer depends on so many variables I decided to dig through what Microsoft, Citrix, IBM recommends and ended up with 0.5 milliseconds (500 uS microseconds) as being the maximum accepted latency for the Ethernet network.
These numbers are provided by IOmeter and are registered when the network is saturated.
As expected, there is a considerable difference between the Low and the Moderate Azure network bandwidth. The difference between Moderate and High network bandwidth is not big.

 

what_does_microsoft_means_by_low_moderate_high_very_high_extremely_high_azure_network_bandwidth_49

The above stacked column chart represents the latency distribution for the [4096 B; 0% Read; 0% random] IOmeter benchmark. As we can see, between these three VMs, AZIOA3-01 (High network bandwidth) registered the best response times – 95.552625% of its I/Os being completed within 0 and 50 uS (microseconds). The second best performer is AZIOA2-01 (Moderate network bandwidth) with 92.109617 % of its I/Os being completed within 0 and 50 uS (microseconds).
Please note the time axis is not linear (it is a logarithmic one), case in which the jump from one interval to the other is considerable high.
The worst performer between these three VMs is AZIOA0-01 (low network bandwidth) with 84.806376% of its I/Os being completed within 0 and 50 uS (microseconds), 4.771172% completed between 15 and 20 mS (milliseconds) and 6.717324% completed within 30 and 50 mS (milliseconds). Even if those percentages are small, the fact are recorded for intervals like 15 to 20 mS or 30 to 50 mS are making the Azure Low network bandwidth not a good performer.

 

 

 

High vs Very High vs Extremely High

what_does_microsoft_means_by_low_moderate_high_very_high_extremely_high_azure_network_bandwidth_50

We can see there is a clear difference in performance between Azure High and Azure Very High or Extremely High network bandwidths. Microsoft is not providing what exactly these network bandwidths means, but so far from the [4096 B; 0% Read; 0% random] IOmeter benchmark results, we can say:

  • Azure High bandwidth performance is around ≈1 Gbps total (send & receive);
  • Azure Very High bandwidth performance is around ≈3 Gbps total (send & receive);
  • Azure Extremely High bandwidth performance is around ≈3 Gbps total (send & receive);

A couple of chart explanations above I mentioned the importance of the average recorded speed. Looking at the average speeds registered by Azure Very High and Azure Extremely High network bandwidths, I tend to say there is not that much difference between them in terms of performance (at least the [4096 B; 0% Read; 0% random] IOmeter benchmark doesn’t indicate that).

Please note the numbers based on which this chart has been generated have been collected using Performance Monitor.

 

what_does_microsoft_means_by_low_moderate_high_very_high_extremely_high_azure_network_bandwidth_51

In terms of write response time, all these VMs registered average times under 0.5 mS. That means the Azure High, Very High or Extremely High network bandwidths can handle very well the network traffic even when the network is saturated with this type of traffic ([4096 B; 0% Read; 0% random]).
As noticed also in the previous chart, there is a clear difference in performance between Azure High and Azure Very High or Extremely High, but the last two are not much different one from the other.

 

what_does_microsoft_means_by_low_moderate_high_very_high_extremely_high_azure_network_bandwidth_52

If we look at the latency distribution chart, the best performer is Azure Extremely High network bandwidth, followed by Azure Very High and High network bandwidth.
Even if the Microsoft naming is kind of indicating the top performers, based on the so far tests we can say the Extremely High and Very High network bandwidths are almost the same.

 

Go back to the previous page.

Leave a Reply