You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: