sp_ (OP)
Legendary
 Offline
Activity: 2898
Merit: 1087
Team Black developer
|
 |
May 04, 2015, 05:33:36 PM |
|
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 Bitcoin software, network, and concept is called "Bitcoin" with a capitalized "B". Bitcoin currency units are called "bitcoins" with a lowercase "b" -- this is often abbreviated BTC.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
scryptr
Legendary
Offline
Activity: 1793
Merit: 1028
|
|
May 04, 2015, 07:19:35 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
|
|
|
|
antonio8
Legendary
Offline
Activity: 1386
Merit: 1000
|
|
May 04, 2015, 07:34:15 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 You overclock a lot on the 750ti's for that hash on lyra2. |
If you are going to leave your BTC on an exchange please send it to this address instead 1GH3ub3UUHbU5qDJW5u3E9jZ96ZEmzaXtG, I will at least use the money better than someone who steals it from the exchange. Thanks  |
|
|
scryptr
Legendary
Offline
Activity: 1793
Merit: 1028
|
|
May 04, 2015, 07:48:55 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 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 |
|
|
|
sp_ (OP)
Legendary
Offline
Activity: 2898
Merit: 1087
Team Black developer
|
|
May 04, 2015, 07:59:30 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 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 |
|
|
|
rednoW
Legendary
Offline
Activity: 1510
Merit: 1003
|
|
May 04, 2015, 08:59:57 PM |
|
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 ... ?
|
|
|
|
|
scryptr
Legendary
Offline
Activity: 1793
Merit: 1028
|
|
May 05, 2015, 12:23:01 AM |
|
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 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. |
|
|
|
flipclip
Member
Offline
Activity: 111
Merit: 10
|
|
May 05, 2015, 02:24:08 AM |
|
scryptr I sent you a PM.
|
|
|
|
|
chrysophylax
Legendary
Offline
Activity: 2814
Merit: 1091
--- ChainWorks Industries ---
|
|
May 05, 2015, 02:41:53 AM |
|
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
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
Legendary
Offline
Activity: 1793
Merit: 1028
|
|
May 05, 2015, 03:23:25 AM |
|
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
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 |
|
|
|
chrysophylax
Legendary
Offline
Activity: 2814
Merit: 1091
--- ChainWorks Industries ---
|
|
May 05, 2015, 03:40:37 AM |
|
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
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 |
|
|
|
flipclip
Member
Offline
Activity: 111
Merit: 10
|
|
May 05, 2015, 12:31:44 PM |
|
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.) |
|
|
|
|
|
|
rednoW
Legendary
Offline
Activity: 1510
Merit: 1003
|
|
May 05, 2015, 12:54:29 PM |
|
2 sp_
blake loads one cpu core to the maximum for me ... gtx750 ... both my own build and from your link
|
|
|
|
|
sp_ (OP)
Legendary
Offline
Activity: 2898
Merit: 1087
Team Black developer
|
|
May 05, 2015, 01:01:31 PM |
|
What is the speed? Try to lower the intensity. The default is set to -i 29 wich is too high.
|
|
|
|
rednoW
Legendary
Offline
Activity: 1510
Merit: 1003
|
|
May 05, 2015, 01:07:16 PM |
|
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_ (OP)
Legendary
Offline
Activity: 2898
Merit: 1087
Team Black developer
|
|
May 05, 2015, 01:37:06 PM
Last edit: May 05, 2015, 02:02:07 PM by 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
|
|
|
|
rednoW
Legendary
Offline
Activity: 1510
Merit: 1003
|
|
May 05, 2015, 03:14:36 PM |
|
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. |
|
|
|
|
|
Slava_K
|
|
May 05, 2015, 04:27:22 PM
Last edit: May 05, 2015, 04:41:49 PM by Slava_K |
|
-g 2 on 3x 960GTX is 5.2 Ghash!  on blake |
|
|
|
scryptr
Legendary
Offline
Activity: 1793
Merit: 1028
|
|
May 05, 2015, 05:52:12 PM
Last edit: May 05, 2015, 09:47:09 PM by scryptr |
|
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 |
|
|
|
|
