Topic: [ANN] sgminer v5 - optimized X11/X13/NeoScrypt/Lyra2RE/etc. kernel-switch miner - page 67. (Read 877859 times)

Several machines on 1 worker? Or asic?

This one is 12.. check those hash rates.. 500-600MH per machine..

this was 8ghs )) https://www.nicehash.com/index.jsp?p=miners&a=12&addr=1GMy4ASNFDVdn3oLYsvgFX5H27Hx2v65Mv

Bitlux only got beautiful pictures of models.

Has anyone noticed just how many new GPU alt coins failed or have fallen to worthless values in April and May?

There was this one coin, Enigma [EGMA] were the coin go delisted from every exchange, because the developer could not even design a working wallet

Then, there is Bitlux [LUX], which is now virtually worthless. Similarly, there is Sixteenbit, which is again worthless.

Well, it'll be a minor disappointment to know that the miner itself will be closed; however, due to its design, few would consider it a security risk. Running as a daemon on miners, the only output meant for the user being the API, the worst it could do is steal hashrate for a time until it was noticed and purged. The frontend, that the user sees and interacts with, will be open source - as well as the API documented, so others can make special-purpose frontends, or simply ones offering different layouts or functionality. I plan to support Windows and Linux, as well.

This is a longer-term project, though - I don't know how long it's going to take me - but I want to do it properly from the start, to make something with functionality that is useful and currently missing, or hacked together, and something that is easy to adapt to new algos and such. For example, the generic algorithm code is mostly done; besides anything I might think of later (the implementation of which will probably be optional), algorithms can be added by writing four functions - the only existing code that needs to be modified is adding the algorithm name to one array, and a corresponding entry in another with the function pointer of the initialization function. I can even see a possibility of algorithms being shared libraries, in fact - while Windows' DllMain() isn't quite ideal for the init function I use, the cleanup function could be implemented in it, which will be run when the library is unloaded.

I'm one person!

God only knows. I can't tell - people post screenshots with absurd rates like 18MH/s on a 280X, but with 10%+ rejects - and I've STILL not seen a 290X for comparison. My estimate is mine is slightly worse than his on 280X, slightly better on 290X, but not sure. I've not imported my latest implementations of the hash functions into Quark yet, though; I've been busy with my full-custom miner, plus one other algo I'm toying with.

It's from the Kachur miner dev - I'd treat with initial caution, but I've seen no evidence of it doing anything malicious so far.

And I like that I can ...


http://s013.radikal.ru/i325/1505/16/9f7d71037386.jpg

no:

l4 = 4 octects = 32 bit binary
l8 = 8 octects = 64 bit binary

they both work on windows and linux, but on linux we do not have the modified miner to run them with.
again: different kernels with different parameters than stock miner!

no:

l4 = 4 octects = 32 bit binary
l8 = 8 octects = 64 bit binary

they both work on windows and linux, but on linux we do not have themodified miner to run them with.
again: different kernels with different parameters than stock miner!

Try xIntensity = 512. It is higher, and the hash rate seen on pool is just slightly lower than local hash rate. If you try xIntensity = 1024 or 2048, the local hash rate is much higher, but the hash rate seen in the pool is similar to xIntensity = 512, but use more electricity.