I am thinking about the sense of the current version over # 110. Well:
1. Absolutely: in the time interval of 60-120 minutes - the application started in server mode goes offline, causing the task to be suspended, causing an obstacle in the form of restarting, and as you know - any break or obstacle - it is not known what it brings.
2. In my case, the reduction of NB_JUMP to 16 raised the hashrate to 7200MK / s. I am beginning to consider whether this change in code has actually benefited or will have a negative impact.
3. After manually restarting the server with the command
Kangaroo.exe -nt 36000000 -w saved.work -i saved.work -wi 300 -d 28 -s input.txt
...the number that was in DEAD is counted again from zero. Is it alright?
4. How will the result be dump if it is found? I implemented a code add-on from a friend's post a few posts before me.
5. Does the indicator next to hashrate 2 ^ XX.XX / 2 ^ YY.YY mean that reaching X to level Y is the maximum time needed for the solution?
#5 (if you are talking server) first 2^ is your current DP# the second 2^ is what is expected, DP wise, to find solution.
#4 yeah, I added my own print to text code for when key is found
#3 I had same thing happen once, it as well showed zero when restarted because I don't think the table/file keeps the dead kangaroos
#2 go back through the posts, Jean Luc did a test on number of jumps, from 32 - 512; 16 seems low, but who knows
#1 hopefully breaks/restarts have no impact or everybody will be in same boat as I am sure everyone has had to stop and restart, intentionally or not, at some point or another
Did you mess around with DP number? What DP did you go with? The lower it is, it will also affect the MKey/s rate.