Throughput unlimited balancers

[FasterJump]

Hello,
I thought this 4-4 balancer was throughput unlimited.
Am I missing something?
Using version 16.36

[Aeternus]

It is as long as all 4 belts get fed or drawn from on either side... Right now you've got imbalanced in, imbalanced out.

[DaveMcW]

It seems the curved belts mess up the timing between both sides of the belt, so the middle splitter fails to achieve full throughput.

If you get rid of all curved belts, it can run at full throughput.

no-curves.jpg (202.74 KiB) Viewed 17465 times

[Zavian]

I did some quick testing with the layout pictured in the OP with both 0.15 and 0.16 (I thought that maybe the belt changes might have caused the OP's problem).

In both 0.15 and 0.16 it sometimes ran at full throughput, but often ran with some gaps in some of the belts. So I think it is just very sensitive to the exact timing items arrive at the splitters. But if you are intending to use that balancer as a permanent 3x3 , you can always feed the 4th output back into the 4th input.

[Hedning1390]

If you get rid of all curved belts, it can run at full throughput.

no-curves.jpg

That doesn't solve the issue. You can have 100% throughput with the curves and you can have 66% throughput with the straight lines. The problem inherent with this balancer is that the "back up tick" needs to be timed with the gaps on the 50% sides.

The easiest (although not very elegant) solution to all such balancing issues is to put two balancers in a row.

[Jap2.0]

Math.

Math.png (348.44 KiB) Viewed 17450 times

[Frightning]

I found this out in my own testing over a year ago, was part of the discussion about UTU balancers (Universally Throughput Unlimited). Using only 3/4 input belts of the standard 4x4 balancer would result in throughput loss, even for only 3 output belts. I noted that part of the problem was that the behavior of the balancer could be very sensitive to initial conditions. Apparently stacking 2 such balancers one after another solves the problem (why I am not 100% sure), but it may be due to the first balancer effectively having 4 output belts to feed, regardless of how many output belts are actually used by the latter balancer.

[ColonelSandersLite]

Once that bottom dead end output fills up and jams, that math is incorrect.

The bottom underground is moving at 0.5, so the belt between the middle splitter and bottom right splitter is capped at 0.5 as well. That extra 0.25, which can't go on the bottom jammed up belt, should be forced from the middle splitter upwards, making that belt 0.75 + 0.25 = 1.

It's probably a timing issue with the algorithm, exactly as zavian and hedning say.

[Jap2.0]

Once that bottom dead end output fills up and jams, that math is incorrect.

The bottom underground is moving at 0.5, so the belt between the middle splitter and bottom right splitter is capped at 0.5 as well. That extra 0.25, which can't go on the bottom jammed up belt, should be forced from the middle splitter upwards, making that belt 0.75 + 0.25 = 1.

It's probably a timing issue with the algorithm, exactly as zavian and hedning say.

Thanks for pointing that out - I only re-calculated the last splitter for after it backed up. Keeping that in mind I have no idea why it's not working:

Math2.png (347.16 KiB) Viewed 17443 times

[Frightning]

Once that bottom dead end output fills up and jams, that math is incorrect.

The bottom underground is moving at 0.5, so the belt between the middle splitter and bottom right splitter is capped at 0.5 as well. That extra 0.25, which can't go on the bottom jammed up belt, should be forced from the middle splitter upwards, making that belt 0.75 + 0.25 = 1.

It's probably a timing issue with the algorithm, exactly as zavian and hedning say.

Thanks for pointing that out - I only re-calculated the last splitter for after it backed up. Keeping that in mind I have no idea why it's not working:

Math2.png

I too wrestled with what you are now pondering back when I was working on UTU balancer thread. My best answer is conceptual only:
Essentially, what I saw in my tests with that the balancer was sensitive to initial conditions, keep in mind that the way splitters are actually implemented is MUCH more complex and also can only work on a per tick basis than the mathematical model you were calculating with. For the reason of these complexities, you can have situations where the system 'settles' into a sub-optimal equilibrium state, as is being observed in the picture in your post. (This is similar to the situation in Game Theory for non-zero sum games and Nash Equilibria, where it is possible to have one Nash Equilibria where the outcomes for several, or even all players are worse than for another Nash Equilibria for that same game). One thing that may help you determine what's going wrong would be to model the individual lanes, I never did work out a version modeled that way, but it's worth noting that a splitter never changes items from left lane to right lane or vice versa, only which belt they leave the splitter on. This is why you can nicely use splitters on mixed (non-rainbow) belts without ruining the mixing.

[KlarkSmith]

[removed]

[KlarkSmith]

Seems like a bug with how the splitters works.

You can fix it by closing the outputs and letting the balancer fill up, then reopen the outputs.

[Hedning1390]

Seems like a bug with how the splitters works.

You can fix it by closing the outputs and letting the balancer fill up, then reopen the outputs.

I don't think it's a bug. Just a result of having too much at one point and too little the next. You still want it to be input balanced too, and it isn't when it keeps 100% throughput. To change it they'd have to make some sort of internal buffer in the splitter.

[quyxkh]

Splitters can only choose from their available options, and if you get the arrival timing just exactly wrong you can leave them with no option but to stall one of their inputs for a while. With exactly the right timing, balancers can be forced into stall loops like this. Doing tick-perfect synchronized startup with fully-compressed belts is a really good way to force that.

On a blue belt, each item takes three ticks to clear its port. The way it appears in my tests, splitter ports for a lane are left-input, right-input, left-output, right-output. Splitters maintain a next-output port per lane and I believe a one-item buffer per output port; which input port an item appears on doesn't matter, splitters route to alternate output ports . . . if they can.

The mechanism that leads to the problem shows up first at the right output splitter in this example. That's not the direct cause of the gaps here, those are caused by the same mechanism repeating upstream in consequence of what's happening at the right output, but it's easiest to understand how it operates when it's clear how it starts, and the right port there is always backed up.

So start at the right output splitter, with a backed-up right port and a clear left one. The right output port and buffer are occupied. The splitter gets an item on each input port, the best it can do is route one item to the left output port and the other to the left output buffer.

Three ticks later, the output port clears, the output buffer delivers to the port. Less than three ticks after that, two items arrive on the input ports.

The splitter has one available buffer slot and two items to deal with. It has no option but to stall one of the inputs.

That's the mechanism. No matter how the buffering works, at some point there's going to be two items arriving at the same time when there's already an item in the buffer, which can't start moving until the output port's available for it.

Now, with inputs to a single splitter that don't arrive, in aggregate, faster than the outputs can accept them, this produces at most a temporary backup, and even if the right output splitter here is a little bit overloaded (it is), the upstream splitters can just shift the load to their other outputs, which are guaranteed to have enough capacity. That's what they're there for, right?

You might begin to suspect what's coming: since the right output splitter is getting more input than it can deliver onto its single output belt, both mixers will soon be in exactly the same situation as that output splitter is in. If things happen in exactly the wrong sequence, the one described above, the mixers might have to temporarily back up one of their inputs until the jam clears. Since the mixers aren't being asked to deliver more output than the total capacity, there are limits on how far back the stall will propagate, and eventually the jam will clear, ...

... but one of each mixer's inputs is compressed, and the mixers cannot know which one. Worse, if the input item arrivals are staggered by a tick, the mixers won't even get to choose which gets stalled, it'll be whichever one arrives second. If the stall happens on the compressed input, you get an unavoidable output gap.

So the way I see it, the general solution is what it's always been: don't constrain the output choices of splitters that have to deal with compressed inputs. That might mean you have to decompress the inputs, split them onto more belts, so the unavoidable temporary backups have some time to clear.

[Zanthra]

... but one of each mixer's inputs is compressed, and the mixers cannot know which one. Worse, if the input item arrivals are staggered by a tick, the mixers won't even get to choose which gets stalled, it'll be whichever one arrives second. If the stall happens on the compressed input, you get an unavoidable output gap.

If an input stalls because the splitters don't know which input line is compressed, priorities can make sure the one of our choosing is compressed and tell them which line it is. Tell the input splitters to load the outside belts with the surplus, and put any shortage on the inside. Then tell the output splitters to pull from the surplus first, and leave the shortage unless it needs it.

Belt Balancer.jpg (1.06 MiB) Viewed 17225 times

[Zanthra]

Here is an ideal stall loop.

https://www.youtube.com/watch?v=9D6IcWY ... e=youtu.be

Copper plates and iron plates arrive at the stalling splitter simultaneously. Copper plates are placed on the right output, but left output is blocked, so iron plates input is stalled. The same tick the copper plates clear the splitter output is the same tick that the iron plates clear the other output, and the splitter moves the iron plates onto the left belt (it last output something onto the right belt, so it's trying to be fair), and leaves a gap on the right belt. The next iron plates arrive with the next copper and it stalls the iron plates again to move the copper (last used the left input, this time the right).

Blueprint for the experement setup:

0eNrll9+OoyAUxt+Fa7tB/NPWi032OTYTg/W0Q6JoAJtpGt99QKcdE9vpgezd3mgQ/HH8zuETrqRqBuiVkIYUVyIOndSk+HslWpwkb9wzc+mBFEQYaElEJG9dCz56BVpvjOJS950ymwoaQ8aICFnDByni8S0iII0wAmbi1LiUcmgrUHbAK1ZE+k7b1zvporDITR6Ri73FdpZaKDjMfWyMVnDmD88ewyNiJTGqa8oK3vlZdMq9cBDqMAhT2r76TjkKpU25Eu4slBnsk3tI84jNH6eW09twJz51jbbnihs3B/k9dX/NA5JXDZS10O5OCqMG+O5VwOvyncvaxWOsFFbwI2/0YsitYx7bdjW4FE3zy/lbtQs5dpeTApDLlInaDk7Ht3F8IHXiL3WKzmN6h9+E2liRKiEnkZ4mkaGSeBSNAfWk3F9kbXApi5fV/k/EzPzFTNBi5v5whoZvV3DdN8JYgddYOlPpr+w1d+cfdIwOeu8NxwsSU284PvDY3z0f10n6CM5CrZkiIg/2Cww8DfV9+v/YPvVxqmV9uDZ7Ylxx5rH+v2wFtf7jPNQSMfWy9YbP3oVZosHOhYHvQ+EIVRgNtEXMxmxtXIP9haqTsr/U+kf6eonedqayH9zWcz0ZC7RgzIckgWxMAtJAd8fEnQWyMXHnHiaQ4j2A+S/THK2H/zLN0Ox9QLFnPxd7N5gn1Z7QQJVWmbUnt+m0VywOhxE5273yNCDfbVm8S3KapOP4CeiP3xo=

Copy blueprint