VSM - Recommended Connection Limits
The vsmServer platforms are carefully specified for the operation of vsmStudio and its components (like vsmGadgetServer and vSNMP) in 24/7 live production environments. They have been carefully selected to meet the control requirements with the majority of broadcast installations. In modern IP infrastructures, VSM has to balance the increasing demands of the controlled devices, which become more powerful with every generation.
The key criteria for the specification of server platforms is the speed of the communication:
- between vsmStudio or VSM components and the controlled infrastructure, and
- between vsmStudio and its components directly.
In VSM's product design, great importance is attached to maintaining the lowest possible latency in communication with third parties, to ensure highest performance and reliability in daily operation. To warrant these specifications, performance limits have to be recommended for the operation of the vsmServers as offered through Lawo. The recommendation is valid for the Standard DL360 server in its current available setup.
A Lawo V__matrix C100 processing blade currently defines the upper limit of the range of performance demanding devices controlled by VSM. The performance limits explained below refer to controlling C100 blades running firmware v1.8.x or v1.10.x and the assumption, that other devices (Lawo specific or 3rd party) either meet or underrun the performance demands of a C100 blade. The lineup below can therefore be understood as a performance limit for controlling known devices with highest demands. Controlling devices with lower demands results in higher amounts of simultaneously connected devices.
Operational Recommendation C100
vm_udx, vm_avp
Mapping1 | 1:1 |
|---|---|
| Max. C100 device connections per Server | 100 |
ยน ) Mapping: Describes how C100 connections are forwarded into vsmStudio. 1:1 = each device resolves into 1 connection towards vsmStudio. n:1 = many devices resolve into 1 connection to vsmStudio.
The 1:1 mapping as shown in the setup recommendations above does not mean for the vsmServer hosting vsmStudio (right in the drawings) it is reaching its connection limit in the same way as the host for vsmGadgetServer in the middle does. Even if vsmStudio is hosted on the same type of server, the communication between vsmGadgetServer and vsmStudio is usually bandwidth-optimized and only exchanges parameters which are used in the configuration. Therefore, the vsmStudio system can usually handle a lot more connections than indicated in the 1:1 mapping scheme above.
vm_dmv
The V_matrix operation mode "Distributed Multi Viewer" (vm_dmv) uses a range of C100 processing blades to process a highly dynamic multiviewer application across them. All C100 blades rendering 1 DMV are being summarized into 1 single control connection. This affects the counting of control connections into vsmGadgetServer and therefore recommendation for the maximum amount of connections handled by 1 vsmGadgetServer.
However, the data bandwidth per physical C100 equals independent of the operational mode of the blade. Therefore, the number of physical C100 blades controlled by one vsmGadgetServer instance remains the decisive factor.
Mapping1 | 1:1 |
|---|---|
Max. C100 device connections per Server, or... | 100 |
... max. DMV connections per Server | 3 (32x C100 blades each) |
The 1:1 mapping as shown in the setup recommendations above does not mean for the vsmServer (right in the drawings) it is reaching its connection limit in the same way as the host for vsmGadgetServer does. Even if vsmStudio is hosted on the same type of server, the communication between vsmGadgetServer and vsmStudio is usually bandwidth-optimized and exchanges parameters which are used in the configuration. Therefore, the vsmStudio system can usually handle a lot more connections than indicated in the 1:1 mapping scheme above.
Operational Examples for 1 instance of vsmGadgetServer on a DL360
The "No. of additional 3rd party control connections on same server" is to be interpreted in two ways:
First line: Connecting devices of the same resource requirements as C100.
Second line: Connecting devices with less resource requirements as C100.
Example 1:
| C100 vm_dmv | - |
|---|---|
| C100 for vm_avp, vm_udx, etc. | 50 blades |
No. of additional 3rd party control connections on same server | 50 with similar resource requirements as C100, at least 50 with lower resource requirements |
Example 2:
| C100 vm_dmv | 20 blades in 1 DMV cluster |
|---|---|
| C100 for vm_avp, vm_udx, etc. | 50 blades |
| No. of additional 3rd party control connections on same server | 30 with similar resource requirements as C100, at least 30 with lower resource requirements |
Example 3:
| C100 vm_dmv | 64 blades in 2 DMV clusters |
|---|---|
| C100 for vm_avp, vm_udx, etc. | - |
| No. of additional 3rd party control connections on same server | 36 with similar resource requirements as C100, at least 36 with lower resource requirements |
Example 4:
| C100 vm_dmv | 96 blades in 3 DMV clusters |
|---|---|
| C100 for vm_avp, vm_udx, etc. | 0 |
| No. of additional 3rd party control connections on same server | no resources left for any other c100 connection at least 4 with lower resource requirements |