RE-RELEASE dot 61--
After mining on NiceHash for about 90 minutes, the re-release of dot 61 apparently performs with a slightly higher hash rate and a correct poolside report of the hash rate. My six-card 750ti FTW rig now hashes Quark at 39.5Mh/s, whereas before it was hashing at about 38.8 Mh/s. Thank you for the hard work! --scryptr
Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 985. (Read 2347601 times)
I have corrected the hashrate bug in quark. and build a new exe. The version number is still 61
Do I have to compile it my own or grab the exe from the github's latest release?If you are running Windows, you can download the new zip package under the releases tab. He built the executable file, and reposted Release dot 61. --scryptr
I have corrected the hashrate bug in quark. and build a new exe. The version number is still 61
Do I have to compile it my own or grab the exe from the github's latest release?If you are running Windows, you can download the new zip package under the releases tab. He built the executable file, and reposted Release dot 61. --scryptr
--ethminer and 750ti on windows--
In a rig with one 970 and one 750ti:
Loading only the 970 with -t 1:
- when running -M (benchmark mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
- when running without -M (mining mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
Loading 970+750ti with -t 2:
- when running -M, memory controller load for both cards is at 100%, rig is hashing at 27.2Mh/s thus giving 8.8Mh/s for the 750ti;
- when running without -M, memory controller load is at 100% for 970 card and 11%! for 750ti, and rig is hashing at 19.4Mh/s, thus giving only 0.968Mh/s for 750ti (exactly 11% from 100% memory controller load).
I have to say that I have no coding skills, I just noticed this while playing with the switches and looking at Afterburner & GPU-Z readings.
Maybe some of the great coders from here can make something out of this so we can hash at full speed with the 750ti on windows.
In a rig with one 970 and one 750ti:
Loading only the 970 with -t 1:
- when running -M (benchmark mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
- when running without -M (mining mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
Loading 970+750ti with -t 2:
- when running -M, memory controller load for both cards is at 100%, rig is hashing at 27.2Mh/s thus giving 8.8Mh/s for the 750ti;
- when running without -M, memory controller load is at 100% for 970 card and 11%! for 750ti, and rig is hashing at 19.4Mh/s, thus giving only 0.968Mh/s for 750ti (exactly 11% from 100% memory controller load).
I have to say that I have no coding skills, I just noticed this while playing with the switches and looking at Afterburner & GPU-Z readings.
Maybe some of the great coders from here can make something out of this so we can hash at full speed with the 750ti on windows.
WINDOWS BUG--
This is a known Windows bug in Ethminer, and Genoil (the dev) knows about it. In Linux, the 750ti mines at 8+ Mh/s. I am all for collaboration, I'd gain 40-50 Mh/s if it were fixed. If you are running the Cuda version of Ethminer, use the "-U --gpu-devices 0 1" string in the command line. Does "-t 2" do the same thing? I thought it was for OpenCL.
--scryptr
Yes, -t
About the 750ti windows bug, have you noticed also that when using benchmark mode (-M) the 750ti hashes at full speed (memory controller at 100%)? It is very odd...
More findings when running only 750ti's:
Running only one 750ti:
- benchmark mode, MCU is at 100% giving expected 8.8Mh/s
- mining mode, MCU is at 63-65% giving 5.1Mh/s
Running two 750ti:
- benchmark mode, MCU is at 100% for both cards, giving 17.4Mh/s
- mining mode, MCU is at 56-63% for card 0 and 3% for card 1, giving 5.1-5.7Mh/s total.
So it seems that 750ti can do at least 5Mh/s on mining mode but only when it's the single card running.
EDIT: weird thing is that when I add the third card (also 750ti) in benechmark mode I only get 10.5Mh/s
I have corrected the hashrate bug in quark. and build a new exe. The version number is still 61
Do I have to compile it my own or grab the exe from the github's latest release?
100% MCU--
Honestly, I haven't bothered to run in benchmark mode. What I notice, is that my GTX 960 (card 0) mines with the MCU at 100% and all of the 750ti cards mine with the MCU at 10%-20%. Ten to twenty percent of 8.8 Mh/s is about 1-2 Mh/s.
A 750ti under Windows mines at about 1-2Mh/s with Ethminer. Ethminer does not report individual card rates like CudaMiner or CCminer. It reports a total hashing rate. How is the hash distributed across the rig? Is this a clue?
Under Linux the 750ti is reported to mine at 8+ Mh/s. The operating environment may be handling instructions differently.
--scryptr
EDIT: Genoil says that the 750ti will run at the full hash rate under Win 7. --scryptr
Honestly, I haven't bothered to run in benchmark mode. What I notice, is that my GTX 960 (card 0) mines with the MCU at 100% and all of the 750ti cards mine with the MCU at 10%-20%. Ten to twenty percent of 8.8 Mh/s is about 1-2 Mh/s.
A 750ti under Windows mines at about 1-2Mh/s with Ethminer. Ethminer does not report individual card rates like CudaMiner or CCminer. It reports a total hashing rate. How is the hash distributed across the rig? Is this a clue?
Under Linux the 750ti is reported to mine at 8+ Mh/s. The operating environment may be handling instructions differently.
--scryptr
EDIT: Genoil says that the 750ti will run at the full hash rate under Win 7. --scryptr
--ethminer and 750ti on windows--
In a rig with one 970 and one 750ti:
Loading only the 970 with -t 1:
- when running -M (benchmark mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
- when running without -M (mining mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
Loading 970+750ti with -t 2:
- when running -M, memory controller load for both cards is at 100%, rig is hashing at 27.2Mh/s thus giving 8.8Mh/s for the 750ti;
- when running without -M, memory controller load is at 100% for 970 card and 11%! for 750ti, and rig is hashing at 19.4Mh/s, thus giving only 0.968Mh/s for 750ti (exactly 11% from 100% memory controller load).
I have to say that I have no coding skills, I just noticed this while playing with the switches and looking at Afterburner & GPU-Z readings.
Maybe some of the great coders from here can make something out of this so we can hash at full speed with the 750ti on windows.
In a rig with one 970 and one 750ti:
Loading only the 970 with -t 1:
- when running -M (benchmark mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
- when running without -M (mining mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
Loading 970+750ti with -t 2:
- when running -M, memory controller load for both cards is at 100%, rig is hashing at 27.2Mh/s thus giving 8.8Mh/s for the 750ti;
- when running without -M, memory controller load is at 100% for 970 card and 11%! for 750ti, and rig is hashing at 19.4Mh/s, thus giving only 0.968Mh/s for 750ti (exactly 11% from 100% memory controller load).
I have to say that I have no coding skills, I just noticed this while playing with the switches and looking at Afterburner & GPU-Z readings.
Maybe some of the great coders from here can make something out of this so we can hash at full speed with the 750ti on windows.
WINDOWS BUG--
This is a known Windows bug in Ethminer, and Genoil (the dev) knows about it. In Linux, the 750ti mines at 8+ Mh/s. I am all for collaboration, I'd gain 40-50 Mh/s if it were fixed. If you are running the Cuda version of Ethminer, use the "-U --gpu-devices 0 1" string in the command line. Does "-t 2" do the same thing? I thought it was for OpenCL.
--scryptr
Yes, -t
About the 750ti windows bug, have you noticed also that when using benchmark mode (-M) the 750ti hashes at full speed (memory controller at 100%)? It is very odd...
--ethminer and 750ti on windows--
In a rig with one 970 and one 750ti:
Loading only the 970 with -t 1:
- when running -M (benchmark mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
- when running without -M (mining mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
Loading 970+750ti with -t 2:
- when running -M, memory controller load for both cards is at 100%, rig is hashing at 27.2Mh/s thus giving 8.8Mh/s for the 750ti;
- when running without -M, memory controller load is at 100% for 970 card and 11%! for 750ti, and rig is hashing at 19.4Mh/s, thus giving only 0.968Mh/s for 750ti (exactly 11% from 100% memory controller load).
I have to say that I have no coding skills, I just noticed this while playing with the switches and looking at Afterburner & GPU-Z readings.
Maybe some of the great coders from here can make something out of this so we can hash at full speed with the 750ti on windows.
In a rig with one 970 and one 750ti:
Loading only the 970 with -t 1:
- when running -M (benchmark mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
- when running without -M (mining mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
Loading 970+750ti with -t 2:
- when running -M, memory controller load for both cards is at 100%, rig is hashing at 27.2Mh/s thus giving 8.8Mh/s for the 750ti;
- when running without -M, memory controller load is at 100% for 970 card and 11%! for 750ti, and rig is hashing at 19.4Mh/s, thus giving only 0.968Mh/s for 750ti (exactly 11% from 100% memory controller load).
I have to say that I have no coding skills, I just noticed this while playing with the switches and looking at Afterburner & GPU-Z readings.
Maybe some of the great coders from here can make something out of this so we can hash at full speed with the 750ti on windows.
WINDOWS BUG--
This is a known Windows bug in Ethminer, and Genoil (the dev) knows about it. In Linux, the 750ti mines at 8+ Mh/s. I am all for collaboration, I'd gain 40-50 Mh/s if it were fixed. If you are running the Cuda version of Ethminer, use the "-U --gpu-devices 0 1" string in the command line. Does "-t 2" do the same thing? I thought it was for OpenCL.
--scryptr
Yes, -t
About the 750ti windows bug, have you noticed also that when using benchmark mode (-M) the 750ti hashes at full speed (memory controller at 100%)? It is very odd...
--ethminer and 750ti on windows--
In a rig with one 970 and one 750ti:
Loading only the 970 with -t 1:
- when running -M (benchmark mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
- when running without -M (mining mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
Loading 970+750ti with -t 2:
- when running -M, memory controller load for both cards is at 100%, rig is hashing at 27.2Mh/s thus giving 8.8Mh/s for the 750ti;
- when running without -M, memory controller load is at 100% for 970 card and 11%! for 750ti, and rig is hashing at 19.4Mh/s, thus giving only 0.968Mh/s for 750ti (exactly 11% from 100% memory controller load).
I have to say that I have no coding skills, I just noticed this while playing with the switches and looking at Afterburner & GPU-Z readings.
Maybe some of the great coders from here can make something out of this so we can hash at full speed with the 750ti on windows.
In a rig with one 970 and one 750ti:
Loading only the 970 with -t 1:
- when running -M (benchmark mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
- when running without -M (mining mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
Loading 970+750ti with -t 2:
- when running -M, memory controller load for both cards is at 100%, rig is hashing at 27.2Mh/s thus giving 8.8Mh/s for the 750ti;
- when running without -M, memory controller load is at 100% for 970 card and 11%! for 750ti, and rig is hashing at 19.4Mh/s, thus giving only 0.968Mh/s for 750ti (exactly 11% from 100% memory controller load).
I have to say that I have no coding skills, I just noticed this while playing with the switches and looking at Afterburner & GPU-Z readings.
Maybe some of the great coders from here can make something out of this so we can hash at full speed with the 750ti on windows.
WINDOWS BUG--
This is a known Windows bug in Ethminer, and Genoil (the dev) knows about it. In Linux, the 750ti mines at 8+ Mh/s. I am all for collaboration, I'd gain 40-50 Mh/s if it were fixed. If you are running the Cuda version of Ethminer, use the "-U --gpu-devices 0 1" string in the command line. Does "-t 2" do the same thing? I thought it was for OpenCL.
--scryptr
--ethminer and 750ti on windows--
In a rig with one 970 and one 750ti:
Loading only the 970 with -t 1:
- when running -M (benchmark mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
- when running without -M (mining mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
Loading 970+750ti with -t 2:
- when running -M, memory controller load for both cards is at 100%, rig is hashing at 27.2Mh/s thus giving 8.8Mh/s for the 750ti;
- when running without -M, memory controller load is at 100% for 970 card and 11%! for 750ti, and rig is hashing at 19.4Mh/s, thus giving only 0.968Mh/s for 750ti (exactly 11% from 100% memory controller load).
I have to say that I have no coding skills, I just noticed this while playing with the switches and looking at Afterburner & GPU-Z readings.
Maybe some of the great coders from here can make something out of this so we can hash at full speed with the 750ti on windows.
EDIT: when adding another 960 memory controller load (for 750ti) drops one bit to 10%, with two 960 stays at 10% and when adding the third 960 (with -t 5), memory controller load for the 750ti drops to 5%.
In a rig with one 970 and one 750ti:
Loading only the 970 with -t 1:
- when running -M (benchmark mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
- when running without -M (mining mode), memory controller load is at 100%, rig is hashing at 18.4Mh/s;
Loading 970+750ti with -t 2:
- when running -M, memory controller load for both cards is at 100%, rig is hashing at 27.2Mh/s thus giving 8.8Mh/s for the 750ti;
- when running without -M, memory controller load is at 100% for 970 card and 11%! for 750ti, and rig is hashing at 19.4Mh/s, thus giving only 0.968Mh/s for 750ti (exactly 11% from 100% memory controller load).
I have to say that I have no coding skills, I just noticed this while playing with the switches and looking at Afterburner & GPU-Z readings.
Maybe some of the great coders from here can make something out of this so we can hash at full speed with the 750ti on windows.
EDIT: when adding another 960 memory controller load (for 750ti) drops one bit to 10%, with two 960 stays at 10% and when adding the third 960 (with -t 5), memory controller load for the 750ti drops to 5%.
I have corrected the hashrate bug in quark. and build a new exe. The version number is still 61
nvidia is famous for its non-problem drivers )) If it is not some strategy, then x11 mining is not a best for today. Quark and lyra2v2 are more profitable (6.5 mhs and 4.5 mhs on 750ti).
I got some 750Ti cards going last night. First time mining Nvidia ever so i feel a bit like a noob.
I have some trouble to get my system to detect the gpu:s.
With AMD i usually install my gpu driver and then add one card at the time without problems.
Does the Nvidia drivers work the same way these days ? Or do i have to have all cards installed in the rig before installing the driver ?
My system had problems finding more then one or two gpu:s when adding more cards to the rig.
I will continue working with the problem after work today.
Anyway. The 750Ti:s i have running now are mining at 3.6Mhs @ X11. I will tweak it a bit more when i get more cards added in the rigs.
I am really happy with the speed so far !
I have some trouble to get my system to detect the gpu:s.
With AMD i usually install my gpu driver and then add one card at the time without problems.
Does the Nvidia drivers work the same way these days ? Or do i have to have all cards installed in the rig before installing the driver ?
My system had problems finding more then one or two gpu:s when adding more cards to the rig.
I will continue working with the problem after work today.
Anyway. The 750Ti:s i have running now are mining at 3.6Mhs @ X11. I will tweak it a bit more when i get more cards added in the rigs.
I am really happy with the speed so far !
Today's share sent
djm34: 80a7312ce2cee21c102c2a91cddbb77b24762e6b9bbc659fd88994db1f957ef0
pallas: a3f2d9ebc1275f00c281ec645d8fa09e17d9c0f43e971d105382c5b690c43507
sp_: 391aeb3a62c788ad633f3601e2cc056b7d739b7da15d82235e4852e2b419cb45
Remain awesome!!
djm34: 80a7312ce2cee21c102c2a91cddbb77b24762e6b9bbc659fd88994db1f957ef0
pallas: a3f2d9ebc1275f00c281ec645d8fa09e17d9c0f43e971d105382c5b690c43507
sp_: 391aeb3a62c788ad633f3601e2cc056b7d739b7da15d82235e4852e2b419cb45
Remain awesome!!
Thanks again for the support!
And thanks for your continued support of ccminer. Not sure if it's relevant as you don't really seem interested, but the low CPU overhead changes you made to ethminer reduce hashrate by like 20% when you have 2+ GPUs.
https://forum.ethereum.org/discussion/2227/cuda-miner/p8
https://forum.ethereum.org/discussion/2227/cuda-miner/p8
I have no problems in Win7x64 with 3x970+1x960. I'm using the sp-mod binary provided by genoil with:
ethminer -F ... -U --gpu-mining-buffers 1 --gpu-workgroup-size 128 --gpu-batch-size 21 --gpu-devices 0 1 2 3
The minning buffers=1 seems better on ethpool, on the others should be probably removed. Maybe there is some more headroom playing with the other 2 parameters...
Today's share sent
djm34: 80a7312ce2cee21c102c2a91cddbb77b24762e6b9bbc659fd88994db1f957ef0
pallas: a3f2d9ebc1275f00c281ec645d8fa09e17d9c0f43e971d105382c5b690c43507
sp_: 391aeb3a62c788ad633f3601e2cc056b7d739b7da15d82235e4852e2b419cb45
Remain awesome!!
djm34: 80a7312ce2cee21c102c2a91cddbb77b24762e6b9bbc659fd88994db1f957ef0
pallas: a3f2d9ebc1275f00c281ec645d8fa09e17d9c0f43e971d105382c5b690c43507
sp_: 391aeb3a62c788ad633f3601e2cc056b7d739b7da15d82235e4852e2b419cb45
Remain awesome!!
Ethereum is still going strong. New pools make it possible for smaller miners now too. Still no interest in adding it to CCminer?
NON-STRATUM ALGO--I am thinking that the difficulty lies in the communication protocol. SP_ modded the hashing protocol, and it is in the latest Ethminer build. --scryptr
I support the shark (quark)
http://coinmarketcap.com/currencies/sharkcoin/
Quark opensource on the AMD (280x 2048 shaders): 2MHASH
Quark opensource on the NVIDIA (980ti 3078 shaders): 30MHASH (sp-mod 60++)
How much morphine were you on when you wrote that? ~_~
And thanks for your continued support of ccminer. Not sure if it's relevant as you don't really seem interested, but the low CPU overhead changes you made to ethminer reduce hashrate by like 20% when you have 2+ GPUs.
https://forum.ethereum.org/discussion/2227/cuda-miner/p8
As others have reported, I am getting higher local quark hashrate reports but nicehash shows I'm down by a lot.
Also having an issue now where when mining Lyra2REv2 where the miner will say its launching 6 threads for my 6 cards, but only 1 card starts hashing. Dunno what's causing that, doesn't happen with other algorithms.
sp said he'll look into it: https://bitcointalksearch.org/topic/m.12201021 Also having an issue now where when mining Lyra2REv2 where the miner will say its launching 6 threads for my 6 cards, but only 1 card starts hashing. Dunno what's causing that, doesn't happen with other algorithms.
As others have reported, I am getting higher local quark hashrate reports but nicehash shows I'm down by a lot.
Also having an issue now where when mining Lyra2REv2 where the miner will say its launching 6 threads for my 6 cards, but only 1 card starts hashing. Dunno what's causing that, doesn't happen with other algorithms.
Also having an issue now where when mining Lyra2REv2 where the miner will say its launching 6 threads for my 6 cards, but only 1 card starts hashing. Dunno what's causing that, doesn't happen with other algorithms.
Did someone have the chance testing GTX950 capabilities ?
Jump to: