Setting up for unicast transmission

[BradsXmasLights]

Someone starting out won't have 16-20 universes.




Don't forgot DNS resolution adds extra packets too!

 

[damona]

Multicast does not need DNS, does not care what the IP address of the device is.

When you configure the universe on the controller you are also configuring the multicast address (which is automatic and follows a standard). The multicast IP address is static, because the dmx universe configuration is static (store in the controllers configuration).

Multicast sends the packets to the Multicast address, not to the IP address of the device. The controllers have multiple IP addresses, the IP address from DHCP, and the Multicast IP Addresses needed for each configure universe. The same multicast address may be on a few controllers, if the have the same universe and this is OK, its how it design to work.

If Pixlite did supported Address Auto Config (http://tools.ietf.org/html/rfc3330 169.254.0.0/16) you would not need a DHCP server or set fixed IP addresses.. All you one need is a Player/Transmitter(E.131) and network switch and E.131 controller and it would work it all out itself.

 (it does not support addr auto config, MS Windows does)


Some may say, what happens if my DHCP server dies, well everytime you turn the device on it asked for a lease extension (24 hours more is handed out), half way through the lease (12 hours), it will ask again for a lease extension (24 hours more is handed out).  Your DHCP server will have a setting to determine how large a lease to give out. You can increase this to weeks/months.  Under the standard if the DHCP server is down, it will use the same address, if it still has a valid lease. (not sure if devices like this remember lease information).

 

[multicast]

Multicast does not need DNS, does not care what the IP address of the device is.

That is correct, Multicast doe'snt.. but you may well need DNS so you can find your devices, easily.

When you configure the universe on the controller you are also configuring the multicast address (which is automatic and follows a standard). The multicast IP address is static, because the dmx universe configuration is static (store in the controllers configuration).

Um what your actually doing is setting up your device to say, "I'll accept these multicast packets that are addressed to 239.255.x.y. In E1.31, there is a mapping between the address of the multicast packet and the universe. ( 239.255.0.1 for example is universe 1 ). Its subtly different but important, as you can say have your device accept multiple different universes.

Multicast sends the packets to the Multicast address, not to the IP address of the device. The controllers have multiple IP addresses,

Not quite, see above, the devices accept not have multiple IP address's, but accept packets addressed to multiple multicast groups. You can't for example connect to the device's web page by a multicast address because which device would you be connecting to?



If Piglet did supported Address Auto Config (http://tools.ietf.org/html/rfc3330 169.254.0.0/16) you would not need a DHCP server or set fixed IP addresses.. All you one need is a Player/Transmitter(E.131) and network switch and E.131 controller and it would work it all out itself.

 (it does not support addr auto config, MS Windows does)

Little plug here for Stellacapes, we support AutoIP.. If your device is put into DHCP mode, and it doesn't get a DHCP address, it will self address according to rfc3330.. you can browse the network using mDNS / Bonjor[/SIZE] ( easiest using a simple plugin for your browser if you are using windows, or natively if you are using a mac )..

Some may say, what happens if my DHCP server dies, well everytime you turn the device on it asked for a lease extension (24 hours more is handed out), half way through the lease (12 hours), it will ask again for a lease extension (24 hours more is handed out).

The lease and expiry and refresh times are variable, it depends on how your DHCP is setup..


Not trying to be nit picky here, but it really helps just to understand what addressing is being setup..

 

[BundyRoy]

Thanks Damona/Driver/Andrew.

If telling the controller what universes you use tells it what IP addresses it needs, how come it is not better/possible to unicast straight to those addresses. It seems to me (and correct me if I'm wrong) that all IGMP is doing is effectively unicasting without the user having to set up any numbers. And there in lies my answer I suppose, it works just as well but the user doesn't have to set up the addresses.

Having said all that the controller IP must be required somehow, otherwise it would/could be as simple as telling the sequencer what universes you use (so it has the automatic IP addresses for those) and telling the controller the same and then Bob's your uncle the two should communicate.

Sorry for rambling but I'm trying to fathom it as I go and writing stuff down helps clarify it in my brain (and I think there are some crossed networks in there let me tell you). I'm now thinking you need to multicast because when you have multiple devices more than one is likely to need the same universe data and this can't be done in unicast (or can't be done as efficiently).

 

[multicast]

Thanks Damona/Driver/Andrew.

If telling the controller what universes you use tells it what IP addresses it needs, how come it is not better/possible to unicast straight to those addresses.

It is of course possible to unicast.. Why multicast?


(1) firstly, if you use the universe in any more than one place, then you reduce load. Unicasting requires your controller ( thats your media server/vixen/lor/lsp ) to send one packet for every universe to every device that uses it. Its additional workload for you controller, and its extra traffic on your network.


(2) The big one, is that you have automatic discovery.. You simply don't need to worry about seeing IP address's anywhere. Controllers or Devices. Just tell your device what Universes it needs, and done. If you are unicasting, you need to (a) statically define your devices ip, (b) configure which universes it needs, (c) tell your controller which universes need to be sent to which devices. It's three more steps of configuration.

It seems to me (and correct me if I'm wrong) that all IGMP is doing is effectively unicasting without the user having to set up any numbers. And there in lies my answer I suppose, it works just as well but the user doesn't have to set up the addresses.

Its not unicasting, because it only needs to send one packet per universe irrespective of how many devices need to receive it. But you really do get the point. Its a LOT less setup.

Having said all that the controller IP must be required somehow, otherwise it would/could be as simple as telling the sequencer what universes you use (so it has the automatic IP addresses for those) and telling the controller the same and then Bob's your uncle the two should communicate.

Your controller ( the mediaserver/lor/vixen ) actually doe'snt have to have any knowledge of the devices that are receiving the data under multicast. It simply just has to stick multicast packets out for the universes you need. Thats it.

Sorry for rambling but I'm trying to fathom it as I go and writing stuff down helps clarify it in my brain (and I think there are some crossed networks in there let me tell you). I'm now thinking you need to multicast because when you have multiple devices more than one is likely to need the same universe data and this can't be done in unicast (or can't be done as efficiently).

Not 'cant' be done, but certainly less efficiently, and more setup time.






Just to clarify, in E1.31 / sACN jargon


'controller' is the thing that is sending data out. that means LOR/LSP/vixen/madrix/GrandMA2 blah blah <insert your choice of software >


'device' is the thing that is receiving the data.
[SIZE=78%]I know that in blinky world 'controller' more often means the same thing as 'device' in E1.31 speak. [/SIZE]

 

[BundyRoy]

So in LOR is the LORCommlistener the controller (ie sends out the data), or is it a program that as the name suggests listens and reports the data transfers.

 

[Beacy]

Well after ready this and understanding about half of it I will throw out a senario for suggestions.


As mentioned in another thread I am having issues with the show coming out of LSP Scheduler running in slow motion.... which sort srews the show... I have gradually increased th refresh rate to 200ms which has shown than it appears to be the speed that data is getting to the controllers.


I have 32,0000 channels- 166 universes - hardware - 6 Pixlite 16's - 5 PixAD8's - 4 DR4's running 16 AVD 48's and running in Multicast.


Will switching to Unicast result in a lower amount of data being pumped into the network and possibly allow the show to run at the correct speed?

 

[nutz4lights]

Hi Beacy,

I have been battling this as well (see: http://auschristmaslighting.com/forums/index.php?topic=6784.0 )

I have around 30,000 channels give or take a 1,000, over 100 universes as well. I am running Unicast, always have, because I was under the impression that it was required with this much network traffic and this many controllers. I have ten controllers out in the yard with unique IP addresses.

Even with Unicast, though, I was still having issues with lag coming out of LSP Scheduler... Someone recommended turning off the wifi I had running on the machine, which I did, and that helped a little. Someone else recommended making sure to deactivate any outputs that weren't actually going to controllers (I had a portion of my display out hence the controller was not plugged in and I can tell you that helped as well). Last but NOT least, the largest impact actually came in the way I sequenced my macros... Eddy recommended changing the frames per second setting in the macros utilizing the largest allotment of channels from 15FPS (the default and the value that I was using) down to 8-10FPS. That made the largest impact for me, just a few days ago... I had to go back in and change all of my sequences (Mine were not music-based so I created new ones which is easier than re-doing them)... now my display is running smoothly, again, using LSP Scheduler...

- turn off any other network cards in the computer
- make sure there aren't signals going to an IP address that is not turned on to receive them
- make sure that the macros and effects you are using are not overkill (mine is super smooth with 10FPS)
- I have also been rebooting after creating a schedule and letting the sequences optimize...

-Louie

 

[Beacy]

hmmmmm. I don't use transitions for that one reason as I have alwasy been aware of the the size issue they cause. All I use is Nutcracker for the tree and I don't believe that has a FPS option.


Now you have thrown me back into the possibility it is a software issue

 

[fasteddy]

The reason is that you would be decoding and sending much more data with additional timings than what is really needed to be processed and sent and this is why Louie found that by reducing the frame rate in macros to around 10ms you still will get a smooth effect but you are reducing the load by 1/3 which can make a huge difference to the amount of data being processed and sent out into the network

 

[multicast]

For what its worth the E1.31 standard doesn't have unicast as an option. So according to the standard, if you are sensding packets in Unicast, its not E1.31. Its e1.31 "like"

 

[AAH]

I don't know if it would be an issue or not but you are running more than twice, almost 3 times, the universes necessary for the number of channels you are running. If it's necessary to send out full universes worth of data to each of the devices at each update then you are sending out over 85,500 worth of channels for the 30,000 that you are using. Only the E1.31 gurus and LSP developers could answer this question probably.

 

[Beacy]

I have shortened all the universes ie one universe start ch is 1 last is 48 next uni start ch is 49 end is 120 depneding on the no if pixels in the universe




The other thought was would changing the "speed" settings on the DR4' PixAD8's & Pixlites make any difference ?

 

[damona]

Your missing out on the big benefit of MultiCasting. Re-Read this thread.
Unicast forces you into one packet per controller. If you have multiple controlers using part of a Universe then only one packet is required to change them all. Be smart with you universes. Have one universe which covers all the small objects/display items, that only have a few pixels, that way you can control lots of things with one packet, the same Universe can be used accross many controllers (different DMX Channels).


If using a private network for the show, I recommend, have an old ADSL Wireless router on the network, let it just be the DHCP server and the Wireless access point if you need to connect to the network. Then Plug the ADSL router into a IGMP Snooping Switch, then plug the controllers into the IGMP Snooping Switch, then plug the thing running the show into the IGMP Snooping Switch (e.g. Raspery Pi)

When configuring the controllers give them "Names". e.g. Pixlight range can have names set, so when your using the windows configuration software you know which is which.

 

[Beacy]

Ok am I correct that even though I have cut the size of the universes down I am still pumping out more data than needed which is bogging things up?


Therefore I may be better off with Multcast