vSTREAM-STL S2D Capabilities: Difference between revisions

From wiki.comcert.com
Jump to navigation Jump to search
No edit summary
No edit summary
 
(6 intermediate revisions by the same user not shown)
Line 4: Line 4:
Source: OPVXG Traffic Generator
Source: OPVXG Traffic Generator


Destination: ME: CRT-VIR-A-VVSTL62:if4
Destination: ME: CRT-VIR-A-VSSTL62:if4


vSTREAM Standalone version 6.2.0-451 on NGS 6.2.0-658 with two MON interfaces (auto tsa 50/50)
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 
OptiView XG Traffic Generator version @ 1Gbps w/ 64,128,256,516, 728,1024,1240 and 1518B packets.


vSphere: ESXi v6.7 with 300 IOS
vSphere: ESXi v6.7 with 300 IOS
Line 16: Line 16:
 
 


[[File:OPVXGTGPayloadType.png|border|center|400px|OPVXGTGPayloadType.png]]
[[File:OPVXGTGPayloadType.png|border|center|600px|OPVXGTGPayloadType.png]]


 
 
Line 22: Line 22:
=== Traffic measured ===
=== Traffic measured ===


=== Graphically with Link Monitor for 60' at 5' AVG: ===
Graph obtained from data collected with Link Monitor for > 60' at 5' AVG:


 
 
Line 32: Line 32:
=== Conclusion ===
=== Conclusion ===


<u>Because the unofficial default capacity of a VSphere Standard Virtual Switch (VSS) is considered to be around&nbsp;250kpps, we must conclude&nbsp;&nbsp;that vSTREAM-STL Stream to Disk capabilities are&nbsp;hardly affected by the number of CPU and&nbsp;memory assigned to the virtual machine</u>.&nbsp;
Because the unofficial default capacity of a VSphere Standard Virtual Switch (VSS) is considered to be around&nbsp;250kpps @ 300 IOPS, <u>we must conclude&nbsp;&nbsp;that vSTREAM-STL Stream to Disk capabilities are&nbsp;hardly affected by the number of CPU and&nbsp;memory assigned to the virtual machine at packet rates that fall within the VMware specifications</u>.
 
Increasing the IOPS of&nbsp;the vSphere Disk Subsystem will eventually have an impact on vSTREAM-STL's streaming capabilities.


The 5' results show a high&nbsp;variation over time at 1488kpps (almost 500% of the assumed capacity of the VSS) is exeeded.&nbsp;
The 5' results show a high&nbsp;variation over time at 1488kpps (almost 500% of the assumed capacity of the VSS) is exeeded.&nbsp;


We did experience instability issues whenever the memory size was not in line with the numer of virtual CPU.&nbsp; You must provide 2GB of RAM per vCPU.&nbsp; This is also a recommendation of VMware itself.
We did experience instability&nbsp; whenever the VM memory size was not in line with the numer of virtual CPU. You must provide 2GB of RAM per vCPU.&nbsp; This is also part of VMware Best Practices.


&nbsp;
&nbsp;


[[Category:Private]]
&nbsp;

Latest revision as of 11:23, 14 May 2020

Test setup

Source: OPVXG Traffic Generator

Destination: ME: CRT-VIR-A-VSSTL62: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 @ 1Gbps w/ 64,128,256,516, 728,1024,1240 and 1518B packets.

vSphere: ESXi v6.7 with 300 IOS

Traffic type

 

OPVXGTGPayloadType.png
OPVXGTGPayloadType.png

 

Traffic measured

Graph obtained from data collected with Link Monitor for > 60' at 5' AVG:

 

VSTSTLS2D.png
VSTSTLS2D.png

 

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.