vSTREAM-STL S2D Capabilities: Difference between revisions
No edit summary |
No edit summary |
||
| Line 38: | Line 38: | ||
The 5' results show a high variation over time at 1488kpps (almost 500% of the assumed capacity of the VSS) is exeeded. | The 5' results show a high variation over time at 1488kpps (almost 500% of the assumed capacity of the VSS) is exeeded. | ||
We did experience instability | We did experience instability whenever the VM memory size was not in line with the numer of virtual CPU. You must provide 2GB of RAM per vCPU. This is also part of VMware Best Practices. | ||
| | ||
[[Category:Private]] | [[Category:Private]] | ||
Revision as of 07:04, 5 August 2019
Test setup
Source: OPVXG Traffic Generator
Destination: ME: CRT-VIR-A-VVSTL62:if4
vSTREAM Standalone version 6.2.0-451 on NGS 6.2.0-658 with two MON interfaces (auto tsa 50/50)
OptiView XG Traffic Generator version
vSphere: ESXi v6.7 with 300 IOS
Traffic type
Traffic measured
Graph obtained from data collected with Link Monitor for > 60' at 5' AVG:
Conclusion
Because the unofficial default capacity of a VSphere Standard Virtual Switch (VSS) is considered to be around 250kpps @ 300 IOPS, we must conclude that vSTREAM-STL Stream to Disk capabilities are hardly affected by the number of CPU and memory assigned to the virtual machine at packet rates that fall within the VMware specifications.
Increasing the IOPS of the vSphere Disk Subsystem will eventually have an impact on vSTREAM-STL's streaming capabilities.
The 5' results show a high variation over time at 1488kpps (almost 500% of the assumed capacity of the VSS) is exeeded.
We did experience instability whenever the VM memory size was not in line with the numer of virtual CPU. You must provide 2GB of RAM per vCPU. This is also part of VMware Best Practices.