UPS wars: smelting challenge (design competition)

[Xtrafresh]

Ok, here's V2. Quite the extreme approach, but actually usable in a real world scenario with minor adjustments. Miners insert directly into a train. Smelting is done offsite, no bots, belts or chests, but 48 trains with 20 cargo wagons each. It'll be interesting to see what works best.
Because of the setup, it does not have a steady output, but it seems to trend to around 375K/m, out of 408 theoretical max. Pretty happy with all that

One thing that this guy will let me test is the impact of splitting the rail networks. If you are interested, I can make a version with all 8 mines on one line using more conventional approach using stackers rather than this pretty much idealized train/bay ratio.

For now, I want to see my processor in pain. I'm going to mine the whole patch and see just how well this scales to BIG.

[quyxkh]

My bot-fu is … not so good. My designs can't play in this league.

But I do have this to offer: when I started using 6-second-clock stack inserters to unload my smelters, so they got 11-12 plates per swing rather than 1-3 for various unclocked unload inserters, I got a >10% overall speed boost (91k ms to 81kms on the benchmark on my box). I wired every unloader in the smelter complex to the same one-signal circuit -- this with a design that scores about 35 here, so clocking the unload inserters on a more efficient design might be a big win.

... edit: yep. I took optera's v2 map, added a five-second clock, and replaced the fast unloaders with clocked stack unloaders:

Code: Select all

(ins)~$ Factorio --disable-audio --benchmark ~/.factorio/saves/optera.v2.orig.zip --benchmark-ticks 100000|grep Performed
Performed 100000 updates in 30104.157 ms
(ins)~$ Factorio --disable-audio --benchmark ~/.factorio/saves/optera.v2.tweaked.zip --benchmark-ticks 100000|grep Performed
Performed 100000 updates in 23283.284 ms

and the baseline bench on my stock 3570K/1333MHz takes ~14000ms, so this was unexpectedly huge.

optera.v2.tweaked.zip

Corrected, still don't know what that first upload was or how it got there.

(3.7 MiB) Downloaded 174 times

[aaargha]

But I do have this to offer: when I started using 6-second-clock stack inserters to unload my smelters, so they got 11-12 plates per swing rather than 1-3 for various unclocked unload inserters, I got a >10% overall speed boost (91k ms to 81kms on the benchmark on my box). I wired every unloader in the smelter complex to the same one-signal circuit -- this with a design that scores about 35 here, so clocking the unload inserters on a more efficient design might be a big win.

Oooh, that is super neat. Not only will you save processing on the inserters but you'll also be able to make more efficient use of the bots as they can also carry more items each time, I wonder if it's worth it to make sure that the inserters always grab a multiple of the robots carrying capacity each time (tweak cycle length and stack size override) so they can always travel with a full load.

This technique should also be applicable to any slow crafting item. It won't be as efficient as smelting, as the overload_multiplier is usually set pretty low, but reducing the inserter activity to half or a quarter shouldn't be impossible, if you also control the input inserters getting the reduction to 1/12 shouldn't be impossible for things like science.

[TBTerra2]

quyxkh: your attached map dosnt seem to contain any timmered inserters. are you sure you uploaded the correct one

having said that the idea of keeping inserters asleep until they can get a full hand, is really interesting. it would be interesting to see how much difference it makes for the different type of designs

[quyxkh]

quyxkh: your attached map dosnt seem to contain any timmered inserters. are you sure you uploaded the correct one

having said that the idea of keeping inserters asleep until they can get a full hand, is really interesting. it would be interesting to see how much difference it makes for the different type of designs

I fixed the attachment. I have no idea how that happened. The benchmark was a c&p from my terminal, but when I checked just now the fast inserters were back on my system too, it's as if it never happened. So I did it again and uploaded a new one, which gets the same results. Damn physicists and their meddling with quantum theory, I bet it's all their fault.

[Xtrafresh]

Very nice! Though it won't work on slow crafting items, because the assembler only keeps one or two items buffered before it stops running. I guess you could go for two items at each swing. i never thought this would make such a massive difference, and I never thought adding a circuit network would decrease the load, so I never considered using it. Now I wonder what other things we could use the network for.

I'm looking at the Doc, and I see the new designs in there, but not their scores. Any reason you are holding back, or is it just WIP?

Also, I'm curious to see if the test is consistent across differently sized factories. can you pick a modular design and see if you get the same score for one or multiple setups? My 2.0 setup would work well, It has 8 modules that operate independently and should be identical to eachother load-wise. It would be easy to do a 1v8 setup scaling test. I wish I could get the benchmark thing to run, I'll try again tonight. :/

[quyxkh]

Okay, here's an entry I think will do reasonably well, it scores ~57 on my box. It's a straight proof-of-concept for the clocked inserters.

quyxkh.clocked-inserters.demo.zip

(1.35 MiB) Downloaded 169 times

p.s. I'm not trying to win any prizes here, if anyone wants to incorporate these into their own entries, well, that'd be neat! I'm off on a couple weeks road trip today anyway.

[quyxkh]

Gaahhh, there's just barely too many trains in that one, leading to naive-station-selection logjams after running fine for a long while. Here's a fixed version with one less train:

quyxkh.clocked-inserters.demo.fixed.zip

(1.3 MiB) Downloaded 189 times

[aaargha]

Very nice! Though it won't work on slow crafting items, because the assembler only keeps one or two items buffered before it stops running. I guess you could go for two items at each swing. i never thought this would make such a massive difference, and I never thought adding a circuit network would decrease the load, so I never considered using it. Now I wonder what other things we could use the network for.

It does actually, stack inserters will overfill as they always grab 12 items if they can, I made a small demo in creative mode just to make sure it actually works.

The attached setup yields 12 crafts of blue science with only 5 inserter swings, 3 input (one for each item type) and 2 output (needed for the +40% productivity). Without using timers 12 crafts should yield 15 swings, 3 input and 12 output.

I see now that the timers on the input inserters that I'm using should not be needed only the output should need a timer, unless a disabled inserter uses less UPS that is.

[Xtrafresh]

Very nice! Though it won't work on slow crafting items, because the assembler only keeps one or two items buffered before it stops running. I guess you could go for two items at each swing. i never thought this would make such a massive difference, and I never thought adding a circuit network would decrease the load, so I never considered using it. Now I wonder what other things we could use the network for.

It does actually, stack inserters will overfill as they always grab 12 items if they can, I made a small demo in creative mode just to make sure it actually works.

The attached setup yields 12 crafts of blue science with only 5 inserter swings, 3 input (one for each item type) and 2 output (needed for the +40% productivity). Without using timers 12 crafts should yield 15 swings, 3 input and 12 output.

I see now that the timers on the input inserters that I'm using should not be needed only the output should need a timer, unless a disabled inserter uses less UPS that is.

Hm, i actually meant the buffer of finished products, but I guess that's also not true then, lol. If disabled machines indeed use a lot less UPS, this might make a difference all the way throughout the base. Is the same true for machines disabled though power switches? I'm looking at the amount of beacons I'm using that I could turn on only when a train is in the station.

[TBTerra2]

looking at it, a disabled inserter does not go to sleep, meaning that a disabled inserter uses more ups than an inserter that cant do anything, but an inserter doing something uses alot more than one that is disabled.

therefor disabling inserters are best used when the craft speed is low enough that normally it would only pickup one item at a time, but high enough that is wouldn't be asleep much. this is ideal for plate smelters, but im less sure about longer crafts (think, steel/red circuit/blue circuit)

also quyxkh, im not sure if its the inserters or the train stop management, but something is making your design very effective

[quyxkh]

When I show the debug timing data the game update cycle hovers at very roughly 1.3ms clocked, 1.7 if I cut the feedback wire so the inserters are always enabled. So going from 3/12 touches to 14/12 touches per plate adds about a third, an inserter swing is _expensive_ on this scale.

I wasn't expecting or even thinking about train efficiency with this, that was just raw luck. I can only speculate why the train update cycle here is so vastly cheaper than for my first attempt, that was a conscious attempt to make the train processing efficient, but as I recall the train update for that was around 790μs while this one's down around 120. I think it might be as simple as each car still counts as a separate thing, and things in motion are what's really expensive. That kinda fits, the earlier trains were very long, 57 cars, and they didn't spend a lot of time sitting still. If that's so, I wonder if it'll get the same optimization love as belts? That would be nice, mentally thinking of each car as a separate expense just feels wrong.

[impetus maximus]

quyxkh, just a heads up.
loaded 'quyxkh.clocked-inserters.demo.fixed.zip' to check out your timer.
i noticed mining productivity research is @ 201 instead of 200.

[TBTerra2]

dun dun dun... scandal
402% productivity rather than 400%, at most a 0.5% change in output

[hypnobunny]

Just read through this thread and I'm loving the timer solution. Before this, I had been trying to fix the problem by using slower inserters. I sent in two new versions, one using red inserters (which almost exactly use their full stack bonus without external input) and then another making use of the circuit network.

Regardless of how this all turns out, I'm definitely going to be changing around the inserters in my megabase.

[quyxkh]

And the smelters aren't close to keeping up with the miners anyway, everything past about 200% is a waste. Don't know how it happened, I already used the quantum-physicists excuse but hey, if anybody can be responsible for multiple problems at once, it's them, right? Anyway, I've got a .squeakyclean version I'm making, took the chance to make it prettier and also added an effective excess-capacity kludge, a naughty-box stop that never closes, behind a pathfinder-penalty station so a train goes there if all the real stations are unready.

To make a long story short, the low digits of the performance figures are sensitive to _everything_, as I discovered when I tried to reproduce the result in a new world. I kinda half suspect this design just needs a long, long burn-in period, it just would not settle on anything for a while in its new home and seemed like it wasn't ever going to perform as well. I tried jiggling the clock cycle by a step or a few, I tried this and that, but eventually it just clicked into place and settled in. Even switching the clock cycle from 230 to 229 or 231 ticks is enough to have a noticeable effect on the production stats . . . aaand it just wandered off its 101.6k/min lock again. However, to my intense relief, the exact same thing happens if I reload with creative enabled and boost the mining prod stat, that _doesn't_ seem to have an effect.

I remember reading that Factorio fluid flow performance is sensitive to the build order of the pipes, maybe there's some effect like that going on here?

quyxkh.clocked.inserters.demo.squeakyclean.zip

(1.85 MiB) Downloaded 164 times

[quyxkh]

Just read through this thread and I'm loving the timer solution. Before this, I had been trying to fix the problem by using slower inserters. I sent in two new versions, one using red inserters (which almost exactly use their full stack bonus without external input) and then another making use of the circuit network.

Regardless of how this all turns out, I'm definitely going to be changing around the inserters in my megabase.

Yah, I definitely want to see the effects on your and DaveMcW's worlds, I'm thinking if it's really new the results will be fairly dramatic, unless someone figured out a way to get plates out of a smelter some other way. But I'm off, doing a road trip and then five days whitewater in Idaho with my kid, which I booked without realizing that also got us the eclipse our first day on the river.

[hypnobunny]

This one doesn't have any chance whatsoever at being the most efficient design overall but it's the best I've been able to do using bots. Basically a series of separate bot networks feeding fully beaconed smelters which then load a train. Bots are used to move ore from miner-->smelter-->train loading then trains transport and unload into void chests. I did take advantage of the timer that was posted a little while ago which definitely increased the efficiency.

[impetus maximus]

dun dun dun... scandal
402% productivity rather than 400%, at most a 0.5% change in output

"The map already has all non infinite research, mining productivity 200 and robot speed 15. you may not increase this further"

[quyxkh]

Lol I couldn't let this rest. There's a construction ghost in the "squeakyclean" upload, a smelter's missing. Correct that construction fault and the design instantly locks on to the original behavior. I usually run with personal bots even in creative mode, but didn't for such a simple hahanobrainer cut'n'paste. When you have eliminated all the complicated, obscure, improbable causes, whatever explanation remains, no matter how obvious, simple and probable must be it. Now we can leave.