Several UPS optimization questions (mainly bots)

[Lastmerlin]

As preparation for my next big base I would like to collect infos how to really optimize production lines. I will use bots, as they are the most UPS-efficient way right now. It turns out, its not that simple as often claimed. Getting good data by testing is really difficult. Thats why I hope for answers from anybody involved in the developement process instead.

Just one sentence on the omnipresent bot vs belt topic: Please cease any discussion about that, I will ask moderators to delete/move out any such posts.

Main question is: What is the real estimate of the update cost for a bot network? Everybody claims, they scale linear, but that cannot be true, because splitting large robot network definitely has a positive effect. This only makes sense for a cost function c(n) with c(n) > 2c(n/2). Moreover, there are many variables:
A - Area of the network
B - bot number
C - Chest number
R - Roboport number

Is it like O(A+B+C+R) or O(B+C+R)? This would be a separate loop over each of the entities - but this would be linear. Or is it O(B*C*R)? Surely not, as this would be actually cubic (and horrible). I suspect something like O(C log(B) log(R)). This would be one loop (here over all chests) with (log time) access to other datastructures within. Then the big question is: What is the main term, and what are the variables inside logarithms? This makes a big difference concening the optimization objective. Of course, it can be something more complicated.

The type of questions I seek to answer is:

• Should you try to minimize the number of chests (by sharing chests etc.), even at the expense of larger size (and most probably more bots/roboports)?
• Should you try to minimize the number of chests (by sharing chests etc.), even at the expense of larger size (and most probably more bots/roboports)?
• Does it make sense to fine-tune the number of roboports?
• Is one chest requesting 5 types of Items better than 5 chests?
• You could clock your requester chests: Each requester is active only 10% of the time, but requests large amounts of items. Then the activity shifts over to the next one, until it cycles back at the end. Could this be better, than all requesters asking for moderate amounts all the time?
• If you request large amounts of items at once and (S)ource and (D)estination are close to each other, then bots often fly like: (R)oboport-S-D-S-D-S-D ... - R . This indicates, that the roboport should not be inbetween Source and Destination, but somewhere else, to really minimize the S-D distance. However, this only works, if there are not too many bots in the system. If you have enough bots, then the System will send 1000 bots doing one R-S-D-R trip, instead of 100 doing R-(S-D)*10 - R. Even, if the chests are directly adjacent, and the robotports are 100 tiles away. Could it make sense to intentionally starve your system of bots, to get the way more efficient second behavior?
• More simple question: Is constant overflow oder underflow of requested items better? I suspect overflow.

And finally: Are there any rough estimates, how the UPS impact relates to the costs of inserters, Machines and combinators? There many tradeoffs to make again: Slightly suboptimal ratios to get direct insertion. Direct insertion vs larger area and suboptimal beacon coverage. 8-Beacon vs 12-Beacon per machine setups (less machines, but larger area). And finally: Are combinators costly? They look cheap, but the underlying data structure is not as simple as it seems. Many of the tricks I can imagine right now need different degrees of combinator fine tuning - so I should really know if it is worth.

Ok, its a long post again. Please dont hestitate posting any partial answers, I am grateful for any help.

[Zavian]

I'm pretty sure bots that from a cpu performance standpoint bots do scale linearly. Every active bot costs a certain amount of cpu instructions. Every chest access costs a certain amount of cpu instructions. So you want to minimise the number of active bots, and minimise the number of chest accesses.

Since each bot trip involves two chest accesses, minimising the number of bot trips also helps minimise the number of chest accesses. As part of minimising the number of trips, you should think about how many times a bot needs to move something from one chest to another. This means it is often better to direct insert things like copper wire, rather than ask bots to carry them. When making steel, you should direct insert iron plate, rather than make bots carry the iron plate. Less trips, means less bots moving which means lower cpu cost.

A less obvious consideration is minising the number of active bots by making sure that each trip is short. Shorter distance means the trips take less time, and hence you need active less bots. Keeping average travel times short also means you will often need to keep the area of each network relatively small. Otherwise you can endup with bots spending too long moving between jobs. Also remember to consider where the bots are going to recharge, and factor that into your planning for short travel distances.

That is where large bots networks leave people thinking that bots don't scale linearly. The issue isn't with the bots themselves, it's that in a large bot network the average travel distance per job tends to go up. When the average travel distance doubles, you need twice the bots, to move exactly the same number of goods. When the logistics area doubles in one direction, and then doubles in the other direction, you have 4 times the area, and probably have 4 times as many assemblers, and probably want to move 4 times as many goods, potentially with double the average travel distance/job. That means you need potentially 8 times as many bots. Often such networks also don't have enough charging, or the charging isn't convenient to the bot paths. So the bots get half way, then they divert somewhere else to charge, and that is another factor that can further increase average bot travel distance per job, and further increase the number of bots a large network requires.

Regarding inserters, I think you want to minimise both the number of inserters, and the number of swings/sec. So use stack inserters, and make sure the requests are set high enough for them to grab a full 12 items as often as possible. Have different ingredients for the same assembler share a chest if one stack inserter can keep up.

Edit: Regarding combinators, I would tend to minimise their use. I wouldn't use them for enabling or disabling inserters to try to minimise inserter swings for example, because that will could easily end up costing more cpu cycles than just letting the inserters swing whenever they want to. (As a minor aside, I wouldn't use circuit or network conditions to prevent inserters from swinging either. Just hard limit the output chest. The inserter will always need to check whether the items can fit. Adding network or circuit conditions just means the cpu needs to check those conditions as well, taking more cpu cycles).

[quyxkh]

What is the real estimate of the update cost for a bot network? Everybody claims, they scale linear, but that cannot be true, because splitting large robot network definitely has a positive effect.

I've looked at this some, the way I figure it UPS costs for bot delivery scale with the number of bots in the air, belts: number of active belt segments, trains: number of active locomotives plus some small fraction of the number of wagons. For short runs the per-trip cost of the inserter swings belts and trains need also matters, for really short runs they're pretty much the entire cost and for bots that cost is zero.

By the time UPS costs matter 100k items/min is about the right task size worth considering, but a max-boost green-chip factory pod delivering ~100k items/min (of which ~20k/min are its output chips and the rest are internal item deliveries) is going to keep about a thousand bots in the air while delivering 100k plates/min across 1000 tiles would need ... hmm, even very late game that'd be a dead minimum a two-minute round trip, so you'd need at the very least 50,000 bots compared to 42 belts or one track loop and a couple of trains.

Even with the 0.16 optimizations belts aren't competitive on long-distance bulk delivery, for 100k items/min across 1000 tiles I've measured it at ~4x the UPS cost, plus even by megabase standards the million ore it takes to build that many underneathies is getting ridiculous. For bots .. heck, just for the sheer ludicrousness of it I'll try that and edit in the results.

[Jap2.0]

What is the real estimate of the update cost for a bot network? Everybody claims, they scale linear, but that cannot be true, because splitting large robot network definitely has a positive effect.

I've looked at this some, the way I figure it UPS costs for bot delivery scale with the number of bots in the air, belts: number of active belt segments, trains: number of active locomotives plus some small fraction of the number of wagons. For short runs the per-trip cost of the inserter swings belts and trains need also matters, for really short runs they're pretty much the entire cost and for bots that cost is zero.

By the time UPS costs matter 100k items/min is about the right task size worth considering, but a max-boost green-chip factory pod delivering ~100k items/min (of which ~20k/min are its output chips and the rest are internal item deliveries) is going to keep about a thousand bots in the air while delivering 100k plates/min across 1000 tiles would need ... hmm, even very late game that'd be a dead minimum a two-minute round trip, so you'd need at the very least 50,000 bots compared to 42 belts or one track loop and a couple of trains.

Even with the 0.16 optimizations belts aren't competitive on long-distance bulk delivery, for 100k items/min across 1000 tiles I've measured it at ~4x the UPS cost, plus even by megabase standards the million ore it takes to build that many underneathies is getting ridiculous. For bots .. heck, just for the sheer ludicrousness of it I'll try that and edit in the results.

I believe splitting networks helps because bots don't make ridiculously long paths, so with the added efficiency there are less in the air at a time.

[Lastmerlin]

My experience is different. Even with a lot of thought into optimizing the flight routes, splitting down yields benefits (assuming, you connect the subfactories by trains, and not by something stupid like mass belts).

Using clocks to fine-tune inserters has been investigated by several people on reddit and they reported some positive results.
Another aspect someone there pointed out: Apparently, queueing to recharge are really costly as well. Any confimations?

At least from a programming viewpoint, linear behavior is hard to believe. It's a complex optimization problem, with serving entities (bots), their source (roboports) and multiple item source and target points. That would be a truely genius algorithm. I guess its a loop over one of the entity types, but you need cross-references to the others. Use a datastructure with non-constant access time and you have already lost perfect linear behavior. Or you have search (for the closest provider or whatever), which is at least log time.

At the end, we are in the terrain of wild guessing here right now. Thats the problem.

[quyxkh]

lol yep, I just tried it.

Delivering 100k/min, 1000 tiles,

bots: ~80ups @robot speed 10, ~52k robots in flight, ~2k roboports
belts: ~4300ups, 42 belts
trains: ~6800ups, 2 1-10 trains.

edit: running the game in benchmark mode, no graphics, reported

bots: 10.045 ms/tick
belts: 0.180 ms/tick
trains: 0.067 ms/tick