 Show Posts
|
|
Pages: [1]
|
Ok, All PPS payments for mining on my temporary pool have been sent. (10 sendmany transactions). I went ahead and paid 102.5% PPS, as a thanks for continuing to mine.  [snip] Thanks, wizkid057. How can I throw a small tip your way for keeping the pool going? |
|
|
|
Update: Everyone effected by the problem, try the new build.
The new build works well, thanks! What was the issue? Side note: I can now use a worksize of either 128 or 256 on OS X 10.7.4 and notice a small increase in hashrate over -w 64. May be worth mentioning in the OP instructions. I assume it's because of (one of?) the OpenCL updates Apple has pushed out. FINALLY THEY FIXED IT! HOLY CRAP APPLE, IT ONLY TOOK TWO YEARS! Also, the issue on AMD was AMD interprets the specification differently than I do. It costs basically nothing to fix it, and on GCN its measurably nothing. Well, I spoke too soon. After letting a few boxes run over the weekend with the latest version, the clients report that they are connecting to the pool and shares are accepted, however the hashrate as reported by the pool is much lower with this latest version than the one in March. The new client was showing an average 34 mhash/s per machine all weekend (looking at Eligius' 3 hr avg & 12 hr avg) vs. 67 mhash/s on the March client (looking at Eligius' 3 hours avg today). I can confirm that just upgrading to 10.7.4 cause an approximate drop of 8-10 mhash/s.  |
|
|
|
Update: Everyone effected by the problem, try the new build.
The new build works well, thanks! What was the issue? Side note: I can now use a worksize of either 128 or 256 on OS X 10.7.4 and notice a small increase in hashrate over -w 64. May be worth mentioning in the OP instructions. I assume it's because of (one of?) the OpenCL updates Apple has pushed out. |
|
|
|
|
Has anyone run this on an iMac with an AMD Radeon HD 6750M (or just OS X Lion, in general) and have any config options to share? Thanks!
|
|
|
|
This may be unrelated to typhoon's problem, but the latest version of diablominer fails to submit to and/or connect to the mining pool I've been using. I'm running on 2011 iMacs, running OS X 10.7.4, with AMD Radeon HD 6750M (512 MB of RAM) and Apple OpenCL 1.1 (Apr 9 2012 19:41:45). The command line arguments I'm using include: ./DiabloMiner-OSX.sh -w 64 -v 2 -na The May 2012 version outputs the following: [5/18/12 10:19:36 AM] Started
[5/18/12 10:19:36 AM] Connecting to: http://mining.eligius.st:8337/
[5/18/12 10:19:36 AM] Using Apple OpenCL 1.1 (Apr 9 2012 19:41:45)
[5/18/12 10:19:37 AM] Added ATI Radeon HD 6750M (#1) (6 CU, local work size of 64)
[5/18/12 10:29:40 AM] ERROR: Cannot connect to mining.eligius.st: Read timed out
[5/18/12 10:31:59 AM] ERROR: Cannot connect to mining.eligius.st: Read timed out
[5/18/12 10:38:21 AM] ERROR: Cannot connect to mining.eligius.st: Read timed out
mhash: 61.0/57.2 | accept: 0 | reject: 0 | hw error: 0 The March 2012 version outputs the following: [5/18/12 2:09:31 PM] Started
[5/18/12 2:09:31 PM] Connecting to: http://mining.eligius.st:8337/
[5/18/12 2:09:31 PM] Using Apple OpenCL 1.1 (Apr 9 2012 19:41:45)
[5/18/12 2:09:32 PM] Added ATI Radeon HD 6750M (#1) (6 CU, local work size of 64)
[5/18/12 2:09:53 PM] mining.eligius.st accepted block 1 from ATI Radeon HD 6750M (#1)
[5/18/12 2:13:39 PM] mining.eligius.st accepted block 2 from ATI Radeon HD 6750M (#1)
[5/18/12 2:15:23 PM] mining.eligius.st accepted block 3 from ATI Radeon HD 6750M (#1)
[5/18/12 2:15:36 PM] mining.eligius.st accepted block 4 from ATI Radeon HD 6750M (#1)
[5/18/12 2:15:54 PM] mining.eligius.st accepted block 5 from ATI Radeon HD 6750M (#1)
mhash: 58.9/59.3 | accept: 5 | reject: 0 | hw error: 0 Are there any options I can use to give more verbose messages? On an unrelated note, I've recently noticed this model iMac go down to ~50-60 mhash/s from a previously consistent ~70 mhash/s. Could this be related to May's change(s) or the latest Lion update from Apple? Try a different pool. I have not changed anything that involves pools at all as far as I know. This has been largely the removal of code, not the changing of it. As for OSX, its probably a Lion update. Quite a few Mac users have bitched that every time OSX puts a new update out, OpenCL apps get slower. Unfortunately, I'm seeing the exact same problem on four different iMacs (all of the same model, OS version, etc.) regardless of whether the firewall is on/off. The only difference between it working and not is whether I run the March or May version. Although I don't know much about the getwork protocol, eventually the March diablominer receives a response from the pool like the following (which I understand to mean that the work was accepted): HTTP/1.1 200 OK
Content-Length: 40
X-Roll-NTime: expire=120
X-Long-Polling: /LP
Server: Eloipool
Date: Sat, 19 May 2012 17:15:11 GMT
Content-Type: application/json
{"result": true, "id": 1, "error": null} As the result of sending a non-empty "params":[] value. Whereas the May diablominer only receives new blocks after POSTing the following {"method":"getwork","params":[],"id":1}I sniffed the May diablominer with wireshark for twenty minutes and never saw a non-empty "params" value sent. The old one sends one every minute to few minutes. I'm not sure how else to troubleshoot this. Have any of the command line options changed (--url being the only other one I use that I didn't already mention)? I suppose I could try another pool, but the only variable here seems to be the newer version. |
|
|
|
Just reporting in that after I upgraded to the latest DiabloMiner, on both my Windows and Linux machines the miner starts as usual.. adding the devices and then hashing away.. However, shares are never submitted. I walked away for a while and saw that in fact no shares had been submitted to eligius. For proof check out: http://eligius.st/~artefact2/7/1AXiiwR4aYktPKMBMsZaP1untDgN9T8FfXEdit: Found an older DiabloMiner and reverted (it does not include the 2 latest commits), back to mining. I cannot reproduce that bug. BTW, I've dropped OpenCL 1.0 support, so if you're on SDK 2.1... don't do that. DM is supposed to detect if you're on 1.0 and refuse to use those devices, too. Well, assuming I coded that test right. I am on Catalyst 12.4 and the SDK that is included with the drivers. Radeon 5870s/5850s in both boxes (CentOS/Windows 7). If there is anything I can do to help you possibly pinpoint the problem I am all ears. Basically diablominer adds the OpenCL devices then starts hashing away at only god knows what.. and never submits shares, all whilst hashing at full speed and making my GPUs waste energy. The hash meter has a number above zero, right? I'm wondering if Windows has a driver bug that Linux doesn't, because I'm on Linux /w Catalyst 12.4 using the runtime that comes with the drivers, and I can't reproduce it. Yes the hashrate is at full speed, causing 100% gpu usage on all gpus. This happens on 2 separate systems, both with catalyst 12.4 and the included sdk. One system is windows and one is linux (CentOS). Thats extra weird. I'm going to have to think about this one for a bit. It doesn't make sense you have the bug and I don't... I wonder if its hardware related, because I'm on a 7970, not a 58xx. This may be unrelated to typhoon's problem, but the latest version of diablominer fails to submit to and/or connect to the mining pool I've been using. I'm running on 2011 iMacs, running OS X 10.7.4, with AMD Radeon HD 6750M (512 MB of RAM) and Apple OpenCL 1.1 (Apr 9 2012 19:41:45). The command line arguments I'm using include: ./DiabloMiner-OSX.sh -w 64 -v 2 -na The May 2012 version outputs the following: [5/18/12 10:19:36 AM] Started
[5/18/12 10:19:36 AM] Connecting to: http://mining.eligius.st:8337/
[5/18/12 10:19:36 AM] Using Apple OpenCL 1.1 (Apr 9 2012 19:41:45)
[5/18/12 10:19:37 AM] Added ATI Radeon HD 6750M (#1) (6 CU, local work size of 64)
[5/18/12 10:29:40 AM] ERROR: Cannot connect to mining.eligius.st: Read timed out
[5/18/12 10:31:59 AM] ERROR: Cannot connect to mining.eligius.st: Read timed out
[5/18/12 10:38:21 AM] ERROR: Cannot connect to mining.eligius.st: Read timed out
mhash: 61.0/57.2 | accept: 0 | reject: 0 | hw error: 0 The March 2012 version outputs the following: [5/18/12 2:09:31 PM] Started
[5/18/12 2:09:31 PM] Connecting to: http://mining.eligius.st:8337/
[5/18/12 2:09:31 PM] Using Apple OpenCL 1.1 (Apr 9 2012 19:41:45)
[5/18/12 2:09:32 PM] Added ATI Radeon HD 6750M (#1) (6 CU, local work size of 64)
[5/18/12 2:09:53 PM] mining.eligius.st accepted block 1 from ATI Radeon HD 6750M (#1)
[5/18/12 2:13:39 PM] mining.eligius.st accepted block 2 from ATI Radeon HD 6750M (#1)
[5/18/12 2:15:23 PM] mining.eligius.st accepted block 3 from ATI Radeon HD 6750M (#1)
[5/18/12 2:15:36 PM] mining.eligius.st accepted block 4 from ATI Radeon HD 6750M (#1)
[5/18/12 2:15:54 PM] mining.eligius.st accepted block 5 from ATI Radeon HD 6750M (#1)
mhash: 58.9/59.3 | accept: 5 | reject: 0 | hw error: 0 Are there any options I can use to give more verbose messages? On an unrelated note, I've recently noticed this model iMac go down to ~50-60 mhash/s from a previously consistent ~70 mhash/s. Could this be related to May's change(s) or the latest Lion update from Apple? |
|
|
|
As the author stated: OSX users: You need at least OSX 10.6 (Snow Leopard) to run OpenCL apps of any kind. Due to bug in OSX's OpenCL stack, use -w 64 -na otherwise DiabloMiner will not function. IOW, change to The other options would be OK, methinks. |
|
|
|
Although I just registered today: - I've been aware of bitcoin for about three years
- I've lurked around a few forums for some time
- I have a proficient understanding of a number of IT areas, generally
- I have a comfortable level of knowledge of bitcoin's design goals and purposes, though I am not yet skilled enough to review the source code (hoping to change that in the future)
- I'd like to discuss DiabloD3's recent changes to diablominer in the mining forum in the appropriate thread dedicated to that app
- I appreciate the newbie rules in the fight against spamming, but request a whitelisting nevertheless.
|
|
|
|
how was the current threshold derived? has there always been a newbie "wait period" or was it added after-the-fact and the parameters tweaked? it's something i've suggested to a few other forums i've come across that have spam issues.
Originally there was no restriction. For a very short time the limit was just 50 posts. Then the current time+posts restriction was put in place. These numbers work alright. If I wanted to stick with newbie restrictions forever, I'd probably add some more restrictions so people couldn't lurk for 4 hours and then post 5 posts in a few minutes. It's planned to remove these newbie restrictions in the future, once the moderation system is improved. I don't like blocking drive-by contributors. It should require almost no effort for an unregistered user to post something. The low "barrier to contribution" is how 4chan and Wikipedia got so popular. Yes, I agree with the drive-by contributor aspect, which is why I am going to request a pre-emptive whitelisting. I have spent who-knows-how-many hours anonymously lurking over quite a few months, but it wasn't until I had a problem with the mining app I use that I wanted to participate in a thread. Same thing happened with wikipedia: I first contributed there in 2003, but didn't make any significant contributions until 2 years later. |
|
|
|
i am curious to know whether the newbie rules have stopped any spam. i do not mind waiting a few hours (and a few posts) in order to report a bug with one of the mining apps. having a large aversion to spammers, i'd really like to know if this rule has resulted in effective spam reduction.
It has been very effective in stopping spam. There is no spam outside of the newbie-accessible sections. It's also fairly effective at deterring trolls, since "drive-by" trolling is eliminated (as well as drive-by contributing, unfortunately...), and getting banned means you have to go through the newbie process again. how was the current threshold derived? has there always been a newbie "wait period" or was it added after-the-fact and the parameters tweaked? it's something i've suggested to a few other forums i've come across that have spam issues. |
|
|
|
|
a combination of crypto, decentralization, (near) anonymity, and to help establish an decent, alternative currency.
|
|
|
|
Is there a Mac version of the Trojan?
Yes. Google "DevilRobber" for one variant. |
|
|
|
|
i am curious to know whether the newbie rules have stopped any spam. i do not mind waiting a few hours (and a few posts) in order to report a bug with one of the mining apps. having a large aversion to spammers, i'd really like to know if this rule has resulted in effective spam reduction.
|
|
|
|
|
good to see security advice threads in the newbie section. you can never be too paranoid when it comes to IT security, though there are some thresholds most people have to draw the line at, for practical purposes, as a few people have reiterated in this thread.
most people, unfortunately, will never be certain that the device(s) they use are secured/uncompromised. it's a risk everyone has to decide whether or not to take in order to utilize the electronic tool(s) at their disposal.
if you think you have to be paranoid now...just wait until the singularity emanates and we have the ability to jack into networks and systems directly with our minds.
|
|
|
|
|
hello. i first heard of bitcoin about three years ago, but it didn't pique my interest at the time, for some reason. i've had a few lower-to-mid level gfx cards mining for a number of months now. i've lurked in the forums on occasion, and registered because i was having a problem with the latest version of diablominer. just biding time until i can report what i've seen in the appropriate thread.
|
|
|
|
|
