CCminer(SP-MOD) Modded GPU kernels.

[mirny]

The opensource is slow. My miner is more than 20% faster on the 1080ti.
(the opensource speed of 760khs taken from the https://cryptomining-blog.com/12546-mine-vertcoin-vtc-after-the-switch-to-the-verthash-algorithm (with settings that does  58 MH/s for Ethereum))

My mod can be pushed to more than 900khash with more oc. The gtx 1080 does around 600khash

even that its not profitable anymore...

[1714779210]

1714779210

[1714779210]

1714779210

[1714779210]

1714779210

[1714779210]

1714779210

[1714779210]

1714779210

[Dr_Victor]

The opensource is slow. My miner is more than 20% faster on the 1080ti.
(the opensource speed of 760khs taken from the https://cryptomining-blog.com/12546-mine-vertcoin-vtc-after-the-switch-to-the-verthash-algorithm (with settings that does  58 MH/s for Ethereum))

My mod can be pushed to more than 900khash with more oc. The gtx 1080 does around 600khash

Is it possible to get 58Mh with GTX 1080Ti for Eth?

[sp_]

Is it possible to get 58Mh with GTX 1080Ti for Eth?

The quote is taken from the cryptomining blog. I guess it was possible when the dag was smaller. I am only able to get 44-45mhash on my cards


About the Decreased performance in the Ethereum mining:

https://forums.developer.nvidia.com/t/blockchain-drivers/110847/13

We’ve confirmed that the performance drop is due to the size of the DAG exceeding the total on-chip TLB capacity on the Pascal GPU. As a result, there is an increased number of TLB misses, which affects performance. Because the TLB is a fixed capacity hardware resource, and the ETH algorithm accesses the DAG randomly, we don’t believe there are any software optimizations that could reduce the TLB miss rate.

In the Volta generation, TLB coverage was increased by 4x, and large DAG sizes (up to ~8GB, which won’t be reached for many years) will still fit in the on-chip TLB. So these newer GPUs (Volta and beyond) will show much less performance sensitivity due to DAG size.

But after modding abit I can still get 50mhash on the 1080ti with the current epoc. And 0% fee..

[moderator's note: consecutive posts merged]

[pallas]

Don't waste your time on keccak, any coin.
A bcu can easily do 30 Gh/s, and there are thousands around.

[sp_]

Don't waste your time on keccak, any coin.
A bcu can easily do 30 Gh/s, and there are thousands around.

I know, but my opensource keccak100 is 30% faster. I wanted to test the performance on the new cards. Keccak is also used in a number of algos. Ethereum, verthash, boolberry etc. So it make sense to optimize it. 30% faster also meens 30% less power and heat. So then you get more power and heat to solve the random memory access. Higher stable clocks->higher hash

[Amph]

sp you are out of the th game i don't remember now, your miner only mine all other coins right?

[JayDDee]

30% faster also meens 30% less power and heat.

No it doesn't, especially if optimizing mem access. It means less time waiting for data and
more time computing, more power and heat. HW optimizations like new instructions reduce power,
but SW optimization usually means increased parallelism, increased instruction throughput, incresed
mem throughput, all increasing power but hopefully less than the performance gain. Reducing the number
of instructions and uncecessary data copying will reduce power.

You didn't even bother to buy a new GPU, still using Pascal.

[mirny]

I have been mining VTC since the hard-fork with my optimized kernel, the profit has been $6-7 a card per day.

gtx 1080ti ~888khash
gtx 1070ti ~525khash
gtx 1070 ~500khash

Private binary for sale. The price is 0.005 btc. PM me

Support the ccminer opensource project

you stole code again, you're not obligated to sell others work, and pretending its yours...

ALL: dont even try to buy this, he's very well know code stealer + you'll get a little backdoor as a present, BE AWARE!!!!

[sp_]

30% faster also meens 30% less power and heat.

Reducing the number of instructions and uncecessary data copying will reduce power.

There is no memory access in keccak100. Why don't you read my code and see what it does. It's free and opensource.

you stole code again

No profit in mining verthash anymore without an optimized miner. Go and mine something more profitable like ethereum..

[moderator's note: consecutive posts merged]

[JayDDee]

30% faster also meens 30% less power and heat.

Reducing the number of instructions and uncecessary data copying will reduce power.

There is no memory access in keccak100. Why don't you read my code and see what it does. It's free and opensource.

I never claimed there was, it was a general statement.

The biggest thing you did was increase the default intensity from 28 to 30, any user could have done that by manually
setting it. That's not optimization. That's tuning, and deceptive to claim it reduces power.

I did notice you optimized the bitswapping of nonces by only bitswapping when a solution is found. That reduces the
number of instructions but doesn't have a measurable effect. I wonder where you got that idea.

I'm not going to spend any time trying to figure out the Cuda code changes, your claims have been sufficiently rebutted.

[sp_]

The biggest thing you did was increase the default intensity from 28 to 30, any user could have done that by manually setting it. That's not optimization. That's tuning, and deceptive to claim it reduces power.

If you try to set the intesity to 30 in the opensource miner it will crash, and it will not optimize the profit 30%. A miner will not care how the optimization is implemented as long as the profit is increased. You didn't read my code good enough. I have reduced the registry usage, and removed instructions (precalculated some of them with the cpu.). If you try to run with 28 intensity it's still much faster and stable than the opensource.

[JayDDee]

If you try to set the intesity to 30 in the opensource miner it will crash, and it will not optimize the profit 30%. A miner will not care how the optimization is implemented as long as the profit is increased. You didn't read my code good enough. I have reduced the registry usage, and removed instructions (precalculated some of them with the cpu.). If you try to run with 28 intensity it's still much faster and stable than the opensource.

Doing precalc on the CPU is good, but can it be done in parallel with the GPU?

[pallas]

If you try to set the intesity to 30 in the opensource miner it will crash, and it will not optimize the profit 30%. A miner will not care how the optimization is implemented as long as the profit is increased. You didn't read my code good enough. I have reduced the registry usage, and removed instructions (precalculated some of them with the cpu.). If you try to run with 28 intensity it's still much faster and stable than the opensource.

Doing precalc on the CPU is good, but can it be done in parallel with the GPU?

Doesn't make much sense, as it takes a tiny fraction of an instant.

[sp_]

Most of the first round of the keccak100 is precalculated on the cpu for every block(round 1 of 22). So each time the pool have a new block to search, the cpu need to precalculate. Not very often.

[JayDDee]

If you try to set the intesity to 30 in the opensource miner it will crash, and it will not optimize the profit 30%. A miner will not care how the optimization is implemented as long as the profit is increased. You didn't read my code good enough. I have reduced the registry usage, and removed instructions (precalculated some of them with the cpu.). If you try to run with 28 intensity it's still much faster and stable than the opensource.

Doing precalc on the CPU is good, but can it be done in parallel with the GPU?

Doesn't make much sense, as it takes a tiny fraction of an instant.

The thought was to decouple the CPU thread from the GPU so the GPU's 1000's of cores don't sit idle
while the CPU is doing it's thing. A "tiny fraction of an instant" times 5000 might not be so insignificant.
There should also be gains by running the hash loop locally on the GPU in instead of controlling it from the CPU.

But I'm not a Cuda expert so I'll defer to those that are.

However, this discussion has been interesting. As futile as optiizimng keccak is for a GPU, I found an even more futile
exercise by optimizing it for a CPU. I had previously overlooked prehashing for keccak because the block size
was >64 bytes. But prehashing 72 bytes (keccak512 block size) works and does speed things up. Unexpectedly keccak256
uses a 136 byte block so prehashing is of no use. As a result it can only be used on the x16r based algos,
and only speeds up the chain by 3% and only when keccak is the first function.

[pallas]

The thought was to decouple the CPU thread from the GPU so the GPU's 1000's of cores don't sit idle
while the CPU is doing it's thing. A "tiny fraction of an instant" times 5000 might not be so insignificant.
There should also be gains by running the hash loop locally on the GPU in instead of controlling it from the CPU.

Since the gpu hash loop is only run once every some tenths of a second, its running time is irrelevant.
I can say that running the loop on gpu doesn't make any improvement because I tried it many times, and there's no measurable gain (unless the compiler can do some optimisations you forgot to put into the code).
Also keep in mind you need to get updates from the pool or wallet, in order not to compute stale work, so going back to the cpu at least every second is highly advised.

[sp_]

I think I will opensource my verthash miner. Vertcoin has been there since the beginning and I like that they constantly change the algorithm to avoid asics. The price of the coin is low, and the team is professional. Let's mine and buy some vertcoins guys!

[scryptr]

I think I will opensource my verthash miner. Vertcoin has been there since the beginning and I like that they constantly change the algorithm to avoid asics. The price of the coin is low, and the team is professional. Let's mine and buy some vertcoins guys!

I CHECKED YOUR GITHUB--

It wasn't there yet.  I did check a couple days ago and found your ZP miner.  I will test your miner if it compiles on Linux!

The open source VertHash miner was attacked by my AV when I tried to use it on my Win 7 box.  I can't make an exception for it at all.  Besides, it is not optimized.

Right now I have some 3GB GTX 1060s mining UbiqHash; PhoenixMiner lets a miner set straps.  According to ZergPool stats, VertHash and UbiqHash are about the same profit wise.  VTC is slightly second.  Optimized, the story may be different.

PhoenixMiner straps get about +4MH/s per GTX 1060 card, ~24MH/s vs. ~20MH/s.  Any chance for a straps option?

--scryptr

[sp_]

My verthash miner is crashing on the new cards. 3xxx series.  Claymore is dead but you can buy straps mods for all the cards you want from wolf0 (CIA defect)

[scryptr]

My verthash miner is crashing on the new cards. 3xxx series.  Claymore is dead but you can buy straps mods for all the cards you want from wolf0 (CIA defect)

THE SUPRMINER WON'T COMPILE--

Your version pops an error.  I tried to compile it several times.  Any clues?       --scryptr