@tromp: It appears that we have a concurrency bug somewhere. The number of solutions found on each run is not the same each time the code is executed for the same nonce. We’ll have to figure out why. In the mean time, it seems we’re only finding an average of 1.7 solutions per run.
I don’t really feel like editing the sol/s numbers right now. If anyone feels like accusing me of being an evil lying sonofab* in the next few hours because of the 10% inaccuracy in our Sol/s estimates, I will agree that those criticisms are valid. Until we fix the bug.
We have started developing the code we would need to provide cloud hashing for our customers. Unlike many “cloud hashing” providers, we will actually be providing hashing: if you give us pool info, we will send your hashes there via stratum. This way, you can be certain that we actually have the hardware needed for your contract and aren’t one of the many ponzi schemes out there. (Lazy people can use our default or recommended pool.)
We will probably offer this service whether or not the crowdfund to open source the software is successful, though the price point will change.
I made one of our debug console.log messages optional, and that improved performance by 2 ms. So we’re now at 64 ms (26.5 Sol/s @ 1.7 Sol/run).
We’ve put a halt to our optimization work for now (fun as it is), and are switching to finishing off the functionality, testing our results for accuracy, and fixing bugs.
@Ben We don’t have any RX 470s yet, but I ordered two from Newegg today and should have them around Wednesday. I expect them to be about 15% slower than the RX 480. Until we figure out how to resolve the driver issue (or maybe get it running on Windows), the RX 480s will be locked in with the AMDGPU-PRO driver and OpenCL ICD, which cuts performance in half. It’s possible but unlikely that we might be able to solve that by precompiling the kernel, or by clever run-time linking.
The extra memory will not confer an advantage with our software. A 2 GiB card will work just fine, as long as it has enough bandwidth and compute power. For the RX 480s, though, the 8 GiB models have faster RAM (8 Gbps) than the 4 GiB models, and will likely perform somewhat better.
We are not writing in CUDA, so it’s not certain that NVIDIA cards will run at all. If they do, they will probably be slow. I am not interested in testing them.
then just put a bigger ram requirement per thread. Everyone got a pc with 16gb of ram or can buy additional memory for cheap. It would help limit gpu mining advantage, avoid huge gpu chinese farm, centralisations and allow regular people like me to try to mine. But I’m sure you won’t even read this
CPU mining is pointless since it will always be slower than GPU by a magnitude, not to mention that a highly optimized CPU miner in my opinion only benefits botnets, and not at all home miners.
Sure they would notice, but I don’t see that mattering. It’s also easy to strangle a botnet miner to using only single core and 1 GB ram. Botnets completely own any profitable mining process of CPU coin where a GPU miner is not available, almost without exception.
We first tested it on a 2 GiB card, and it worked fine. I have no doubts about it working on a 3 GiB 7970.
Not yet. We wrote the code last night to work based on getblocktemplate-generated headers and to generate submitblock messages, but we’ve still got a few bugs to track down and quash that are affecting the accuracy of our results.
Everything from setting up the blake2b hash dataset to filtering out bogus solutions.
Yes, there are.
I can’t be more specific than that without giving up information on our competitive advantage, sorry.
@dannygroove You can’t test in CUDA without rewriting the whole program in CUDA. We have finite development resources.