Jean Luc - or anyone:

Precomp Table!

I want to do a precomputation of table, where only Tame Kangaroos are stored.

I tried tinkering with the current source code, but to no avail.

Do you know/can you tell me what I need to change in code or does it require a code overhaul?

I will be grateful for the code, because I don't think I will finish it :-(


Yes, I use the original one. I will add an answer from -winfo work28.save

Those. The problem is most likely when the clients are not on the local network. Namely, the problem is caused by an error in working with sockets.

I like the idea. How would it work, for the division of production?

If nothing else, settle on a DP to use and share equal sized workfiles each day. So if workfiles was to be 10 mb each day and it took 100 mb to solve, then anyone who submitted a 10 mb workfile, would get 10 percent of prize. If they submitted more than 10 mb, say 20 mb, then they get 20 percent of prize. Only problem is trust, using this method.

But I like the concept and would be willing to join.

A distributed project like this is probably necessary if we want to solve the puzzles in the 130-160 bit range.

Makes sense. What do we need to set it up?

Maybe I'm not following you. Earlier you said you had file saving every 10 minutes and server restart below that. So that made since why your work file was not growing with saved DPs. 1 minute read/write is a lot when you are getting higher up. If you start a new save file, reduce the read/write to 0s, you are getting more work done. Example, if you are saving every 5 minutes, and it takes 1 minute to read/write then you are losing 12 minutes of work time every hour, as opposed to less than a minute with a smaller work file. I don't know. Again, maybe I'm not tracking.
Also, if your server restarts every 3-15 minutes, who's to say it doesn't restart just prior to it saving?

Maybe I don't understand the solver. I thought a DP was a DP regardless of how/where/when it was found (as long as it's the same number, i.e. both work files have DP size of 28). Whether a DP is found at the end of a 6 GB file or at the beginning of a 1 GB file, doesn't matter. That's the point of the merge file, to check all DPs and see if their is a collision.

Think about this. Let's say you have zero issues with server and clients and they run straight for 50 days but then a power outage happens. You restart your program but new DPs found with different kangaroo starting points will go into the saved work file. Do you think those DPs found at new starting points don't count? or make you start from scratch? All kangaroos will be different, i.e. different starting points...

I have merged many files into one, with restarts. If this doesn't act the same as one long running file, I am screwed and will never find key

But to answer you. For smaller range keys (56-80 bits), I have stopped and started and merged many files and it still found the key. So hopefully the same will be true for 110 bits.

My server is secure. I also checked the logs and I don't have any unknown IPs. Everyone else has a problem, so that's not the problem.

----
And now another question:

[DP COUNT 2^27.60 2^27.55] - I don't understand again ... (?)