Hi all. I'm new here.
I would like to start mining with DiabloMiner.
I'm having troubles to understand how to run it; till now I'm stuck on the NoClassDefFoundError error.
But first of all I'm not sure that my system is able to do GPU mining. I'm running Gentoo Linux with NVidia GeForce 7100 GS; I made some search with no success.
Could you confirm/exclude I can do GPU mining?
thanks!
Topic: DiabloMiner GPU Miner - page 73. (Read 866596 times)
how do you set the user and pass?
I go in my user home folder and while there is a ".bitcoin" folder there is no "bitcoin.conf" file
should I create it? if so what do I put in it?
I go in my user home folder and while there is a ".bitcoin" folder there is no "bitcoin.conf" file
should I create it? if so what do I put in it?
yes, create it.
it should have two lines, if you're mining on the local machine:
rpcuser=
rpcpassword=
how do you set the user and pass?
usage: DiabloMiner -u myuser -p mypassword [args]
-D,--devices devices to enable
-d,--debug enable extra debug output
-f,--fps target execution timing
-g,--getwork seconds between getwork refresh
-h,--help this help
-l,--url bitcoin host url
-o,--host bitcoin host IP
-p,--pass bitcoin host password
-r,--port bitcoin host port
-u,--user bitcoin host username
-w,--worksize override worksize
-x,--proxy optional proxy settings IP:PORT<:username:password>
Remember to set rpcuser and rpcpassword in your ~/.bitcoin/bitcoin.conf
before starting bitcoind or bitcoin --daemon
I go in my user home folder and while there is a ".bitcoin" folder there is no "bitcoin.conf" file
should I create it? if so what do I put in it?
usage: DiabloMiner -u myuser -p mypassword [args]
-D,--devices
-d,--debug enable extra debug output
-f,--fps
-g,--getwork
-h,--help this help
-l,--url
-o,--host
-p,--pass
-r,--port
-u,--user
-w,--worksize
-x,--proxy
Remember to set rpcuser and rpcpassword in your ~/.bitcoin/bitcoin.conf
before starting bitcoind or bitcoin --daemon
I go in my user home folder and while there is a ".bitcoin" folder there is no "bitcoin.conf" file
should I create it? if so what do I put in it?
Sounds like the cards overheated, the driver tried a GPU restart, and failed.... which GPU restarts on Linux ALWAYS fail, and theres no way to shut it off. Just leave your GPU fans at full speed.
Just improved my ventilation, got it 15 degrees colder (from ~83C to ~70C) will check back if anything changes.
DiabloD3 -
just thought i'd check in with my compliments.
i'm running Debian testing (LMDE) - i froze updates at march 30 on my mining-only box.
with your miner set at -w 128 -f 1, my two (VisionTek) 5850s (with crossfire connector attached) are putting out 495,200 Mh/s regular as an atomic clock. i'll screw with overclocking after i've scored a couple of blocks - i'm coming up on 'average time' (six days plus some) as i write this. my case is a piece of crap though: less than 1/2" clearance between the second card and the bottom of the case. i'm running it open with a couple extra fans, and the bottom card fluctuates between 72-74.5 degrees. gotta poke a hole in it or get a bigger case if i'm gonna overclock.
my SDK is 2.1, and Catalyst is 11.2. motherboard is an MSI 870A-G54, with a ~90 watt Phenom dual-core (whatever...) and 2 gig RAM.
you sell shit and i'm your customer...
EDIT: oh - and coinage on blockage, of course...
just thought i'd check in with my compliments.
i'm running Debian testing (LMDE) - i froze updates at march 30 on my mining-only box.
with your miner set at -w 128 -f 1, my two (VisionTek) 5850s (with crossfire connector attached) are putting out 495,200 Mh/s regular as an atomic clock. i'll screw with overclocking after i've scored a couple of blocks - i'm coming up on 'average time' (six days plus some) as i write this. my case is a piece of crap though: less than 1/2" clearance between the second card and the bottom of the case. i'm running it open with a couple extra fans, and the bottom card fluctuates between 72-74.5 degrees. gotta poke a hole in it or get a bigger case if i'm gonna overclock.
my SDK is 2.1, and Catalyst is 11.2. motherboard is an MSI 870A-G54, with a ~90 watt Phenom dual-core (whatever...) and 2 gig RAM.
you sell shit and i'm your customer...
EDIT: oh - and coinage on blockage, of course...
I had two complete lock ups of my system (probably due to me using aticonfig to adjust the fan speeds in a cronjob) at 30 hours between each other (100'000 seconds ~= 30 hours). I was wondering whether this is a known bug or one of my cards is dying on me:
Sounds like the cards overheated, the driver tried a GPU restart, and failed.... which GPU restarts on Linux ALWAYS fail, and theres no way to shut it off. Just leave your GPU fans at full speed.
I had two complete lock ups of my system (probably due to me using aticonfig to adjust the fan speeds in a cronjob) at 30 hours between each other (100'000 seconds ~= 30 hours). I was wondering whether this is a known bug or one of my cards is dying on me:
Code:
[109453.772] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[109453.905]
Backtrace:
[109454.293] 0: /usr/bin/X (xorg_backtrace+0x3b) [0x80ef31b]
[109454.293] 1: /usr/bin/X (mieqEnqueue+0x1ab) [0x80ecb5b]
[109454.293] 2: /usr/bin/X (xf86PostMotionEventP+0xd2) [0x80bd662]
[109454.330] 3: /usr/lib/xorg/modules/input/evdev_drv.so (0x684000+0x4961) [0x688961]
[109454.330] 4: /usr/lib/xorg/modules/input/evdev_drv.so (0x684000+0x4a56) [0x688a56]
[109454.330] 5: /usr/lib/xorg/modules/input/evdev_drv.so (0x684000+0x5296) [0x689296]
[109454.330] 6: /usr/bin/X (0x8048000+0x62e7f) [0x80aae7f]
[109454.330] 7: /usr/bin/X (0x8048000+0x121b4e) [0x8169b4e]
[109454.330] 8: (vdso) (__kernel_sigreturn+0x0) [0xdaa400]
[109454.365] 9: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (ulReadMmRegisterUlong+0xd7) [0x12f90b7]
[109454.368] 10: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (0xf89000+0x351733) [0x12da733]
[109454.368] 11: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (0xf89000+0x351691) [0x12da691]
[109454.368] 12: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (0xf89000+0x35163a) [0x12da63a]
[109454.368] 13: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (MCIL_WaitFor+0x99) [0x12b4a29]
[109454.368] 14: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (Cail_MCILWaitFor+0xc8) [0x12da4f8]
[109454.368] 15: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (Cail_WaitForMCIdle_Internal+0x77) [0x12ccd37]
[109454.368] 16: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (CAIL_WaitForMCIdle+0x3e) [0x12c50ee]
[109454.368] 17: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (swlCailWaitForMCIdle+0x1f) [0x12ab25f]
[109454.369] 18: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (MCIL_WaitForMCIdle+0x22) [0x12b4b52]
[109454.369] 19: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (swlPPLibCwddepm+0x67) [0x12bb787]
[109454.369] 20: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (0xf89000+0x2f3cbb) [0x127ccbb]
[109454.369] 21: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (0xf89000+0x2f151c) [0x127a51c]
[109454.369] 22: /usr/bin/X (0x8048000+0x26ee7) [0x806eee7]
[109454.369] 23: /usr/bin/X (0x8048000+0x1a5da) [0x80625da]
[109454.369] 24: /lib/libc.so.6 (__libc_start_main+0xe7) [0x28ace7]
[109454.369] 25: /usr/bin/X (0x8048000+0x1a1b1) [0x80621b1]
Update: Merged jwadamson's patch that gets rid of the OSX dock icon
Try -w 256, or very low values of -f like -f 1. The bug doesn't make any sense, and is clearly in the drivers, and as I've said in other posts in this thread, it also has effected some poclbm users.
Just a head's up:
With the a Raedon 6850 and Catalyst 11.4 preview drivers (which have huge performance improvements for games), I'm only getting 5670/5650 khash/sec.
Unfortunately with me downgrading the Catalyst drivers is not an option.
Using suggested command line for Windows, an IRC user suggested adding "-f 30" but nothing changed.
With the a Raedon 6850 and Catalyst 11.4 preview drivers (which have huge performance improvements for games), I'm only getting 5670/5650 khash/sec.
Unfortunately with me downgrading the Catalyst drivers is not an option.
Using suggested command line for Windows, an IRC user suggested adding "-f 30" but nothing changed.
fps means "frames per second", its how many times the OpenCL kernel runs per second. Lower values means the kernel runs for longer, reduces overhead, but decreases desktop interactivity. Higher values means the kernel runs for less time, increases overhead, but increases desktop interactivity.
Tune it until it feels right for you. The default is 60, a lot of people just say fuck it and run at 1000
Tune it until it feels right for you. The default is 60, a lot of people just say fuck it and run at 1000
i use
./DiabloMiner-OSX.sh -u MYUSERNAME -p PASSWORD -o deepbit.net -r 8332 -g 5
right now as i simply copy pasted the command from deepbit
what exactly does the -f do?
-f,--fps target execution timing
does not make alot of sense to me
./DiabloMiner-OSX.sh -u MYUSERNAME -p PASSWORD -o deepbit.net -r 8332 -g 5
right now as i simply copy pasted the command from deepbit
what exactly does the -f do?
-f,--fps
does not make alot of sense to me
hi i was wondering if there is a list of all the diablominer flags. i havnt found any in the op or at any of the links provided in the op.
also if it is not asking too much could you give an explanation of what these flags do in layman terms.
im asking as i just read some of the last posts in this thread talking about the -f 1 flag resulting in more kh/s
true enough the relatively weak 320m in my macbook went from 5100kh/s to about 7000kh/s (it got a 2sec peak at more than 10mh/s) so the increase is very significant. The only draw back was the machine became unusable so i would like some info so i can find a sweet spot.
also if it is not asking too much could you give an explanation of what these flags do in layman terms.
im asking as i just read some of the last posts in this thread talking about the -f 1 flag resulting in more kh/s
true enough the relatively weak 320m in my macbook went from 5100kh/s to about 7000kh/s (it got a 2sec peak at more than 10mh/s) so the increase is very significant. The only draw back was the machine became unusable so i would like some info so i can find a sweet spot.
Did you try starting the miner with -h?
And the sweet spot is user specific. The default for -f is 60, try moving it up and down by multiple/divisors of 60 (1, 15, 30, 60, 120, etc) until you get what you want.
hi i was wondering if there is a list of all the diablominer flags. i havnt found any in the op or at any of the links provided in the op.
also if it is not asking too much could you give an explanation of what these flags do in layman terms.
im asking as i just read some of the last posts in this thread talking about the -f 1 flag resulting in more kh/s
true enough the relatively weak 320m in my macbook went from 5100kh/s to about 7000kh/s (it got a 2sec peak at more than 10mh/s) so the increase is very significant. The only draw back was the machine became unusable so i would like some info so i can find a sweet spot.
also if it is not asking too much could you give an explanation of what these flags do in layman terms.
im asking as i just read some of the last posts in this thread talking about the -f 1 flag resulting in more kh/s
true enough the relatively weak 320m in my macbook went from 5100kh/s to about 7000kh/s (it got a 2sec peak at more than 10mh/s) so the increase is very significant. The only draw back was the machine became unusable so i would like some info so i can find a sweet spot.
Cerebrum, I think you've overlooked -d. It tells you lots of information, including when it submits a hash, and if the hash is accepted or not.
Also, my miner double checks all solutions before submitting... if there is a hw error, it bitches very loudly without -d.
And I don't believe poclbm's hash meter is correct. Mine lists two numbers, 15 second average, forever average. poclbm does not have a meter that is comparable to either. My miner is also faster because poclbm does not try to keep work queued for the hardware.
In addition, since I queue multiple kernels in parallel, network activity for remote pools costs much less than it does on poclbm.
Also, my miner double checks all solutions before submitting... if there is a hw error, it bitches very loudly without -d.
And I don't believe poclbm's hash meter is correct. Mine lists two numbers, 15 second average, forever average. poclbm does not have a meter that is comparable to either. My miner is also faster because poclbm does not try to keep work queued for the hardware.
In addition, since I queue multiple kernels in parallel, network activity for remote pools costs much less than it does on poclbm.
Wonderful. Thanks for these clarifications. It is never complaining about invalid or stale hashes so I guess I'm never making any.
I was noticing that when I run a single instance of DiabloMiner with all 4 graphics cores, I get worse performance than running 4 seperate instances with one for each core. Do you have any idea why that is? The performance difference isn't huge (about 4-5%) but it's definitely present. Any idea as to why it works better with 4 independent instances than with all 4 in the same instance?
EDIT: Forgot to ask. Is there any way to start up a fake X session from the command line so that I can start the miner via SSH? Or do I have to look into getting VNC installed on my desktop so I can log into the graphical environment remotely?
You shouldn't be getting less. Are you sure you're doing your math right? Run with -f 1 connecting to a local, and let it run for 5-10 minutes and check the second number.
If you're on Radeon hardware, you require a real X session running. You don't have to use VNC or use X for anything at all, just start your miner with DISPLAY=:0 ./DiabloMiner over ssh as the user that started X.
Thanks for pointing out my obvious error. It turns out that I wasn't waiting long enough when doing that test on single vs. multiple instances, and I'm actually getting about 500KH/s more per core from the combined instance.
Cerebrum, I think you've overlooked -d. It tells you lots of information, including when it submits a hash, and if the hash is accepted or not.
Also, my miner double checks all solutions before submitting... if there is a hw error, it bitches very loudly without -d.
And I don't believe poclbm's hash meter is correct. Mine lists two numbers, 15 second average, forever average. poclbm does not have a meter that is comparable to either. My miner is also faster because poclbm does not try to keep work queued for the hardware.
In addition, since I queue multiple kernels in parallel, network activity for remote pools costs much less than it does on poclbm.
Also, my miner double checks all solutions before submitting... if there is a hw error, it bitches very loudly without -d.
And I don't believe poclbm's hash meter is correct. Mine lists two numbers, 15 second average, forever average. poclbm does not have a meter that is comparable to either. My miner is also faster because poclbm does not try to keep work queued for the hardware.
In addition, since I queue multiple kernels in parallel, network activity for remote pools costs much less than it does on poclbm.
Wonderful. Thanks for these clarifications. It is never complaining about invalid or stale hashes so I guess I'm never making any.
I was noticing that when I run a single instance of DiabloMiner with all 4 graphics cores, I get worse performance than running 4 seperate instances with one for each core. Do you have any idea why that is? The performance difference isn't huge (about 4-5%) but it's definitely present. Any idea as to why it works better with 4 independent instances than with all 4 in the same instance?
EDIT: Forgot to ask. Is there any way to start up a fake X session from the command line so that I can start the miner via SSH? Or do I have to look into getting VNC installed on my desktop so I can log into the graphical environment remotely?
You shouldn't be getting less. Are you sure you're doing your math right? Run with -f 1 connecting to a local, and let it run for 5-10 minutes and check the second number.
If you're on Radeon hardware, you require a real X session running. You don't have to use VNC or use X for anything at all, just start your miner with DISPLAY=:0 ./DiabloMiner over ssh as the user that started X.
Cerebrum, I think you've overlooked -d. It tells you lots of information, including when it submits a hash, and if the hash is accepted or not.
Also, my miner double checks all solutions before submitting... if there is a hw error, it bitches very loudly without -d.
And I don't believe poclbm's hash meter is correct. Mine lists two numbers, 15 second average, forever average. poclbm does not have a meter that is comparable to either. My miner is also faster because poclbm does not try to keep work queued for the hardware.
In addition, since I queue multiple kernels in parallel, network activity for remote pools costs much less than it does on poclbm.
Also, my miner double checks all solutions before submitting... if there is a hw error, it bitches very loudly without -d.
And I don't believe poclbm's hash meter is correct. Mine lists two numbers, 15 second average, forever average. poclbm does not have a meter that is comparable to either. My miner is also faster because poclbm does not try to keep work queued for the hardware.
In addition, since I queue multiple kernels in parallel, network activity for remote pools costs much less than it does on poclbm.
Wonderful. Thanks for these clarifications. It is never complaining about invalid or stale hashes so I guess I'm never making any.
I was noticing that when I run a single instance of DiabloMiner with all 4 graphics cores, I get worse performance than running 4 seperate instances with one for each core. Do you have any idea why that is? The performance difference isn't huge (about 4-5%) but it's definitely present. Any idea as to why it works better with 4 independent instances than with all 4 in the same instance?
EDIT: Forgot to ask. Is there any way to start up a fake X session from the command line so that I can start the miner via SSH? Or do I have to look into getting VNC installed on my desktop so I can log into the graphical environment remotely?
Cerebrum, I think you've overlooked -d. It tells you lots of information, including when it submits a hash, and if the hash is accepted or not.
Also, my miner double checks all solutions before submitting... if there is a hw error, it bitches very loudly without -d.
And I don't believe poclbm's hash meter is correct. Mine lists two numbers, 15 second average, forever average. poclbm does not have a meter that is comparable to either. My miner is also faster because poclbm does not try to keep work queued for the hardware.
In addition, since I queue multiple kernels in parallel, network activity for remote pools costs much less than it does on poclbm.
Also, my miner double checks all solutions before submitting... if there is a hw error, it bitches very loudly without -d.
And I don't believe poclbm's hash meter is correct. Mine lists two numbers, 15 second average, forever average. poclbm does not have a meter that is comparable to either. My miner is also faster because poclbm does not try to keep work queued for the hardware.
In addition, since I queue multiple kernels in parallel, network activity for remote pools costs much less than it does on poclbm.
Thanks, Diablo3!
That got it working. But any idea why I'm only getting about 5000khps? Seems like something's wrong...
That got it working. But any idea why I'm only getting about 5000khps? Seems like something's wrong...
Did you try using -f 1? That improved my performance on a 5970 from about 15M Hash/s to about 330M Hash/s.
I have no idea why DiabloMiner is affected by the -f option so much more than poclbm, but apparently it is.
Also, is there a way that we can have DiabloMiner output all those interesting statistics about mining like the modified version of poclbm that's been going around here? (Invalid/Stale Percentage, Current position in the getwork, Ratio of getworks to submissions, hashrate, ratio of getworks to answers with more work in them) Those were great for getting a very condensed picture of how your mining is going.
-f effects it because my global run size code is more finely tuned than his. If larger -fs work, that indicates either a driver bug or a bug in the OS's scheduler.
I don't intend on adding all those numbers to -d because they have no use. You have zero control over those, and they are not informative.
I'd debate whether those statistics are informative or not. I don't give a damn about that efficiency statistic, nor the current getwork number, or the spot in the current getwork. However, a statistic on how many of the hash solutions found were invalid/stale would be great. That's what's telling me that I should stick with DiabloMiner instead of switching to poclbm, since poclbm reports that 3-5% of hash solutions are invalid, but gets about 2% better hashrate than DiabloMiner.
However, since DiabloMiner remains mute on that subject, I assume that no hashes computed by DiabloMiner are invalid or stale. This leads me to the conclusion that I should use DiabloMiner over poclbm, so it would be good to include that statistic, if only to allow the users to make a more informed decision about which miner they should use to get the most out of their hardware investments.
And about that not being controllable: As I understand it, that metric is within the user's control as soon as overclocking is involved. If overclocked too aggressively, cards start producing invalid hashes more frequently, no? This may be a useful tool for properly tuning overclocking settings.
Thanks, Diablo3!
That got it working. But any idea why I'm only getting about 5000khps? Seems like something's wrong...
That got it working. But any idea why I'm only getting about 5000khps? Seems like something's wrong...
Did you try using -f 1? That improved my performance on a 5970 from about 15M Hash/s to about 330M Hash/s.
I have no idea why DiabloMiner is affected by the -f option so much more than poclbm, but apparently it is.
Also, is there a way that we can have DiabloMiner output all those interesting statistics about mining like the modified version of poclbm that's been going around here? (Invalid/Stale Percentage, Current position in the getwork, Ratio of getworks to submissions, hashrate, ratio of getworks to answers with more work in them) Those were great for getting a very condensed picture of how your mining is going.
-f effects it because my global run size code is more finely tuned than his. If larger -fs work, that indicates either a driver bug or a bug in the OS's scheduler.
I don't intend on adding all those numbers to -d because they have no use. You have zero control over those, and they are not informative.
Jump to: