So, I've got good news and bad news. Good, in that we now understand mergers enough to be able to answer problems like this. Bad, in that we now know that the 5 assembler long alt. Quickwire manifold is impossible (4 should be just fine though).
The problem with Eila's mergers is that we aren't merging five 90 ppm inputs, we're actually merging two 450 inputs on a single merger. That kind of merging produces gaps like shown above, which make it impossible for the mergers to output a whole 450 ppm.
Because 90 parts per minute is the average of the actual value, 12 parts every 7.5 minutes, we will look at that case instead.
Because our items are on conveyors and moving, It's naturally easier to express distances in time rather than length, especially because the measurement of distance in of itself is almost impossible in Satisfactory. As well, the best way to express a set of items is by presenting it as a packet of individual frequency(f) in ppm from the conveyor itself, which I consider to have a flux(ϕ), to ease diction. Because of that, I'll be using the distance Δt to represent the length of a single packet, and ΔT to represent the distance between packets which are produced from the same machine. This problem is simpler in that the flux and frequency are the same, but if we had 900 ppm belts that would be a different story.
So, pulling out some equations that I've developed (made up) these past couple of days (I can give a more detailed explanation to anybody interested),
Δt = (n-1)/f : where n is the number of items in the packet.Two packets on a line right next to each other must have the time length of a single item added in between to account.
ΔT = ΔT_c - Δt : as shown easily enough in the diagram
ΔT_c = 1/f_c : where f_c is the cycle frequency, this is the number of cycles a machine makes in a minute (7.5 here)
t = L/ϕ : an item's length divided by belt speed
starting off with two assemblers, the time it takes for every item to come out of the first assembler is just Δt. I'll call our packets P(t) for semantic simplicity.
A (t1), the very end of the packet is L/ϕ in front of the merger, which will be the origin of the system. This means that P1(t1) = L/ϕ
Why L/ϕ in front of the merger? This is because our second packet, from the second assembler, must be able to fit on the output conveyor of the merger. Any delay between P1 getting to L/ϕ and P2 reaching the merger is parts per minute lost, so we'll call it instantaneous. Because our packets are positioned at the very rear of the set of items, we have to say that P2(t1) = -Δt to keep our positions orderly.
To find the actual distance time distance between 1 and 2, we can use a simple relation with no great symbolism.
P2 + T = P1
Which, plugging in the previous relations gives
-Δt + T = L/ϕ
T = L/ϕ + Δt
T = L/ϕ + (n-1)/f
In this case, both f and ϕ are 450 ppm, so since n = 12, this simplifies to a tidy 12/450 min. Reconverting from time distance to actual distance, it's a surprisingly manageable number of 12 meters.
(There are 12 poles in that second picture)
That isn't the whole picture though. If you recall the ΔT from earlier, we can calculate it right now
ΔT = 1/7.5-11/450 = 0.1088 min, this is the time it takes before the second shipment of wire rears its head.
So going on with that in mind, since we have the ability to merge all of the packets flawlessly without any gaps in between, we can calculate its period. In this case P1 is the first shipment of wire. P2 is the second shipment after 8 more seconds. P1's final position will be dependent on the 4 other packets coming in behind.
P2 + ΔT = P1 :Following from above
P1(t1) = L/ϕ + 4Δt + 3 L/ϕ + L/ϕ : 4 other packets + 3 junctions + moving forward until the rear of the last packet is at L/ϕ
P2 = -Δt : same reasoning as the last
-Δt + ΔT = 4Δt + 5L/ϕ
ΔT = 5Δt + 5L/ϕ =
5(11)/450 + 5/450 =
An unfortunate result, it means that the time it takes for the first shipment to get out of the merger happens to be longer than the time it takes for the second shipment to get to the merger. This is the cause of the buildup Eila was seeing in the last two assemblers.
So, the problem isn't latency, nor a game bug, nor any other speculation, it's simply an unfortunate situation that arose from the limitations of merging items to begin with.