GUI mining - updated Dec 3 with 7970 bugfix, also supports Stratum!

[chaud]

after 10 minutes of no activity / no connection - play an alarm (make it optional, the length of time configurable and the sound/music play mp3 + wav files with 1 default one included in the app)

Forget the alarm, just kill off the old miner process if it is still around and restart. Phoenix keeps stopping for no reason and I keep losing mining time.

[1714314654]

1714314654

[1714314654]

1714314654

[1714314654]

1714314654

[short]

please make a linux version of this preferably that would work with linuxcoin

I'll copy that. Besides that, great piece of work so far!
 
People, donate where donation is due!!



cheers,

short

[becoin]

For now, most suitable version of bitcoin client for windows is  0.3.20.

I've installed older version 0.3.21 and then tried 0.3.20. Message for problem connecting to bitcoin RPC disappeared. It is showing the correct Mhash/s rate, but it is also showing 'Difficulty 1 hashes: 0'. Isn't it supposed to show the correct difficulty for current block?

Thanks again for help.

[Coinbuck @ BTCLot]

Phoenix and the normal OpenCL miner are consuming 25% of my CPU while mining a CPU !!

[Nachtwind]

Hi, Good work on your program :0)

Have to bump my "problem":

Code:

2011-06-09 22:01:01: Listener für "btc":                                                                                                                                                                               [09/06/2011 22:01:01] Server gave new work; passing to WorkQueue
2011-06-09 22:01:33: Listener für "btc":                                                                                                                                                                               [09/06/2011 22:01:33] Server gave new work; passing to WorkQueue
2011-06-09 22:01:34: Listener für "btc":                                                                                                                                                                               [09/06/2011 22:01:34] Result 0000000030e7a466... accepted
2011-06-09 22:02:06: Listener für "btc":                                                                                                                                                                               [09/06/2011 22:02:06] Server gave new work; passing to WorkQueue
2011-06-09 22:02:07: Listener für "btc":                                                                                                                                                                               [09/06/2011 22:02:07] Result 0000000014d660b7... accepted
2011-06-09 22:02:16: Listener für "btc":                                                                                                                                                                               [09/06/2011 22:02:16] LP: New work pushed
2011-06-09 22:02:16: Listener für "btc":                                                                                                                                                                               [09/06/2011 22:02:16] Server gave new work; passing to WorkQueue
2011-06-09 22:02:17: Listener für "btc":                                                                                                                                                                               [09/06/2011 22:02:16] New block (WorkQueue)
2011-06-09 22:02:19: Listener für "btc":                                                                                                                                                                               [09/06/2011 22:02:19] Server gave new work; passing to WorkQueue
2011-06-09 22:02:48: Listener für "btc":                                                                                                                                                                               [09/06/2011 22:02:48] Server gave new work; passing to WorkQueue
2011-06-09 22:02:52: Listener für "btc":                                                                                                                                                                               [09/06/2011 22:02:52] Result 000000009e62c6a7... accepted
2011-06-09 22:03:03: Listener für "btc":                                                                                                                                                                               [09/06/2011 22:03:03] Result 00000000fe0c49b8... accepted
2011-06-09 22:03:20: Listener für "btc":                                                                                                                                                                               [09/06/2011 22:03:20] Server gave new work; passing to WorkQueue

Somewhat my console is full with these signs... no matter what i replace or do.. (on cmd it doesnt show up though)

Then i have a small feature to ask for:
Can you do "schedules"? Like having from 1am to 8am running profile a, from 8am to 3pm profile b and so on? I would really love to set my agression settings depending on my sleep/university/work/others automatically...

[FuzzyCoins]

I notice that when I have multiple pools defined (as backup pools) and when one of the primary pools goes down (GUIMiner reports "Connection problems"), the total hash rate down in the lower right corner retains the last seen hash rate from the pool connection that went down instead of zeroing it out.

Or in other words if I have two miners defined and one is normally running at 200 Mhash/sec and the other runs at 1Mhas/sec (lower priority), my total hash rate is reported as 201Mhash/second as expected.

If the first miner goes down with connection problems and the second minor ramps up to 200 Mhash/sec, the total reported is like 400Mhash/sec. It appears that during "connection problems" GUIMiner still thinks the downed miner is running at full speed.

Edit: 2 typos.

[mjsbuddha]

Just adding my name to the list of people that desire some sort of fail over support.

[um0rion]

I get a connection error on one of my cores about once a day, something to restart a miner that gets stuck would be fantastic. Also, Slush added an address to mine at... api.bitcoin.cz.

Any plans to release a new version?

[dishwara]

Hey everyone, I am putting out a BETA release to try and fix the weird "logo.ico" error a couple people reported. It also has a test version of CPU affinity built in, so if that's a feature you were waiting for you can test that out too for me

The BETA version is here:

GUIMiner BETA 20110610

If this resolves the logo issue and there's no bugs with the affinity, I'll do a full release of it in the next couple days.

I tired the BETA version & it works fine.
The affinity works perfectly.
I am using BETA in 2 systems. one with single miner & another with 3 miner. Both working fine for the past 3-4 hours with out any problem

[Kiv]

Thanks for the report, I'll fix this when I get a chance.

I notice that when I have multiple pools defined (as backup pools) and when one of the primary pools goes down (GUIMiner reports "Connection problems"), the total hash rate down in the lower right corner retains the last seen hash rate from the pool connection that went down instead of zeroing it out.

Or in other words if I have two miners defined and one is normally running at 200 Mhash/sec and the other runs at 1Mhas/sec (lower priority), my total hash rate is reported as 201Mhash/second as expected.

If the first miner goes down with connection problems and the second minor ramps up to 200 Mhash/sec, the total reported is like 400Mhash/sec. It appears that during "connection problems" GUIMiner still thinks the downed miner is running at full speed.

Edit: 2 typos.

[Kiv]

A new version of the miner is available; I've updated the download link on the first post, or you can get it here:

    guiminer-20110614.exe (self-extracting archive)


Changes:

- Slush's pool moved from mining.bitcoin.cz to api.bitcoin.cz. If any miners on slush's pool cannot connect, you should delete and re-create the worker to make sure it's using the new address.
- Add CPU affinity support, meaning miners can be assigned to a specific CPU core. Users seeing the 100% CPU usage when mining with OpenCL due to buggy drivers can reduce their CPU usage by allowing the miner to only run on a specific core.
- Fix error about missing logo.ico.
- New Italian translation, big thanks to MasterHunterHD for contributing this.

Thanks to all other translators who submitted updated translations to me, I'm afraid I added even more text in this version for you.

For everyone asking about Linux support: for the adventurous you can try running it from source on GitHub. The only thing stopping me now is finding a nice way to install it; it doesn't seem like I can nicely bundle everything together in an EXE like I do on Windows. Maybe I can somehow include it with LinuxCoin (though I don't know what that is right now). Any Linux gurus that could help me out with this would be appreciated

For everyong asking about restarting support: I was thinking of doing it so if there were no accepted shares in X minutes (X being configurable per miner) it would restart the miner.

For switching to a backup pool support: just using the -f flag to set priorities as described in the FAQ works just fine for me. I don't particularly want to do something elaborate unless there's a convincing case. If people can't figure out how to use the -f flag then that's actually a documentation bug and I should fix that

[becoin]

A new version of the miner is available

Kiv, thanks for the great work you do for all BTC enthusiasts.

Yesterday, however, something very strange happened. I was using guiminer solo to mine and despite very low hash generation power (about 1.5 Mhash/s) a block was solved and the corresponding single share accepted. But I didn't get the 50 BTC on my bitcoin balance... This has happened somewhere in between blocks 130798-130805. Could you please help explain what went wrong? See below screen shots I made:



---



Thanks for taking the time to have a look at it.

[stellan0r]

A new version of the miner is available; I've updated the download link on the first post, or you can get it here:

For switching to a backup pool support: just using the -f flag to set priorities as described in the FAQ works just fine for me. I don't particularly want to do something elaborate unless there's a convincing case. If people can't figure out how to use the -f flag then that's actually a documentation bug and I should fix that

Thank you for the Update!
Regarding the -f support, I hope I did understand right that for using phoenix miner I have to use the AGGRESSION= setting instead. But if I do so, if a miner with a high aggression (like 13 or 14) fails because the pool goes down, and my backup miner has aggression <10, that one goes nowhere near 100% hashing power when the "master miner" stops working.

Any ideas? (except switching to opencl miner instead of phoenix  )

[chaud]

For everyong asking about restarting support: I was thinking of doing it so if there were no accepted shares in X minutes (X being configurable per miner) it would restart the miner.

Yes please, that would be great.

[markietalkie]

Linuxcoin seriously needs this.  Could this be installed via Synaptics in the future?

[Kiv]

Hi becoin, in this case a block was not actually solved and thus you didn't get the 50 BTC. What is shown there is a "difficulty 1 hash" being reported, which is analogous to a share being reported in a pool. Just as a small fraction of shares are valid solutions to a block, a small fraction of these hashes are valid solutions to a block.

In the case of a block being solved it would show "Blocks: 1" in the miner's tab.

Sorry to get your hopes up on winning the 50 BTC lottery I am not sure if I should re-word the terminology since I think it's quite confusing, but I don't know what to call it instead.

A new version of the miner is available

Kiv, thanks for the great work you do for all BTC enthusiasts.

Yesterday, however, something very strange happened. I was using guiminer solo to mine and despite very low hash generation power (about 1.5 Mhash/s) a block was solved and the corresponding single share accepted. But I didn't get the 50 BTC on my bitcoin balance... This has happened somewhere in between blocks 130798-130805. Could you please help explain what went wrong? See below screen shots I made:



---



Thanks for taking the time to have a look at it.

[becoin]

What is shown there is a "difficulty 1 hash" being reported, which is analogous to a share being reported in a pool.

Exactly. Which means 'difficulty 1 hash 1' is analogous to 'shares 1 hash 1'... And this is precisely what we see on 'Summary' tab - Accepted 1 (1). There is no point in accepting 'Difficulty 1 (1), of course.

Just as a small fraction of shares are valid solutions to a block, a small fraction of these hashes are valid solutions to a block.

I don't get this at all.

There is only one valid solution to a block, not many. Whatever small they are, shares are always part of a valid solution to a block. Otherwise, they wouldn't be shares at all, because they would be shares of zero!

This explanation is rather unconvincing, Kiv. Sorry.

[Kiv]

There is only one valid solution to a block, not many. Whatever small they are, shares are always part of a valid solution to a block.

That's incorrect. There are a large number of solutions to any given block. For a given difficulty, there is a target hash value and all hashes smaller than this target value are valid solutions to a block. If you look at the Bitcoin Calculator you can enter any difficulty and see the corresponding target value.

Notice that the lower the difficulty, the higher the target value. The higher the target value, the more numbers are smaller than the target and therefore the easier it is to find a solution. I encourage you to play with the calculator until you're sure you understand how this works, because it's key to understanding what is happening in your case.

Now, a share is the same thing as a difficulty 1 hash: it is a hash that would be a valid solution to a block if the difficulty was 1. In other words, it's a hash value smaller than 2.695953529101131e+67. Let's say your miner crunches some data and comes up with a hash of 1e+65. This would be a valid solution if the difficulty was 1 since it's smaller than that target. But it's not small enough to be a valid solution at the current difficulty of 877226, which has a target value of 3.073269009644151e+61. This hash is useless to you except as reassurance that your miner is working correctly.

Say you then come up with a hash of 1e+60. This is valid at difficulty 1 and also at difficulty 877226 and is a valid solution to the block. This earns you 50 bitcoins and a fanfare of trumpets.

From this example I hope you can see that a share/difficulty 1 hash is either a valid solution to a block, or it is utterly useless. Shares never "combine" to solve a block and no number of non-winning shares are of any value.

You may be wondering why pools even collect shares if most shares are worthless and cannot be combined in any way. The reason is simple: the fact that you are submitting shares to the pool is proof that you're really trying to solve the block and not just freeloading. A faster machine will generate more shares in a given period of time and therefore deserve more credit when one share actually happens to be valid.

I don't want to derail this topic discussing the technical details of mining, so if you're still confused let's move this to a separate topic

[trippp]

For switching to a backup pool support: just using the -f flag to set priorities as described in the FAQ works just fine for me. I don't particularly want to do something elaborate unless there's a convincing case. If people can't figure out how to use the -f flag then that's actually a documentation bug and I should fix that

First of all, I would like to thank you for putting so much work into this. Thank you!

On the issue of backup pool support, I would love if it was implemented into the GUI. I know how to use the -f flags, but while that technique works, it's far from perfect. Some of the issues are:

• If I set one priority really high and another priority really low, there's still a few (fractions of) MH going into the low-priority pool. These MH are wasted. If I want to be really safe and use a chain of five or so pools, this waste grows even bigger.
• If the primary pool fails and the low priority pool kicks in, it still won't receive the same amount of MH as the primary pool did. Since the low priority pool has a lower priority not only in regards to the other pool but also to the whole operating system, the speed goes down a bit.

[gboytazzz]

hey i keep getting this message "problem communicating to bitcoin" when i click the start mining button any help would greatly be appreciated