Author

Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 1105. (Read 2347601 times)

legendary
Activity: 1400
Merit: 1050
hi all ...

been busy trying to figure out what it is that the issue maybe with the compilation lock up and freezes since the addition of neoscrypt in ccminer-sp ...

with the help of a fantastic ( but for the moment hidden - you know who you are mate ) watcher of this thread - it looks like we have narrowed down the issue to versions of cuda ( and some associated files ) in fedora itself ...

if this is the case - and it really seems like it is - then a full upgrade of the farm needs to be taken into account ... something we were not looking forward to ... a full weeks worth of work ...

djm34 pointed a similar issue out quite a while ago when he still had the miner in closed distribution ( cuda version 6.0 - cuda 6.5 ) - whereby his neoscrypt miner refused to compile in the same environment ...

yep, I told you so repeatedly    Grin

must admit, I never understood your insistence at that level for keeping a deprecated package, cuda is a dev package for nvidia (not related to any specific drivers, neither to the os)... anyway...
I guess many have to tell you the same thing for you to listen...  Grin


no - not at all djm ...

its the working model we have for the farm ... we are not just a single user with a computer or two that just mine occasionally djm ... we have a certain protocol we follow in order to make things digestible for easy implemenatation for the farm that are under the guidelines we have set for the farm ...

even so - ccminer-spmod is STILL not working with cuda 6.5 - but it compiles now ...

its the distro we have chosen ( fedora IS bleeding edge - so its expected to have bugs and incompatabilities ) ... and the reason we have chosen THIS distro is due to its ease of use as a desktop environment ...

our farm is NOT just for farming - its for ease of upgrade ... fedora is the 'better' package for that ...

if the farm is to be pulled apart for instance - and sold off - the machines require no more than a few packages removed and another few installed for it to be built into a computer system that can be sold off for the basic user ... a matter of 20 minutes work - unlike a completely full install with additions of hdd and a few other components .. these machines are COMPLETE in every way as a desktop system except for the software ( and 5 or 6 cards per machine ) ... our goal is for adaptability for the farm and unfortunately - that is fraught with issues ...

the new farm ( upgraded farm we have been working on for the last few months ) is SPECIFICALLY a farm - even though it has a similar goal for updatability - it is designed only to be upgraded as a farm and nothing else ... so the apps and versions and way its built ( from custom designed frames to 'standard' software and apps rolled out across the entire farm ) is standard right down to the components used ... ALL machines will be EXACTLY the same ...

so - one compile - one miner - one installation ...

we are trying to save a lot of work upgrading THIS current farm ( especially me ) - so deprecated or not - it is what we were aiming at using different components ( different cpus - ram - motherboards psu ) ... this farm is what we have until the other farm is ready ... once the new farm is ready - it will be very easy to replicate every machine - both hardware and software ... and it will all have the latest software - so we can keep up Wink ...

so you are correct in that we need to sustain updatability - but even with the successful compile - the miner is still not working ...

we cannot be the ONLY ones with this issue - considering fedora is one of the largest distributions for desktops in the world ... maybe those with these issues also are just not speaking up Smiley ...

when we get the miner running properly under fedora ( 20 or 21 ) - then the whole process can be replicated easily ...

until then - v47 is the version that is running currently with v48 on a couple of the other systems under fedora 19 x64 ...

cuda 7.0 repo is about to be released under fedora 21 x64 ... that is the one im more interested in Wink ... as apparently it has backward compatibility to the previous versions ...

i personally want an automated system for farmers ... which will mean that even those that just want to run only a couple of systems - will be able to duplicate the method and have miners / workers AND desktops / development machines with a single install ...

i would luv to be able to have a management console that could be rolled out ( in a single .rpm ) across an entire system for stats and maintenance purposes ... but that is a bit down the track ...

btw - we cannot use 'other' systems like kompiemtu and the like unless we can convert these machines back to desktop systems ... ideas are always welcome though Wink ...
#crysx
actually kopiemtu and alike work from a usb stick or very small drive, and wouldn't alter your system at all, actually it would be even better for you, since you could keep your system and have a dedicated os for mining you could run or not.
full member
Activity: 139
Merit: 100
Hi guys,
Just received a new graphics card for my gaming rig and had to test ccminer on it :-)
The results are quite impressive and I wanted to know if they look normal to you :
- GTX 970 (Gigabyte G1 Gaming) : 16.4MH/s on quark, Windows 8.1, 200W
- GTX 750 Ti (Gigabyte N750TOC-2GI) in my mining rig : 5.68MH/s each on quark, Ubuntu 15.04, 60W
Both systems are running the latest 1.5.49-git version. All cards are at stock clock.
If these figures are correct, that means it takes 3 750s to match my 970. And these 3 750 are more expensive than the bigger card.
Granted, they consume a little bit less (about 10% at equal hashrate), but the reduced footprint and density gain might be worth it.
What do you think? Did I miss something? Do you get similar values on the latest version?
@SP, here are the results for the other algos I tested with my 970:
X11, 8320 kH/s
X13, 6660 kH/s
X15, 5770 kH/s
Qubit, 12600 kH/s
Skein, 220000 kH/s
NeoScrypt, 560 kH/s

Skein is abit low at 220. You should get closer to 265.
The  N750TOC-2GI comes with a 6pin powercable. Since the power draw is 60 watt you should get more hash with overclocking. Reflash the bios to gforce black.
Other 750ti cards can use as low as 40watt per card when hashing.

200watt for quark is abit high, but so is your hashrate.

with 6-7 970 cards at 200w you need 1500Watt of power for your rig. Cheaper to spread the cards, 2-3 970 and fill the rest of the pci slots with 960 or 750ti cards.
Then you can use normal cheaper gaming PSU's

...

http://www.geforce.com/hardware/desktop-gpus/geforce-gtx-970/specifications:

The GeForce GTX 980 has a TDP rating of just 165 Watts, and the GTX 970 145Watt.

Thanks for the reply. I have to say I'm really impressed with this card. I guess I'll leave a miner running on my gaming rig when I don't use it, can't leave that kind of hashpower asleep ;-)
And glad to see I was not mistaken. I'll consider a mix of 970 and 750 for my next upgrades. My rig currently uses a 550W PSU I had laying around and my motherboard has 6 PCI-E ports. So I guess it should be able to handle 2 970 and 3 750 before I have to upgrade.
Another factor to take into account is the noise: the 750 rig is silent. The 970 definitely is not...

My test of the other algos was very short (2-3 minutes to get a ballpark figure), so that might explain the low value for Skein. I'm only interested in Quark ATM, since it is the only algo that's profitable in the summer with my setup :-)

Is you miner able to handle different cards? Or is it safer to run separate instances? One for the 970s and one for the 750s?


EDIT: After a bit more fiddling with the 970, I forced the intensity to 20 which seems to be the sweet spot for me: it keeps desktop functionnality (fullscreen videos run fine) with an honest 15.7MH/s on quark and a power consumption of 180W. I loose a little, but it allows me to keep the miner running when I'm not playing :-)
sr. member
Activity: 248
Merit: 250
with 6-7 970 cards at 200w you need 1500Watt of power for your rig. Cheaper to spread the cards, 2-3 970 and fill the rest of the pci slots with 960 or 750ti cards.
Then you can use normal cheaper gaming PSU's

...

http://www.geforce.com/hardware/desktop-gpus/geforce-gtx-970/specifications:

The GeForce GTX 980 has a TDP rating of just 165 Watts, and the GTX 970 145Watt.
Maybe better to spread the psu's Smiley))  Grin

that was one of the main considerations with building our workers ...

we have cut psu usage down from high powered 1500W psu - to standard 850W thermaltake due to the use of the gigabyte 750ti oc lp cards ...

the new systems will be built with 1000W corsair rm1000 psu ( as they are a low profile managed psu also ) - to power all 6 x 750ti oc lp cards and the rest of the machine with plenty of ( power ) room to spare ...

#crysx
Corsair Rm1000 W psu is too much for 6 x750Ti rig.RM1000W is Chicony built good quality psu .Easliy configurable with 12 750Ti Smiley)) .Usualy regular good quality psu's have best efficients between %50-80 load.According to wattmeter 5x750Ti (Bios moded Tdp incerase to 65W +o/c 150core 100mem vomoded to 1.2v)390W from the wall(Quark) other algos consumption is less then quark With a %85 efficeny psu so its :330W in reality. My advice is 600-750w (strongly recommend Seasonic or enermax builds) Psu strong and very effiecient option with 6x750Ti rigs.
legendary
Activity: 2912
Merit: 1091
--- ChainWorks Industries ---
with 6-7 970 cards at 200w you need 1500Watt of power for your rig. Cheaper to spread the cards, 2-3 970 and fill the rest of the pci slots with 960 or 750ti cards.
Then you can use normal cheaper gaming PSU's

...

http://www.geforce.com/hardware/desktop-gpus/geforce-gtx-970/specifications:

The GeForce GTX 980 has a TDP rating of just 165 Watts, and the GTX 970 145Watt.
Maybe better to spread the psu's Smiley))  Grin

that was one of the main considerations with building our workers ...

we have cut psu usage down from high powered 1500W psu - to standard 850W thermaltake due to the use of the gigabyte 750ti oc lp cards ...

the new systems will be built with 1000W corsair rm1000 psu ( as they are a low profile managed psu also ) - to power all 6 x 750ti oc lp cards and the rest of the machine with plenty of ( power ) room to spare ...

#crysx
sr. member
Activity: 248
Merit: 250
with 6-7 970 cards at 200w you need 1500Watt of power for your rig. Cheaper to spread the cards, 2-3 970 and fill the rest of the pci slots with 960 or 750ti cards.
Then you can use normal cheaper gaming PSU's

...

http://www.geforce.com/hardware/desktop-gpus/geforce-gtx-970/specifications:

The GeForce GTX 980 has a TDP rating of just 165 Watts, and the GTX 970 145Watt.
Maybe better to spread the psu's Smiley))  Grin
sp_
legendary
Activity: 2926
Merit: 1087
Team Black developer
with 6-7 970 cards at 200w you need 1500Watt of power for your rig. Cheaper to spread the cards, 2-3 970 and fill the rest of the pci slots with 960 or 750ti cards.
Then you can use normal cheaper gaming PSU's

...

http://www.geforce.com/hardware/desktop-gpus/geforce-gtx-970/specifications:

The GeForce GTX 980 has a TDP rating of just 165 Watts, and the GTX 970 145Watt.
sp_
legendary
Activity: 2926
Merit: 1087
Team Black developer
Hi guys,
Just received a new graphics card for my gaming rig and had to test ccminer on it :-)
The results are quite impressive and I wanted to know if they look normal to you :
- GTX 970 (Gigabyte G1 Gaming) : 16.4MH/s on quark, Windows 8.1, 200W
- GTX 750 Ti (Gigabyte N750TOC-2GI) in my mining rig : 5.68MH/s each on quark, Ubuntu 15.04, 60W
Both systems are running the latest 1.5.49-git version. All cards are at stock clock.
If these figures are correct, that means it takes 3 750s to match my 970. And these 3 750 are more expensive than the bigger card.
Granted, they consume a little bit less (about 10% at equal hashrate), but the reduced footprint and density gain might be worth it.
What do you think? Did I miss something? Do you get similar values on the latest version?
@SP, here are the results for the other algos I tested with my 970:
X11, 8320 kH/s
X13, 6660 kH/s
X15, 5770 kH/s
Qubit, 12600 kH/s
Skein, 220000 kH/s
NeoScrypt, 560 kH/s

Skein is abit low at 220. You should get closer to 265.
The  N750TOC-2GI comes with a 6pin powercable. Since the power draw is 60 watt you should get more hash with overclocking. Reflash the bios to gforce black.
Other 750ti cards can use as low as 40watt per card when hashing.

200watt for quark is abit high, but so is your hashrate.
sp_
legendary
Activity: 2926
Merit: 1087
Team Black developer
Fixed it now.
try with -g 2. on the 750 ti the boost is 150MHASH. But it crashes after a while. Will reduce intensity
With build 780, the 2x970 FTW+ rig gets 2.88Gh/s, or 1.44Gh/s per card with no "-g" switch.  With "-g 2", 4 threads initialize at launch, I get a 5.0gH/s reported locally at the console, and I think it crashes.  I get a poolside rate of about 2Gh/s, and the console is reporting hash only for GPU #0.

I have fixed the console output. with 2 gpu's in the rig it only displayed statistics for GPU #0. As for the multiple threads it needs some more work. I tried with -g 4 and the displayed hashrate is increased, but I get less yays on the pool. The only problem is that I don't get any "does not validate on the cpu errors." and the benchmark mode is working. It could be a nounce problem, that two threads are solving the same problem at the same time. I need to review the extranounce code, perhaps remove it with a switch to see if the hashrate is increased.
legendary
Activity: 2912
Merit: 1091
--- ChainWorks Industries ---
hi all ...

been busy trying to figure out what it is that the issue maybe with the compilation lock up and freezes since the addition of neoscrypt in ccminer-sp ...

with the help of a fantastic ( but for the moment hidden - you know who you are mate ) watcher of this thread - it looks like we have narrowed down the issue to versions of cuda ( and some associated files ) in fedora itself ...

if this is the case - and it really seems like it is - then a full upgrade of the farm needs to be taken into account ... something we were not looking forward to ... a full weeks worth of work ...

djm34 pointed a similar issue out quite a while ago when he still had the miner in closed distribution ( cuda version 6.0 - cuda 6.5 ) - whereby his neoscrypt miner refused to compile in the same environment ...

yep, I told you so repeatedly    Grin

must admit, I never understood your insistence at that level for keeping a deprecated package, cuda is a dev package for nvidia (not related to any specific drivers, neither to the os)... anyway...
I guess many have to tell you the same thing for you to listen...  Grin


no - not at all djm ...

its the working model we have for the farm ... we are not just a single user with a computer or two that just mine occasionally djm ... we have a certain protocol we follow in order to make things digestible for easy implemenatation for the farm that are under the guidelines we have set for the farm ...

even so - ccminer-spmod is STILL not working with cuda 6.5 - but it compiles now ...

its the distro we have chosen ( fedora IS bleeding edge - so its expected to have bugs and incompatabilities ) ... and the reason we have chosen THIS distro is due to its ease of use as a desktop environment ...

our farm is NOT just for farming - its for ease of upgrade ... fedora is the 'better' package for that ...

if the farm is to be pulled apart for instance - and sold off - the machines require no more than a few packages removed and another few installed for it to be built into a computer system that can be sold off for the basic user ... a matter of 20 minutes work - unlike a completely full install with additions of hdd and a few other components .. these machines are COMPLETE in every way as a desktop system except for the software ( and 5 or 6 cards per machine ) ... our goal is for adaptability for the farm and unfortunately - that is fraught with issues ...

the new farm ( upgraded farm we have been working on for the last few months ) is SPECIFICALLY a farm - even though it has a similar goal for updatability - it is designed only to be upgraded as a farm and nothing else ... so the apps and versions and way its built ( from custom designed frames to 'standard' software and apps rolled out across the entire farm ) is standard right down to the components used ... ALL machines will be EXACTLY the same ...

so - one compile - one miner - one installation ...

we are trying to save a lot of work upgrading THIS current farm ( especially me ) - so deprecated or not - it is what we were aiming at using different components ( different cpus - ram - motherboards psu ) ... this farm is what we have until the other farm is ready ... once the new farm is ready - it will be very easy to replicate every machine - both hardware and software ... and it will all have the latest software - so we can keep up Wink ...

so you are correct in that we need to sustain updatability - but even with the successful compile - the miner is still not working ...

we cannot be the ONLY ones with this issue - considering fedora is one of the largest distributions for desktops in the world ... maybe those with these issues also are just not speaking up Smiley ...

when we get the miner running properly under fedora ( 20 or 21 ) - then the whole process can be replicated easily ...

until then - v47 is the version that is running currently with v48 on a couple of the other systems under fedora 19 x64 ...

cuda 7.0 repo is about to be released under fedora 21 x64 ... that is the one im more interested in Wink ... as apparently it has backward compatibility to the previous versions ...

i personally want an automated system for farmers ... which will mean that even those that just want to run only a couple of systems - will be able to duplicate the method and have miners / workers AND desktops / development machines with a single install ...

i would luv to be able to have a management console that could be rolled out ( in a single .rpm ) across an entire system for stats and maintenance purposes ... but that is a bit down the track ...

btw - we cannot use 'other' systems like kompiemtu and the like unless we can convert these machines back to desktop systems ... ideas are always welcome though Wink ...

anyway ... back to work on it again ...

#crysx
member
Activity: 75
Merit: 10
Hi guys,

Just received a new graphics card for my gaming rig and had to test ccminer on it :-)
The results are quite impressive and I wanted to know if they look normal to you :
- GTX 970 (Gigabyte G1 Gaming) : 16.4MH/s on quark, Windows 8.1, 200W
- GTX 750 Ti (Gigabyte N750TOC-2GI) in my mining rig : 5.68MH/s each on quark, Ubuntu 15.04, 60W

Both systems are running the latest 1.5.49-git version. All cards are at stock clock.

If these figures are correct, that means it takes 3 750s to match my 970. And these 3 750 are more expensive than the bigger card.
Granted, they consume a little bit less (about 10% at equal hashrate), but the reduced footprint and density gain might be worth it.
What do you think? Did I miss something? Do you get similar values on the latest version?


@SP, here are the results for the other algos I tested with my 970:
X11, 8320 kH/s
X13, 6660 kH/s
X15, 5770 kH/s
Qubit, 12600 kH/s
Skein, 220000 kH/s
NeoScrypt, 560 kH/s

Getting a bit mores on x11 with a 980 but my quark numbers were lower.

what pool did you use...
legendary
Activity: 1400
Merit: 1050
hi all ...

been busy trying to figure out what it is that the issue maybe with the compilation lock up and freezes since the addition of neoscrypt in ccminer-sp ...

with the help of a fantastic ( but for the moment hidden - you know who you are mate ) watcher of this thread - it looks like we have narrowed down the issue to versions of cuda ( and some associated files ) in fedora itself ...

if this is the case - and it really seems like it is - then a full upgrade of the farm needs to be taken into account ... something we were not looking forward to ... a full weeks worth of work ...

djm34 pointed a similar issue out quite a while ago when he still had the miner in closed distribution ( cuda version 6.0 - cuda 6.5 ) - whereby his neoscrypt miner refused to compile in the same environment ...

yep, I told you so repeatedly    Grin

must admit, I never understood your insistence at that level for keeping a deprecated package, cuda is a dev package for nvidia (not related to any specific drivers, neither to the os)... anyway...
I guess many have to tell you the same thing for you to listen...  Grin
legendary
Activity: 2912
Merit: 1091
--- ChainWorks Industries ---
hi all ...

been busy trying to figure out what it is that the issue maybe with the compilation lock up and freezes since the addition of neoscrypt in ccminer-sp ...

with the help of a fantastic ( but for the moment hidden - you know who you are mate ) watcher of this thread - it looks like we have narrowed down the issue to versions of cuda ( and some associated files ) in fedora itself ...

if this is the case - and it really seems like it is - then a full upgrade of the farm needs to be taken into account ... something we were not looking forward to ... a full weeks worth of work ...

djm34 pointed a similar issue out quite a while ago when he still had the miner in closed distribution ( cuda version 6.0 - cuda 6.5 ) - whereby his neoscrypt miner refused to compile in the same environment ...

if the testing over the next few days proves this - then ill be back with an update ... especially if the code now uses all the latest cuda 6.5 processes ( which we think is compute 5.2 - which we 'think' cuda 6.0 does not support ) ...

with fedora 19 x64 - it is not that easy to install cuda 6.5 via repo ... and it still has issues with installing into fedora 20 x64 - with no display driver active due to the incompatibility of the akmod-nvidia kernel module ...

BUT - a ssh session into that same fedora 20 x64 with cuda 6.5 machine ( that has no display - so ssh is the only way to log in ) shows that ccminer-spmod compiles successfully ...

now all thats needed is to have a WORKING fedora 20 x64 system ( with a working x11.org  display ) so that we can test to see if the miner runs and test what the hashrates are ... possibly even f21x64 ( which is the desktop i personally use for work ) ...

will keep you updated - if you are still interested in knowing these trials of course Smiley ...

tanx ...

#crysx
full member
Activity: 139
Merit: 100
Hi guys,

Just received a new graphics card for my gaming rig and had to test ccminer on it :-)
The results are quite impressive and I wanted to know if they look normal to you :
- GTX 970 (Gigabyte G1 Gaming) : 16.4MH/s on quark, Windows 8.1, 200W
- GTX 750 Ti (Gigabyte N750TOC-2GI) in my mining rig : 5.68MH/s each on quark, Ubuntu 15.04, 60W

Both systems are running the latest 1.5.49-git version. All cards are at stock clock.

If these figures are correct, that means it takes 3 750s to match my 970. And these 3 750 are more expensive than the bigger card.
Granted, they consume a little bit less (about 10% at equal hashrate), but the reduced footprint and density gain might be worth it.
What do you think? Did I miss something? Do you get similar values on the latest version?


@SP, here are the results for the other algos I tested with my 970:
X11, 8320 kH/s
X13, 6660 kH/s
X15, 5770 kH/s
Qubit, 12600 kH/s
Skein, 220000 kH/s
NeoScrypt, 560 kH/s
legendary
Activity: 1797
Merit: 1028
Fixed it now.

try with -g 2. on the 750 ti the boost is 150MHASH. But it crashes after a while. Will reduce intensity

With build 780, the 2x970 FTW+ rig gets 2.88Gh/s, or 1.44Gh/s per card with no "-g" switch.  With "-g 2", 4 threads initialize at launch, I get a 5.0gH/s reported locally at the console, and I think it crashes.  I get a poolside rate of about 2Gh/s, and the console is reporting hash only for GPU #0.  I still get console reports of 4 to 5 Gh/s, the pool is having difficulty making sense of it.  At best, the miner was reported as producing 3Gh/s of 3.4Gh/s total for all three mining connections hashing Blake at the time, of which my rig was only 1.       --scryptr

With build 782, the same rig behaves well, and with identical numbers as above, for single-threaded use.  With "-g 2", the results are again pretty much the same.  I get a hash rate at the console of 4-5Gh/s accepted from the rig, and all reports of card rates are for card #0, at 2.5-2.8Gh/s per card.  The pool reports receiving 2.7Gh/s from my rig after about 15 minutes.

I haven't generated a coin-share yet with Blake as I mine on Yaamp.  The rig is the only current miner on Blake.       --scryptr
hero member
Activity: 677
Merit: 500
-g 2  on 3x 960GTX is 5.2 Ghash! Smiley on blake
legendary
Activity: 1510
Merit: 1003

try with -g 2. on the 750 ti the boost is 150MHASH. But it crashes after a while. Will reduce intensity
Sorry, I have no faith in -g parameter. I think miner-shown performance is incorrect in this mode. Pools have no confirm of the boost in -g mode in my case.
sp_
legendary
Activity: 2926
Merit: 1087
Team Black developer
Fixed it now.

try with -g 2. on the 750 ti the boost is 150MHASH. But it crashes after a while. Will reduce intensity
legendary
Activity: 1510
Merit: 1003
What is the speed? Try to lower the intensity. The default is set to -i 29 wich is too high.

the speed is 474900 khashes/s
-i parameter doesn't change cpu load. The same 100% load of one core. With real-time priority unusable ...
sp_
legendary
Activity: 2926
Merit: 1087
Team Black developer
What is the speed? Try to lower the intensity. The default is set to -i 29 wich is too high.
legendary
Activity: 1510
Merit: 1003
2 sp_

blake loads one cpu core to the maximum for me ... gtx750 ... both my own build and from your link
Jump to: