We've launched our new site at www.openlighting.org. This wiki will remain and be updated with more technical information.
Difference between revisions of "OLA ArtNet Roadmap"
From wiki.openlighting.org
Mrpackethead (talk | contribs) |
Peternewman (talk | contribs) m (→Multiple ArtNet Devices: Switch to interwiki links) |
||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
This describes proposed changes to the [[OLA]] [[ArtNet]] plugin to make it more usable. Some of the use cases that have been requested include: | This describes proposed changes to the [[OLA]] [[ArtNet]] plugin to make it more usable. Some of the use cases that have been requested include: | ||
| + | |||
| + | == Use Cases == | ||
* Receiving broadcast ArtNet data and unicasting to a static list of destinations | * Receiving broadcast ArtNet data and unicasting to a static list of destinations | ||
* Converting many universes (10s, 100s?) from ArtNet to E1.31 and visa versa. | * Converting many universes (10s, 100s?) from ArtNet to E1.31 and visa versa. | ||
| + | * Receiving broadcast ArtNet data on one interface, and then sending using ArtNet2 / ArtNet 3 on another interface. | ||
| + | |||
| + | Artnet-1 to Artnet-2. There are some media servers that do not support Unicast Art-net at all, and all packets are broadcast. When the number of universes exceeds some threshold ( typically >20 ) many end devices can't cope with the number of packets that are needed to be discarded. You end up with irractic and laggy results. ( end devices typically have low power embedded microcontrollers ). Broacast packets need to received from a console/media server and retransmitted in unicast. Its important to be able to either use the Art-net poll mechanism to auto-populate which universes are required on which devices or to use a 'static' routing system. Because we are listening to an Art-net Speaking console, we need to be listen to a large number of universes. | ||
| + | |||
| + | A typical device that we would want to listen to could be a GrandMA VPU. It does not support Static assignment of Universes to IP address', and there is a requirement to be able to send more than 4 universes to an Art-net device.. | ||
| − | |||
== Requirements == | == Requirements == | ||
| Line 11: | Line 17: | ||
* Support more than 4 ports in both directions | * Support more than 4 ports in both directions | ||
* De-couple the ArtNet universe from the OLA universe number to support any-way patching. i.e. patch ArtNet universe 5 to OLA universe 3. | * De-couple the ArtNet universe from the OLA universe number to support any-way patching. i.e. patch ArtNet universe 5 to OLA universe 3. | ||
| + | |||
== Proposed Changes== | == Proposed Changes== | ||
| Line 16: | Line 23: | ||
=== Investigate Optimizing the Send Path === | === Investigate Optimizing the Send Path === | ||
| − | The [http://man7.org/linux/man-pages/man2/sendmmsg.2.html sendmmsg] syscall was added in Linux 3.0. It allows multiple datagrams to be sent with a single syscall. sendmmsg would | + | The [http://man7.org/linux/man-pages/man2/sendmmsg.2.html sendmmsg] syscall was added in Linux 3.0. It allows multiple datagrams to be sent with a single syscall. sendmmsg would allow us to reduce the number of syscalls required for each ArtNet packet when unicasting. This scope of this change is to make the required changes and then benchmark the performance. |
Steps: | Steps: | ||
| Line 22: | Line 29: | ||
* Add a method to the UDPSocket class to enable a single data message to be sent to many addresses | * Add a method to the UDPSocket class to enable a single data message to be sent to many addresses | ||
* Modify the ArtNetNode::SendDMX method to use the new UDPSocket method | * Modify the ArtNetNode::SendDMX method to use the new UDPSocket method | ||
| + | |||
| + | |||
| + | ''with the large number of universes being used, the likely scenario is that most universes will only be used at a single destination, the number of replicated packets probalby is quite low'' | ||
=== Multiple ArtNet Devices === | === Multiple ArtNet Devices === | ||
| − | Right now only a single ArtNet Device is created. This should be changed so that OLA creates [ | + | Right now only a single ArtNet Device is created. This should be changed so that OLA creates [[code:plugins/artnet/ArtNetPlugin.cpp#L46|one device per logical interface]]. |
| − | Currently the ArtNetNode object binds to the wildcard address ([ | + | Currently the ArtNetNode object binds to the wildcard address ([[code:plugins/artnet/ArtNetNode.cpp#L1596|code]]) which means trying to create a second instance will fail. |
We need some research into how broadcast traffic is handled with multiple interfaces. Ideally each instance should bind to the broadcast addresses for the specified logical interface. | We need some research into how broadcast traffic is handled with multiple interfaces. Ideally each instance should bind to the broadcast addresses for the specified logical interface. | ||
=== Increased Output Ports === | === Increased Output Ports === | ||
| + | |||
| + | This shouldn't be too hard. Only the first 4 ports will be represented in the ArtPollReply responses. We'll need to store the net, subnet and port ids on a per-port basis. Right now the net & sub-net values are the same for all ports in a node. | ||
=== Increased Input Ports === | === Increased Input Ports === | ||
| + | |||
| + | This is more challenging since it requires multiple IP addresses on the host in order to work correctly (that is, have the ports show up in ArtPollReplies). [[libartnet]] supported the concept of merging node instances, we should do something similar in OLA. It may be challenging to work out the corner cases when this interacts with the multi-device change. | ||
Latest revision as of 08:49, 28 December 2014
This describes proposed changes to the OLA ArtNet plugin to make it more usable. Some of the use cases that have been requested include:
Contents
Use Cases
- Receiving broadcast ArtNet data and unicasting to a static list of destinations
- Converting many universes (10s, 100s?) from ArtNet to E1.31 and visa versa.
- Receiving broadcast ArtNet data on one interface, and then sending using ArtNet2 / ArtNet 3 on another interface.
Artnet-1 to Artnet-2. There are some media servers that do not support Unicast Art-net at all, and all packets are broadcast. When the number of universes exceeds some threshold ( typically >20 ) many end devices can't cope with the number of packets that are needed to be discarded. You end up with irractic and laggy results. ( end devices typically have low power embedded microcontrollers ). Broacast packets need to received from a console/media server and retransmitted in unicast. Its important to be able to either use the Art-net poll mechanism to auto-populate which universes are required on which devices or to use a 'static' routing system. Because we are listening to an Art-net Speaking console, we need to be listen to a large number of universes.
A typical device that we would want to listen to could be a GrandMA VPU. It does not support Static assignment of Universes to IP address', and there is a requirement to be able to send more than 4 universes to an Art-net device..
Requirements
- Support multiple ArtNet Devices, one per logical network interface.
- Support unicasting data to a static list of IPv4 addresses.
- Support more than 4 ports in both directions
- De-couple the ArtNet universe from the OLA universe number to support any-way patching. i.e. patch ArtNet universe 5 to OLA universe 3.
Proposed Changes
Investigate Optimizing the Send Path
The sendmmsg syscall was added in Linux 3.0. It allows multiple datagrams to be sent with a single syscall. sendmmsg would allow us to reduce the number of syscalls required for each ArtNet packet when unicasting. This scope of this change is to make the required changes and then benchmark the performance.
Steps:
- Detect support for sendmmsg in configure.ac
- Add a method to the UDPSocket class to enable a single data message to be sent to many addresses
- Modify the ArtNetNode::SendDMX method to use the new UDPSocket method
with the large number of universes being used, the likely scenario is that most universes will only be used at a single destination, the number of replicated packets probalby is quite low
Multiple ArtNet Devices
Right now only a single ArtNet Device is created. This should be changed so that OLA creates one device per logical interface.
Currently the ArtNetNode object binds to the wildcard address (code) which means trying to create a second instance will fail.
We need some research into how broadcast traffic is handled with multiple interfaces. Ideally each instance should bind to the broadcast addresses for the specified logical interface.
Increased Output Ports
This shouldn't be too hard. Only the first 4 ports will be represented in the ArtPollReply responses. We'll need to store the net, subnet and port ids on a per-port basis. Right now the net & sub-net values are the same for all ports in a node.
Increased Input Ports
This is more challenging since it requires multiple IP addresses on the host in order to work correctly (that is, have the ports show up in ArtPollReplies). libartnet supported the concept of merging node instances, we should do something similar in OLA. It may be challenging to work out the corner cases when this interacts with the multi-device change.
