What is DDP?

[dkulp]

We use the 'push' flag already which does help if you run things like large P# matrices in bridge mode.   In bridge mode, every 50ms (settable on advanced settings), we take whatever data is in the buffer and send it out.   However, we don't know if we are in the middle of receiving a frame of data or anything so you can potentially get tearing.   With DDP, if we get the push flag, we send the data out immediately and restart the timer.  Thus, you are much more likely to have the full frame available.  I actually suggest with bridge mode and DDP to set the timer higher (100ms) and let the push flags control when the frame is displayed.     You would get much better timing than you do with normal e1.31 setup.  (That said, I did update the e1.31 bridge code to also accept sync packets and do the same thing, just quite a bit harder to setup than DDP)

[najetset]

I assume the choice of 1440 bytes of channel data (+10 for the header) was to fit nicely as payload in an ethernet frame?  Perhaps with some headroom left over for a .1Q tag?


If so, for those running jumbo frame networks (9000 octet MTU), can the DDP channel data payload size be increased to make use of the additional frame size?  I noticed today that the DDP setup in xLights max's out at 1440, and can only be reduced (I assume to allow for Q in Q tags?).  This would further increase the efficiency quite dramatically.  I suppose of course that this would also require the use of gigabit (or better) interfaces to be of any value.

[dkulp]

If so, for those running jumbo frame networks (9000 octet MTU), can the DDP channel data payload size be increased to make use of the additional frame size?  I noticed today that the DDP setup in xLights max's out at 1440, and can only be reduced (I assume to allow for Q in Q tags?).  This would further increase the efficiency quite dramatically.  I suppose of course that this would also require the use of gigabit (or better) interfaces to be of any value.

The spec itself only allows for 1440 due to the MTU.   There's likely a couple reasons, one being that almost all the devices we use just use 100MB ethernet which wouldn't support the jumbo frames.   The other reason is that the receiving buffers on the devices are likely not large enough.  I know in FPP, right now, I just use 1500 byte msg receive buffers as I "assume" that would be the largest.   I'm honestly not sure what would happen if it received a larger packet.    It would obviously not fit in a 1500byte buffer so I don't know if it would fully be dropped (udp would allow dropping frames) or fragment into multiple messages, but that could then really confuse the receive code as msgs wouldn't match the expected headers and such.     I'd be happy to increase the buffer size if someone would like to give it a try. 

[najetset]

I'd be happy to increase the buffer size if someone would like to give it a try. 

I'll be ordering a sancloud BBE, when it comes in I'll be happy to give it a go.  I'll let you know once it's all set up.

[dkulp]

I'd be happy to increase the buffer size if someone would like to give it a try. 

I'll be ordering a sancloud BBE, when it comes in I'll be happy to give it a go.  I'll let you know once it's all set up.

Nope.  Doesn't seem to support jumbo frames:

[20284.298261] eth0: Invalid MTU 9000 requested, hw max 1500

[kd7hgt]

So is this mainly for out P5/P10 panel setups?  I just deleted my Null setups for Xlights and changed them to DDP.  How are we doing the E131 stuff that directs it to the Falcon?  In my new DDP setup do I use the IP Address "Port" of my remote FPP?   Still trying to figure this DDP out.

[dkulp]

So is this mainly for out P5/P10 panel setups?  I just deleted my Null setups for Xlights and changed them to DDP.  How are we doing the E131 stuff that directs it to the Falcon?  In my new DDP setup do I use the IP Address "Port" of my remote FPP?   Still trying to figure this DDP out.

At this point, it's very useful for the P# setups, but it's also useful for things like PiHats and the various BBB based pixel controllers. 

[JonB256]

So is this mainly for out P5/P10 panel setups?  I just deleted my Null setups for Xlights and changed them to DDP.  How are we doing the E131 stuff that directs it to the Falcon?  In my new DDP setup do I use the IP Address "Port" of my remote FPP?   Still trying to figure this DDP out.

FPP units (Pi or BBB) can received DDP when they are in Bridge Mode. That's all the "setup" needed to make them DDP users. Of course, you'll still have to setup any pixel or panel outputs as for any other FPP mode of operations.

And, yes, you just need the IP address or (Dan says he's done this but I haven't) you can send DDP to the DNS Name you've given to the FPP unit.
I used DDP for everything this last Christmas (except for Falcon controllers that don't YET understand DDP).
It was great, eliminating many many many universe lines of setup in xLight and reducing network traffic due to packet efficiency.

[jnealand]

As I understand it there is no benefit if running master/remote with wifi sync.  It is basically for wired communications.

[dkulp]

As I understand it there is no benefit if running master/remote with wifi sync.  It is basically for wired communications.

More or less.  However, if you have your remotes setup in xLights as DDP (instead of a null output or similar), then you can easily test things on the live lights by flipping FPP from remote to bridge mode.   It's very simple.

[Stormyblade]

So, after reading through this topic, I have a question or two regarding my current setup, and whether or not setting up DDP would be more efficient/easier/less jumbled/etc:


Let's say, from the Capture1 picture included, my P10 matrix is a 5x4 matrix, 20 panels total, so it would be 60 universes with a total of 30720 channels, and I have it entered into xLights as a "normal" E1.31 entry (I couldn't include all 60 line entries in the screen capture, but you get the idea). Are you guys suggesting that to convert over to a DDP setup entry all I have to do in xLights is make an entry as I did in the Capture2 picture? Also, is there going to be a problem if I tell my BBB/Octoscroller to be in Bridge mode vs Remote mode when I am running my show and sequences? You guys mentioned that you flip from Remote to Bridge and back to test your matrix - that's why I am asking which mode to use when running.


Also, this year I am "upgrading" my P10 matrix to P5 panels - the matrix will be the same size, a 5x4, for a total of 20 panels, just in P5 pitch. This will double the channels and universes - this should not affect the way that the DDP protocol handles the data, correct?


I'm still trying to wrap my head around some of this and I think I understand it, but I just want to be sure I understand it. 

[dkulp]

P10 -> P5 is quadruple the data, not double. 


For the most part, you are completely correct.   It's a single entry in the xLights setup.   Obviously make sure the start channels are correct and the number of channels allocated to that DDP output entry covers the number of channels needed for the matrix, but that's relatively simple.


With a matrix that size, we generally would recommend running in remote mode in your show.   123K channels is a LOT of data to get across the network, even with DDP.  Thus, sticking with remote mode keeps the amount of network traffic down.   However, when testing things from within xLights, you may want to see what things look like on the "live lights".   Flipping the FPP over to Bridge mode and "enabling" the output in xLights allows that.   However, as mentioned, it's a TON of network traffic so it often doesn't look quite as good from xLights as in remote mode. 

[Stormyblade]

Thanks, Dan, for both giving me that explanation and correcting my math. 


I'd love to enable a DDP output within xLights to help erase all those lines of universe entries within the Setup tab -- my inner OCD loves it when I have fewer lines to scroll through. It sounds as though utilizing DDP in xLights and in FPP will help me have less screen clutter to go through. I'm still waiting on my P5 panels to show up from the January pre-sale, but I've already been going through my xLights setup with the intention of trying to make things less messy and to add my extra props I bought for this coming season.


Edit: I didn't mention it here, but I have mentioned last year that this network is on it's own private network, meaning I've got a Rasp Pi 3 running the entire show that is tied into an 8-port Gigabit router, and everything is hard wired. I shouldn't have network traffic congestion concerns about that setup, right?

[JonB256]

... I've got a Rasp Pi 3 running the entire show that is tied into an 8-port Gigabit router, and everything is hard wired. I shouldn't have network traffic congestion concerns about that setup, right?

When I went DDP to all my Bridge Mode FPPs (4 P10 panel matrices), plus a few E1.31 controllers, I had to go to a 16-port Gigabit switch.
By the time I was done and running, I had 5 ports left open on that switch.

[dkulp]

Edit: I didn't mention it here, but I have mentioned last year that this network is on it's own private network, meaning I've got a Rasp Pi 3 running the entire show that is tied into an 8-port Gigabit router, and everything is hard wired. I shouldn't have network traffic congestion concerns about that setup, right?

Network congestion - no, but you may be hitting other limits.   Using 25ms timing, 20 P5 panels will be around 6MB/s.  On the 100MB connections that both the Pi 3 (not B+) and BBB use, that's a very significant chunk of it.    Just something to be aware of.  It is a lot of data.