Setting up for unicast transmission

[multicast]

I'm getting mixed responses (which is good and normal) so I figured it is time to get some specifics. I have put an extra network card in my computer already to separate the ADSL from the lights. The lights don't run through a switch or router. I only have one controller so it is hooked up direct. I guess I should plan for a switch in the future as things expand.I currently only have around 7 universes in play.

From what I can workout it all hinges on whether I can reasonably expect to be able to use the computer for other stuff whilst it is being used for controlling the lights. If it is possible to use it then I don't really want multicast to be killing the use of the internet and the kids wifi for their ipods.

If using the computer whilst it is controlling lights is likely to cause problems with the lights then I guess that makes the decision simpler. Go back to multicast and tell the kids to keep their ipods off. Leaving the ipods off won't stress me at all.

It absolutely possible to use multicast on your home network and keep everything happy!!

 

[BundyRoy]

I'm having trouble understanding the logic here. My understanding is that multicast sends the data (packets?) to every address in your network so that it has to go to the ones that need that data.

If this is the case then do I somehow have to give it a range of names/addresses to multicast to so that it doesn't overpower my ADSL modem. I just can't fathom how the computer can be constantly sending data to the modem and the modem can still work properly. If I have to set up a range is this done under the DNS tab in the TCP/IPv4 properties. I think I've worked out that if I set it to choose IP address automatically this enables DHCP.

I'm sorry to keep asking but I have been trying to work this out by myself and I just can't seem to understand it. You may have noticed things really bug me when I can't understand them.

For what it's worth, and I'm not even sure it's related, I have my network connection set up with the IP address 192.168.0.10, and subnet mask (whatever that is) 255.255.255.0. My logic behind doing this was the IP address is in the same range as the controller (192.168.0.60) and I can't remember but I would have got/copied the subnet mask from somewhere.

This network connection is connected directly to the controller (at this stage). Everything else goes through another network connection. I realise it's been said I don't need two, but I have two now so that's how it is.

I realise I've probably covered heaps of areas that need addressing but if anyone could point me in the right direction I would be very grateful.

 

[multicast]

I'm having trouble understanding the logic here. My understanding is that multicast sends the data (packets?) to every address in your network so that it has to go to the ones that need that data.

Unicast: one to one
Broadcast: one to everything
multicast: one to *some*

If this is the case then do I somehow have to give it a range of names/addresses to multicast to so that it doesn't overpower my ADSL modem.

Excellent question. the answer is you don't have to provided your network supports IGMP snooping, and your controller devices reply to IGMP.


It works like this.


Your controller devices 'annouce' to the network, which multicast 'groups' they want. or E1.31, there is a one to one mapping between Universe numbers and Group numbers. If you want universe 1, you'd announce to the network ( with an IGMP reply ) " I want group 239.255.0.1 ". Your switch "snoops" on on those IGMP messages, and works out what Multicast messages need to go where. ( it builds a forwarding table ). So, if the switch as worked out that controller A and B, on ports 1 and 3 for example want the group 239.255.0.1 ), it would only forward that packet to to ports 1 and 3. If your ADSL modem was on port 24, it woud'tn see this multicast ( unless it had asked for it ).


Switches that don't support IGMP properly, flood multicast to every port on the switch, because they simply don't know how and where to forward to.

I just can't fathom how the computer can be constantly sending data to the modem and the modem can still work properly.

As above, if the switch is running IGMP properly, the data simply doesn't get there, and its not a problem.

If I have to set up a range is this done under the DNS tab in the TCP/IPv4 properties. I think I've worked out that if I set it to choose IP address automatically this enables DHCP.

Not DNS, but it seems you've found the right place. Yes, setting it to automatic, will let it get an address from a DHCP 'service'. Often this is your ADSL device in home networks. In bigger networks it can be a whole server or servers.


For what it's worth, and I'm not even sure it's related, I have my network connection set up with the IP address 192.168.0.10, and subnet mask (whatever that is) 255.255.255.0.

Ok, what that means, is that your IP address is 192.168.0.10 and the subnet mask tells us what address's are on the same local network as yours. Subnet masks are another topic, but please just accept this means that address's from 192.168.0.1 to 192.168.0.254 would be reachable via your local network. and they do not need to be 'routed' via your router. ( 192.168.0.0 and 192.168.0.255 are special address, the .255 is the broadcast address for the network and the .0 is the 'network' address. Again another topic, but suffice to say, you can't use them to address devices )..


If you had a network address of say 10.50.50.45 and a mask of 255.255.255.0 your range would be 10.50.50.1 to 10.50.50.254 )

This network connection is connected directly to the controller (at this stage). Everything else goes through another network connection. I realise it's been said I don't need two, but I have two now so that's how it is.

"everything else" is done by using the default route. its sometimes called 0.0.0.0/0 that measn "the entire internet". Routing works by looking for the most specific ( smallest ) networks first, and using that rule.. you'll even find on your local pc, a routing table ( try running 'route print' from the command line )


So, you have a set up that is like this..


192.168.0.0/24 is avaialbe locally,
0.0.0.0/0 is available by sending the packets to your adsl router.


Now here is a trap. If you are running multicast on windows, the OS will send the mulicast packets out the interface that has the default route. that because it does'tn have any specific routes for the multicast address's. So, if you have two interfaces, one for 'lighting' and one for 'internet', you might find that you need to put in a static route for the multicast.. ( again another topic )...


This traps up lots of people, i hard, and is why i strong advocate for networks that support IGMP, and use DHCP for addressing, and multicast for sending data out. It because it just works without needing to make lots of manual setup entrys.

I realise I've probably covered heaps of areas that need addressing but if anyone could point me in the right direction I would be very grateful.

yes, one or two topics!!

 

[BundyRoy]

Thanks for the reply Andrew. Whilst I won't pretend to understand all that you said it does help.

With the IGMP snooping, I gather this something that applies to switches/routers or can it apply to the network card interface on your computer as well.

Is there a way to tell if your switch is IGMP compliant without going through the paperwork.

 

[BundyRoy]

Just came home and checked my modem/router. It says it has IGMP snooping V1/2 and IGMP multicast. Sounds like it might be right for the job.

 

[BundyRoy]

I noticed the other day when I was configuring the network settings in LOR that for universe 1 if I chose multicast it set the IP address to 239.255.0.1 and for universe 2 in multicast 239.255.0.2 etc etc. Then I notice that when you refer to universe 1 and the controller asking for 239.255.0.1. Is this some universal standard for IP addresses. And how does the controller ask for 239.255.0.1 if its IP address is 192.168.0.60, they are not even in the same range.

I did the route print command as you suggested. I think I can understand what is showing in the active routes. I would have been very confused though if you hadn't mentioned about the 255 being the broadcast address and the 0 being the network address. So thanks, otherwise I would have been wondering why there so many active routes.

It just came to me. You mention that in windows the multicast data is sent to the default interface option. In my case the default option has IGMP snooping on the router so the data should then go nowhere on the router. I guess the problem is not so much tying up the router as much as the data not getting sent to the second interface. My issue is that I'm pretty sure that when I was using multicast and had the lights running I couldn't use the internet. I'm not 100% sure on that now as it was a while ago but if it was the case then my understanding of the above is wrong.

The only other thing I can think of that may cause it is the "comm listener" (can't remember the name) that fires up when I use LOR. Could this of been the issue not the multicast.

 

[bluzervic]

I tried Multicast at first, and realized the constant Multicast Chatter on the network was intense. So I changed to static IP's(unicast). The downfall of this is the P16 and P4 do not allow you to set The default gateway like some of the other controllers.


I use two NICS in my network to keep the Normal house traffic off the E1.31 traffic. Eventually I will Isolate my PC from the house network all together. Not sure when I will get to this though. I do not route the E1.31 network though, so that tends to keep it separated enough.


If you use DHCP, consider setting a Permanent reservation for the IP address. Then you should have no problems.


-Blu

 

[multicast]

Thanks for the reply Andrew. Whilst I won't pretend to understand all that you said it does help.

With the IGMP snooping, I gather this something that applies to switches/routers or can it apply to the network card interface on your computer as well.

The "IGMP snooping" is something that the switch does. "IGMP" is what your devices need to participate in. So the switch is listening in ( 'snooping') on the IGMP conversations that are going on between your devices.


I think at next years Minis, we really should have a practical session on this.




Is there a way to tell if your switch is IGMP compliant without going through the paperwork.



Got a make / model, I could probably work it out for you.

 

[multicast]

Just came home and checked my modem/router. It says it has IGMP snooping V1/2 and IGMP multicast. Sounds like it might be right for the job.

Sounds like you've got something that will do the job. This used to be somethig you'd only find on high end gear. But now you find it on $40 switches and ADSL boxes..


You'll need to double check with your controller supplier, if they support IGMP. All of Stellascapes gear does ( some earlier firmware might need upgrading )..

 

[AAH]

Unicast is more load on your network.

Yes no and Maybe. If you have the situation where more than one receiving device is receiving the same universe then this is true. your controller ( the thing sending the data ) only has to send one packet of data per universe. If you had three devices all receiving universe 7, you'd save sending two packets when compared to unicast ( which would mean, the controller sending the same data in three packets ).

ADSL routers that are switch based are fine. Besides most adsl routers would not have enough ports and would be used to allocate an IP only. Or be a wireless bridge so you can check your outside network.

In smaller set ups, you'll probably get away with any old switch. My general advice here is anything less than 16 universes and you'll probably be ok.

For larger setups, what ever is doing the switching in a multicast environment, needs to be able to make "forwarding" decision for the multicast packets. The feature you are looking for is called "IGMP Snooping". Switches that are not multicast aware, will simply forward any multicast packet to every port on the switch. What that means is that if you had say 100 Universes ( and therefore 100 packets ), every device on every port would see every universe. Your switch may well handle that, but many of the devices that are in common use in blinky world simply don't have the ability to cope with this. Effectively they would be spending most of their time, discarding packets that they did'tn need.

My general advice here is anything less than 16 universes and you'll probably be ok. <<<-- 16 universes or 16 E1.31 devices? I'm assuming 16 E1.31 boards as there are a number of individual boards that will do a lot more than 16 universes on the 1 board. I'm only assuming and I have been known to make some bad assumptions over the years.

 

[multicast]

My general advice here is anything less than 16 universes and you'll probably be ok. <<<-- 16 universes or 16 E1.31 devices? I'm assuming 16 E1.31 boards as there are a number of individual boards that will do a lot more than 16 universes on the 1 board. I'm only assuming and I have been known to make some bad assumptions over the years.

16 Universes. The number of devices doesn't make any difference.. You could have 200 devices, and 16 universes, and you'd be fine.. But you could have 200 universes and 16 devices and have lots of trouble.


each universe requires 1 packet irrespective of how many things are receiving it.

 

[BradsXmasLights]

For anyone starting out with just a handful of controllers and/or universes, I'd just be assigning static IP's to your controllers and using Unicast.


Multicast IGMP filtering whilst good in theory is infamous IMO for screwing up on cheap switchgear and/or if the controlling software isn't programmed correctly.

Even if you had to send the same universe to multiple controllers (eg: as multiple packets) - it's going to make bugger all difference unless your already at the grand-scale of lighting productions.

With unicast, you don't need to worry about flooding your Wireless access point, or any other slow devices on your network that can't tolerate the fast packet rate.

As for DNS hostnames - just dymo label everything with it's IP - and you'll be remembering it in no time. Not an enterprise network here

 

[BundyRoy]

Just checked my controller and the pixlite 16 supports IGMP. So it looks like I am slowly heading in the right direction. So now I know that I have to enable DHCP on the interface and I can do that. Is there settings I need to have on the router to make sure it uses IGMP snooping or does this happen automatically.

Thanks again for your patience with my slow uptake and all your replies.

 

[damona]

Re: E.131 and Multicast

pixlite is best with DHCP and Multicast. As the management software scans the local subnet for any pixlite controller. You can give the pixlite controller a name and it will be show in the management interface.

With the pixlite you do not care what its IP address is. It's only used by the management software running on your PC, and as I said, every time you start the management software it does a scan.

pixlite 16 more than likely will use more than one Universe. Pixlite 4.

An example might be that you have 5 x Pixlite 4 controlers. The first cable/outlet of each is used to control a candy cane with 8 pixels. The second cable/outlet, of each Pixlite 4 controls a bar light 16 pixels. So that one packet can control all of the candy cane you use once universe and spread that universe's channels across all of the 5 x PixLite 4

Some Controllers have web interfaces, and they maybe be better off with fixed DHCP IP.

When using more than one network card, ensure the packets are going to the right network card. My laptop has virtual network cards for Virtual Machines, a Wireless card etc. For xlights I had to disable the other network interfaces to force the packets to the right network card. Vixen 3 has "Mutlicast <Name Of Network Card>" when setting up the E.131 controllers.

 

[multicast]

For anyone starting out with just a handful of controllers and/or universes, I'd just be assigning static IP's to your controllers and using Unicast.

I deeply disagree with this, and have hundreds of installations worldwide to back up this positoon

Multicast IGMP filtering whilst good in theory is infamous IMO for screwing up on cheap switchgear and/or if the controlling software isn't programmed correctly.

really? Any more trouble than dual nics, changing routes, overloaded controllers? and misconfigured static configs.

Even if you had to send the same universe to multiple controllers (eg: as multiple packets) - it's going to make bugger all difference unless your already at the grand-scale of lighting productions.

As previously discussed, its in the range 16-20 universes where things often start becoming detrimental.

With unicast, you don't need to worry about flooding your Wireless access point, or any other slow devices on your network that can't tolerate the fast packet rate.

As for DNS hostnames - just dymo label everything with it's IP - and you'll be remembering it in no time. Not an enterprise network here

Or enjoy the fact that you can have a dyncmially and automatically setting up list.