Topic: Bitminter client (Windows/Linux/Mac) - page 47. (Read 654616 times)

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.

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

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

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.

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


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.

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?


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?


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

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.

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

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

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.

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.

I ran your bfi kernel in fpgaminer's poclbm and it was giving me 144.828 to 145.259 and it updates once a second in a very stable way
but your software bounces between 141 and 148 not even after submitting a share, it's just never giving readings as consistent

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

Nice speeds Did you try starting all the GPUs at once? I've had reports of crashes resulting from doing that on Linux. I can't reproduce it on Windows, and my Linux machines only have 1 GPU.


Let me see what I can do...


It just flashes when you go into the red zone. The red zone should be 10% above what your GPU would normally deliver. The speedometer is adjusted for the specific GPU that is detected. But the "normal speed" for each GPU may be a little off - there are many GPUs and I probably don't have the right values for each one. Please report any GPUs that are not in the green zone even when running on stock frequenzy and voltage.

But yeah, if you are overclocking, then it is normal. I thought it was cool when I added it. But if it's annoying, I can remove it or make it optional.

Just tried the Bitminter software the other day, on windows 7 and linux..

with my 6970's im getting 426-437 under linux and 391-400 under windows 7

had 5 cards running on the linux machine using bitminter with no problems.

any chance of adding a option to auto-start certain miners, ie; have a check box for each one or something? im running a few different systems headless would be nice to have it just start up and go.

Does the red flashing light on the speedo just mean you are hitting 400+ or is that indicating something else?


Great Job!

Nice! Good to hear the speed improvements are working out.

I know, the two second average shown by BitMinter sometimes fluctuates a lot. I was thinking of putting in some sort of exponential moving average.

bitminter beta is the fastest miner for 5xxx cards right now, although it's kind of hard to compare because there is no 5 second average to look at, but it's about the same as cgminer for my card (which uses a modified phatk 2.2)

since the speeds update every second or something I have to mentally average them they go between 141 and 148

In the future I will release new changes as a beta release first before they go into the regular miner version. When you log into your account on the website there is a button to start the beta version of the miner. You can also start it from here:



Changes in the current beta:

• 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

Let me know if there are any problems.

Yes, the problem was only there for a few hours and produced just a few bombs. If you have 25% bombs there's probably something wrong.

Is the GPU overclocked? Getting hot?

Quick fix on the pool backend a few minutes ago. It would sometimes send out work that the new miner version did not like, which would result in miscalculations ("bombs" in the GUI). This is now fixed. Sorry if this caused you to think you had a hardware problem.

Some updates for the software today:

• The status bar (the only thing visible in performance mode) now has a start/stop button and shows some information about proofs of work. Much requested features - sorry it took so long!
• Upgraded to latest version of Steel Series. The power meter tick marks looked weird for some CPU models in the old version - this looks better now.
• Better error handling when reading settings (currently names+password to log in). Some users got a blank login window with nowhere to enter name and password. I'm not sure what causes this, but at least now the login window should be usable. Please let me know if your saved name+pass disappears and/or you get error messages.
• Bug fix: when stopping a device, it would burn through a bunch of work units (you could see the "work units started on" counting up). This has been fixed.

You will get the new version the next time you restart the miner.


I can't reproduce this. Could you try starting it from the command line with the exact same environment you run other miners, and as the same user? To start the miner use this command: javaws http://bitminter.com/client/bitminter.jnlp