matrix which spans two etherdongles seems to have lag issues.

[taybrynn]

So I have increased my tune to matrix size from 32x32 to 48x32 this year.

The 32x32 portion is on Etherdongle#2 in the 16k-32k pixelnet universes.  On a Zeus.v1

The 16x32 portion (the new poart) is on Etherdongle#1 in the 0-16k universes.  On a Zeus.v2

I have two gig-E network cards, and xlights has all 64 (512) universes set up for multicast.   I have
set the new adaptor to static ip 10.0.0.1 ... and have all the multicast traffic routed to the static IP
using the follow command prompt command:  route -p ADD 239.255.0.0 MASK 255.255.255.0 10.0.0.1

So most things seem to be working fine, but I'm noticing that this new 48x32 matrix is lagging in sections
for some reason.  The lag seems to occur at boundaries which do not correlate to the physical channels
(i.e. the lag appears every 5 conduits, but the physical breakup is 4 conduits per string/channel).

So I'm wondering if anyone has any experience with this kind of thing.

I will say that the new panel seems to be working fine ... but the old 32x32 (2 panels) is lagging, and seems to
have sections which appear ok and others which appear lagged.

Thanks,
Scott

[taybrynn]

I have concluded that the latency from the two etherdongles is just different enough that I really need to build a 3rd etherdongle and put the entire matrix on the same etherdongle ... which should not be difficult since they were added in as a single model to xlights and I would just need to map them out to a different channel range on the 3rd etherdongle ... and run another wire of course. 

[taybrynn]

So just to follow up ... I added a 3rd etherdongle and ran a new cat5 out to the my Zues v1 and Zeus v2 which are controller my 48x32 matrix panel  (really 3 physical panels of 4 strings each -- put together) ... and it did nothing the fix the lag problems.  I think the issue now my be related to the fact the 2 zeus controller one object (the combined matrix) may be the issue.  I seem to get no lag running either just the panels from the first zeus v1 or the panel on the second zeus only.  When I feed the pixelnet out from zeus #1 to zeus #2 (pn in) ... then the lag happens in what you see.  I tried reversing it (zeus v2 to v1) and same thing.  So my latest guess is that I take the 8 channels (and cords) off the Zeus v1 and move them to the Zeus v2 ... for a total of 12 channels on the Zeus v2 ... and reprogram them (and make sure my PS can handle this increased load of 12 strings) ... I'm hoping that will fix the problem.  I never considered this before because I didn't have enough free channels on any Etherdongle to do it, even using the Zeus v2.  Now that I have a 3rd etherdongle running 32-48k PN range ... I will try putting the first panel of 4 strings on ED#3 U#1 (starting at ch#1 of the 1-4096 range) ... and then put the second panel of 4 strings on ED#2 U#2 and the third panel on ED#3 U#3 ... making the programming of each panel basically identical (interchangable) ... and I'd just hook up the first panel to Zeus V2 ch1-4, the second panel to Zeus V2 ch5-8 and the third panel to Zeus v2 ch9-12 ... I know this is probably boring for some to read, but I'll let you know if this works ... I think/HOPE it will.  The main problem is scrolling isn't possible because of the lag between zeus board being different.  So to be clear, the etherdongles being different didn't seem to be the main problem as I had guessed.  I wonder if the performance of a Zeus v1 and v2 might just vary enough to cause this problem?

[RJ]

The firmware is the same only jumpers selecting which universe for each chip so the most variation you should see is the difference from channel 1 to channel 4096. This would be much less than what you are describing. Since channel # 1 of all four universes go out at the same time, and all the others work the same.

No idea why you would be seeing this.
RJ

[taybrynn]

Thanks RJ ... that what I thought ... I know it was a minor change to the v1 design.  I have no idea either.  My only thought is maybe one of the boards has a problem and the other doesn't ... like a bad chip or something?

My current plan is to leave it through Christmas or till the snow melts and the roof is safe again ... then pull both off the roof and consolidate them all into one Zeus v2 with 12 channels being used.  I'll probably reflash it from scratch and just set all new channels to the 32k-48k range and program as mentioned above ... 1 4k universe per panel so they are interchangable if needed. 

The lights on the first two panels would be approx. a year older ... and the 3rd panel are lights I got from ray this year.  All are the SS Nodes listed in the wiki ... but they do seem to differe a bit from year to year, but hopefully performance changes are not happening.   I've been sticking with these nodes to be consistent over time.

[taybrynn]

Update: I moved  all 12 strings to the Zeus 2,  reprogrammed them to use  3 ranges in each of the  4 universes on a new etherdongle with the 32-48k (3rd set of 16k pixel net) ... It tested fine ... And running the PC to etherdongle 3 to the Zeus 2 ... Getting the same funky behavior ... Very laggy.   Lights in all panels are not working great.   I've repaired the heck out of these panels but still need more repairs ... But I'm wondering if the lights are part of the problem?   Maybe my Zeus 5 had a problem or I have some bad lights?   Anyways, about ready to give up on this  matrix.    Just too many problems.

[taybrynn]

Final update: I found that I could control my matrix better with my second etherdongle.  Conclusion is that my third etherdongle has issues and really can't control anything very well for some reason.  So for the heck of it I tried controling the first 8 strings of the matrix with a pixelnet flashed (DMX) dongle.  And wow, it worked great and no lag.  I mean it was working ok with the second etherdongle, but it was still exhibiting some sluggishness I can't explain.  Probably acceptable but a little laggy even just using control straight from PC to etherdongle#2 and then to the Zeus2 and matrix strings.  But when I tried the same test sequence using the pixelnet flashed dongle ... it was the best by far.  So I decided I would use 10 of the 12 strings and run the first 85 nodes on the 11th string ... since thats how many I could fit on one pixelnet flashed dongle with 4k PN channels.  It's working great.

I do wonder if the length of the cords on the matrix panels might be an issue?  I mean they are generous, but I think all are 3' or less and maybe if you add that 1-2' from the Zeus 2 side ... I'm still 5-6' max I think.  But anyways, it seems that the matrix works best this way, and I just don't understand exactly WHY.   It was enough of an improvement that I decided I'd rather have almost 11 panels of smooth, no lag ... vs. 12 panels with some lag from a single ED into a single Zeus2.  I may try it again after the season with a regular zues, but it has the same 4096 single universe limitation, so at this point that doesn't get me to using 12 strings either.  I may try a falcon unit and I'm guessing that may fix it, who knows.