python OpenCL bitcoin miner - page 20.

Elanzer

newbie

Activity: 15

Merit: 0

Quote from: zoro on March 27, 2011, 06:41:27 AM

try sdk 2.2 instead

Using SDK 2.2 instead of 2.3 or 2.4, I still get 2 cores put to 100% load using a HD 5870 and HD 5670 on Win7.

For the meanwhile anyone with this problem can set CPU affinity to only 1 (same for all) core for all poclbm processes so only one core is fully loaded, that way less electricity is used and less heat is made until a proper solution arises.. it doesn't seem to effect hash rate at all.

m0mchil

full member

Activity: 171

Merit: 127

Thanks nelisky! I'll add this in next version.

nelisky

legendary

Activity: 1540

Merit: 1002

Not sure if this was discussed before, I didn't find anything on my 5 seconds search. I needed to use ssl for remote miners and while bitcoind now supports that out of the box, poclbm didn't seem to, at least not the version I was using (and I'm too lazy to try and upgrade a perfectly running system) so here's a patch to allow for that. Patch is for BitcoinMiner.py and you just supply the host part with 'https://' prefix to make it use ssl.

Code:

158,159c158,162
< 
< 		self.host = '%s:%s' % (host.replace('http://', ''), port)
---
> 		if host.find('https:') >= 0:
> 			self.connector = httplib.HTTPSConnection
> 		else:
> 			self.connector = httplib.HTTPConnection
> 		self.host = '%s:%s' % (host.replace('http://', '').replace('https://', ''), port)
220c223
< 				self.connection = httplib.HTTPConnection(self.host, strict=True, timeout=5)
---
> 				self.connection = self.connector(self.host, strict=True, timeout=5)

m4rkiz

full member

Activity: 170

Merit: 100

Quote from: qed on March 26, 2011, 08:34:48 AM

Version 20110325 is a good 5%-10% slower on my 2nd and 3rd card compared to version 20110311.

i have a drop of ~2000 khash/s on 6950 and ~1000 khash/s on 5970 and 5870, nothing major, not even 1%

kindle

member

Activity: 84

Merit: 10

Oh thanks for the prompt reply, will overclocking failure reflect rejected?

Beremat

full member

Activity: 263

Merit: 100

YGOLD is a Defi platform

Quote from: kindle on March 27, 2011, 03:39:10 PM

Hi does anyone know if the accepted shares should be shown?

I am running solo with the latest poclbm client and unlike mining in pool the command prompt doesn't show any accepted shares or rejected shares. Is this normal?

Cheers!

There are no shares when mining solo, only found blocks.

kindle

member

Activity: 84

Merit: 10

Hi does anyone know if the accepted shares should be shown?

I am running solo with the latest poclbm client and unlike mining in pool the command prompt doesn't show any accepted shares or rejected shares. Is this normal?

Cheers!

zoro

full member

Activity: 226

Merit: 100

try sdk 2.2 instead

Raulo

full member

Activity: 238

Merit: 100

Quote from: qed on March 27, 2011, 01:14:13 AM

Quote from: Raulo on March 26, 2011, 03:49:53 PM

On the contrary, on my 2x5970 Linux mining rig, no difference in hashspeed compared to older versions. Everything works fine.

Crossfire disabled?

Yes, disabled.

qed

full member

Activity: 196

Merit: 100

Quote from: Raulo on March 26, 2011, 03:49:53 PM

Quote from: qed on March 26, 2011, 08:34:48 AM

Version 20110325 is a good 5%-10% slower on my 2nd and 3rd card compared to version 20110311.

On the contrary, on my 2x5970 Linux mining rig, no difference in hashspeed compared to older versions. Everything works fine.

Crossfire disabled?

OVerLoRDI

member

Activity: 60

Merit: 10

Has anyone found some remedies I can get rid of the 100% core usage of poclbm? I have 2 miners running with my 6970s and they each load up a core on my system.

The system seems to be tied to SDK 2.3 + 69xx cards. I have two 5870s running on SDK 2.3 also and their instances of poclbm do not suck up much cpu time at all.

I tried the 11.4 RC1 driver that came out a few days ago, no change. I'm back on 11.2 currently.

Raulo

full member

Activity: 238

Merit: 100

Quote from: qed on March 26, 2011, 08:34:48 AM

Version 20110325 is a good 5%-10% slower on my 2nd and 3rd card compared to version 20110311.

On the contrary, on my 2x5970 Linux mining rig, no difference in hashspeed compared to older versions. Everything works fine.

qed

full member

Activity: 196

Merit: 100

Quote from: m0mchil on March 26, 2011, 11:37:02 AM

Quote from: qed on March 26, 2011, 08:34:48 AM

Version 20110325 is a good 5%-10% slower on my 2nd and 3rd card compared to version 20110311.

There is a change in the way '-f' works. Simply said, just use lower '-f' now to achieve same performance/desktop lag as before. 5% seems too much though, what's your setup? Is the first card faster?

3x HD 6950@725MHz and 0.950V.
Windows 7 64-bit and catalyst 11.4 RC2.
CrossfireX enabled.

With the 20110311 version everything is fine and i'm getting around 270 Mhash/s on each card. With the 20110325 the crossfire issue is back, random drop at 180-190Mhash/s and an average of 250-260 Mhash/s on the 2nd and 3rd card.

Thanks for your great work.

EDIT: I'm using "-f 60"

m0mchil

full member

Activity: 171

Merit: 127

Quote from: qed on March 26, 2011, 08:34:48 AM

Version 20110325 is a good 5%-10% slower on my 2nd and 3rd card compared to version 20110311.

There is a change in the way '-f' works. Simply said, just use lower '-f' now to achieve same performance/desktop lag as before. 5% seems too much though, what's your setup? Is the first card faster?

qed

full member

Activity: 196

Merit: 100

Version 20110325 is a good 5%-10% slower on my 2nd and 3rd card compared to version 20110311.

travex

member

Activity: 158

Merit: 10

Eh, do I have to disable crossfire for my 5970(1 card) using this miner guys ?

m0mchil

full member

Activity: 171

Merit: 127

Quote from: jaybob20 on March 26, 2011, 02:45:13 AM

Working much better for me now. Before this update, I had the miner restart if it threw a RPCError in getwork.
Now I see a bunch of "warning: job finished, miner is idle," but it keeps chugging along.
I haven't looked at the new code yet, but would some pre-fetching help?

No. You need as fresh jobs as possible. Try to figure out why it fails to fetch new one in a reasonable time. If not in pool - there is an issue currently which can make getwork() extremely slow, see https://bitcointalksearch.org/topic/createnewblock-too-slow-especially-while-bitcoin-is-under-tx-spam-attack-4853

jaybob20

newbie

Activity: 5

Merit: 0

Quote from: m0mchil on March 25, 2011, 08:48:54 AM

New version is up. All changes are pool related.

- long polling is slightly better in preventing stales to escape to server;
- miner now supports 'time rolling' whenever there is 'X-Roll-NTime' header in HTTP response;
- improved check for end of current task

Working much better for me now. Before this update, I had the miner restart if it threw a RPCError in getwork.
Now I see a bunch of "warning: job finished, miner is idle," but it keeps chugging along.
I haven't looked at the new code yet, but would some pre-fetching help?

slush

legendary

Activity: 1386

Merit: 1097

Quote from: LobsterMan on March 25, 2011, 08:59:58 PM

With the latest version while mining for myself, I seem to be getting intermittent "problems communicating with bitcoin rpc" errors. They appear and disappear seemingly randomly...

This may be related to the getwork locking in bitcoind, the same trouble as I solved. More people already reported troubles with mining on their own with many pending transactions.

You can a) patch the bitcoind with m0mchil's patch published yesterday b) Join my pool, now you even know how to do that Wink

LobsterMan

member

Activity: 73

Merit: 10

With the latest version while mining for myself, I seem to be getting intermittent "problems communicating with bitcoin rpc" errors. They appear and disappear seemingly randomly...

Topic: python OpenCL bitcoin miner - page 20. (Read 1239035 times)