Currently, when daemon.js decides to target a server that is prepped, it schedules many batches far in advance, as illustrated below:
While the timings have all been figured out in advance and this usually results in a good flow of money, it has the disadvantage of tying up RAM that isn't actually being used. For instance, that 19 minutes could have been spent charging stanek, sharing RAM, or hacking lower priority targets with a shorter time-to-hack.
While it will probably take a larger refactor of how daemon.js does batching, we should try to switch to "just-in-time" creation of batch cycles / scripts to minimize sleep time needed and keep RAM available until just a few seconds before they need to start running.
Currently, when daemon.js decides to target a server that is prepped, it schedules many batches far in advance, as illustrated below:
While the timings have all been figured out in advance and this usually results in a good flow of money, it has the disadvantage of tying up RAM that isn't actually being used. For instance, that 19 minutes could have been spent charging stanek, sharing RAM, or hacking lower priority targets with a shorter time-to-hack.
While it will probably take a larger refactor of how daemon.js does batching, we should try to switch to "just-in-time" creation of batch cycles / scripts to minimize sleep time needed and keep RAM available until just a few seconds before they need to start running.