FPP-channel & universe numbers?

[Santacarl]

Hey All,

Just curious about how many pixels a FPP 3 and 4 can run when the display uses unicast with sequences set to 25ms and everything connected via Cat 5 (no wireless)?  

I run the show on 1 FPP don't use any remote FPP's and I keep adding to the show every year and was wondering if there is a point (number of pixels wise) where the single FPP struggles to run the show.

[dkulp]

The limitation is the SD card read speed.   FPP on a Pi4 can easily max out the gigabit ethernet (~100MB/sec) outputting DDP.   The processor and the ethernet is not an issue at all.   The main issue is that SD card only reads at about 40MB/sec.    With compressed sequences, MOST of the time the 40GB/sec is fine.  However, if you are embedding a bunch of videos or something that don't compress well, you may have issues.  One option is to move to SSD at which point the ethernet would become the bottle neck again. 

In any case, at 40fps it would be about 1.5million channels using e1.31 for a Pi4 using e1.31, over 2M for DDP.

[Santacarl]

The limitation is the SD card read speed.  FPP on a Pi4 can easily max out the gigabit ethernet (~100MB/sec) outputting DDP.  The processor and the ethernet is not an issue at all.  The main issue is that SD card only reads at about 40MB/sec.    With compressed sequences, MOST of the time the 40GB/sec is fine.  However, if you are embedding a bunch of videos or something that don't compress well, you may have issues.  One option is to move to SSD at which point the ethernet would become the bottle neck again.

In any case, at 40fps it would be about 1.5million channels using e1.31 for a Pi4 using e1.31, over 2M for DDP.

Thanks Dan....Good to know the work around if my SD card starts having issues with video....get an SSD and adapter..

[Poporacer]

Good to know the work around if my SD card starts having issues with video....get an SSD and adapter..

Actually a much better solution is to use MultiSync, you can run WAY more that way! (probably almost limitless, but I am not the expert here, @dkulp might have better information on this)

[JonD]

FPP will run faster than most controllers.  Dan has suggested in the past that most 100mb controllers often start bottlenecking after 10mb/sec.  I am sure he will correct me if that is not correct. 

I have had issues over 40k channels natively with the Falcons, and have seen several others report issues after 40-60k range.  If you place a packet sniffer on the network wire, it is no where near overwhelmed, but the matrices start to drop packets just the same.  I have an old XLATW Greatest Show sequence and when the curtains start to roll back, with the bear. elephant, and lion start walking, the video started to glitch out last year.  It looks great on the xlights preview, and worked fine for 4-5 years at smaller resolutions, but simply going from 3" spacing to 2" spacing doubling the light count in all my matrices the video glitches badly now.  IMHO, you would not be able to actually run 1.5 million pixels without running into several other bottlenecks before getting there, but if I am corrected here I need to take a closer look at my display to see what is going on.  I guess when I looked into it prior, I was told that was to be expected and accepted it.

[dkulp]

FPP tends to send out e1.31/DDP data as fast as it possibly can.  That's one of the reasons why FPP could potentially max out the gigabit ethernet.   If you have 150 universes to send to a controller, it will send all 150 out in a single sendmmsg call and Linux will blast them out as fast as it can.    From FPP side, that's great.   Low impact, it has done its job, it can move onto the next frame.    

The problem is the low end embedded processors on the controllers tend to get overwhelmed by that.  Many cannot receive 150 packets in such a short time.  They tend to have relatively slow embedded processors, maybe one or two cores running at 160mhz or slower, and they have a lot of work to do.  They have to take the data, figure out how to map it to ports, maybe do color re-ordering, brightness, gamma, handle smart receiver protocols, etc...  They also tend to have limited memory, mostly measured in KILOBYTES, not the MB or GB that we're used to with Pi's and Beagles.  They also have to handle things like servicing the web pages requests, etc...  Thus, they have limits.   Since e1.31 and DDP are both UDP based, if the receiver isn't ready to receive a packet, it can be dropped by the switch or pretty much anywhere in between.  

For FPP 8.4.2, there are new advanced mode settings for the UDP output page that will change how the data is sent.   There are "blocking" modes that will call sendmsg (not sendmmsg) for each packet individually and make sure it gets sent out on the wire.  That can slow things down enough that some controllers can respond better.    We've also discovered that some controllers like the Experience controllers have severe memory limitations that make it so you really need to turn off the "monitoring" checkbox.   The monitoring checkbox sends a "ping" every 30 seconds or so to make sure the controller is there, but if the controller is too bogged down or having memory issues, it may not respond and FPP will start working on disabling that controller.   

Anyway, this is mostly an issue for folks that try to max out their controllers.   Ironically, one "fix" is to have more controllers and a larger show.   By having many controllers, the multithreaded output for FPP will interleave the packets to the controllers which then makes them arrive at the target controllers at a slower pace.   

[JonD]

Ironically, one "fix" is to have more controllers and a larger show.   By having many controllers, the multithreaded output for FPP will interleave the packets to the controllers which then makes them arrive at the target controllers at a slower pace.

I have several, but my Falcon's think they are government employees and don't work very hard.   Most pixels I have on a controller is my megatree at 4,300 pixels, and the rest of them are under 2,500 pixels.  The F16v4s are my problem children for sure.  They are typically feeding the larger video models, but in one case I have a F16v3 running more pixels and you don't notice the issue.  It is still there if you look hard, but the end users would never notice. 

For FPP 8.4.2, there are new advanced mode settings for the UDP output page that will change how the data is sent.

Very cool!  Will this have to be manually set, or will xLights autoconfig automatically adjust this per controller type?