Smallest reliable production time

Post all other topics which do not belong to any other category.
Premu
Inserter
Inserter
Posts: 24
Joined: Wed Nov 13, 2019 4:40 pm
Contact:

Smallest reliable production time

Post by Premu »

With beacons and speed modules we can speed up production speeds a lot - but in my experience the theoretical speed up can't be actually reached if the production time is too low. If I speed up the already fast recipes with 0.5s base time up a lot to theoretical value below 0.1s per production cycle it's almost impossible to actually feed a machine with input materials and get out the resulting products fast enough. Even if the throughput of the inserters should be theoretically enough - in doubt you can use two or three stack inserters - the machine will simply not run continuesly. The latency of the inserters or a small gap on the feeding belt might be enough that the machine runs out of material.

I wonder - did anyone already try to analyse how small you can get the absolute production time and still reach a continous production? I definetly see issues with times smaller than 0.1s, but how low can we go so that the theoretical values actually match reality?

Koub
Global Moderator
Global Moderator
Posts: 5321
Joined: Fri May 30, 2014 8:54 am
Contact:

Re: Smallest reliable production time

Post by Koub »

In vanilla ? Have you used multiple stack inserters with logibot fed requester chests, and same for output with provider chests ?
In modded, have you tried the uber upgraded inserters some mods add ?
Theory says the fastest you can get is 1 craft per cycle (1/60th of a second).
Koub - Please consider English is not my native language.

urza99814
Long Handed Inserter
Long Handed Inserter
Posts: 89
Joined: Sat Dec 10, 2016 12:57 am
Contact:

Re: Smallest reliable production time

Post by urza99814 »

Premu wrote:
Thu Jan 16, 2020 10:06 pm
The latency of the inserters or a small gap on the feeding belt might be enough that the machine runs out of material.
I don't think I've gone *quite* that fast on anything, but you definitely don't want to be feeding from a belt. Stack inserters will be MUCH faster if they're pulling from a chest since they can grab the entire stack at once instead of sitting there waiting for enough to come down the belt.

Koub
Global Moderator
Global Moderator
Posts: 5321
Joined: Fri May 30, 2014 8:54 am
Contact:

Re: Smallest reliable production time

Post by Koub »

A stack inserter can feed the assembling machine 27 items/sec (source : https://wiki.factorio.com/Inserters#Chest_to_chest)
With 2 chests and 2 stack inserters per 1 item needed for a 1 tick craft, you can almost feed the assembling machine fast enough (54 items out of the 60 deeded)
Koub - Please consider English is not my native language.

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 3953
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Smallest reliable production time

Post by eradicator »

Premu wrote:
Thu Jan 16, 2020 10:06 pm
in doubt you can use two or three stack inserters - the machine will simply not run continuesly.
Inserters are naive. Using two inserters to pull from the same source will *not* double your input speed because they will mostly just interfere with each other. You have to use circuits (or stack size override) to force the inserters to pull from the source in alternating order.

For examples i recommend searching for heavily beaconed green circuit builds - copper wires are the most common throughput-limited recipe in vanilla, producing one wire every 1.33 ticks, and consuming one plate every 3.75 ticks in a 12 beacon speed*24/prod*4 setup.
Author of: Hand Crank Generator, Screenshot Hotkey 2.0
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

Premu
Inserter
Inserter
Posts: 24
Joined: Wed Nov 13, 2019 4:40 pm
Contact:

Re: Smallest reliable production time

Post by Premu »

eradicator wrote:
Fri Jan 17, 2020 8:28 am

Inserters are naive. Using two inserters to pull from the same source will *not* double your input speed because they will mostly just interfere with each other. You have to use circuits (or stack size override) to force the inserters to pull from the source in alternating order.

For examples i recommend searching for heavily beaconed green circuit builds - copper wires are the most common throughput-limited recipe in vanilla, producing one wire every 1.33 ticks, and consuming one plate every 3.75 ticks in a 12 beacon speed*24/prod*4 setup.
It's definetly important to take into account the "source". Three stack inserters feeding from the same belt will lead to the last in the row being starved and to more hickups compared to three seperate belts lead to the same machine. The latter leads at least to no interference between the inserters, that's the reason I chose that to supply my green circuit machines with copper. At least now it's getting close to it's maximum theoretical output, although very short interruptions can still happen.

Using bot based systems feeding only from and to crates will allow obviously for more throughput. But belts have one major advantage in my opinion - a large belt system with different colored goods on it is simply beautiful!

Honktown
Filter Inserter
Filter Inserter
Posts: 642
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Smallest reliable production time

Post by Honktown »

If you put multiple stack inserters on multiple sides, you can feed at least 9*13.85 = 124.65 (according to wiki) items per second. Even with a 2:1 down recipe like iron gears, it's not possible to have 100% uptime with vanilla inserters because you can only remove 3*13.85 = 41.55 items per second (would need at least 60/s for 100% uptime). Same goes for wires: they're 1 in 2 out, so you'd need 180 items per second, which isn't possible with twelve stack inserters.

Any mods that increase inserter capacity, or using sped up loaders would work fine. I'm a dirty cheater and use 120 item per second belts and (mini-)loaders. Custom vector inserters would also allow one to fit in another 4 inserters at the corners (and would be the most vanilla-like, because it wouldn't be messing with "overdriven" inserter sizes/speeds/loaders).16 inserters * 13.85 items = 221.6 items per second, enough to feed the beast. Would just barely work for a 1+1:1 or 1:1+1 recipe, because 5*13.85 = 69.25, enough for at least 60 items per second.
I have mods! I guess!
Link

User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2402
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Re: Smallest reliable production time

Post by Optera »

It's very much possible to stall 0.5s recipes like cables in pure vanilla, even in chest > assembler > chest designs.
Inserters react too late to low input inventory. By the time an inserter picked up from a chest, rotated 180° and droped in the assembler the inventory already drained.

Replace all 0.5s recipes with 5s recipes producing 10x amount at once.
1) Inserters seem to react better to slower, high volume recipes
2) The game has to calculate recipes less often resulting in better performance

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 3953
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Smallest reliable production time

Post by eradicator »

Premu wrote:
Sun Jan 19, 2020 12:10 am
Three stack inserters feeding from the same belt will lead to the last in the row being starved and to more hickups compared to three seperate belts lead to the same machine.
The wiki lists belt-2-chest speed for stack inserters as 13.85, multiplied by three that's 41.55, so smaller than the 45 transported on a blue belt. So with proper timing it's at least theoretically possible to have three stack inserters work in parallel on a single belt (in practice there are some additional limitations like item-chasing).

If you're interested in inserter timing these are some good threads to start reading:
(Careful, these are about 0.16 which had different inserter/belt speeds. I don't know any extensive threads about 0.17.)
viewtopic.php?f=194&t=69863&start=20
viewtopic.php?f=194&t=58728
viewtopic.php?f=5&t=61699
Optera wrote:
Sun Jan 19, 2020 7:57 am
It's very much possible to stall 0.5s recipes like cables in pure vanilla, even in chest > assembler > chest designs.
Inserters react too late to low input inventory.
Very true. With chests it should be much easier to solve though, for example by limiting stack_size_override / swing_time to be as close as possible to the total desired in/output (usually it's too high).
Author of: Hand Crank Generator, Screenshot Hotkey 2.0
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 3953
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Smallest reliable production time

Post by eradicator »

Optera wrote:
Sun Jan 19, 2020 7:57 am
2) The game has to calculate recipes less often resulting in better performance
Do you have any actual data on that? I never heared that recipe duration has any impact on performance. Only the amount of machines used.
Author of: Hand Crank Generator, Screenshot Hotkey 2.0
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2402
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Re: Smallest reliable production time

Post by Optera »

eradicator wrote:
Sun Jan 19, 2020 9:52 am
Optera wrote:
Sun Jan 19, 2020 7:57 am
2) The game has to calculate recipes less often resulting in better performance
Do you have any actual data on that? I never heared that recipe duration has any impact on performance. Only the amount of machines used.
Easy enough to create a dataset for that.
Benchmark over 36000 ticks for a 12k Electronic circuit module.
base:
2646.760ms

10x bulk recipe for cable and ec:
2403.710ms

That's almost 10% faster.


Edit:
Previous test might have had too many variables like loaders, belts and ec assembler waiting for cables.
Here's a benchmark on a pure infinity chest > assembler > infinity chest setup producing 107k cables
base:
1812.732 ms

10x bulk:
1329.587 ms
This time bulk is even 26% faster, probably because I used 6 inserters per assembler.

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 3953
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Smallest reliable production time

Post by eradicator »

Optera wrote:
Sun Jan 19, 2020 12:32 pm
This time bulk is even 26% faster, probably because I used 6 inserters per assembler.
Were there supposed to be any pictures in that post, because i don't see any? 26% sounds like far too much. I mean, the recipe progress needs to be calculated every tick independantly of the recipe length, so unless there are some special optimizations in the code for long recipes, then i just don't understand *what* that time is supposedly being saved on. The only variables seem to be less math for in/output-stack count substraction/addition and changes in inserter behavior. The latter of which seems more likely (?) and i wouldn't count it because it's not strictly an improvement of assembler performance.

(Also sorry @OP if this is going too far off topic :|)
Author of: Hand Crank Generator, Screenshot Hotkey 2.0
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

Premu
Inserter
Inserter
Posts: 24
Joined: Wed Nov 13, 2019 4:40 pm
Contact:

Re: Smallest reliable production time

Post by Premu »

eradicator wrote:
Sun Jan 19, 2020 1:53 pm
Optera wrote:
Sun Jan 19, 2020 12:32 pm
This time bulk is even 26% faster, probably because I used 6 inserters per assembler.
Were there supposed to be any pictures in that post, because i don't see any? 26% sounds like far too much. I mean, the recipe progress needs to be calculated every tick independantly of the recipe length, so unless there are some special optimizations in the code for long recipes, then i just don't understand *what* that time is supposedly being saved on. The only variables seem to be less math for in/output-stack count substraction/addition and changes in inserter behavior. The latter of which seems more likely (?) and i wouldn't count it because it's not strictly an improvement of assembler performance.

(Also sorry @OP if this is going too far off topic :|)
Actually, it makes sense that it needs significantly less computing power.

If I think of a potential implementation of the production process, I'd define several states for the machine in which it will behave differently:

- Idle
- Initiate production
- Ongoing production
- Finish production

The logic for the idle phase to check if it can start the next production cycle is the most complex - you need to check if enough raw materials are available and if the output slot is available. The initiation and finishing process has also some work to do by removing the raw materials respective adding the finished product to the machines inventory and to trigger the attached inserters to get active again if necessary. The ongoing production in comparison is the easiest step - you only have to add up the progress bar.

So by lengthening the least taxing phase for your CPU you will get more performance.

User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2402
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Re: Smallest reliable production time

Post by Optera »

Like Premu said. Performance gain is due to Inserters waking up from idle less often.

Here's the picture of the test setup:
2020-01-19-20-02-47-0830395.png
2020-01-19-20-02-47-0830395.png (1.63 MiB) Viewed 642 times
With a setup condensed down to entity updates being almost exclusively happening when recipes finish, I was expecting even more than 26%.

PS: I might write a quick mod turning the most commonly used 0.5s recipes into bulk recipes. I'm curious how much performance gain real megabases could get from that.

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 3953
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Smallest reliable production time

Post by eradicator »

But my original question was:
eradicator wrote:
Sun Jan 19, 2020 9:52 am
Optera wrote:
Sun Jan 19, 2020 7:57 am
2) The game has to calculate recipes less often resulting in better performance
Do you have any actual data on that? I never heared that recipe duration has any impact on performance. Only the amount of machines used.
Now you're saying yourself that the gain is from less inserter movement and not from fewer assembler-update calculations. Disproving yourself. Q.E.D. Unless i missed something. Not trying to be rude, was just honestly interested if you had proof that longer recipes have relevant performance benefits by themselfs - because that would've been new to me. "Reducue inserter movement to increase performance" isn't new.
Author of: Hand Crank Generator, Screenshot Hotkey 2.0
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

User avatar
DaveMcW
Smart Inserter
Smart Inserter
Posts: 3057
Joined: Tue May 13, 2014 11:06 am
Contact:

Re: Smallest reliable production time

Post by DaveMcW »

Premu wrote:
Thu Jan 16, 2020 10:06 pm
The latency of the inserters or a small gap on the feeding belt might be enough that the machine runs out of material.
Inserter swing latency is not a problem. Fast assembling machines get a bonus to slot size, to ensure they always request enough items to survive the latency. The exact formula is:

Code: Select all

slot_size = (ROUNDUP(1.166 * recipes_per_second) + 1) * items_per_recipe
For 12-beacon advanced circuits at 1.86 recipes per second, the input slot size is 6 or 12, and the output slot size is 3.
For 12-beacon copper cables at 22.4 recipes per second, the input slot size is 28 and the output slot size is 56.

Belts are a real problem. Belt-to-assembler speed varies based on belt direction, lane, and underground. And of course gaps are a problem as you pointed out. If you are running a high-speed assembling machine from a belt, it might make sense to add a buffer chest.

Honktown
Filter Inserter
Filter Inserter
Posts: 642
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Smallest reliable production time

Post by Honktown »

DaveMcW wrote:
Sun Jan 19, 2020 9:53 pm
Premu wrote:
Thu Jan 16, 2020 10:06 pm
The latency of the inserters or a small gap on the feeding belt might be enough that the machine runs out of material.
Inserter swing latency is not a problem. Fast assembling machines get a bonus to slot size, to ensure they always request enough items to survive the latency. The exact formula is:

Code: Select all

slot_size = (ROUNDUP(1.166 * recipes_per_second) + 1) * items_per_recipe
For 12-beacon advanced circuits at 1.86 recipes per second, the input slot size is 6 or 12, and the output slot size is 3.
For 12-beacon copper cables at 22.4 recipes per second, the input slot size is 28 and the output slot size is 56.

Belts are a real problem. Belt-to-assembler speed varies based on belt direction, lane, and underground. And of course gaps are a problem as you pointed out. If you are running a high-speed assembling machine from a belt, it might make sense to add a buffer chest.
There's another issue with belts: they can only be grabbed from so fast. Regardless of how quickly you can produce things, a stack inserter has to wait to grab items. A box in front would sort-of help, because anything in it can be grabbed instantly, but then you have to feed the box from at least two sides. Bots would "fix" that problem. On top of it, even though a belt moves more items than the stack inserter can put per second, if you had another stack inserter on the same belt it has to wait longer because there's gaps from the first inserter. I forget if it took 6 or 8 stack inserters to reliably clean a blue belt, last I remember doing that was in .16.
I have mods! I guess!
Link

User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2402
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Re: Smallest reliable production time

Post by Optera »

eradicator wrote:
Sun Jan 19, 2020 9:25 pm
But my original question was:
eradicator wrote:
Sun Jan 19, 2020 9:52 am
Optera wrote:
Sun Jan 19, 2020 7:57 am
2) The game has to calculate recipes less often resulting in better performance
Do you have any actual data on that? I never heared that recipe duration has any impact on performance. Only the amount of machines used.
Now you're saying yourself that the gain is from less inserter movement and not from fewer assembler-update calculations. Disproving yourself. Q.E.D. Unless i missed something. Not trying to be rude, was just honestly interested if you had proof that longer recipes have relevant performance benefits by themselfs - because that would've been new to me. "Reducue inserter movement to increase performance" isn't new.
Are you trying to troll now or what!?

Inserter updates have to happen when an assembler next to them finishes a recipe since the inventory changes. To me recipe calculation includes inserters being woken up.

I'm not going to carefully weigh every single word as long as the overall context is valid. If you want that, talk to a lawyer not a developer.

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 3953
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Smallest reliable production time

Post by eradicator »

Optera wrote:
Mon Jan 20, 2020 7:59 am
Are you trying to troll now or what!?
No i'm not. And i explicitly stated so because i feared this kind of reaction would happen.
Optera wrote:
Mon Jan 20, 2020 7:59 am
I'm not going to carefully weigh every single word as long as the overall context is valid. If you want that, talk to a lawyer not a developer.
No need to become aggressive. Just try to remember that other people might be trying to be more precise than you deem necessary for your own posts.
Optera wrote:
Mon Jan 20, 2020 7:59 am
To me recipe calculation includes inserters being woken up.
And to me it does not (i also stated that) because i think it depends on too many other factors.
Which is why i asked if you knew something about the engine that i don't (i.e. "longer recipes have inherently less performance cost per second"). Because - as a mod developer too - knowledge of the engine is important to me. And asking other people is the best way to gain more knowledge.
Author of: Hand Crank Generator, Screenshot Hotkey 2.0
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

mrvn
Smart Inserter
Smart Inserter
Posts: 4034
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Smallest reliable production time

Post by mrvn »

Honktown wrote:
Sun Jan 19, 2020 1:30 am
If you put multiple stack inserters on multiple sides, you can feed at least 9*13.85 = 124.65 (according to wiki) items per second. Even with a 2:1 down recipe like iron gears, it's not possible to have 100% uptime with vanilla inserters because you can only remove 3*13.85 = 41.55 items per second (would need at least 60/s for 100% uptime). Same goes for wires: they're 1 in 2 out, so you'd need 180 items per second, which isn't possible with twelve stack inserters.

Any mods that increase inserter capacity, or using sped up loaders would work fine. I'm a dirty cheater and use 120 item per second belts and (mini-)loaders. Custom vector inserters would also allow one to fit in another 4 inserters at the corners (and would be the most vanilla-like, because it wouldn't be messing with "overdriven" inserter sizes/speeds/loaders).16 inserters * 13.85 items = 221.6 items per second, enough to feed the beast. Would just barely work for a 1+1:1 or 1:1+1 recipe, because 5*13.85 = 69.25, enough for at least 60 items per second.
But inserters take 7 cycles to turn and only start to move when the assembler is below 2x recipe (more with faster assemblers / beacons). In some cases the trigger when inserters move doesn't give enough times for the inserters to complete the swing and deposit more items. You go from 0 items to 9*12 = 108 items in one tick and then the inserters all stop till you are low on items again.

The idea of a solution there is to use circuit control on the inserters so they work in a precise pattern and have the second inserter start moving the tick before the first deposits its 12 items, while the item count is still below the threshold. That way you have items already on the way while the item count is above the threshold because you know you will need them when the swing completes.

Post Reply

Return to “General discussion”

Who is online

Users browsing this forum: No registered users