Bitminter client (Windows/Linux/Mac)

[DrHaribo]

so I guess it's averaged in some kind of way?

Probably. I haven't been able to get stable values when measuring OpenCL performance over short timespans.

I updated the beta of the miner just now:

• 10 minute timeout on longpoll connections. Should hopefully fix the problems for those few who get a very high number of stales. I suspect it is because you have a router that kills idle connections after only a few minutes.
• Get rid of Java login window if you mistyped name or password. A failed login should now re-display the BitMinter login window.
• Mining speed shown is now an exponential moving average. Should give more stable speed measurements, but may need more tweaking.

If you had problems with many rejected proofs of work or speed measurements varying a lot, please let me know if this helps.

[1714007016]

1714007016

[1714007016]

1714007016

[1714007016]

1714007016

[DrHaribo]

BitMinter client v1.0.0 released.

Changes:

• Faster on Radeon GPUs, especially 5xxx series (still working on improving this further)
• Minimize to systray option (under the "settings" pulldown menu)
• Remember settings for systray and verbose logging between sessions
• 10 minute timeout on longpoll connections. Should hopefully fix the problems for those few who get a very high number of stales. I suspect it is because you have a router that kills idle connections after only a few minutes.
• Get rid of Java login window if you mistyped name or password. A failed login should now re-display the BitMinter login window.
• Mining speed shown is now an exponential moving average. Should give more stable speed measurements, but may need more tweaking.

All changes have been tested a while as beta, so should be stable. Regular and beta on the server are now the same (v1.0.0) until a new beta is ready.

Edit: To get the latest version, simply restart the miner.

[FalconFour]

Wow. Your client (and hence, pool) is definitely the sexiest, least irritatingly/needlessly-complex client I've seen yet. Mucho kudos! And for that, here, have my miner, for what it's worth; the 211MH/s on my dandy 6770 oughtta do some good

Couple things I've noticed since I started using it:

• The Java launcher sucks ass. For the unfamiliar, or those without Java installed, the "jnlp" format is just an "unknown file", and without a hint on the page saying "this is a Java web application link file", or providing an alternate launcher, it prevents it from presenting a truly "polished" appearance.
• Setting the GPU "relax period" too high, say 500ms, on my miner box, works OK but silently shoots CPU usage through the roof. CPU usage translates directly to excess wasted power/heat, so perhaps a slider could be put here instead. The client, being as robust as it is, could probably auto-detect the interval where CPU usage begins to rise - likely caused by trying to update the display quicker than the GPU comes back from its loop(s). Personally, I'd rather have an unresponsive desktop and a fast miner using 0% CPU, than a zippy desktop without a monitor attached!
• The graphics are awesome.
• The UI design is awesome.
• Unlike other miners, it properly detected the 128-bit memory bus in my 6770, and accordingly set the work size to 128. Other miners have defaulted to 256. This will certainly result in amazing performance boosts if this auto-detection continues to work properly for other new users, many of whom - not active users here - don't know the difference.
• Speaking of which, if there is a known issue with the driver/OpenCL setup on the miner PC (like running Catalyst 11.8 or something), and it's getting poor performance/high CPU, bring it to the user's attention and I can guarantee you'll have the most efficient pool and most popular client around in no time

Just my "kinda putting on a black turtleneck and jeans while I say this" sort of friendly tips The thing looks incredible, and as long as nothing terrible goes wrong (like "hey, why the hell is my balance still 0?" or the like - haven't run it long enough to see, of course), I hope to run this for a while

[aldiyen]

• FAST - the very fastest on Radeon 6970/6990 and GeForces

Speed comparison 2011.07.08:

AMD Cayman (Radeon 6990), overclocked to 935 MHz, Catalyst 11.6:
- 419 mhps BitMinter (BFI_INT, vectors on, worksize 128, 50 ms intervals)
- 414 mhps DiabloMiner (-f 20 -v 2 -w 128)
- 410 mhps Phoenix (-k phatk BFI_INT VECTORS FASTLOOP AGGRESSION=7 WORKSIZE=128
                    and Ma()-optimization on phatk kernel)

NVIDIA GTX 580, overclocked to 812 MHz, GeForce 275.33 drivers
- 134 mhps BitMinter (vectors off, worksize 64, 50 ms intervals)
- 132.3 mhps Phoenix (-k poclbm WORKSIZE=64 VECTORS FASTLOOP AGGRESSION=7)
- 33 mhps with DiabloMiner and Phoenix+phatk (with vectors on: only 13 mhps)

AMD Cayman on Catalyst 11.7 beta:
- 419.3 mhps BitMinter
- 416.5 mhps DiabloMiner
- 411.7 mhps Phoenix w/phatk

I don't see any source links. is your miner open-source? if not, how is anyone to know that the reported speeds, apparently showing it to be the fastest miner in existence, are accurate (other than possibly decompiling your java code, I suppose)?

-aldiyen

[FalconFour]

I don't see any source links. is your miner open-source? if not, how is anyone to know that the reported speeds, apparently showing it to be the fastest miner in existence, are accurate (other than possibly decompiling your java code, I suppose)?

-aldiyen

If you get paid, who the hell cares? Hash rate has been proven to be an inaccurate measure of actual work being done - I could hash the same numbers 200 million times a second and report 200Mhash/sec, but get no work done. Personally, I don't give two craps about the accuracy of the speed; the "client that uses the most efficient method available" will be getting 212Mhash/sec on my card, and that's what this one does. Couldn't care less if it's accurate or what client it's using under the hood, as long as it's working properly, performing work, and paying a proportionate amount to the work being done, I'm happy to use it.

There's good and understandable incentive to keeping the source code private. I'm happy as it is until there becomes a reason to care to see the source code, but as it is now, the argument of speed reporting is so weak, it's hardly even worth doing more than laughing at the idea.

[aldiyen]

If you get paid, who the hell cares? Hash rate has been proven to be an inaccurate measure of actual work being done - I could hash the same numbers 200 million times a second and report 200Mhash/sec, but get no work done.

If you were hashing the same numbers 200 million times, then your miner would be useless. For all we know, this BitMinter miner could be doing just that.

How, exactly, is hash rate an inaccurate way to measure miner speed? Some miners may report inaccurate speeds, but the number of nonces you actually calculate over a given span of time directly relates to how much work is being done. What other metric is there, valid shares submitted? That's a nothing more than reflection of your hash rate, but with more variance because there is an unpredictable element.

Even if what you say were somehow accurate, DrHaribo is boasting that his miner is the fastest, so if that's not relevant then why even make this post?

Personally, I don't give two craps about the accuracy of the speed; the "client that uses the most efficient method available" will be getting 212Mhash/sec on my card, and that's what this one does. Couldn't care less if it's accurate or what client it's using under the hood, as long as it's working properly, performing work, and paying a proportionate amount to the work being done, I'm happy to use it.

I'm not sure what you're trying to say here... Are you trying to say that because it reports the same hash rate as some other client, its reported hash rate must be accurate?

There's good and understandable incentive to keeping the source code private. I'm happy as it is until there becomes a reason to care to see the source code, but as it is now, the argument of speed reporting is so weak, it's hardly even worth doing more than laughing at the idea.

What, pray tell, is this good and accurate incentive to keep the source completely closed?

[DrHaribo]

If you were hashing the same numbers 200 million times, then your miner would be useless. For all we know, this BitMinter miner could be doing just that.

I don't think it would be creating blocks if that was the case.

What, pray tell, is this good and accurate incentive to keep the source completely closed?

I created the miner for the pool. It's meant as an incentive and bonus for mining in the BitMinter pool.

I wanted to create something different. I made my own miner, pool backend and web application. Of the three, the miner is the one that has been the most work so far. BitMinter is a major development effort. The goal is to create a new community and a new offering that stands apart from the rest. I didn't want to create yet another miner for DeepBit users, with 10 different forks on github. I also didn't want to create a new pushpool with exactly identical pools popping up like toadstools.

That is why BitMinter is closed source. This may change in the future. But for now, the strategy and goals remain the same.

About the hashrate, I never claimed to be fastest on all GPUs. BitMinter was fastest on a few GPUs. The speedtest in the original post is getting a bit old now, though. Most miners, including BitMinter, have gotten faster since then. Back when that speedtest was done, BitMinter was far behind the competition on Radeon 5xxx cards, and I never claimed differently. And more importantly, the miner showed clearly how slow it was. People would start the miner and go "damn this is slow on my 5970". It never showed an artificial hashrate. It's much faster on Radeon 5xxx now, but still useless on CPUs.

Although there are surely still bugs in my software, I never intentionally put anything incorrect or malicious in there. And I am not trying to deceive anyone. So far many are quite happy with the miner, and others mine at the BitMinter pool with different miners. All of them have been paid correctly and on time. I even gave them 5% extra out of my own wallet. I think we are off to a good start. But in the end, of course, who you trust with your bitcoins and your hashrate is up to you.

[FalconFour]

Good reason for keeping the source closed? Simple. If someone wants to screw up the pool, read the source and defeat any anti-cheating/anti-abuse measures. Or if someone wants to make a competing pool for their own profit, read the source and steal any tricks the client uses to be better. There's GOOD DAMN COMPETITIVE REASON to keep the source closed, and I'm damn happy to be part of a piece of work that does things "better". There's no need to "spread the love" around all pools that didn't do the work to make their own optimized code, or to allow others to leech off the hard work of others... open source code has a very important part in making things accessible, but once it's accessible, it's completely understandable why the "really good ideas" stay behind closed doors. Now if the project goes dead and the developer moves on to better things, that's when it should go open, so the good ideas aren't left to rot for waste, unused and forgotten. But while it's serving a competitive purpose, it's only fair that we get to enjoy the benefits of a good piece of software, without that developer being forced to share that competitive edge with everyone else. Make sense?

As for hash rate being inaccurate, I've had a client spin its wheels at 230+Mhash/sec and return no results. Why? My GPU timings were all muffed up, it was crunching hashes but it was crunching duplicates instead of real work. It wasn't returning any results but it also wasn't reporting any hardware errors it was running into. Without knowing about the hardware errors, the Mhash/sec values are worthless. It's ALWAYS the reported results that count, and I'd really love it a lot more if these miners would report results/minute or results/hour instead of Mhash/sec. It's the results/shares we get paid for in a pool, and if a CPU/GPU is too slow, someone could be mistaken into believing that 10Mhash/sec would return about 1/20th the payout of 200Mhash/sec on a GPU. It doesn't. Sometimes it pays more per Mhash. Sometimes less. It depends on the implementation. I've tested mining on a crapload of different combinations (and my 6770 is the only system that breaks over 20Mhash/sec, sadly), and that's the trend I see. I spent a whole night sitting out at my miner tweaking parameters and playing with different clients... and Mhash/sec is hardly an accurate measurement.

Now, don't get me wrong - I'm not saying Mhash/sec is *completely useless*, I'm saying it's accurate to a point - if the client is working properly, and it's returning results at a rate comparable to other clients, it's an accurate measurement of performance. But I'm saying there are factors that can cause Mhash/sec to be unreliable: perhaps a high Mhash/sec is resulting in a lot of re-calculations to get a single result, but a lower Mhash/sec from another configuration may be crunching through more bits of fresh data and returning more results. It's the number of results that should be smoothed and reported - a 10-minute average, perhaps - instead of raw "how many failures per second" are being reported. That's all. Since it's the results that equal Bitcoins, it should be the results that are measured.

[iopq]

If someone wants to screw up the pool, read the source and defeat any anti-cheating/anti-abuse measures.

you can already do this, it's java and it's not obfuscated

[FalconFour]

If someone wants to screw up the pool, read the source and defeat any anti-cheating/anti-abuse measures.

you can already do this, it's java and it's not obfuscated

So it's essentially open-source for those purposes, but somehow not for...

[conspirosphere.tk]

Very nice. I am getting a good output both with my 5870 @980/300 (415 Mhs), and my 5750 @880/300 (170 Mhs), so I am going to take part in your pool.

[DrHaribo]

Very nice. I am getting a good output both with my 5870 @980/300 (415 Mhs), and my 5750 @880/300 (170 Mhs), so I am going to take part in your pool.

Looks like I'm finally doing something right with Radeon 5xxx. 

Welcome on the team!

[DrHaribo]

Beta version 1.0.1 now available.



This is a bugfix release for improved stability. If noone reports new problems with this beta I will release these changes in the production version very soon as they fix some very annoying things.

Changes:

• Fixed memory leak that could cause problems after running for a long time
• Fixed "failed to map buffer" error that caused GPUs to refuse to start on some Linux systems
• Restart long poll connections every 5 minutes to appease even the most aggressive NAT routers that kill idle connections very quickly. This should fix the high stales that a few users were still seeing.

As always please report any problems you experience.

[P4man]

1.0.1 seems to work fine so far (testing on ubuntu). I just have 2 minor complaints/requests, but they apply to all versions of you app;

first of all, "break Interval" settings arent saved. Every time you launch the app, you have to reconfigure it again.

I also think the default shouldnt anywhere near 50, it makes the pc very sluggish to the point of being unusable. Im using 10 and that is much better, with afaict, zero difference in MH/s. I would actually want to set it lower even, but it wont let me set anything lower than 10. Can you set 10 as default, and allow lower values?

[conspirosphere.tk]

+1

I would actually want to set it lower even, but it wont let me set anything lower than 10. Can you set 10 as default, and allow lower values?

[P4man]

For some reason bitminter wouldnt launch on my machine, neither from the desktop nor the website (not the release nor the beta). Not sure if this is a problem with bitminter, but deleting my java cache solved it. Thought id mention it. For ubuntu users, its ~/.icedtea/cache

[DrHaribo]

BitMinter client v1.0.1 released.

Changes:

• Fixed memory leak that could cause problems after running for a long time
• Fixed "failed to map buffer" error that caused GPUs to refuse to start on some Linux systems
• Restart long poll connections every 5 minutes to appease even the most aggressive NAT routers that kill idle connections very quickly. This should fix the high stales that a few users were still seeing.

Just restart the miner to get the latest version.

I put your requests about settings (intervals etc) on my TODO-list for the next version.

[FalconFour]

Well, sad to say I've had to go back to Phoenix on my miner (freshly outfitted with a 1.0GHz Pentium-DC - originally 2.7GHz)... the CPU usage of javaw.exe (BitMinter client) is just too high to run. It starts off blazing up the GH/s dial with ~3-5% usage, then a couple seconds later jumps to 8%... then 14%... then 25% (which is 50% of one core/thread), and it stays there indefinitely. The GPU break period value seems to have no effect on anything anymore (responsiveness, CPU, etc). It also seems to be running slower than before by 2-5 Mhash/sec.

For the time being, I'm achieving higher Mhash/sec (about 213 as usual) with Phoenix with the modded phatk kernel from here:
https://bitcointalk.org/index.php?topic=25860.0
And the line:
C:\Users\Falcon\Desktop\phoenix-orig\phoenix.exe -u http://FalconFour_Miner:password@mint.bitminter.com:8332/ -v -q 2 -k phatkmod VECTORS2 DEVICE=0 AGGRESSION=9 WORKSIZE=128 BFI_INT=true FASTLOOP=false
(hey, if you want to mine to my credit, go right ahead )

213 Mhash/sec and 0% CPU usage on my 6770 with Catalyst 11.9 Beta

[P4man]

I also noticed bitminter runs like a dog on my rat-rig (pentium 4 3.4 GHz). Im not sure i understand why. On my Core 2 quad, bitminter's cpu load is basically zero (okay 2%). The P4 is of course slower, (God, it really is painfully slow lol) but not 50x slower.

No biggie, bitminter is more suited for desktop users than dedicated headless mining rigs, you want a command line app for those anyway, but I found it surprising it brought the P4 to its knees. Then again the P4 has an nvidia card for now, so maybe thats somehow causing it. Even with phoenix Im seeing 100% cpu load, but the system remains usable nonetheless, unlike with bitminter.  I guess Ill find out when my new 5850 arrives.

[conspirosphere.tk]

I started to have exactly the same problem: javaw sucking 30-40% of my cpu (AMD64 X2@3Ghz) and puter getting hogged and unresponsive (even lowering the priority of javaw). So now I am mining with Phoenix, which sucks 40% of my cpu too, and is slower than the bitminter client (403Mhs vs 420 from a 5870) but at least keeping it at low priority my puter remains snappy.

Anyone knows if it is normal a so high cpu load when mining, or there is some fix I could try?
I am now using official drivers 11.9 on XP32.

Well, sad to say I've had to go back to Phoenix on my miner (freshly outfitted with a 1.0GHz Pentium-DC - originally 2.7GHz)... the CPU usage of javaw.exe (BitMinter client) is just too high to run. It starts off blazing up the GH/s dial with ~3-5% usage, then a couple seconds later jumps to 8%... then 14%... then 25% (which is 50% of one core/thread), and it stays there indefinitely. The GPU break period value seems to have no effect on anything anymore (responsiveness, CPU, etc). It also seems to be running slower than before by 2-5 Mhash/sec.

For the time being, I'm achieving higher Mhash/sec (about 213 as usual) with Phoenix with the modded phatk kernel from here:
https://bitcointalk.org/index.php?topic=25860.0
And the line:
C:\Users\Falcon\Desktop\phoenix-orig\phoenix.exe -u http://FalconFour_Miner:password@mint.bitminter.com:8332/ -v -q 2 -k phatkmod VECTORS2 DEVICE=0 AGGRESSION=9 WORKSIZE=128 BFI_INT=true FASTLOOP=false
(hey, if you want to mine to my credit, go right ahead )

213 Mhash/sec and 0% CPU usage on my 6770 with Catalyst 11.9 Beta