I heard about Bitcoins and want to test a bit of mining.
Now i have some questions about your miner.
My hardware is:
Geforce GTX 285
Core Due 6300, 2 GB RAM, Win 7
I create a bitcoin.conf with rpc user and password and started bitcoin.exe with -server variable. I have also started and it worked with standard settings. It shows me about xxxxx/30000 khash/ in the cmd window of DiabloMiner and about 1000 khash/s in the Bitcoin Gui. Is right or did i something wrong or miss something?
Thanks for help, Mowo
The Bitcoin client only shows its own CPU mining. I recommend you turn CPU mining off in the client, as its a waste of electricity, hardware, and time and usually slows GPU mining down too. |
|
|
|
If you knew anything about statistics, Atroxes, you'd know that even right now there's already a good chance his pool finds a few blocks in a row, 51% is a myth.
Even with 40% he will get 6 blocks in a row 0.41% of the time meaning he only needs 244 attempts to succeed once. Is that in any way shape or form good for the health and security of Bitcoin? I seriously doubt Satoshi would be happy if he saw a client have this much of the total hashing speed, and it even arguably defeats the whole point of mining.
EDIT: And I understand that everyone is participating voluntarily it's just that I don't want to see us suffer even a single fraud attack which could potentially bring the whole thing down.
What if [Tycho] is really Satoshi Nakamoto himself ? I am the one, who accused directly that [Tycho] "WILL" bring down Bitcoin. http://forum.bitcoin.org/index.php?topic=9090But, the working style, speed, quick response, non stop increase in pool size, still he is BELOW 50% for the past 2-3 months, I think it is Satoshi Nakamoto himself running deepbit.net in alias form, [Tycho], so that NO OTHERS take down the bitcoin. If some one like US govt, try to take down bitcoin then any one think that Satoshi Nakamoto will just sit & do nothing? With the power of pool size [Tycho] has Satoshi Nakamoto can easily with out much effort can make bitcoin stay forever, who ever, what ever times attack bitcoin, to bring down bitcoin. Am i right? Some secrets must stay secret only, to protect everything.No way man. I'm Satoshi. So is Gavin. And Luke. AND YOU. We're all Satoshi, each and every one of us. |
|
|
|
I've got a crappy Intel GMA X3100 on my MacBook.
Isn't it compatible with GPU miners?
No. Intel only very recently manufactured GPUs that do OpenCL, it is limited to the new GMA HD 2000/3000 series only. GMA 2000/3000/4000 and GMA HD (aka 5000 aka HD 1000) do not support it and do not even have the hardware to support it. |
|
|
|
I'm on a macbook air and i can't seem to get more than 700 khash/sec
any suggestions?
./DiabloMiner-OSX.sh ... -w 64
[6/4/11 12:24:51 PM] Started
[6/4/11 12:24:51 PM] Connecting to: http://..../
[6/4/11 12:24:51 PM] Using Apple OpenCL 1.0 (Dec 23 2010 17:30:26)
[6/4/11 12:24:51 PM] Added GeForce 320M (#1) (6 CU, local work size of 64)
442/619 khash/sec
You should get about 6 mhash. Try a higher -w value, Apple's OpenCL implementation is extremely buggy. Thanks. Whenever I try a -w setting of 256 or higher, the miner seems to have trouble (lots of OpenCL errors),and still is in that sub 800 khash range I can imagine higher, its not valid for most GeForces (or any Radeon for that matter). What does local work size say when you don't use -w? That is your maximum. |
|
|
|
Hi Diablo, I'm running the RPCminer on a quad-core Xeon 2.26GHz and only getting about 2MHash/s.
Even my ancient core2 duo PC is getting about 5MHash/s so what am I doing wrong?
Ahh, dunno. Your question would be better off towards the author of RPC Miner or the front end for it. |
|
|
|
I'm on a macbook air and i can't seem to get more than 700 khash/sec
any suggestions?
./DiabloMiner-OSX.sh ... -w 64
[6/4/11 12:24:51 PM] Started
[6/4/11 12:24:51 PM] Connecting to: http://..../
[6/4/11 12:24:51 PM] Using Apple OpenCL 1.0 (Dec 23 2010 17:30:26)
[6/4/11 12:24:51 PM] Added GeForce 320M (#1) (6 CU, local work size of 64)
442/619 khash/sec
You should get about 6 mhash. Try a higher -w value, Apple's OpenCL implementation is extremely buggy. |
|
|
|
Each GPU uses 3 queues in three different threads and are setup in a way that can never cause this.
If you do -D 2, only Barts #2 should have a load.
Also for dual-head on one card but not the other, I'd carefully edit the redundant screen definitions out of xorg.conf after running that second command.
Okay, sorry to keep bothering you like this, but I'd like to figure this out. After a night of mining, here are some stats: Command: ./DiabloMiner-Linux.sh --url http://user.worker:pass@mining.bitcoin.cz:8332/ -v 19 -w 192 -D 1,2
Output: 6/4/11 1:55:59 PM] Started
[6/4/11 1:55:59 PM] Connecting to: http://mining.bitcoin.cz:8332/
[6/4/11 1:56:00 PM] Using AMD Accelerated Parallel Processing OpenCL 1.1 AMD-APP-SDK-v2.4 (595.10)
[6/4/11 1:56:03 PM] BFI_INT patching enabled, disabling hardware checking
[6/4/11 1:56:03 PM] Added Barts (#1) (12 CU, local work size of 192)
[6/4/11 1:56:09 PM] BFI_INT patching enabled, disabling hardware checking
[6/4/11 1:56:09 PM] Added Barts (#2) (12 CU, local work size of 192)
[6/4/11 1:56:19 PM] Block 1 found on Barts (#1)
[6/4/11 1:56:52 PM] Block 2 found on Barts (#2)
[6/4/11 1:57:05 PM] Block 3 found on Barts (#2)
[6/4/11 1:58:04 PM] Block 4 found on Barts (#2)
[6/4/11 1:58:16 PM] Block 5 found on Barts (#2)
[6/4/11 1:58:59 PM] Block 6 found on Barts (#1)
[6/4/11 2:00:21 PM] Block 7 found on Barts (#1)
226765/231103 khash/sec
aticonfig --odgc --adapter=all Adapter 0 - AMD Radeon HD 6800 Series
Core (MHz) Memory (MHz)
Current Clocks : 900 1000
Current Peak : 900 1000
Configurable Peak Range : [600-1000] [1000-1250]
GPU load : 99%
Adapter 1 - AMD Radeon HD 6800 Series
Core (MHz) Memory (MHz)
Current Clocks : 300 300
Current Peak : 900 1000
Configurable Peak Range : [600-1000] [1000-1250]
GPU load : 0%
aticonfig --odgt --adapter=all Adapter 0 - AMD Radeon HD 6800 Series
Sensor 0: Temperature - 82.00 C
Adapter 1 - AMD Radeon HD 6800 Series
Sensor 0: Temperature - 52.00 C
With one configuration last night I actually saw the meter go up to 460, but I can't remember what I did. My xorg.conf is at https://gist.github.com/1008220 to show how these cards are set up. I would really appreciate it if anyone could come up with an explanation for what is going on. Thanks in advance. Woah, that xorg.conf doesn't look right. Without -D, does it list, say, 4 Barts? |
|
|
|
|
Update: I think I've refixed mtrlt's mining bug. I hope.
The math to calculate this, you need three things, mhash, number of shares (at least 100), and the number of minutes between the first and last shares.
mhash * 60 * minutes
4296 * shares
So, for example 367 mhash, 100 shares, 18 minutes
367 * 60 * 18 = 396360
4296 * 100 = 429600
So in this case, I was luckier than normal.
If you have the bug, the share hashrate will be approximately 2/3rds of the actual hashrate.
|
|
|
|
I am using "-w 128 -v 2 -f 60 -dd" but for sure I am not losing 1/3 of the shares [..] With -v 2, I'm not getting any hardware-issue-failed-shares (but only 262mhash/s). The problem with 1/3 hardware issues only happens with -v 19 for me. So your problem is probably with overclocking. BTW, my temperature usually is ~71°C, so that shouldn't be a problem. It's either some nicely hidden bug in diablo, or it's a driver/hardware bug that shows when interleaving 3 sha256 runs. After digging through the .cl and .java code for some time, I gave up and am now using -v 2.  Certain combinations drive the hardware harder. If you're borderline overclocked too far, some settings could push you over. Also, -f 60 could also drive the hardware harder over -f 30, so ymmv. (And no, you don't win here, 60 is slower than 30 on Windows, and causes a more variable hashrate otherwise). |
|
|
|
After a whole night mining with -dd I have 80 failed attemps out of 1634 not sure if all of them are due "hardware problems" but for sure most are. I am mining on a 5770 at 915GPU 1200 Mem (a bit oced) the good point is that even running with -dd I haven't seen a MHash drop on average (194MHs using -f 60)
Deepbit is more or less accurate (170-190Mhs) but I have 2% of lifetime stales (41K shares) I don't know why but I had some problems with windows suspending the screen and losing mining capacity (going back to 70-100Mhs) and increasing the stale ratio, I think I fixed that and haven't seen the problem for some time but the stats are already there.
I am using "-w 128 -v 2 -f 60 -dd" but for sure I am not losing 1/3 of the shares but what bothers me as is I have a 5% of failed attempts misscalculated then 5% of the total hashes should be also misscalculated including some attempts that arent being recognized as such so effectively I have 185MHs rate. If this is due to the oc probably it is better to just reset to normal speeds and get 100% efficiency on 180MHs
80 out of 1634 seems to be fine for an OC'ed card. Do not try to suspend the monitor during mining, Windows tries to get clever and fails. HW check errors do not effect stale shares on the pool, as they are never sent in. |
|
|
|
[6/3/11 6:49:05 PM] Block 10 found on Barts (#2)
[6/3/11 6:49:09 PM] Block 11 found on Barts (#1)
[6/3/11 6:49:29 PM] Block 12 found on Barts (#2)
[6/3/11 6:49:40 PM] Block 13 found on Barts (#1)
[6/3/11 6:49:44 PM] Block 14 found on Barts (#2)
[6/3/11 6:50:25 PM] Block 15 found on Barts (#2)
[6/3/11 6:50:43 PM] Block 16 found on Barts (#2)
[6/3/11 6:50:57 PM] Block 17 found on Barts (#1)
So, if DM is outputting stuff like this, then are the blocks defiantly being found by the cards that are in parentheses? What I mean is that Barts (#2) doesn't seem to be accessible by certain aticonfig options, and my hash rate seems to be that of a single GPU. Is it possible that all blocks are being completed by Barts #1 but being labeled otherwise? Nope. Sure you have the right speed in mind? A 6870 should be doing somewhere around 270 or so at stock speeds. I have two 6850s and I'm getting 230 overclocked (to a core clock of 900). I can't use aticonfig to set any setting for Barts #2, yet DM says it is finding blocks, so I'm confused if it is contributing to the hash meter or not. 230 sounds closer to a single 6850. No, it can't accidentally label blocks coming from the wrong device. It is contributing to the hash meter. You're on Linux, so did you forget to turn off Crossfire? You need to run sudo aticonfig --initial --adapter=all -f and then restart X. Do you know how I would run aticonfig to set up both of these cards with one of them having a dual head setup? sudo aticonfig --initial=dual-head allows me to boot, but sudo aticonfig --initial=dual-head --adapter=all -f seems to generate a dual head setup for both cars that screws everything up. What is required for the miner to use a card? Does it just need a device section in xorg.conf, or does it need to be connected to a screen? EDIT: Okay, now (after some careful editing of xorg.conf) aticonfig shows that Barts #1 is at a GPU load of 99% while Barts #2 of 0%. Other stats, such as temperature are confirming this. While I know there is something wrong with my setup, are you sure there isn't a bug in the miner? It still reports the blocks being solved by both cards. EDIT2: If I run DM with -D 2, aticonfig still says all of the load and temp increase is on Barts #1. Also, Crossfire is disabled. Each GPU uses 3 queues in three different threads and are setup in a way that can never cause this. If you do -D 2, only Barts #2 should have a load. Also for dual-head on one card but not the other, I'd carefully edit the redundant screen definitions out of xorg.conf after running that second command. |
|
|
|
[6/3/11 6:49:05 PM] Block 10 found on Barts (#2)
[6/3/11 6:49:09 PM] Block 11 found on Barts (#1)
[6/3/11 6:49:29 PM] Block 12 found on Barts (#2)
[6/3/11 6:49:40 PM] Block 13 found on Barts (#1)
[6/3/11 6:49:44 PM] Block 14 found on Barts (#2)
[6/3/11 6:50:25 PM] Block 15 found on Barts (#2)
[6/3/11 6:50:43 PM] Block 16 found on Barts (#2)
[6/3/11 6:50:57 PM] Block 17 found on Barts (#1)
So, if DM is outputting stuff like this, then are the blocks defiantly being found by the cards that are in parentheses? What I mean is that Barts (#2) doesn't seem to be accessible by certain aticonfig options, and my hash rate seems to be that of a single GPU. Is it possible that all blocks are being completed by Barts #1 but being labeled otherwise? Nope. Sure you have the right speed in mind? A 6870 should be doing somewhere around 270 or so at stock speeds. I have two 6850s and I'm getting 230 overclocked (to a core clock of 900). I can't use aticonfig to set any setting for Barts #2, yet DM says it is finding blocks, so I'm confused if it is contributing to the hash meter or not. 230 sounds closer to a single 6850. No, it can't accidentally label blocks coming from the wrong device. It is contributing to the hash meter. You're on Linux, so did you forget to turn off Crossfire? You need to run sudo aticonfig --initial --adapter=all -f and then restart X. |
|
|
|
Okay I'll try Diablo with a smaller pool that has been more reliable for me in the past and let you know if that helps. Like I've said to others, I believe there is either a widespread bug in how some pools operate (such as giving the wrong diff target out, or incorrectly checking hashes (such as H == 0 only instead of also G <= target)), or Pheonix is incorrectly reporting that shares have been accepted when they haven't.
For me, on Deepbit, I get two or three stale shares for every 1000 give or take.
I connected to a small pool I often use with Diablo. It kept up reporting 304Mhash/s but after several hours the pool reported that of the 1231 requested blocks Diablo had only been able to return 854, for an efficiency of 69%. With phoenix my efficiency is upwards of 90% even though my Mhash rate is slower by 5. I don't know enough about the long polling process or the way the rpcs work to identify if this is a bug with my pool or the miner. But my effective hash rate is certainly better with phoenix. You're suffering from the bug. It eats about 1/3rd of hash attempts. Although, interestingly, not using vectors doesn't trigger it. Sigh. I hate bugs. |
|
|
|
and why diablo miner shows xxxx/yyyyy khash ?
what does the yyyy means?
15 second average/forever average |
|
|
|
how can I check my sdk version?
where can I see it?
It spits it out on startup now. |
|
|
|
[6/3/11 6:49:05 PM] Block 10 found on Barts (#2)
[6/3/11 6:49:09 PM] Block 11 found on Barts (#1)
[6/3/11 6:49:29 PM] Block 12 found on Barts (#2)
[6/3/11 6:49:40 PM] Block 13 found on Barts (#1)
[6/3/11 6:49:44 PM] Block 14 found on Barts (#2)
[6/3/11 6:50:25 PM] Block 15 found on Barts (#2)
[6/3/11 6:50:43 PM] Block 16 found on Barts (#2)
[6/3/11 6:50:57 PM] Block 17 found on Barts (#1)
So, if DM is outputting stuff like this, then are the blocks defiantly being found by the cards that are in parentheses? What I mean is that Barts (#2) doesn't seem to be accessible by certain aticonfig options, and my hash rate seems to be that of a single GPU. Is it possible that all blocks are being completed by Barts #1 but being labeled otherwise? Nope. Sure you have the right speed in mind? A 6870 should be doing somewhere around 270 or so at stock speeds. |
|
|
|
|
Using the log vonshmitt sent me, the people suffering from this bug are losing about 1/3rd shares (rejected and accepted combined).
I wonder if I missed additional bugs in mtrlt's patch.
Edit: double fuck, its doing it here too.
|
|
|
|
Good morning,
can someone please explain me how do I setup the DiabloMiner.app for SOLO mining, if this is possible at all?
Like do I have to run the Bitcoin Client, what do I enter then in the DiabloMiner Setup for host, port, user and pw?
Thanks!
Set the user and pw you put in bitcoin.conf, and use localhost and 8332 Thanks Diablo! But can you please specify that? like those: #rpcuser=user #rpcpassword=password ?  I know where to put the file, but I'm not sure what I have to put in it to make it work. Try this: rpcuser=(your account name) rpcpassword=(your password) rpcport=8332 gen=1 server=1 That's my bitcon.conf rpcuser and rpcpassword means the account where your Bitcointclient is running at. Write it without "#" in the bitcoin.conf. My diablo seems to be running now. It just saying this: Starting DiabloMiner (GPU)... ----------------------------- [03.06.11 12:34:04] Started [03.06.11 12:34:04] Connecting to: http://127.0.0.1:8332/[03.06.11 12:34:05] Added GeForce 9600M GT (#1) (4 CU, local work size of 256) [03.06.11 12:34:08] Added GeForce 9400M (#2) (2 CU, local work size of 256) 2411/2436 khash/sec Is it right? If you have one of the Macs with a hybrid GPU setup, OpenCL apps may not function correctly. I think no. It's just a Macbook Pro (late 08) for testing. Something like Dual Core 2,4 with 9600 and/or 9400. The "big" test's starting on Monday. Anyway, can you gife me/us an example of "you got a trophy" with Diablo miner. *cough* Thats a dual nvidia hybrid. Only one chip is on at the same time, and it confuses the hell out of most apps because OSX is too stupid to not list chips that are powered off. |
|
|
|
I cannot reproduce this bug.
That's fine, there are other miners. Well, if the bug happens to be on the pool side (ie, pools are not properly checking hashes), then not only is that exploitable, it would be blocked by the pool software I'm writing (which checks share validity fully). If the bug IS in my miner, I would love to find out what exactly triggers it so I can fix it, but I just don't think it is. |
|
|
|
Either you do not have OpenCL drivers installed, or your device does not support OpenCL.
Duh I didn't read anything about the need of OpenCL anywhere... it should be included with ATI drivers right? So it should be installed already. Nonetheless, it's not workin, what should I do? If you're on Windows, and have installed a recent version of Catalyst (11.4 and up), it installs the OpenCL runtime unless you tell it not to. What hardware do you have? |
|
|
|
|
Show Posts
