CCminer(SP-MOD) Modded GPU kernels.

[chrysophylax]

Is VTC solo issue fixed ?

VTC-SOLO--

T-nelson was working on it when a "Lyra2v2 doesn't work" false alarm propagated thru the thread.  He is diagnosing with one 750ti, so it may take a week to hit a block and get error log and debug info.  CryptoMining Blog states that CCminer crashes on hitting a block, and my personal results agree.  However, I was not running any error-catching software.       --scryptr

false alarm? ... what did i miss? ...

#crysx

[tromp]

For a simple introduction to Cuckoo Cycle, please check my recent blog post at

http://cryptorials.io/beyond-hashcash-proof-work-theres-mining-hashing/

That's an intereseting concept for PoW (I know I'm very late to it), but I don't see any coin using it and it's been around since 2014...

very interesting indeed ...
i would definitely look into that with granite ...
#crysx

What's granite? Another GPU info tool like GPU-Z?
Are there any such tools available for Linux?

[chrysophylax]

For a simple introduction to Cuckoo Cycle, please check my recent blog post at

http://cryptorials.io/beyond-hashcash-proof-work-theres-mining-hashing/

That's an intereseting concept for PoW (I know I'm very late to it), but I don't see any coin using it and it's been around since 2014...

very interesting indeed ...
i would definitely look into that with granite ...
#crysx

What's granite? Another GPU info tool like GPU-Z?
Are there any such tools available for Linux?

no - its the x11 coin im renaming to granite from granitecoin ...

been working on it with core coin dev and - anomgst other things for the granite network ...

ccminer ( and sgminer ) have played a HUGE part in thefarm - which mines and continues to grow to mine - most of the coins out there ...

the granite ecosystem is coming together - and part of that is the donation links for miners ( to the devs ) and the pools ... i am just getting it all together slowly ...

so no - its not a tool for gpus ... but a coin that can be mined with gpus - and im continuing to look for ways of improving it ... and i do it all under linux ... ...

#crysx

[Cryptozillah]

I have noticed one strange thing with NiceHash (Quark)

I always get lower rejected hash after a reboot. If i reboot all my rigs i get like 30Mhs more (130-140Mhs in total) in total accepted hashrate. And then it slowly go down to stabilize at 100Mhs, at the same rate as the rejected hasrate goes up.

So right now i am rebooting my rigs on schedule every two hours to keep the rejects as low as possible.

Anyone have an idea about why this is happening ?

[pallas]

I have noticed one strange thing with NiceHash (Quark)

I always get lower rejected hash after a reboot. If i reboot all my rigs i get like 30Mhs more (130-140Mhs in total) in total accepted hashrate. And then it slowly go down to stabilize at 100Mhs, at the same rate as the rejected hasrate goes up.

So right now i am rebooting my rigs on schedule every two hours to keep the rejects as low as possible.

Anyone have an idea about why this is happening ?

it doesn't happen to me (reject rate is always very low and negligible), maybe it's network related?

[chrysophylax]

I have noticed one strange thing with NiceHash (Quark)

I always get lower rejected hash after a reboot. If i reboot all my rigs i get like 30Mhs more (130-140Mhs in total) in total accepted hashrate. And then it slowly go down to stabilize at 100Mhs, at the same rate as the rejected hasrate goes up.

So right now i am rebooting my rigs on schedule every two hours to keep the rejects as low as possible.

Anyone have an idea about why this is happening ?

it doesn't happen to me (reject rate is always very low and negligible), maybe it's network related?

try a lower intensity for the miner ...

#crysx

[Masked_Immortal]

beer for you

sp     : e5765c44e2589c7f66c0afcc871a001a35045b03d4b7b9b628f01b9e55720ed4
pallas : 50c053b2871b0fa1856b3dd6465001e28fd6378844f4eccc0a69aca6dc223ad4

[pallas]

beer for you

sp     : e5765c44e2589c7f66c0afcc871a001a35045b03d4b7b9b628f01b9e55720ed4
pallas : 50c053b2871b0fa1856b3dd6465001e28fd6378844f4eccc0a69aca6dc223ad4

thanks! :-)

[myagui]

I have noticed one strange thing with NiceHash (Quark)

I always get lower rejected hash after a reboot. If i reboot all my rigs i get like 30Mhs more (130-140Mhs in total) in total accepted hashrate. And then it slowly go down to stabilize at 100Mhs, at the same rate as the rejected hasrate goes up.

So right now i am rebooting my rigs on schedule every two hours to keep the rejects as low as possible.

Anyone have an idea about why this is happening ?

I would advise setting up each rig as it's own nicehash worker, and preferably use fixed share difficulty, adjusted to about 1 share per minute on each rig (needs experimentation until the best value is found).

Have you confirmed if restarting ccminer on all the rigs achieves the same result (high hashrate & low rejects) as the full reboot?
The only other thing I can think of, is the case of your rigs all heating up beyond the optimal performance sweet spot. You could try lowering clocks or increasing fan speeds, and see if performance settles at a higher figure after warming up.

[Genoil]

Agree, Ethminer is still very lucrative although it looks like Nvidia hardware hit the memory controller limitation and can't go anywhere else, much like Cryptonote.

Look at lyra2v2. It's also a memory hard algorithm.
280x Sgminer opensource(200watt) 4MHASH
750ti Djm-34 (sp-mod) opensource (40watt) 5MHASH
It's like creating a etherum miner that does 35MHASH on the 750ti.
But the opensource is only doing 8MHASH...

(djm34 here...)
The main difference between the algo of ethereum and other mem hard algo, is that you can't rescale mem usage as it always requires the full dag file to run (ie 1.2Gb or so of vram with many random over the full dag file)
Meaning you can't really improve passed what has already been done... (yeah, I tried already   ).

But you should be able to make the kernal run at copyspeed. (memory bandwidth limit) The gpu can do register operations while writing to memory. The keccak passes should be integrated and more than one hash per run. Then you will get keccak for free. (memory pipelining)

thx i'll try that 

[Cryptozillah]

I have noticed one strange thing with NiceHash (Quark)

I always get lower rejected hash after a reboot. If i reboot all my rigs i get like 30Mhs more (130-140Mhs in total) in total accepted hashrate. And then it slowly go down to stabilize at 100Mhs, at the same rate as the rejected hasrate goes up.

So right now i am rebooting my rigs on schedule every two hours to keep the rejects as low as possible.

Anyone have an idea about why this is happening ?

it doesn't happen to me (reject rate is always very low and negligible), maybe it's network related?

Hmm not sure.

I have noticed one strange thing with NiceHash (Quark)

I always get lower rejected hash after a reboot. If i reboot all my rigs i get like 30Mhs more (130-140Mhs in total) in total accepted hashrate. And then it slowly go down to stabilize at 100Mhs, at the same rate as the rejected hasrate goes up.

So right now i am rebooting my rigs on schedule every two hours to keep the rejects as low as possible.

Anyone have an idea about why this is happening ?

it doesn't happen to me (reject rate is always very low and negligible), maybe it's network related?

try a lower intensity for the miner ...

#crysx

I am running 24 right now on my nvidia rigs. I will lower it a bit and see what happends.
I have the same problems on my AMD rigs though. I forgot to say that.

I have noticed one strange thing with NiceHash (Quark)

I always get lower rejected hash after a reboot. If i reboot all my rigs i get like 30Mhs more (130-140Mhs in total) in total accepted hashrate. And then it slowly go down to stabilize at 100Mhs, at the same rate as the rejected hasrate goes up.

So right now i am rebooting my rigs on schedule every two hours to keep the rejects as low as possible.

Anyone have an idea about why this is happening ?

I would advise setting up each rig as it's own nicehash worker, and preferably use fixed share difficulty, adjusted to about 1 share per minute on each rig (needs experimentation until the best value is found).

Have you confirmed if restarting ccminer on all the rigs achieves the same result (high hashrate & low rejects) as the full reboot?
The only other thing I can think of, is the case of your rigs all heating up beyond the optimal performance sweet spot. You could try lowering clocks or increasing fan speeds, and see if performance settles at a higher figure after warming up.

How do i do that ?, i mean set fixed share diff ?
I need a full reboot to gain maximum accepted hashrate at NiceHash. Restarting the miner only wont affect anything.

[pokeytex]

Does anyone know what the whirlpoolx algo is like on ccminer?

[pallas]

Does anyone know what the whirlpoolx algo is like on ccminer?

On AMD my whirlpoolx miner does 670 Mh/s.
I tried ccminer some time ago on 970 and it was about 300 Mh/s, if I recall correctly.
I'd be glad to optimize ccminer like I did for AMD, but I see less and less interest in mining that algo, so I dropped the idea.

[scryptr]

Is VTC solo issue fixed ?

VTC-SOLO--

T-nelson was working on it when a "Lyra2v2 doesn't work" false alarm propagated thru the thread.  He is diagnosing with one 750ti, so it may take a week to hit a block and get error log and debug info.  CryptoMining Blog states that CCminer crashes on hitting a block, and my personal results agree.  However, I was not running any error-catching software.       --scryptr

false alarm? ... what did i miss? ...

#crysx

MEMORY--

I beleive that you said that you were using the wrong port.  --scryptr

[flipclip]

Is VTC solo issue fixed ?

VTC-SOLO--

T-nelson was working on it when a "Lyra2v2 doesn't work" false alarm propagated thru the thread.  He is diagnosing with one 750ti, so it may take a week to hit a block and get error log and debug info.  CryptoMining Blog states that CCminer crashes on hitting a block, and my personal results agree.  However, I was not running any error-catching software.       --scryptr

false alarm? ... what did i miss? ...

#crysx

MEMORY--

I beleive that you said that you were using the wrong port.  --scryptr

He might have been, but lyra2v2 was broken, which sp_ fixed.

[myagui]

[...]
I am running 24 right now on my nvidia rigs. I will lower it a bit and see what happends.
I have the same problems on my AMD rigs though. I forgot to say that.
[...]
How do i do that ?, i mean set fixed share diff ?
I need a full reboot to gain maximum accepted hashrate at NiceHash. Restarting the miner only wont affect anything.

You didn't say anything about running separate workers. I don't understand how you can tell that the problem is global, without having looked at individual worker stats. This is particularly important since you mention that also AMD rigs are doing the same.

It's most likely that it is a single rig having trouble, not all of them.

For fixed difficulty (though I'm not sure if it stays fixed onwards, or if just adjusting starting diff):
-p d=1 (replace 1 with whatever is your desired difficulty)

For individual worker shares, all mining into the same BTC addy:
-u yourbtcaddy.worker (replace worker with some unique worker name for each rig)

Another way of finding out which rig is causing trouble, if it is indeed a single rig, is that you could point one rig at a time into some alternate btc addy, so that you isolate the stats for that rig alone. Measure up to the 2 hour point or so, and move on to the next rig. With individual worker names you should be able to monitor individual rig stats while keeping the btc destination the same.

[Cryptozillah]

[...]
I am running 24 right now on my nvidia rigs. I will lower it a bit and see what happends.
I have the same problems on my AMD rigs though. I forgot to say that.
[...]
How do i do that ?, i mean set fixed share diff ?
I need a full reboot to gain maximum accepted hashrate at NiceHash. Restarting the miner only wont affect anything.

You didn't say anything about running separate workers. I don't understand how you can tell that the problem is global, without having looked at individual worker stats. This is particularly important since you mention that also AMD rigs are doing the same.

It's most likely that it is a single rig having trouble, not all of them.

For fixed difficulty (though I'm not sure if it stays fixed onwards, or if just adjusting starting diff):
-p d=1 (replace 1 with whatever is your desired difficulty)

For individual worker shares, all mining into the same BTC addy:
-u yourbtcaddy.worker (replace worker with some unique worker name for each rig)

Another way of finding out which rig is causing trouble, if it is indeed a single rig, is that you could point one rig at a time into some alternate btc addy, so that you isolate the stats for that rig alone. Measure up to the 2 hour point or so, and move on to the next rig. With individual worker names you should be able to monitor individual rig stats while keeping the btc destination the same.

Ah i see. I just thought it was too much hashrate to only involve one of my rigs.
Thanks for the explanation about the diff. I will give it some time to try out stuff with individial workers.

[flipclip]

For fixed difficulty (though I'm not sure if it stays fixed onwards, or if just adjusting starting diff):
-p d=1 (replace 1 with whatever is your desired difficulty)

Its starting diff, and set as your preferred difficulty (though if there are no orders at that diff, nicehash adjusts it)
From Nicehash: "Nevertheless you can use parameter d=diff in your password to set starting difficulty." and "...since the difficultly you set is only a preferred difficulty and the actual difficulty depends on the current orders at NiceHash."

[flipclip]

....
I will give it some time to try out stuff with individial workers.

For the worker name nicehash accepts "up to seven alphanumeric (Aa-Zz, 0-9) characters".  Just in case you get too crazy with the name 

[Cryptozillah]

For fixed difficulty (though I'm not sure if it stays fixed onwards, or if just adjusting starting diff):
-p d=1 (replace 1 with whatever is your desired difficulty)

Its starting diff, and set as your preferred difficulty (though if there are no orders at that diff, nicehash adjusts it)
From Nicehash: "Nevertheless you can use parameter d=diff in your password to set starting difficulty." and "...since the difficultly you set is only a preferred difficulty and the actual difficulty depends on the current orders at NiceHash."

Good stuff ! Thanks alot

....
I will give it some time to try out stuff with individial workers.

For the worker name nicehash accepts "up to seven alphanumeric (Aa-Zz, 0-9) characters".  Just in case you get too crazy with the name  

ok, miner 1-6 works for me lol