Priority Splitters - Why Is This Happening?

[Sinehmatic]

My priority splitters are slowing down throughput even though they have a perfect input. None of my input belts are set to pulse, only hold. The parameters on my input belts are "read belts contents - hold" and my output belt is set to "enable/disable anything > 12". I can recreate this problem all the way down to 8 as well...

I also managed to recreate this/similar problem(s) with several other setups. The other problem that is in one of the images is that it doesn't keep belts completely saturated without letting items seep onto other belts.

• http://i.imgur.com/pJLdEiV.png

• http://imgur.com/5AVcI5e.png

• http://imgur.com/eggHKof.png

• http://imgur.com/rQPNIC0.png

For some ridiculous reason, I can't post any images for reference --' so I hope you guys can still help...

Edit: For some reason, using this setup, I haven't been able to recreate any problems. The parameters are the same except for the output belt being set all the way up to a signal of 54.

[nobodx]

When i Build priority Splitters, I'll check the output of the Splitters instead of the Input -
The Primary Lane is set to Read Content & Hold, the secondary one to "On/Off" & "Item > 5"
maybe even > 6 when i want more Items on the Primary Belt (though the secondary >>might<< jam, if you set it too close to 8)

[mexmer]

one segment of belt holds only up to 6 items, so if you set 12 you need to actually get input from 2 parts of belt, otherwise you never will get 12

[mrvn]

Connect a combinator to it and watch the signals. On a full belt items enter and leave the scanner at different times. That causes the reported signal to fluctuate and causes your stutter.

To get an accurate reading on weather a belt is full or not and act on it you need to split the belt in two and count both outputs.

On a single belt the fluctuations can only go down while you want the maximum content. If you wait for the maximum content you stop the belt between items leaving the scanner and the next item entering and get stuttering. If you wait for less then you don't stop the belt till the other side is completely full all the time and again get stuttering.

With a split belt, since each side is only half full, the fluctuations can go up as well as down (you want it to go only up and now you can). That leaves some buffer space to overfill the belt at that point and smooth out the fluctuations. So when items enter and leave at different times the amount of backlog on the split section fluctuates and not the throughput.