python OpenCL bitcoin miner

[brocktice]

Fixed issue with lost results due to single output per kernel run (thanks OneFixt, ArtForz).

Ack, it broke compatibility with my daemon.py but I got it all fixed up. Thanks for the fixes!

[1713555428]

1713555428

[1713555428]

1713555428

[1713555428]

1713555428

[geebus]

30Mhash/s slower after the update.

HD6950 went from 226M to 196M.

[sc8nt4u]

30Mhash/s slower after the update.

HD6950 went from 226M to 196M.

This makes me not want to update.

[Chuck]

30Mhash/s slower after the update.

HD6950 went from 226M to 196M.

No obvious change for me ( 5850 ), still getting between 249M - 251M.

[LobsterMan]

My hash rate is actually somewhat higher with the new version, I went from about 50mhash/s per gtx275 to around 58mhash/s, but my desktop is somewhat less responsive with the miners running now where it was not before

[m0mchil]

@LobsterMan, the default '-f' is 30 now, use '-f 60' (previous default) or more if it hogs your desktop

[Cablesaurus]

30Mhash/s slower after the update.

HD6950 went from 226M to 196M.

No obvious change for me ( 5850 ), still getting between 249M - 251M.

No change for me either, getting the exact same, no slowdown.

[FairUser]

I'm still seeing several invalid stale hashes being submitted.

05/02/2011 16:12, 3725321b, accepted
05/02/2011 16:13, b794eb73, invalid or stale
05/02/2011 16:13, 898ceca7, invalid or stale
05/02/2011 16:13, bde1a5f3, invalid or stale
05/02/2011 16:14, 0a07cf1a, accepted

Any idea as to why?

[slush]

I'm still seeing several invalid stale hashes being submitted.
Any idea as to why?

Maybe because they are really stale? http://blockexplorer.com/block/00000000000018cf119be227dcf0d7403b20dc9b8fa0c3d6bc9022c65baf9a39

[FairUser]

Literally just got these

05/02/2011 22:00, 2a07e960, accepted
05/02/2011 22:00, fe7439af, accepted
05/02/2011 22:01, 2a07e960, invalid or stale
05/02/2011 22:01, fe7439af, invalid or stale
05/02/2011 22:01, 2a07e960, invalid or stale
05/02/2011 22:01, fe7439af, invalid or stale
05/02/2011 22:01, 2a07e960, invalid or stale
05/02/2011 22:01, fe7439af, invalid or stale

This is on a stock miner....no mods of any kind.
6 getworks were requested, and the answer found were repeats.

[FairUser]

I'm still seeing several invalid stale hashes being submitted.
Any idea as to why?

Maybe because they are really stale? http://blockexplorer.com/block/00000000000018cf119be227dcf0d7403b20dc9b8fa0c3d6bc9022c65baf9a39

So getworks are now going stale even faster....thanks for clarifying.

[m0mchil]

Literally just got these

05/02/2011 22:00, 2a07e960, accepted
05/02/2011 22:00, fe7439af, accepted
05/02/2011 22:01, 2a07e960, invalid or stale
05/02/2011 22:01, fe7439af, invalid or stale
05/02/2011 22:01, 2a07e960, invalid or stale
05/02/2011 22:01, fe7439af, invalid or stale
05/02/2011 22:01, 2a07e960, invalid or stale
05/02/2011 22:01, fe7439af, invalid or stale

This is on a stock miner....no mods of any kind.
6 getworks were requested, and the answer found were repeats.

There are two ways to get something like this - first one is using ask rate of more than ~12 seconds with an overclocked 5870 (stock max -a is 10 seconds). Other one is network problems triggering resubmission of results - this mechanism is removed since last version. Since you said it happened with stock miner I vote for the latter. 

[Quantumboredom]

Hi. I'm trying to get this to work, and want to check it with the "testnet" I've heard about.

What I've done:
Followed the guide. After starting bitcon.exe -server and the .bat-file as described I get a cmd window with the hash speed showing.
I then copied the bitcoin.conf to %appdata%/bitcoin/testnet, ran bitcoin.exe -server -testnet and then launced the .bat-file as before. Again the hash speed is showing in a cmd-window, but after about 30 minutes with ~280000 khash/s I've still not gotten any messages about completed blocks. My impression was that that should happen very quicly on the testnet. What am I doing wrong?

Thanks for any help.

[Cryptoman]

The last time I looked, the testnet difficulty factor was around 350.  Using that number as a guide, 280 Mhash/s should yield a block on average every 1.5 hours.

[Quantumboredom]

Aye a couple showed up when I let it run for a while longer, thanks

Another question, it's ok to close poclbm.exe and bitcoin, correct? It isn't necessary to keep them running non-stop untill a block is solved?

[Cryptoman]

Both m0mchil's python program and bitcoind must be running continuously for mining to take place.  I have no idea how to run or monitor detached processes on Windows, but my guess is that you have to keep the command windows open.  Maybe someone with Windows experience will chime in here.

[Quantumboredom]

I think you misunderstood my question. I do keep both bitcoin.exe and poclbm.exe running at the same time, what I'm wondering is what happens if I restart the programs, or reboot my computer. Will I start again from scratch or does the mining continue where it left off?

[Cryptoman]

Finding a correct hash is a completely random event, and the probability depends only on the hash rate and the total amount of time dedicated to mining.  You lose a little time having to reconnect to the network and retrieve the latest transactions, but it's pretty insignificant.  A 280 Mhash/s rig turned on for 12 hours a day should perform the same as a 140 Mhash/s rig running 24 hours a day.

[BitLex]

Will I start again from scratch or does the mining continue where it left off?

Yes and yes.  
it's not that you're making any "progress" that could be lost,
you start from scratch with any single hash, like drawing lottery-tickets a few thousand/million times a second,
you either get a winning-ticket, or a loser. won't help you to keep the loser in your pocket.

[Quantumboredom]

Ok I understand, thanks for the help Cryptoman and BitLex