Topic: Bitminter client (Windows/Linux/Mac) - page 46. (Read 654946 times)

Setting it to low priority isn't going to help the fact that you're burning tons of CPU heat with a runaway CPU process performing no work... great way to screw over your power bill is letting your CPU run full speed when the GPU is doing all the work. At the very least, set a power profile with a maximum CPU state of 50% in Windows 7 power options just for mining.

But the proper fix is to untangle the cause of the CPU usage. BitMinter doesn't have aggression options (just a vague "delay period" option that doesn't conceptually tie in well with "Aggression" IMO), but most others do. You can feed any "aggression" setting you want at it, but if you go "over your limit" on what the GPU can actually process, you end up generating CPU usage which is the result of trying to feed too much work to the GPU at once. In Phoenix, try adjusting the "AGGRESSION=" parameter somewhere between 5 (uber low-end card) and 12 (uber high-end card) to see what setting just barely gets phoenix.exe to get you 0-5% CPU.

Its the AMD drivers (though nvidia drivers are not better, at least on linux)
Im now running an 5850  on the same old Pentium 4 and my CPU load is pretty much zero with bitminter. Im using (I think) catalyst 11.3. This is on ubuntu, but the problem is the same as on windows, so try grabbing some old ati drivers.

Because of the way the OpenCL drivers work you get one core at 100% for each GPU on nvidia and on AMD with more than 1 GPU in the system. If you use only a single AMD GPU, it may be possible without one core getting 100% usage.

Apparently it's possible to avoid the problem on nvidia if using CUDA instead of OpenCL, I believe there you can choose to busy-wait (causing 100% usage on a core) or not. Haven't looked into CUDA yet, though.

Edit: When I say 'core' here I mean CPU core.

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.

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.

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://bitcointalksearch.org/topic/further-improved-phatkdia-kernel-for-phoenix-sdk-26-2012-01-13-25860
And the line:
C:\Users\Falcon\Desktop\phoenix-orig\phoenix.exe -u http://FalconFour_Miner:[email protected]: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

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.

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

+1

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?

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.

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

Welcome on the team!

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