multicast ip numbering

R

robertt

New elf
Joined
Mar 12, 2012
Messages
32
Location
berghem
hello,

Got a question about how I should assign the ip numbers when I want to run in multicast.
I have got 4 x p12, 5 x p2, 1 x d2 running a total of 5000 ws2811 modules and some dmx lights.
Can I just give every board the subsequent ip-number with the same subnetmask or is there an other aproach I should take to not overflow the boards with data?
maybe some fancy ip numbering or a switch that can filter the multicast data?

greetings, robert
 
As the default number on J1sys boards is 10.10.10.10 I change them from this and do it sequentially 10.10.10.11, 10.10.10.12 & 10.10.10.13 for my pix8's and then use 10.10.10.20, 10.10.10.21 for my p2's but nothing much fancier than that.


I leave the subnet mask as it is
 
the 10.x.x.x ip address you are talking about is only for the web server on the controllers. nothing at all to do with multicast which is UDP not IP


However there is another IP in use in sACN (E1.31) which is in the 239.255.x.x subnet which starts at 239.255.0.1 for universe 1, 239.255.0.2 for universe 2 etc for a total of 65000 universes. This is the one you need to make sure goes down the right NIC card if you are running multiple network cards on your system and it may not the be the default network.


So from a webpage control perspective then you just need to assign a unique IP address in the same subnet to each controller and it only gets used when you connect to the controller through a web page to configure it.
 
neil said:
However there is another IP in use in sACN (E1.31) which is in the 239.255.x.x subnet which starts at 239.255.0.1 for universe 1, 239.255.0.2 for universe 2 etc for a total of 65000 universes. This is the one you need to make sure goes down the right NIC card if you are running multiple network cards on your system and it may not the be the default network.
Click to expand...

Okay, clear. (got only 1 NIC)
But should I do something to prevent the controllers from an overflow with data (and if so, what?) or should I not worry about overflowing the controllers?

I could just test if everything is ready but it helps me a lot to understand what I'm doing :)

Thanks!
Greetings, Robert
 
How many controllers and how many universes are you planning on running

Generally for any of the displays we are doing, data flooding the controllers is not really an issue.
 
ɟɐsʇǝppʎ said:
How many controllers and how many universes are you planning on running

Generally for any of the displays we are doing, data flooding the controllers is not really an issue.
Click to expand...

I have got 4 x p12, 5 x p2, 1 x d2 running a total of 5000 ws2811 modules and some dmx lights.
planning on 35 universes...

greetings, robert

* modified typo's; S3 and my fingers are still to big... :(
 
if you have too much traffic that will overfill the 100Mbs network then you will need to look at a layer 2 router that gives you the capability of IGMP routing for the multicast traffic and managed switchs. fortunately you are not getting close to needing to that yet.
 
neil said:
if you have too much traffic that will overfill the 100Mbs network then you will need to look at a layer 2 router that gives you the capability of IGMP routing for the multicast traffic and managed switchs. fortunately you are not getting close to needing to that yet.
Click to expand...

hi neil,

In some other topics it was already explained that overfilling a network is not likely....
I just don't know how wel all j1sys products can coop with the multicast traffic.
Got my main cabinet nearly ready and then I can test but if I have to change things then that
is not so easy....

greetings, robert
 
when you think of any multicast traffic on a network segment, the controller is going to need to do some processing on each packet. the best thing a controller can do is quickly reject the packets its not interested in and that's done with some lookup xref tables held its cache. not sure how far j1sys has taken this though.


So if you only have 1 segment all traffic is going to route down it, the next step up is to start routing the multicast traffic using IGMP which requires a layer 2 router and experience in setting up the VLANS to add more network segments. that way you can reduce the multicast traffic on each segment. I am sure this is something that Andrew (MPH) is very familar with since his installations are now approaching 500 Universe. He may not be using E1.31 (sACN) for this though and go more down the Art-net route.
 
Can you set your software to push traffic via Unicast instead of Multicast? Packets will then be directed to the NIC of the controller.

I setup Unicast on all my controllers in LSP.
 
burner said:
Can you set your software to push traffic via Unicast instead of Multicast? Packets will then be directed to the NIC of the controller.
Click to expand...

Hello burner,

Thought about unicast but there are some great apps that allow you to test the lights with your cell.
They all only use multicast.....
100 day's until our show so can still test :D

Greetings, Robert
 
it will direct the traffic to the NIC assuming that the switch is intelligent to only send traffic for that specific IP down the switch port that the controller is hanging off, home based switch's dont do this too well.

burner said:
Can you set your software to push traffic via Unicast instead of Multicast? Packets will then be directed to the NIC of the controller.

I setup Unicast on all my controllers in LSP.
Click to expand...
 
neil said:
it will direct the traffic to the NIC assuming that the switch is intelligent to only send traffic for that specific IP down the switch port that the controller is hanging off, home based switch's dont do this too well.
Click to expand...

I think you are thinking of the old school "hubs", any "switch" will only pass unicast traffic on ports that the MAC address is advertised on. The discovery of the MAC address is broadcast, but once the switch has learnt the port it exists on, the traffic will only be sent port to port.
 
David_AVD said:
Is there a reason it has to be a phone based testing app?
Click to expand...

euhmmmmm, no. Can't think off a reason it has to be a phone.
but it sure will be cool!! :D :D :D :D

greetings, robert
 
You must log in or register to reply here.
Back
Top