Packing universes: reducing channels per universe to minimize network traffic?

[watkinrt]

Summary: Rather than packing a bunch of controllers into a single universe through channel offsets, can you pack a universe by lowering the "channels per universe" setting on your controller?

Details
I have a relatively modest show with around 1200 pixels. All of my pixels run off 4x ESPixel Pops. This year I've been struggling with some latency throughout my display. Nothing huge (nothing like the 3-4 seconds I see a lot of people post about), but noticeable to at least my critical eye. The point of this post is not to track down this particular issue, but rather understand a concept I came across while investigating this issue: when running WiFi controllers (i.e., sACN), it seems to be recommended that you pack your universes. My basic understanding regarding this concept is as follows:

• The relatively standard channel count per universe for pixels is 510
• If you have just a small prop assigned to a default universe setup, even though your prop only uses a small subset of the channels, your controller still sends out data for all channels in the universe, even if they are just empty
• By packing your universes, you minimize the amount of "empty" data that you're sending out and hence minimize your network traffic burden.

So, back to my question: rather than trying to pack a bunch of controllers into one universe through channel offsets, etc, can you just reduce the channels per universe on your controller to achieve the same effect? I personally like the cleaner approach of having dedicated universes for a controller and reducing the "channels per universe" but I'm just not sure if I'm missing something obvious.

Thoughts?

Network setup

• All ESPixel Pops run on multicast
• I use a Ubiquiti Loco M2 AP for my WiFi and attach it directly to my raspberry pi running FPP
• I live in a pretty densely populated area, so the WiFi domain is pretty congested, which I believe is the primary issue I'm running into regarding latency

[pmiller]

510 is the maximum, well, actually 512 is but you can make it less if you like. However, on a large show you won't be able to span channels across universes meaning it would take more universes for the amount of channels. You don't need to change the 510 or 512 on the controller, just assign each universe the number of channels you want. Your controller setup in your sequencing software also needs to reflect the channel count. By using less channels for each universe you will end up using more universes.
BTW. When using multicast you're sending data to every controller and the controller sorts out what it uses. If you use unicast it only sends info to the designated controller assigned ip.

Sent from my SM-T710 using Tapatalk

[DreamKiller]

I was in your situation last year (my first year) with almost the exact setup. I have 20 ESPixel Pops and two rPi FPP remotes with Pixel PiCaps and the Ubiquiti Loco M2 AP. I had horrible delays. I don't know if allowed but there is a post on the Green site that helped me a lot.

https://www.diychristmas.org/vb1/sho...px3mmold9D3pgY

I got it working acceptably, but not perfect. WiFi will never be.

Things I did.
1) Setup the AP per the attached post, especially the Mcast rate.
2) Made sure the AP had the best line of sight to each ESP as possible . Made sure in the ESP connection status (ESP web page) was better than 70% and on the AP station status the TX/X rates were > 10s of Mbps, worst is 18Mbps. most are 72/54Mbs.
3) Used a Wifi scanner app on my android phone to find the best channel and lock the AP to that. I too have very congested WiFi.
4) Packed universes like a crazy person. I think this did the most good. For example I have wreaths each with 50 pixels and each on its own ESP. I combined 3 into one universe of 150 pixels (450 universe). So those three wreaths use the same data message. Other universes had odd sizes like 297. Some Universes serve multiple ESPs and other ESPs have their own universe depending on the model size. I did have some ESPs that controlled 600 pixels and crossed multiple universes. This year I replaced those with the FPP Ras Pi remotes thinking that might help, but don't think it really did. Point is I have 0 unused channels mixed in with used channels. My channels run contiguously from 1 to 11115 with no gaps.

I still notice small glitches here and there but no one else that does not do this stuff notices.

This is my XLAW submission using almost all WiFi controlled ESP this year. It can be done. Hope this helps.

https://youtu.be/Joe8n-zYV4Y

Paul

[David_AVD]

It will also depend on how the E1.31 sender sends the data. It may send the whole universe even if only a small number of channel are used, or it may send a smaller amount. I'd work on the assumption that whole universes are always sent.

[DreamKiller]

Oh and multicast is a must on WiFi. Unicast will keep trying until it gets through and acknowledged. On iffy WiFi this can really bog things down. I get up to 10% missed packets (sequence errors) on my ESPs and don't really notice using multicast.

Paul

[codec101]

I'm running just over 2800 pixels this year. Sure wifi
Would be most convenient especially with the area I have to work with but I just don't trust it for that reason. I too have a critical eye and even though I tell myself the folks watching won't know the difference, I will and it will bug me. I've been up and running for 2 weeks now and I'm still knit picking some of my sequences. I think I'll always prefer running a wire to everything.

[jchuchla]

Last I checked, in the case of short universes, xLights and LOR sent zero padded 512 channel universes, Vixen and FPP would only send the number of channels defined. But it's been a few years since I looked into that.

sACN isn't a particularly data efficient protocol. It doesn't matter a whole lot on a wired network, but it matters a lot on a WiFi network Each universe packet contains about 125 bytes of header data. So for a 512 channel universe, 20% of it is overhead. If you have a universe with only 50 pixels at 150 channels of data, then you're looking at 50% overhead. So it's always technically better to pack universes and send them full of meaningful data. How much it actually matters depends on your network.

Since you're using WiFi, channel packing is very important. You do want to use multicast. But on WiFi, regardless of unicast or multicast, it's still a shared network medium. It's not like a wired switched network where packets get directed where they are intended to go. The AP has to make time to send to all clients, and all clients will actually hear all traffic. They just ignore what is not meant for it.

Even in ideal well tuned WiFi scenarios, you can't actually send all too many universes. I haven't heard anyone successfully pushing more than 25 universes. I've got 18 WiFi universes in use here.

If you're already running into lag, making more universes is only going to make it worse, not better.

Pick the clearest choice of channels 1,6 or 11. Use the scanning function on the AP itself to determine the best choice. Set it fixed, not auto.
Use Multicast ONLY
Make sure to keep all phones and computers off of the show WiFi network. ESPs only!
Don't watch the stats pages of the ESPs while making observations about lag.
Make sure all clients have decent reception.
If you're still seeing lag after all of that, apply the multicast rate override settings to the AP.

[EE351]

Even in ideal well tuned WiFi scenarios, you can't actually send all too many universes. I haven't heard anyone successfully pushing more than 25 universes. I've got 18 WiFi universes in use here.

I'm running 26 universes over wifi. Any more universes introduces lag in my show (I verified this by adding a 27th universe). This is with 86 APs in use in my neighborhood, the 2.4ghz band is really crowded where I live.

Next year, I'm going to experiment with adding a second AP driven by a FPP remote on a different subnet, to split the wifi traffic evenly between both APs. I'm hoping this will allow me to add another 26 universes wirelessly.

[watkinrt]

Last I checked, in the case of short universes, xLights and LOR sent zero padded 512 channel universes, Vixen and FPP would only send the number of channels defined. But it's been a few years since I looked into that.

Interesting. As I am currently using FPP to play my show, it doesn't seem that this is my issue; although, I'll poke around a little more to see what I can find.

sACN isn't a particularly data efficient protocol. It doesn't matter a whole lot on a wired network, but it matters a lot on a WiFi network Each universe packet contains about 125 bytes of header data. So for a 512 channel universe, 20% of it is overhead. If you have a universe with only 50 pixels at 150 channels of data, then you're looking at 50% overhead. So it's always technically better to pack universes and send them full of meaningful data. How much it actually matters depends on your network.

This is what I was worried about. I hadn't really thought about it, but it makes sense that there is overhead associated with each universe. In my particular case, I have a pretty modest setup with 4 ESPixels spanning 8 universes. I think as best I could compress that down to 6 or 7; so, likely not much of an improvement from further packing.

Oh and multicast is a must on WiFi. Unicast will keep trying until it gets through and acknowledged. On iffy WiFi this can really bog things down. I get up to 10% missed packets (sequence errors) on my ESPs and don't really notice using multicast.

Hmm, maybe I'm overly sensitive? I think the my worst ESP has a 2% sequence error (which I've ready is pretty standard for sACN).

I'm running 26 universes over wifi. Any more universes introduces lag in my show (I verified this by adding a 27th universe). This is with 86 APs in use in my neighborhood, the 2.4ghz band is really crowded where I live.

Next year, I'm going to experiment with adding a second AP driven by a FPP remote on a different subnet, to split the wifi traffic evenly between both APs. I'm hoping this will allow me to add another 26 universes wirelessly.

Yeah, I've got the same problem: there are around 80 APs that my AP can detect when running the site survey. I'd be interesting to see if the second AP helps.

Thanks to everyone for your general comments. I think I've attempted most of the setup implementations posted (multicast, no phones or other peripherals on the network during shows, overall good signal quality [see attached], multicast rate override set to 24 mbps [although, it looks like the steady state TX for my show is around 800 kbps, so I'm not sure if this is really doing much]

[jchuchla]

If you’re still seeing lag even with the multicast rate override, then something didn’t get set correctly. You shouldn’t see lag as soon as you set that. What you might see is dropped packets. But not late ones.


Sent from my iPhone using Tapatalk