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) (→Usecases) |
Mrpackethead (talk | contribs) (→Investigate Optimizing the Send Path) |
||
Line 37: | Line 37: | ||
* 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 === |
Revision as of 16:55, 8 March 2013
This describes proposed changes to the OLA ArtNet plugin to make it more usable. Some of the use cases that have been requested include:
- 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.
Contents
Usecases
Using OLA as a 'protocol' converter, to allow equipment that is otherwise incompatible to work together.
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..
Using OLA as a 'protocol' converter, from Art-net to E1.31
Similar to above, but receiving Art-net and transmitting in E1.31.. It woudl be good to be able to support E1.31 in both Multicast and Unicast.
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 allos 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.