Active Robots
Posted: Fri Dec 09, 2016 5:18 pm
Is there a limit on the number of active robots that can be out? I have a lot of things they can be built by them but most of my bots are sitting idle in the roboport.
Yes..........I know.Smarty wrote:only construction bots can place stuff
This means that every second there should be 180 robots (60 ticks/s * 3 robots/tick) dispatched to ghosts or deconstruction orders. If you have construction/deconstruction tasks outside of the construction range then they will still be included in that calculation but no robots will be dispatched, making the overall dispatch rate lower and this can cause that issue. If all your (de)construction orders are inside the construction range but your construction robots sit idly in roboports and do nothing then please upload your save file.Rseding91 wrote:Robots are dispatched at a maximum of 3 per tick in a cyclic loop over all ghosts.
Oh would you look at that. It's the thread where I brought up math numbers which show the dispatch logic doesn't remotely optimally use bots.daniel34 wrote:viewtopic.php?p=193621#p193621
You're right that the calculation is a little off (it's too short by 2 seconds per 60 bots in the network). I account for the network being out of bots by using a different way to total working time.Deadly-Bagel wrote:Your numbers in the other topic don't add up for me. You use 5000 / 60 * 10 to calculate 60 bots dispatched per tick taking 10 seconds per task for 5,000 tasks, but that's incorrect. That calculation is for if you had 60 bots in your network and they were all dispatched instantly. The actual calculation is more complex but basically it's a maximum of 5,000 / 60 + 10 which is 93 seconds (total time to loop ghosts plus job time).
I think you're overcomplicating this. It would take ~16.7 seconds to release all 1,000 bots (1000 / 60). After 10 seconds, bots start returning ready for a new job, if each takes exactly 10 seconds they will return at exactly the rate they are being dispatched so the process is perpetual and the ONLY limiting factor is how fast it can loop over the ghosts. It takes (5000 / 60) = 83.3 seconds to dispatch robots to all ghosts, and 10s for the last robot to finish, therefore 93 seconds. In fact it's less than this because once the ghosts fall below 1,000 it speeds up to 180 robots per second, so really (4,000 / 60) + (1,000 / 180) + 10 = 82.2 seconds.bk5115545 wrote:I have 5000 tasks. I have 60 bots.
5000/60 = 83.333 tasks per bot.
Each task takes 10 seconds (theoretical).
ceil(83.333) * 10 = 840 seconds total.
The calculation error is only 2 seconds because the bots are initially dispatched over the first second i.e. the system isn't efficiently operating until the second second. The system's startup latency is translated into a 1 second sliding window of 100% efficiency (100% efficiency is when all bots are working on a task). The second second of error comes in at the end of the tasks where there are more bots than their are jobs to be done. The spin-up and spool-down rate is dependent on the number of bots available in the system. The number of bots in the system is dependent on the initial count and the length of the tasks. Knowing this information, we can find how many bots optimally exist in a network where there are more ghosts than bots.
Assuming a 10 second task time and going off of the previous stated dispatch rate of 1 bot per tick, we need 10 * 1 * 60 bots in the network to maintain 100% efficiency. We know from the above that every 60 bots adds another 2 seconds of inefficient operation by increasing how long the sliding window takes to reach 100% efficiency. To achieve close to the 833 second calculation, we would need to have 600 bots and 5000 tasks. The problem is that the 2 seconds of inefficient operation add 600/60 or 20 seconds of delay (I think you calculated 10s here; really we're thinking the same).
See above, your calculation again takes the amount of time to dispatch robots to all ghosts and then multiplies it by the time taken. Because the robots are completing the task faster than all robots are dispatched, the answer is the same as if you have 1,000 robots or even 600, it's the time required to dispatch robots to all ghosts plus the time for the last robots to finish (5,000 / 60) + 10bk5115545 wrote:Based on the above math, the below 3 scenarios are true.
Scenario 1:
I place a blueprint with 5001 tasks in a network with 5000 bots. There are more tasks than bots so at most 1 bot will be dispatched per tick. Lets still assume that it takes 10s per task.
Optimally, it would take ceil(5001/5000)*10 or 20 seconds. This is obviously not possible to implement without absolutely destroying the game's performance so there has to be some limit.
With the limit of 1 bot per tick or 60 bots per second, it will take 5001/60*10 or 835 seconds. This is because this scenario doesn't matter how many bots we have in the network (as long as there is always 1 ready to be dispatched), it only depends on the dispatch rate and the number of ghosts.
It takes 3.3 seconds to dispatch 600 robots at 180 per second, plus ten seconds for the last robot to complete its task is 13.3 seconds.bk5115545 wrote:Scenario 2:
If I have a network with 1800 bots and place a blueprint which requires 600 tasks then at most 3 bots are dispatched per tick. These tasks still take 10s.
Optimally, it would only take ceil(600/1800)*10 or 10 seconds. This still isn't possible for the same reason as above.
With the limit of 3 bots per stick or 180 bots per second, it will take 600/180*10 or 33 seconds. This is because the dispatch logic limits the amount of bots which can be dispatched to maintain better performance.
YES! This one is more or less accurate (though a bit roundabout). Indeed only 600 robots are active at any one time but this is only due to the short nature of the job, often they might take at least thirty seconds to pick up an item and place it which allows for 1800+ active construction bots.bk5115545 wrote:Scenario 3:
If I have a network with 1200 bots and place a blueprint which requires 5000 tasks then at most 1 bot is dispatched per tick. Tasks take 10s.
Optimally, it would only take ceil(5000/1200)*10 or 42 seconds. This still isn't considering game performance.
With the limit of 3 bots per tick, we will have at most 600 bots airborne at any given time (60 bots dispatched per tick times 10 second task time is 600 airborne). That leaves half my bots unused which I really don't like. Total task time is ceil(5000/600)*10 or 84 seconds.
I don't get your last line here. You're basically saying it's the exact same conditions but you came up with wildly different figures but you can't see that?bk5115545 wrote:Evaluation:
Scenario 1 takes 835/20 or 41.75 times longer than optimal ergo my complaint about how my resources aren't being used efficiently.
Scenario 2 takes 33/10 or 3.3 times longer than optimal. While I don't like the numbers, this scenario doesn't feel slow and changing it would significantly buff the bot build times for large blueprints.
Scenario 3 takes 84/42 or 2 times longer than optimal. This is a good efficiency ratio however 600 bots are being wasted. This is what I have a problem with. No matter how many bots are added, the blueprint takes the same amount of time until I have as many bots as tasks.
Scenario 1 and 3 are actually the same scenario with different numbers.
I believe I specifically stated that there were only 60 bots. Thank you for mostly confirming my calculation.Deadly-Bagel wrote:I think you're overcomplicating this. It would take ~16.7 seconds to release all 1,000 bots (1000 / 60). After 10 seconds, bots start returning ready for a new job, if each takes exactly 10 seconds they will return at exactly the rate they are being dispatched so the process is perpetual and the ONLY limiting factor is how fast it can loop over the ghosts. It takes (5000 / 60) = 83.3 seconds to dispatch robots to all ghosts, and 10s for the last robot to finish, therefore 93 seconds. In fact it's less than this because once the ghosts fall below 1,000 it speeds up to 180 robots per second, so really (4,000 / 60) + (1,000 / 180) + 10 = 82.2 seconds.
Your calculations seem to assume that during the 10s window that 60 robots are performing their duty, the roboport is not dispatching additional robots which is of course nonsense, a constant stream of 60 robots per second (if I understand it correctly) is being dispatched by the roboport so the time required to do the job doesn't come in to play until either you run out of robots to dispatch or a robot is sent to the last ghost.
I noticed a slight parenthesis error on my part which would lead you to assume your calculation is similar to mine. When I wrote, 5000/60*10, it should have been 5000/(60*10)+10, or 18.33 s.Deadly-Bagel wrote:See above, your calculation again takes the amount of time to dispatch robots to all ghosts and then multiplies it by the time taken. Because the robots are completing the task faster than all robots are dispatched, the answer is the same as if you have 1,000 robots or even 600, it's the time required to dispatch robots to all ghosts plus the time for the last robots to finish (5,000 / 60) + 10
This may be true but it still takes way too long to place solar panel blocks. I even fill storage chests right next to the central roboport with panels and based on these numbers, I'm not making the process go any faster; I'm just making it use less bots. In an actual scenario, when I mark a bunch of trees around me for deconstruction (outside of any network range) and my personal roboports handle it then the main base also slows down building it's solar and the outposts slow down repairs. A better system would as follows:Deadly-Bagel wrote:YES! This one is more or less accurate (though a bit roundabout). Indeed only 600 robots are active at any one time but this is only due to the short nature of the job, often they might take at least thirty seconds to pick up an item and place it which allows for 1800+ active construction bots.
I did get that. The increasing figure was meant to help people see how the system fails to use increasingly larger numbers of bots.Deadly-Bagel wrote:Scenario 1 and 3 are actually the same scenario with different numbers.
I don't get your last line here. You're basically saying it's the exact same conditions but you came up with wildly different figures but you can't see that?
is very different than typing "but can't you see that?" The first attacks my character while the latter is a legitimate question. Since English isn't the only, or even most important, language on Earth; I forgive you.Deadly-Bagel wrote:but you can't see that?
Yes, however you said it was a breakdown of this calculation:bk5115545 wrote:I believe I specifically stated that there were only 60 bots. Thank you for mostly confirming my calculation.
Therefore this is what I was referring to, not your calculation of 60 robots which is correct but irrelevant to my query. You're using the same calculation for both so I used the relevant figure of 1000 that I originally referred to.bk5115545 wrote:I have 1000 construction drones and 5000 ghosts. If we assume that it takes a drone 10s to complete it's task ... dispatching only 1 drone per tick (since I don't have enough drones) means that it will take about 833s (5000/60*10) which is around 14 minutes.
Are we talking about the same quote here? Because what I was quoting was not similar to mine, nor is your corrected version. Also your point in the fragment I quoted was "bots take ages" but in your corrected calculation they don't take any time at all. Also I'm not entirely sure what it's supposed to be representing. Total jobs divided by (robots times job time)? That would imply that the longer the job takes, the quicker it gets done.bk5115545 wrote:I noticed a slight parenthesis error on my part which would lead you to assume your calculation is similar to mine. When I wrote, 5000/60*10, it should have been 5000/(60*10)+10, or 18.33 s.
Yeah but how many trees could you possibly be marking within 90 seconds of placing a 5,000 entity blueprint? The "optimal solar/accu ratio setup" (kinda looks like a chest) has under 400 components. You would need to place at least 13 of these simultaneously to get the sort of 'poor' performance we're talking about here. If you place them one at a time a robot will be dispatched to every single component in about two seconds. If you place four at a time it would take eight seconds (it would take you longer to line the next lot up) as long as you have at least 1600 robots.bk5115545 wrote:This may be true but it still takes way too long to place solar panel blocks. I even fill storage chests right next to the central roboport with panels and based on these numbers, I'm not making the process go any faster; I'm just making it use less bots. In an actual scenario, when I mark a bunch of trees around me for deconstruction (outside of any network range) and my personal roboports handle it then the main base also slows down building it's solar and the outposts slow down repairs.
First of all that isn't even remotely close to an attack. The way I said it isn't a question of if you can see it, it's a statement that (as far as you're letting on) you can't tell the two scenarios are identical with identical completion times and I'm wondering why. However this is purely semantics and is irrelevant. If you want to read attacks into my replies then suit yourself but rest assured I have no interest in your character.bk5115545 wrote:I did get that. The increasing figure was meant to help people see how the system fails to use increasingly larger numbers of bots.
Also,is very different than typing "but can't you see that?" The first attacks my character while the latter is a legitimate question. Since English isn't the only, or even most important, language on Earth; I forgive you.Deadly-Bagel wrote:but you can't see that?
The simple answer is that dispatching a bot takes a lot of steps. I'd like to know the real answer too but I like to know everything.Xeanoa wrote:Why does the game deploy only so few robots per second? That seems to make no sense.