It describes submitting through RPC submitblock or RPC getblocktemplate mode submit on the pool's side. That's fine. It seems your pool attempts to submit incompatible data. Maybe it has something to do with TX messages. Do you add any of them to coin base? A JSON dump of what your pool sends to the daemon before receiving this invalid mode error would make it clear.

I'd like to return the question. If NSGminer with OpenCL starts to offer comparable performance to ccminer some day, will be a direct CUDA support necessary?

I don't see much difference in the GBT code apart of TXDB vs. UTXO and some cosmetics which is unrelated. This code fails in your case:


So, what JSON data do you submit in case of ORB and HAL?

Could you try HAL? It has no TX messaging, otherwise quite similar to ORB in what comes to NeoScrypt. Block hash is also BLAKE2s while PXC employs SHA-256d, though I doubt it matters in this case.

There are getinfo, getdifficulty and listtransactions. Where are getblocktemplate or submitblock? If the daemon doesn't report them in debug.log, must be something wrong with the call syntax or endianness. Your pool also reports invalid mode. If it works for PXC which has no TX messages, disable them.

I guess Luke is trolling them with this PoW change patch. There is no chance those people behind Classic approve something like this. However if their fork succeeds which is possible, Luke may re-use this patch for Core

Could you experiment with the testnet? It's less expensive than to mine blocks on the livenet which get rejected for some reason. There are two active testnet nodes at seed1.orbitcoin.org:25298 and seed2.orbitcoin.org:25298

Start the daemon with debugging on and look at debug.log to see why it rejects them actually.

If many people write or tweet them. They want to see a strong community support.

Must be a misconfiguration. Could you ask other pool ops?

However Scrypt wasn't compute bound without gapping, was it?

Transaction messages are for users. Turn them off for coin base.

Don't use submitblock. It wasn't tested while hard forking to NeoScrypt a year ago. Use getblocktemplate mode submit instead.

I don't think there will be any advantage. If a GTX 980 outputs 800KH/s, my downvolted and downclocked HD7990 does the same with a comparable or lower power consumption. I call it a fair competition.




Cryptsy's demise has been expected, though it was a bit surprising to see so much drama and bull shit. There are many people out there who have lost (or about to lose) much more than you. Yet I see no connection between the future of NeoScrypt and whatever happens to Cryptsy. There were hundreds of coins traded featuring various algos. What you say NeoScrypt has problems with CPU botnets, it's a key design feature actually. They are worse than huge ASIC farms.

If anyone here wants to see a high performance NVIDIA OpenCL support in NSGminer, join a crowdfunding campaign in the NSGminer thread. You know, I cannot get it off the ground without a modern GPU like 750 Ti or so.

Looks like an unrecoverable DB error. Restore from a back-up, bootstrap or redownload.

500KH/s on a reference R9 280X is nearly what I get now by optimising my v6 kernel. I think it can do more. That's for vector Salsa, ChaCha and BLAKE2s. Scalar are -10KH/s.



EDIT: Updated the screen shot with a longer run time.

ANN: If anyone wants NVIDIA OpenCL support in NSGminer with optimisations and hardware monitoring, donate to the addresses in the OP and post to this thread. The target is 0.5 BTC to cover the hardware cost at least.

Well, BLAKE2S_COMPACT is just an option which doesn't do any good now apart of reducing compiled kernel size. NSGminer is a fork of BFGminer v2.10.14 last updated 2 years ago. Although there was no ASIC related code which I would have to remove otherwise. There are also a few good things not found in CGminer/SGminer. I have rewritten many parts anyway to make it really work rather than just work. For example, SGminer displays incorrect block hashes, bogus network diff and the best share, share diff is inflated by 16, maybe solo mining is still broken. diff1 for NeoScrypt (and Scrypt, too) is 0.00024414 of the BTC diff1, that's nBits = 0x1E0FFFF0 big endian which gets decompressed to this uint256 target:

0000000000000000000000000000000000000000000000000000000FFFF00000x0

SGminer lost one most significant zero for some arcane reason. I guess it was also bad in the initial CGminer port to NeoScrypt. Divide this by a share hash/target to get the share diff. That's why all share diffs are 16x higher than actual.

I run NSGminer in lxterminal usually with a cron powered watchdog script, though I don't recall it crashing. Maybe it needs an update in this area to make X happy.

I haven't tested it myself on NVIDIA, though the kernel configures itself for all scalar code in their case, so it may work actually. There is no hardware monitoring available for NVIDIA, but this something I can add in the near future.

Well, we can make a much better progress if you upload your work somewhere to take a closer look. I'm very flexible on NSGminer and can do things SGminer will not in order to keep compatibility with their bunch of various algos and kernels. NSGminer isn't my private project, you can also commit your changes.

While optimising for GCN, I also try not to break support for VLIW. For example, this kernel is about 2x faster than yours on the VLIW5 & VLIW4 hardware. I admit most miners are on GCN now, but it's a good thing to keep the older hardware useful.

I haven't seen any real improvement on vector BLAKE2s, though I have added it as a feature.


Could you switch to vector code for Salsa and ChaCha to see if it makes a positive difference on GCN with the 15.x drivers?


FASTKDF_COMPACT 1 also seems to improve performance a little on GCN. Maybe SALSA_UNROLL_LEVEL and CHACHA_UNROLL_LEVEL are better if set to 3 like previously instead of 4.