Max number universes on FPP?

[Santacarl]

It isn't typically "the network" if you are wired that is slowing things down. It is reading the data, doing any transforms and then pushing the packets out that fills up the 25ms slot. From last year's thread, also see how your controllers can be the problem because they can't handle the high speed packets that FPP could output.

Plugging your second rPi into the network would work fine. Your switch will handle the network side and direct the packets to the right devices. Basically you tell the controllers and FPP to work together to create a little network within network. Separate sub networks (192.168.2.x and 192.168.3.x or whatever you want to use) would make it "simple".

Are you a xLights or Vixen user? In any case, you can get a fseq that only has the data you need for the controllers connected to that FPP instance. That is what helps with the speed. Less data to read and transform.

Bottom line, from reading last year's thread closely, I don't think you will have a problem adding a few more props assuming it means more controllers as well. You have a rpi on hand in case you see some problems so just keep it simple Santa!

Thanks Mike....  xLights here.  How do you go about getting fseq's specific to controllers connected to a particular FPP?  I haven't seen that mentioned any place before.  Is that what most folks do?  That would make it common knowledge which shows how little attention I've been paying to updates and forum discussions...   Haha.

[JonD]

A Pi3 will connect at 1gb, but it is an emulated 1gb and limited to the Pi3 USB speed which seems like is around 300mb.  With all the lights you have, a Pi4 or Pi5 with a full 1gb connection would certainly help ethernet speed, but that may not be the issue.

I only have half the lights you do and was running into several performance issues a few years ago.  My 36 port megatree and large windows matrices would lag on fast paced videos.  Running data packet captures, ethernet was no where near capacity.  I ended up deleting all props other than the megatree making it the only thing running and still had the same issue.

I ended up finding that I had a bad serial setting on the Falcon.  I was not using serial, but from a prior config it was configured to use one.  I resolved that and converted from E1.31 to DDP which made a huge difference.  After switching to DDP I immediately noticed things ran much better.

Remotes are a very cool feature, but may not resolve the performance issues you are seeing.

[allknowing2012]

The proxy field on the controller tab determines who sends that data to that controller. Most folks have the same proxy - ie their main showplayer. In your case it would be the address of the remote pi sitting in front of those 2 (remote) falcons.

[Santacarl]

Thanks for the heads up.  I would have guessed the proxy would have been the master...

Shows how little I understand about this networking related areas....I can get in trouble REAL fast when I'm left to my own guessing!  Haha....

Oh, wait.... You're referring to the XL Controller tax....specifically the IP address....  DUH....It didn't dawn on me at first....

[Santacarl]

UPDATE:

OK....I got over my overthinking and watched a couple of Greg's videos and was able to get a remote to work.    

It was easier than I thought BUT you don't know what you don't know and I'm not very intuitive so I struggle when I don't fully understand the "how to" without that 'blueprint' showing the connections....as it were....It's an engineer 'thang'.  Haha.