CCminer(SP-MOD) Modded GPU kernels.

[Grout]

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

[chrysophylax]

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 ...

tanx ...

#crysx

[djm34]

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   

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... 

[Nubminer]

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...

[chrysophylax]

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    

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...  

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 ...

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 ...

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 ... 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 ...

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

#crysx

[sp_]

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.

[sp_]

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_]

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.

[fenomenhaa]

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 )) 

[chrysophylax]

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 ))  

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

[fenomenhaa]

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 ))  

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 )) .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.

[Grout]

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 :-)

[djm34]

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   

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... 

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 ...

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 ...

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 ... 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 ...
#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.

[antonio8]

I get low accepted % on lyra2. Around 84% on release 49.

[chrysophylax]

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 ))  

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 )) .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.

thats the whole point ... the rigs ( custom designed frames and systems ) will have exactly 12 x gigabyte 750ti oc lp units running from it ...

building it this week ... as it has passed all the testing that we have thrown at it - and is not that expensive for a good quality unit ...

no modding on ANY of the cards ... we like to stick with stock cards so there are no hidden surprises ... the moment you start modding and playing with anything else bar the clocks - you are putting yourself in a situation of uncharted territory - and may cause a great deal of loss of time and effort ... valuable time that could have gone into building a better system - and much more of them ...

for those that want to mod and play with firmware - no issues ... we cannot afford that luxury of the untested grounds ... yet ...

currently - its a testing phase for fedora 20 x64 and all thats involved with running these systems efficiently and building a practical working system as a base ... THEN when the whole farm is done - start to work on mods and such ...

high efficiency psu like the rm1000 will be a long term investment for the miners ... less downtime and much less maintenance ...

we have been running thermaltake 875W 850W as well as 750W and a few other psu's ( size and brands ) only to find intermittent issues with these lower end psu's ... still good for the short term - but not very efficient ...

each rig will be a hashrate junkie - with potential to be upgraded to MUCH bigger systems if need be ...

this current farm we have has taught us a great deal ... ...

#crysx

[chrysophylax]

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   

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... 

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 ...

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 ...

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 ... 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 ...
#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.

agreed ...

but with so many systems being built and running them on a system like that ( one which we have very little experience with ) the learning curve is a steep and long one ...

you do however - make a very strong point about it being a separate system to run - without touching the base system ...

i personally have looked into it - and find it fascinating in that it is already set as an 'as is' miner ...

really - the only issue that i have found with it - is as soon as you start changing bits in the software - you 'can' run into issues with driver compatibility and so forth ...

we have a copy of it here - so when the testing and building and reconstruction of the farm is done - i will definitely look into it further in much more depth ...

tanx djm ...

#crysx

[chrysophylax]

I get low accepted % on lyra2. Around 84% on release 49.

are you using ccminer-spmod with the -g option? ...

if so - drop it and go back to the 'standard' parameters and see how that works mate ...

#crysx

[sp_]

I get low accepted % on lyra2. Around 84% on release 49.

Try this build, or build yourself.

http://cryptomining-blog.com/4718-updated-windows-binary-of-the-ccminer-1-5-49-git-fork-by-sp-for-maxwell/

There has been some fixes/improvements in lyra2

[antonio8]

@ chrysophylax 

No -g parameter. It does not work for me as it just crashes my driver, Windows 7 64 bit. It does the same on Windows 10 64 bit. Just running regular bat. Not even -i setting.

@ sp_

That build does have a slight speed increase and my hash rat is a little higher after about 10 minutes of running but still only 88% so far.

Will see if it gets better.

[Slava_K]

Cant use   sp-mod ccminer on lga775 intel platform. Only old djm34 mod...
p.s. win7 x64, clean install, latest drivers, vc 2013 runtimes installed.