Could anyone check the speed of blake on the 980 960 and the 970?
ccminer -a blake -o stratum+tcp://yaamp.com:4533 -u WALLET_ADDRESS -p xx
build yourself or download binaries from here:
http://cryptomining-blog.com/4718-updated-windows-binary-of-the-ccminer-1-5-49-git-fork-by-sp-for-maxwell/
Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 1106. (Read 2347601 times)
eitherway - non of the latest are compiling now since the introduction of neoscrypt - that was the pivot between a successful compile ( which i can still replicate with the earlier versions using the SAME environment and SAME script ) to a non-successful one ( also using the SAME environment and script ) ...
the ONLY difference between them was the introduction of neoscrypt ... which leads me to believe ( and i could be WAy off here ) that there are certain calls to the compile of the source that are NOT standard - or at least as you suggested - may have conflicts with the versions of the build ...
the farm is still running v47 and v48 - and will remain that way until there is a resolve for the this ...
in a few weeks - the farm will grow in size again by a fraction - and i really want to get this resolved before then - so any suggestions on the part of the compilation would very highly sought ... and i would be very grateful ...
#crysx
Which version of CUDA are you compiling with? 6.0 or 6.5? I compile with 6.5 without issue (though Ubuntu, like scryptr). Are you able to compile djm34's ccminer without issue? (since that is where the neoscrypt and yescrypt code is from, I believe.)
COMMIT 778 and 779--
Both commits built readily with "BASH build.sh" and the default makefile.am. I notice that SP_ already has commit 780 on GitHub.
For Lyra2, I am getting 820kh/s per 750ti, and 4.8 mh/s for my 6x750ti FTW rig. Quark is a little slower, though, building up to 38Mh/s for the 750ti rig, and slower than the previous 38.6Mh/s on the same rig. --scryptr
Both commits built readily with "BASH build.sh" and the default makefile.am. I notice that SP_ already has commit 780 on GitHub.
For Lyra2, I am getting 820kh/s per 750ti, and 4.8 mh/s for my 6x750ti FTW rig. Quark is a little slower, though, building up to 38Mh/s for the 750ti rig, and slower than the previous 38.6Mh/s on the same rig. --scryptr
so you build with bash and not sh? ...
ok ... ALL of my compiles have been using sh ...
with the introduction of neoscrypt - does that change anything? ...
ill setup a test for use with bash and see how it goes ... NONE of the new commits are compiling now - NONE! ...
ive tested a compile using the older v47 and v48 - and they compile within minutes ... and work very well - using the SAME environment and compilation method that im using the latest with ...
something strange is happening and the code is just refuses to compile ...
#crysx
BASH vs SH--
I started specifying BASH after the script posted by Skunk would not execute properly with SH. The two are not completely equivalent. I think just "./build.sh" would work if you tried it, making sure that it had executable permission.
I did not realize there was a difference. Some scripts have an sh header, some have a bash header, I never paid attention.
If your build.sh script is messing up, it is out of my league. It might be a linux distro conflict. I'll help if I can, but you may likely be looking at a package conflict between distros of linux. The current (commit 780) "Makefile.am" works on my Ubuntu system with no editing or fatal error. --scryptr
the compile script ( which is just a simply a few changes to the build.sh file that sp provides - but with a few more commands to automate the ccminer installation on our fedora systems ) is ALWAYS run via sh ( #!/bin/sh as the header ) and has always worked ...
whereas the original build.sh that comes with sp's commits are all started with #!/bin/bash/ ...
i know there are slight differences ( but dont know exactly what they are ) - but never had any issue with the build until very recently ...
eitherway - non of the latest are compiling now since the introduction of neoscrypt - that was the pivot between a successful compile ( which i can still replicate with the earlier versions using the SAME environment and SAME script ) to a non-successful one ( also using the SAME environment and script ) ...
the ONLY difference between them was the introduction of neoscrypt ... which leads me to believe ( and i could be WAy off here ) that there are certain calls to the compile of the source that are NOT standard - or at least as you suggested - may have conflicts with the versions of the build ...
the farm is still running v47 and v48 - and will remain that way until there is a resolve for the this ...
in a few weeks - the farm will grow in size again by a fraction - and i really want to get this resolved before then - so any suggestions on the part of the compilation would very highly sought ... and i would be very grateful ...
#crysx
COMMIT 778 and 779--
Both commits built readily with "BASH build.sh" and the default makefile.am. I notice that SP_ already has commit 780 on GitHub.
For Lyra2, I am getting 820kh/s per 750ti, and 4.8 mh/s for my 6x750ti FTW rig. Quark is a little slower, though, building up to 38Mh/s for the 750ti rig, and slower than the previous 38.6Mh/s on the same rig. --scryptr
Both commits built readily with "BASH build.sh" and the default makefile.am. I notice that SP_ already has commit 780 on GitHub.
For Lyra2, I am getting 820kh/s per 750ti, and 4.8 mh/s for my 6x750ti FTW rig. Quark is a little slower, though, building up to 38Mh/s for the 750ti rig, and slower than the previous 38.6Mh/s on the same rig. --scryptr
so you build with bash and not sh? ...
ok ... ALL of my compiles have been using sh ...
with the introduction of neoscrypt - does that change anything? ...
ill setup a test for use with bash and see how it goes ... NONE of the new commits are compiling now - NONE! ...
ive tested a compile using the older v47 and v48 - and they compile within minutes ... and work very well - using the SAME environment and compilation method that im using the latest with ...
something strange is happening and the code is just refuses to compile ...
#crysx
BASH vs SH--
I started specifying BASH after the script posted by Skunk would not execute properly with SH. The two are not completely equivalent. I think just "./build.sh" would work if you tried it, making sure that it had executable permission.
I did not realize there was a difference. Some scripts have an sh header, some have a bash header, I never paid attention.
If your build.sh script is messing up, it is out of my league. It might be a linux distro conflict. I'll help if I can, but you may likely be looking at a package conflict between distros of linux. The current (commit 780) "Makefile.am" works on my Ubuntu system with no editing or fatal error. --scryptr
COMMIT 778 and 779--
Both commits built readily with "BASH build.sh" and the default makefile.am. I notice that SP_ already has commit 780 on GitHub.
For Lyra2, I am getting 820kh/s per 750ti, and 4.8 mh/s for my 6x750ti FTW rig. Quark is a little slower, though, building up to 38Mh/s for the 750ti rig, and slower than the previous 38.6Mh/s on the same rig. --scryptr
Both commits built readily with "BASH build.sh" and the default makefile.am. I notice that SP_ already has commit 780 on GitHub.
For Lyra2, I am getting 820kh/s per 750ti, and 4.8 mh/s for my 6x750ti FTW rig. Quark is a little slower, though, building up to 38Mh/s for the 750ti rig, and slower than the previous 38.6Mh/s on the same rig. --scryptr
so you build with bash and not sh? ...
ok ... ALL of my compiles have been using sh ...
with the introduction of neoscrypt - does that change anything? ...
ill setup a test for use with bash and see how it goes ... NONE of the new commits are compiling now - NONE! ...
ive tested a compile using the older v47 and v48 - and they compile within minutes ... and work very well - using the SAME environment and compilation method that im using the latest with ...
something strange is happening and the code is just refuses to compile ...
#crysx
scryptr I sent you a PM.
COMMIT 778 and 779--
Both commits built readily with "BASH build.sh" and the default makefile.am. I notice that SP_ already has commit 780 on GitHub.
For Lyra2, I am getting 820kh/s per 750ti, and 4.8 mh/s for my 6x750ti FTW rig. Quark is a little slower, though, building up to 38Mh/s for the 750ti rig, and slower than the previous 38.6Mh/s on the same rig. --scryptr
scryptr Both commits built readily with "BASH build.sh" and the default makefile.am. I notice that SP_ already has commit 780 on GitHub.
For Lyra2, I am getting 820kh/s per 750ti, and 4.8 mh/s for my 6x750ti FTW rig. Quark is a little slower, though, building up to 38Mh/s for the 750ti rig, and slower than the previous 38.6Mh/s on the same rig. --scryptr
You overclock a lot on the 750ti's for that hash on lyra2.
I rewrote and optimized blake256 and keccak256. Using similar code to the x11 mod. boost in the hashrate for lyra2
COMMIT 780--
I have both of my Linux rigs running build 780. The 2x970 FTW+ mines Lyra2 at 1135kh/s per card, and 2.267Mh/s for the rig. The 6x750ti FTW rig mines Lyra2 at 820kh/s per card, and 4.8Mh/s for the rig. The thing I notice is that the rigs ares slower to reach top speed when mining Quark, and may be slightly slower mining Quark on both rigs, but not by much.
I moved from beta driver 147.xx (that comes with CUDA 7 bundle) to latest 150.xx
And with it a lost 10khs in lyra2: #49 build by sp_ from 884 goes to 872.
With latest commits my own build makes 874khs.
Rather weird ... other algo's feel fine and it seems to have some boost on driver change.
Maybe something wrong with my testings ... ?
And with it a lost 10khs in lyra2: #49 build by sp_ from 884 goes to 872.
With latest commits my own build makes 874khs.
Rather weird ... other algo's feel fine and it seems to have some boost on driver change.
Maybe something wrong with my testings ... ?
COMMIT 778 and 779--
Both commits built readily with "BASH build.sh" and the default makefile.am. I notice that SP_ already has commit 780 on GitHub.
For Lyra2, I am getting 820kh/s per 750ti, and 4.8 mh/s for my 6x750ti FTW rig. Quark is a little slower, though, building up to 38Mh/s for the 750ti rig, and slower than the previous 38.6Mh/s on the same rig. --scryptr
scryptr Both commits built readily with "BASH build.sh" and the default makefile.am. I notice that SP_ already has commit 780 on GitHub.
For Lyra2, I am getting 820kh/s per 750ti, and 4.8 mh/s for my 6x750ti FTW rig. Quark is a little slower, though, building up to 38Mh/s for the 750ti rig, and slower than the previous 38.6Mh/s on the same rig. --scryptr
You overclock a lot on the 750ti's for that hash on lyra2.
I rewrote and optimized blake256 and keccak256. Using similar code to the x11 mod. boost in the hashrate for lyra2
COMMIT 778 and 779--
Both commits built readily with "BASH build.sh" and the default makefile.am. I notice that SP_ already has commit 780 on GitHub.
For Lyra2, I am getting 820kh/s per 750ti, and 4.8 mh/s for my 6x750ti FTW rig. Quark is a little slower, though, building up to 38Mh/s for the 750ti rig, and slower than the previous 38.6Mh/s on the same rig. --scryptr
Both commits built readily with "BASH build.sh" and the default makefile.am. I notice that SP_ already has commit 780 on GitHub.
For Lyra2, I am getting 820kh/s per 750ti, and 4.8 mh/s for my 6x750ti FTW rig. Quark is a little slower, though, building up to 38Mh/s for the 750ti rig, and slower than the previous 38.6Mh/s on the same rig. --scryptr
scryptr
You overclock a lot on the 750ti's for that hash on lyra2.
This is a Linux rig, and although I have tried, I haven't mastered overclocking via Linux. I use an "intensity" setting of "-i 16.5" in the command line. My 750ti SSC cards on Win 7 x64 get about 725kh/s on Lyra2, non-overclocked. With overclocking, they can get 780kh/s, but it is not stable. SP_ improved Lyra2 hash rate with today's builds. --scryptr
COMMIT 778 and 779--
Both commits built readily with "BASH build.sh" and the default makefile.am. I notice that SP_ already has commit 780 on GitHub.
For Lyra2, I am getting 820kh/s per 750ti, and 4.8 mh/s for my 6x750ti FTW rig. Quark is a little slower, though, building up to 38Mh/s for the 750ti rig, and slower than the previous 38.6Mh/s on the same rig. --scryptr
Both commits built readily with "BASH build.sh" and the default makefile.am. I notice that SP_ already has commit 780 on GitHub.
For Lyra2, I am getting 820kh/s per 750ti, and 4.8 mh/s for my 6x750ti FTW rig. Quark is a little slower, though, building up to 38Mh/s for the 750ti rig, and slower than the previous 38.6Mh/s on the same rig. --scryptr
scryptr
You overclock a lot on the 750ti's for that hash on lyra2.
COMMIT 778 and 779--
Both commits built readily with "BASH build.sh" and the default makefile.am. I notice that SP_ already has commit 780 on GitHub.
For Lyra2, I am getting 820kh/s per 750ti, and 4.8 mh/s for my 6x750ti FTW rig. Quark is a little slower, though, building up to 38Mh/s for the 750ti rig, and slower than the previous 38.6Mh/s on the same rig. --scryptr
Both commits built readily with "BASH build.sh" and the default makefile.am. I notice that SP_ already has commit 780 on GitHub.
For Lyra2, I am getting 820kh/s per 750ti, and 4.8 mh/s for my 6x750ti FTW rig. Quark is a little slower, though, building up to 38Mh/s for the 750ti rig, and slower than the previous 38.6Mh/s on the same rig. --scryptr
Submitted a fix for skein and blake. (at yaamp.com)
The hashrate should now be improved on the pool and the duplicate shares messages should be gone.
The hashrate should now be improved on the pool and the duplicate shares messages should be gone.
Are you running the latest drivers?
I just submitted a 117% faster blake coin.
from 230MHASH to 515MHASH on the 750ti.
I just submitted a 117% faster blake coin.
from 230MHASH to 515MHASH on the 750ti.
I think a solution will be to exlude all the scrypt code with a #define in the project.
#define includescrypt 1
#define includescrypt 1
maybe - but that that doesnt actually resolve the issue ...
i can replicate this EVERY time - so its an inherent issue ...
im stumped ...
#crysx
Did you get the last commit (makefile)?
scryptr buildt it yesterday on linux.
Please do a full clean and get the latest sourcecode and try again.
scryptr buildt it yesterday on linux.
Please do a full clean and get the latest sourcecode and try again.
my compile script does exactly that ...
1 - deletes the current compile directory completely ...
2 - git clone
3 - cd into ccminer directory and 'builds' the ccminer file ...
4 - mv the newly compiled ccminer file to the miner directory and renames it to ccminer-sph-xxx ( xxx being whatever i want it to be ) ...
5 - mv the current ccminer file to ccminer-orig ...
6 - copies the newly made ccminer-sph-xxx to ccminer ...
7 - changes ownership of the miner directory ( as all the above is done as root ) ...
8 - reboots ...
when the machine restarts - it runs the new ccminer and the settings in the miner script ...
this is fine for all compiles except the latest ones ... since the commit when you added neoscrypt ...
now it just stops and freezes at part 3 of the compile / install sequence ...
ive tried it manually also with your 'standard' build.sh file and its still locks up in the same place - the yescrypt part you see in above ...
ive also found that since neoscrypt has been added - BEFORE all this happened ( and forgot to mention ) the 'build.sh' would not even start the compile unless fedora had installed the static c++ libraries ( which it never needed prior to this ) ...
so i added them in the install ...
yum -y install libstdc++-static.x86_64 ...
the compile started and continued up until now ... the compile just simply stalls at the same place everytime ...
possibly scryptr has and idea? ... or djm maybe? ... anyone? ...
im now lost as to why this wont compile sp ...
#crysx
djm34 - its not that it takes a long time ... to test this i have left it ...
it is now more than 6 hours ( only due to the fact im not in the office at the moment and i CAN leave it ) and its still in the same position it was when i left it ...
impossible for a compilation to take that sort of time ...
how has everyone else compiled this version? ... i have had no issues with the previous versions ...
frustrated with it now :| ...
#crysx
Hi just tried release49 for X11 and getting occasionally a few booooos due to low difficulty shares. Cards not overclocked.
Did you get the last commit (makefile)?
scryptr buildt it yesterday on linux.
Please do a full clean and get the latest sourcecode and try again.
scryptr buildt it yesterday on linux.
Please do a full clean and get the latest sourcecode and try again.
my compile script does exactly that ...
1 - deletes the current compile directory completely ...
2 - git clone
3 - cd into ccminer directory and 'builds' the ccminer file ...
4 - mv the newly compiled ccminer file to the miner directory and renames it to ccminer-sph-xxx ( xxx being whatever i want it to be ) ...
5 - mv the current ccminer file to ccminer-orig ...
6 - copies the newly made ccminer-sph-xxx to ccminer ...
7 - changes ownership of the miner directory ( as all the above is done as root ) ...
8 - reboots ...
when the machine restarts - it runs the new ccminer and the settings in the miner script ...
this is fine for all compiles except the latest ones ... since the commit when you added neoscrypt ...
now it just stops and freezes at part 3 of the compile / install sequence ...
ive tried it manually also with your 'standard' build.sh file and its still locks up in the same place - the yescrypt part you see in above ...
ive also found that since neoscrypt has been added - BEFORE all this happened ( and forgot to mention ) the 'build.sh' would not even start the compile unless fedora had installed the static c++ libraries ( which it never needed prior to this ) ...
so i added them in the install ...
yum -y install libstdc++-static.x86_64 ...
the compile started and continued up until now ... the compile just simply stalls at the same place everytime ...
possibly scryptr has and idea? ... or djm maybe? ... anyone? ...
im now lost as to why this wont compile sp ...
#crysx
I think a solution will be to exlude all the scrypt code with a #define in the project.
#define includescrypt 1
#define includescrypt 1
Did you get the last commit (makefile)?
scryptr buildt it yesterday on linux.
Please do a full clean and get the latest sourcecode and try again.
scryptr buildt it yesterday on linux.
Please do a full clean and get the latest sourcecode and try again.
my compile script does exactly that ...
1 - deletes the current compile directory completely ...
2 - git clone
3 - cd into ccminer directory and 'builds' the ccminer file ...
4 - mv the newly compiled ccminer file to the miner directory and renames it to ccminer-sph-xxx ( xxx being whatever i want it to be ) ...
5 - mv the current ccminer file to ccminer-orig ...
6 - copies the newly made ccminer-sph-xxx to ccminer ...
7 - changes ownership of the miner directory ( as all the above is done as root ) ...
8 - reboots ...
when the machine restarts - it runs the new ccminer and the settings in the miner script ...
this is fine for all compiles except the latest ones ... since the commit when you added neoscrypt ...
now it just stops and freezes at part 3 of the compile / install sequence ...
ive tried it manually also with your 'standard' build.sh file and its still locks up in the same place - the yescrypt part you see in above ...
ive also found that since neoscrypt has been added - BEFORE all this happened ( and forgot to mention ) the 'build.sh' would not even start the compile unless fedora had installed the static c++ libraries ( which it never needed prior to this ) ...
so i added them in the install ...
yum -y install libstdc++-static.x86_64 ...
the compile started and continued up until now ... the compile just simply stalls at the same place everytime ...
possibly scryptr has and idea? ... or djm maybe? ... anyone? ...
im now lost as to why this wont compile sp ...
#crysx
Jump to: