Replying to a bunch of the previous comments:
- I'll disable the "aborting scan" message in the next set of changes. I still want to put in a slightly better method for doing this, because I think it is increasing the reject rate a little bit. @ptsrush, my guess is it's a little bit because of latency and a little bit because the miner works in bigger chunks. I'll make it a priority to get that in the next build.
@allano, re source code to github:
(a) Which opteron do you have? I'm running the SSE one on AMD CPUs with SSE support. It works just fine.
(b) I have a few reasons I'm not pushing the source yet: First, the build is a mess, and I need to move it to using autoconf or some other method. There are currently four different makefiles that the project inherited from ptsminer, and part of my recent optimization adds different code that runs on different CPUs. The combination of this is currently unmanageable.
Second, I'm trying to figure out what the right strategy is for this one to fund development. It's pretty clear based on what happened with the GPU miners that if I release all of my tricks without supporting more pools and windows, a whole lot of clones will spring up with binary builds for other platforms with high dev fees that go to someone else. I'm fine with that in the long term, but I want to be careful. I've put .. um .. rather a lot of work into the current optimized CPU version.
My current thought is that I'm going to wait until *I* can provide easy-to-use binaries for both linux and windows with a 1-2% dev fee that supports both beeeeer and ypool, and then release the source as well. Of course, I'd also be happy to go with a sponsored code release again or explore other options, but the dev fee really does seem like a very equitable way.
@noobster: Agreed. The 3% dev fee is temporary. I'm going to cut it down to 2% pretty soon.
- Do you mind the 60 second dev mine starting time? I'd rather increase the user time from 2000 to 3000 seconds than reduce dev mine from 60 to 40 --- it's more efficient to run for longer.
- Amount of RAM per thread: The algorithms I'm using in this are completely different from what previous miners did. There's no way to use less RAM because of the way I store the data, and using more RAM will actually make it slower.
Did you want to use *less* RAM, or more because you want it go to faster?
-Dave