Author Topic: DDP Usage  (Read 402 times)

Offline Poporacer

  • Sr. Member
  • ****
  • Join Date: Dec 2017
  • Location: Meridian Idaho
  • Posts: 361
  • Kudos: 5
DDP Usage
« on: January 13, 2019, 01:28:49 PM »
I would like to understand the DDP protocol and how to use it. From my understanding, DDP is used for the actual transmission of sequencing data to the various FPP instances while your show is playing? So if you are using a Master/Remote setup, DDP would only be beneficial for testing if you want to send data directly from XLights?
When you set up the DDP, there are some options, what do the various options do? i.e.
Id? It populates with 64001 and because it auto-populates, I assume the default is what you should keep? What is the purpose for this number, where do you use it? Does it need to be unique? (when I create a second DDP channel, it populates with the same 64001 id). What would the repurcussions be if you changed the id to like 1, then the next DDP controller to 2?
Then there are the number of channels. Does this have to match the number of channels you are actully using on that controller? If not, what repurcussions are there if you use a significant amount over what you really need?
The Channels per packet are prepopulated as well, what is this setting used for?
Then Keep Channel Numbers comes pre-selected, what is the purpose of that function?
Finally there is the Supress Duplicate Frames, what is the purpose of that function?

Thanks for the information!
If to err is human, I am more human than most people.

Online dkulp

  • Developer
  • ******
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,429
  • Kudos: 78
Re: DDP Usage
« Reply #1 on: January 13, 2019, 03:17:41 PM »

ID is something Keith added only for use in xLights.   Basically, it gives it a universe ID so if you use the "Universe:Offset" style numbering, you can use that ID as the universe.   Kind of silly to me, but whatever.   Just make sure it doesn't conflict with any other universes of anything you have defined.


Number of channels is the number of channels you need to send to that controller.   For something like P5s, it's the total number of channels you need.  Feel free to send more channels, they will waste network bandwidth, but be ignored on the other side.  For me, I have each controller set for about 1-2K extra channels to give me space to move things around a bit without having to renumber everything.


Channels per packet - for the most part, leave that alone.  If you need to set a lower MTU on your network card, you may need to reduce this. 


Keep channel number - when a packet is sent, we can either use the same channel start numbers as we do in xLights or we can set them to be offset from the beginning of the controller.  I would expect Vixen to use the later more than xLights.   For example, if you setup your P5 panel to be "start channel 1" in FPP, you can turn OFF this option and move the channels around in xLights all you want.  The problem is that when we generate the fseq files to run it in remote, the channels wouldn't match.  (enhancement request for FPP connect.... Hmmmm)


Suppress duplicates - if a frame is the same as the previous, don't send.   Just an optimization, particularly for black frames or tune to's that don't change much.









Dan Kulp

Offline jchuchla

  • Sr. Member
  • ****
  • Join Date: Jul 2014
  • Location:
  • Posts: 355
  • Kudos: 1
Re: DDP Usage
« Reply #2 on: January 13, 2019, 04:24:10 PM »
I hope you don't mind if I tag on a few more questions to this thread since it's an extension to the same questions.

Does DDP or falcon's implementaton of it have any rules regarding packet rate?  e.g. minimum and maximum number of frames per second?

What's the behavior on the loss of the DDP stream?  Does it detect the loss of the stream?  e.g. no packets in xxx time? or something similar.  What does it do when the stream is lost?  Stay in last state, turn off?

What's FPPs behavior if it [near] simultaneously receives DDP streams from two different sources at once?

Offline Poporacer

  • Sr. Member
  • ****
  • Join Date: Dec 2017
  • Location: Meridian Idaho
  • Posts: 361
  • Kudos: 5
Re: DDP Usage
« Reply #3 on: January 13, 2019, 08:47:05 PM »

ID is something Keith added only for use in xLights.   Basically, it gives it a universe ID so if you use the "Universe:Offset" style numbering, you can use that ID as the universe.   Kind of silly to me, but whatever.   Just make sure it doesn't conflict with any other universes of anything you have defined.
just so I am clear, could you have 2 DDP networks with the same id but because they reference different IP addresses, then it will be ok? Or does the id have to be unique? If so, maybe put a test there to prevent it? And on the Layout page, you could use either Absolute Addressing or the "Id:offset" method similar to Universes where each controller would start at channel 1?

Also, I currently have some universe/Channel E.131 setup and want to keep them because I am using Master Remote and want to see how DDP works in my scenario. When I make the E.131 networks inactive and add the DDP setups, It will set the beginning start channel to the next available channel. So if I want to use the DDP for testing directly from XLights, then I will have to change all of the Model Start numbers to match the DDP channels and then back again once the testing is over?. I think I am missing something.

Thanks!
« Last Edit: January 13, 2019, 09:25:56 PM by Poporacer »

Offline Poporacer

  • Sr. Member
  • ****
  • Join Date: Dec 2017
  • Location: Meridian Idaho
  • Posts: 361
  • Kudos: 5
Re: DDP Usage
« Reply #4 on: January 15, 2019, 10:45:00 AM »
I am trying to learn all the abilities and capabilities of XLights and FPP, so I am playing with the DDP and I am having some problems. Is DDP only efficient for wired networks? In my testing, I have only one 9 panel P10 setup and I have a strong wireless connection to both the laptop and the P10 panel. When I change effects in XLights, I can walk to the other room and it will take a few seconds for the effect to change. Once it does change, the display is very choppy. Am I missing something?

Online JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 5,137
  • Kudos: 119
    • Granbury Christmas Lights
Re: DDP Usage
« Reply #5 on: January 15, 2019, 06:42:33 PM »
I know Dan Kulp has done DDP over wireless for testing but not for running production sequences.
I used DDP extensively but only over CAT5. I am not surprised by the choppiness you're seeing over wireless.

Offline nickd

  • Newbie
  • *
  • Join Date: Dec 2018
  • Location:
  • Posts: 4
  • Kudos: 0
Re: DDP Usage
« Reply #6 on: January 15, 2019, 09:21:53 PM »
Did you test with E1.31?  Did you see the same choppyness?  DDP should be more efficient then E1.31 over wireless.  E1.31 uses more packets to convey the same amount of information as DDP.  And since every packet is subject to varying latency caused by interference and congestion, the less packets needed the better.

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 1,354
  • Kudos: 43
Re: DDP Usage
« Reply #7 on: January 15, 2019, 09:35:58 PM »
In my tests with DDP over wireless it was much smoother and had less packet errors than E1.31 over wireless
-Mark

Offline jchuchla

  • Sr. Member
  • ****
  • Join Date: Jul 2014
  • Location:
  • Posts: 355
  • Kudos: 1
Re: DDP Usage
« Reply #8 on: January 15, 2019, 09:54:14 PM »
DDP is unicast only, which means that when used on WiFi, it's subject to link layer acknowledgements.  The WiFi network is going to guarantee that every packets gets there.  But in order to do that, it'll take as much time it needs to make sure it gets there.  If DDP isn't working well for you, it's because your wifi network is sketchy at best. 

DDP will likely perform better than sACN via unicast.  But it won't overcome network issues

SACN via multicast gets around the issue by throwing away data rather than using it late.  On a poor wifi network, you'll still have skips, but not late packets.  would you rather have all the data even if it arrives at the wrong time, or would you rather only get the data that is there at the right time?

Also worth noting is that WiFi is an asymetrical link.  It's designed to serve client devices consuming data, not server devices providing data.  It will give more airtime to data going from the AP to devices than it will to traffic coming from a device to the AP.   So if you're sending DDP data, the sender should be on the wired network segment, and only clients should be on the WiFi segment.  If you try to send DDP (or any large volume of unicast data) from a wifi device out to the network, you can expect it to suffer from a lot of queueing of data and see a lot of stutter and lag.  Even worse if you're sending from wifi, to the AP and back to Wifi clients.  Wifi is not really intended for client to client communications.  In that case you're pumping that data thru the same wifi network twice.  It's really optimized to transfer data from the wired network to devices on the wifi side. 





Offline nickd

  • Newbie
  • *
  • Join Date: Dec 2018
  • Location:
  • Posts: 4
  • Kudos: 0
Re: DDP Usage
« Reply #9 on: January 15, 2019, 11:33:21 PM »
Yes the trade-off of reliability over latency in WiFi does make WiFi less then ideal for this type of application, though the L2 ack favors DDP as you will have less packets to ack.  However, if you have a network with poor latency it won't matter much which protocol you run.

Now for the discussion of multicast over WiFi, don't virtually all APs do a multicast to unicast conversion?  I know that use to be the case except for enterprise gear where you could control that. 
I haven't really kept up with that so it might of changed.  The simple idea was that true multicast over 802.11 had to run at the slowest speed so it was usually faster to send the packets serially via unicast at the faster speeds with the added benefit of avoiding the numerous other problems associated with multicast over 802.11 (https://tools.ietf.org/id/draft-mcbride-mboned-wifi-mcast-problem-statement-01.html)

Great discussion.


Offline jchuchla

  • Sr. Member
  • ****
  • Join Date: Jul 2014
  • Location:
  • Posts: 355
  • Kudos: 1
Re: DDP Usage
« Reply #10 on: January 16, 2019, 07:32:25 AM »
Now for the discussion of multicast over WiFi, don't virtually all APs do a multicast to unicast conversion?  I know that use to be the case except for enterprise gear where you could control that. 
I haven't really kept up with that so it might of changed.  The simple idea was that true multicast over 802.11 had to run at the slowest speed so it was usually faster to send the packets serially via unicast at the faster speeds with the added benefit of avoiding the numerous other problems associated with multicast over 802.11 (https://tools.ietf.org/id/draft-mcbride-mboned-wifi-mcast-problem-statement-01.html)

Great discussion.

I don't use a lot of different APs.  Now that the higher end options are affordable enough to use for almost any application, there's not much need for me to play with SOHO type APs.  But most of the higher end APs that I'm aware of do handle multicast properly.  Multicast is becoming more and more common in enterprise networks.  VoIP systems use it for paging and group calls.  IPTV uses it.  Some APs do have the option to convert multicast to multiple unicast.  But if the AP is following spec, that's an option, not the default behavior. In the Ubiquiti APs, that option is called "Multicast Enhancement" and in general, it should be turned off if you want to support realtime data.

Broadcast traffic is what needs to be sent at the lowest possible rate of 1mbps.  It has to be able to be received by all clients in all cases.  Multicast traffic on the other hand is to be sent at the rate of the slowest client that's subscribed to the group.  So the rate is variable based on connection conditions.  As I've noted on other threads, it's possible on some APs like the nanostations to set a floor for this speed so it never goes below a certain threshold even if a particular client can't handle it.  That allows you to drop out a client with a poor connection rather than have the whole show suffer.

https://www.diychristmas.org/wiki/index.php?title=Streaming_ACN_over_WiFi

 

Back to top