Just an info for those that are compiling with CUDA Toolkint 7.5 RC: Nvidia today released the final version of CUDA Toolkit 7.5 so i recommend you update your installation.
I am getting an error. It started last night at 2 am ( this was literally 20 minutes after I went to bed ) so I ended up not making anything during my sleep
Tried running again this morning and it is consistantly failing after 5 or so minutes.
As for the new update - another git clone and cmake ? I assume the same steps as before just gotta recompile this new release right?
DAG Generation Failure. Reason: Permission denied terminate called after throwing an instance of 'boost::exception_detail::clone_impl' what(): std::exception Aborted (core dumped)
** edit **
This may be cause I wasn't in root, will update in a bit.
Edit 2 - Seems it was the lack of root. Thought I was already in it. Which leads me to another question, when the miner finds a solution, it'll either get accepted, not accepted or Failure: GPU gave incorrect result.
Are the 2 failed results a normal occurrence? the not accepted has me thinkin someone beat me to it, not sure about the other.
In Ubuntu, when I run just one card, hashrate is very stable. However, with 6 cards, hashrate begins to jump. I also check the system monitor to see how the processor does.
1. Sempron 145: 100% 2. FX 6300: 100% all 6 cores
Hashrate is about the same in 2 system, but the system with FX 6300 will draw more power.
I switch back to cudaminer branch, and it runs about the same speed with very slow CPU.
cudaminer-frontier's master branch actually runs fine on my single 960 desktop, but always generates 180% cpu load (2 cores) on a 6x750ti rig, doesn't matter if i choose spin, yield or sync as --cuda-schedule argument...
@Genoil : I am playing around with Windows 7. I usually get ethminer on cryptomining-blog.com. I notice that they compiled the newest update with CUDA 6.5 (cudart64_65.dll). So, I got really bad result with that on 2 GTX750ti cards.
When I try to run with your ethminer that attached on page 17 (require cudart64_75.dll), I got extremely high result. It was about 21.2 Mh/s with 2 cards. Then I try the 3rd card. Ethminer can see 3 cards, but hashrate is the same with 2 cards. I delete all DAG files and run again. OMG, it runs full speed 32Mh/s with 3 cards.
I got driver crash. I didn't know because I did overclock too much or a 3rd card messed up ethminer. Now, I can run full speed with 2 cards. Sometimes, I can run with 3 cards. Don't know why. Still testing.
@Phantom & @skunk regarding your issues when mining under linux- it is not easy to determine what is causing the high cpu usage despite using the --cuda-schedule sync option. Might be some problem with the driver or the OS itself, or the combination... or it might be something completely different that is burning the CPU... it sounds funny that despite having 6 GPUs you see only 2 CPU cores being used (or do you only have 2 cores?). Have you tested what happens if you start the miner with only one GPU? And when you start with two? or three? I could try to implement a different type of synchronization, i do not know if that would help. You would have to build and test it yourself, i am on windows so i can't tell if it will help with the CPU under linux.
A little explanation regarding the different --cuda-schedule options:
spin - the most aggressive setting - the thread is spinning and polling the status of the GPU on one cpu core and does not yield to other threads so the latency is the lowest possible and that translates to the highest performance.
yield - almost the same as spin, the difference is that the thread also yields to other threads so they can also do some work if they need to - this is the preferred option if you have more GPUs than CPU cores as the spin option in that case would perform badly. Latency in this case is only slightly higher as with the spin option so performance impact should be only small.
sync - in contrast to the previou two options, this option causes the thread to go to sleep and wat for a signal from the GPU instead of actively polling the status. Latency in this case is the highest so the performance is the lowest.
auto - is just an automatic decision between spin and yield (so always causing high CPU usage) based on the number of GPUs and CPU cores.
How much performance difference you will actually experience depends on quite a few factors (OS, hardware, miner configuration etc.). Generally speaking, larger values for --cuda-streams, --cuda-grid-size and --cuda-block-size will tend to make the negative impact of latency lower. Of course increasing these values can cause other problems so i would advise to do some testing and find the values that work best for you.
having trouble installing ethminer on ubuntu. Missing some dependencies I think, anyone know what this means?
Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation:
The following packages have unmet dependencies: unity-control-center : Depends: libcheese-gtk23 (>= 3.4.0) but it is not going to be installed Depends: libcheese7 (>= 3.0.1) but it is not going to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
@RoBiK ok, i've figured out there are some issues with command line arguments parsing... my command line is like this: "./ethminer -U -F pool_url --cuda-devices 0 1 2 3 4 5" and i was specifying eg. "--cuda-schedule=spin" at the end of the line because "--cuda-schedule spin" after "--cuda-devices 0 1 2 3 4 5" returns "Invalid argument: sync". instead moving the "--cuda-schedule spin" argument after the -U switch, works as expected, at least with genoil's cudaminer-frontier tree: ~180% cpu load with both spin and yield, ~1% with sync. on the other hand, with your event-test tree, --cuda-schedule has no impact on cpu load which always stays at ~1%. apart from cpu load, there's no significant change in hashing rate with any tree or scheduler, so i'm back to genoil's miner with default scheduler...
@RoBiK ok, i've figured out there are some issues with command line arguments parsing... my command line is like this: "./ethminer -U -F pool_url --cuda-devices 0 1 2 3 4 5" and i was specifying eg. "--cuda-schedule=spin" at the end of the line because "--cuda-schedule spin" after "--cuda-devices 0 1 2 3 4 5" returns "Invalid argument: sync". instead moving the "--cuda-schedule spin" argument after the -U switch, works as expected, at least with genoil's cudaminer-frontier tree: ~180% cpu load with both spin and yield, ~1% with sync. on the other hand, with your event-test tree, --cuda-schedule has no impact on cpu load which always stays at ~1%. apart from cpu load, there's no significant change in hashing rate with any tree or scheduler, so i'm back to genoil's miner with default scheduler...
ps: the cpu is a G3240 with 2 cores/threads
@skunk glad to hear that the --cuda-schedule switch is working properly after all. The command line parsing needs to be fixed but other than that seems like the miner is working fine.
can someone share cmd line for single 750 under Win7 AND used driver version? Since some time (maybe driver update?) I can't get more than 3MH/s per 750Ti card
@restless this a known issue. Can you confirm that it does about 8MH/s in benchmark mode (ethminer.exe -U -M), while when actually mining, it does only 3MH/s?
Hm weird. I'm now in a situation that depending on the (size of) dag I load, I get either 8 or 3 MH/s. But that's maybe because I run the 750 headless. Also weird that @Phantom is the only win7 user I've seen with a normal functioning 750....it shouldn't work!
Working on a clear test case now that I can send with a bug report.
I've never gotten 3Mhs with a single GTX750ti on Win7, just over 8 Mhs. I just create DAG, then delete when I test. Now, I am staying with Ubuntu. Earn some coins first. @Genoid, please pm me your Shift or Expanse wallet. I give you some beer
No matter what I do, I cannot get more than 1.8 Mhs on my GTX750Ti on Win7 (CUDA miner). Deleted DAGs, even reinstalled the OS with latest cuda 7.5. Tried latest Phantom's bin as well as the one from cryptomining-blog ... I'm giving up on this. p.s.: this is a secondary GPU in a system (no monitor attached) with primary AMD 7950 - this one is easily hashing on 25 Mhs (OpenCL).
@kenshirothefist: I don't think Nvidia and AMD Radeon work well together. You should run HD 7950 alone. When I run GTX750ti on Win7, I just install Nvidia driver, nothing else.
If you plan to stick with Ethminer, you should sell your GTX750ti. Then buy a used HD 7950. This way, you could easy manage your rig with Windows.
@kenshirothefist: I don't think Nvidia and AMD Radeon work well together. You should run HD 7950 alone. When I run GTX750ti on Win7, I just install Nvidia driver, nothing else.
Basically I'm running this rig as a test rig for various scenarios, testing various algorithms and various coins as part of my research in cryptocurrencies, and I like to have it in one box ... Nvidia and AMD driver does happily coexist together, for example, I can run Quark on 750Ti at 5.5 Mhs (6.5 Mhs overclocked), therefore I know there is nothing wrong with setup, driver or card. It just seems that 750Ti is having issues in Ethereum performnace, but for my testing purposes it will be just fine. I'll also try Ubuntu on this box and see if there are any differences in performance, will report later here. Anyway - all of you working on ethminer - keep up the good work!
i also running around 8.7M per cards. and 51MH/s per miner in local(6cards). i thought unstable connect to pools. i got other AMD miner using same connect.
Genoli, something useful concerning memory limitations in Ethereum from the CCminer thread, not sure if it's of any use to you.
[quote author=sp_ link=topic=826901.msg12456338#msg12456338 date=1442577066] [quote author=theotherme link=topic=826901.msg12455947#msg12455947 date=1442573769] [quote author=sp_ link=topic=826901.msg12455428#msg12455428 date=1442568532] [quote author=bensam1231 link=topic=826901.msg12454857#msg12454857 date=1442563100] Agree, Ethminer is still very lucrative although it looks like Nvidia hardware hit the memory controller limitation and can't go anywhere else, much like Cryptonote. [/quote] Look at lyra2v2. It's also a memory hard algorithm. 280x Sgminer opensource(200watt) 4MHASH 750ti Djm-34 (sp-mod) opensource (40watt) 5MHASH It's like creating a etherum miner that does 35MHASH on the 750ti. But the opensource is only doing 8MHASH... [/quote] (djm34 here...) The main difference between the algo of ethereum and other mem hard algo, is that you can't rescale mem usage as it always requires the full dag file to run (ie 1.2Gb or so of vram with many random over the full dag file) Meaning you can't really improve passed what has already been done... (yeah, I tried already ;D ). [/quote]
But you should be able to make the kernal run at copyspeed. (memory bandwidth limit) The gpu can do register operations while writing to memory. The keccak passes should be integrated and more than one hash per run. Then you will get keccak for free. (memory pipelining)
Comments
Thanks!
Cflush
regular mining on ethpool
**** EDIT ****
Given that ethpool is down, I have switched over to ethereumpool and I am using Genoil's recent changes. I am still seeing the same 49MH/sec.
Tried running again this morning and it is consistantly failing after 5 or so minutes.
As for the new update - another git clone and cmake ? I assume the same steps as before just gotta recompile this new release right?
DAG Generation Failure. Reason: Permission denied
terminate called after throwing an instance of 'boost::exception_detail::clone_impl'
what(): std::exception
Aborted (core dumped)
** edit **
This may be cause I wasn't in root, will update in a bit.
Edit 2 -
Seems it was the lack of root. Thought I was already in it. Which leads me to another question, when the miner finds a solution, it'll either get accepted, not accepted or Failure: GPU gave incorrect result.
Are the 2 failed results a normal occurrence? the not accepted has me thinkin someone beat me to it, not sure about the other.
.bat file: ./ethminer -U -F http://xxx --cuda-grid-size 8192 --cuda-block-size 128 --cuda-schedule auto
Windows 7:
8.6 Mh/s - Stock clock
10.75 Mh/s - OC
Ubuntu:
8.33 Mh/s - SC
9.6 Mh/s - OC
In Ubuntu, when I run just one card, hashrate is very stable. However, with 6 cards, hashrate begins to jump. I also check the system monitor to see how the processor does.
1. Sempron 145: 100%
2. FX 6300: 100% all 6 cores
Hashrate is about the same in 2 system, but the system with FX 6300 will draw more power.
I switch back to cudaminer branch, and it runs about the same speed with very slow CPU.
You'll have to fiddle with the CUDA-schedule flag for a bit.@Phantom. You're right, I'm going to roll back.
rolled back. but it seems i jumped the gun. --cuda-schedule will likely be back soon
now back in cudaminer-frontier. @Phantom can you check again? Default schedule now is sync. For me it gives ~0% CPU.
When I try to run with your ethminer that attached on page 17 (require cudart64_75.dll), I got extremely high result. It was about 21.2 Mh/s with 2 cards. Then I try the 3rd card. Ethminer can see 3 cards, but hashrate is the same with 2 cards. I delete all DAG files and run again. OMG, it runs full speed 32Mh/s with 3 cards.
I got driver crash. I didn't know because I did overclock too much or a 3rd card messed up ethminer. Now, I can run full speed with 2 cards. Sometimes, I can run with 3 cards. Don't know why. Still testing.
@phantom try going to Task manager and setting cpu priority to high for etherminer.... that is if your using the low cpu loading version.
I could try to implement a different type of synchronization, i do not know if that would help. You would have to build and test it yourself, i am on windows so i can't tell if it will help with the CPU under linux.
A little explanation regarding the different --cuda-schedule options:
spin - the most aggressive setting - the thread is spinning and polling the status of the GPU on one cpu core and does not yield to other threads so the latency is the lowest possible and that translates to the highest performance.
yield - almost the same as spin, the difference is that the thread also yields to other threads so they can also do some work if they need to - this is the preferred option if you have more GPUs than CPU cores as the spin option in that case would perform badly. Latency in this case is only slightly higher as with the spin option so performance impact should be only small.
sync - in contrast to the previou two options, this option causes the thread to go to sleep and wat for a signal from the GPU instead of actively polling the status. Latency in this case is the highest so the performance is the lowest.
auto - is just an automatic decision between spin and yield (so always causing high CPU usage) based on the number of GPUs and CPU cores.
How much performance difference you will actually experience depends on quite a few factors (OS, hardware, miner configuration etc.). Generally speaking, larger values for --cuda-streams, --cuda-grid-size and --cuda-block-size will tend to make the negative impact of latency lower. Of course increasing these values can cause other problems so i would advise to do some testing and find the values that work best for you.
git clone -b event-test --single-branch https://github.com/RoBiK75/cpp-ethereum.git
sudo apt-get install libglew-dev libcheese7 libcheese-gtk23 libclutter-gst-2.0-0 libcogl15 libclutter-gtk-1.0-0 libclutter-1.0-0
my command line is like this: "./ethminer -U -F pool_url --cuda-devices 0 1 2 3 4 5" and i was specifying eg. "--cuda-schedule=spin" at the end of the line because "--cuda-schedule spin" after "--cuda-devices 0 1 2 3 4 5" returns "Invalid argument: sync".
instead moving the "--cuda-schedule spin" argument after the -U switch, works as expected, at least with genoil's cudaminer-frontier tree: ~180% cpu load with both spin and yield, ~1% with sync.
on the other hand, with your event-test tree, --cuda-schedule has no impact on cpu load which always stays at ~1%.
apart from cpu load, there's no significant change in hashing rate with any tree or scheduler, so i'm back to genoil's miner with default scheduler...
ps: the cpu is a G3240 with 2 cores/threads
Since some time (maybe driver update?) I can't get more than 3MH/s per 750Ti card
Win7 x64, driver 353.62 whql, cpu [email protected]
Working on a clear test case now that I can send with a bug report.
If you plan to stick with Ethminer, you should sell your GTX750ti. Then buy a used HD 7950. This way, you could easy manage your rig with Windows.
I usually buy a used card at gpushack.com.
This card (http://gpushack.com/collections/all-gpus-for-sale/products/his-iceq-hd-7950-boost) could run 25 Mhs with 180-190W when undervolt to 1.088 mV
[quote author=sp_ link=topic=826901.msg12456338#msg12456338 date=1442577066]
[quote author=theotherme link=topic=826901.msg12455947#msg12455947 date=1442573769]
[quote author=sp_ link=topic=826901.msg12455428#msg12455428 date=1442568532]
[quote author=bensam1231 link=topic=826901.msg12454857#msg12454857 date=1442563100]
Agree, Ethminer is still very lucrative although it looks like Nvidia hardware hit the memory controller limitation and can't go anywhere else, much like Cryptonote.
[/quote]
Look at lyra2v2. It's also a memory hard algorithm.
280x Sgminer opensource(200watt) 4MHASH
750ti Djm-34 (sp-mod) opensource (40watt) 5MHASH
It's like creating a etherum miner that does 35MHASH on the 750ti.
But the opensource is only doing 8MHASH...
[/quote]
(djm34 here...)
The main difference between the algo of ethereum and other mem hard algo, is that you can't rescale mem usage as it always requires the full dag file to run (ie 1.2Gb or so of vram with many random over the full dag file)
Meaning you can't really improve passed what has already been done... (yeah, I tried already ;D ).
[/quote]
But you should be able to make the kernal run at copyspeed. (memory bandwidth limit) The gpu can do register operations while writing to memory. The keccak passes should be integrated and more than one hash per run. Then you will get keccak for free. (memory pipelining)
[/quote]