I'm still not sure what this suggests, though. Perhaps a network issue that one instance recovered from more gracefully than the other? I'll be sure to take better notes of what's going on if it happens again.
Yes, indeed it sounds like there was a network problem and afterwards your friend's instance was alright but yours didn't recover properly. I'd be very interested in more info to be better able to hunt down any bugs that may be causing this. If you or someone else experiences this again, try if you can to get me a cut'n'paste of the log, a description of how the miner is behaving and anything you know about what lead up to it. |
|
|
|
|
Bitcurex arrives to up the ante. In addition to the 5 BTC for the winner there will also be a Bitcurex card ! If you want to cash out some of the coins you minted, this is the perfect way to do it. Details above have been updated.
The race is on !
|
|
|
|
The race is now over. Winner: Entropy  BitMinter is approaching 1000 bitcoin blocks. Whoever creates block no. 1000 will receive a Bitcurex card and 5 BTC. The Bitcurex card is a VISA card you can use to cash out from the Bitcurex exchange after selling bitcoins. Block list available here: http://bitminter.com/blocksBitcoin block at height 199506 by amazingrando is the pool's 988th BTC block. We'll ignore the stale/orphan status, all blocks on the list will count. A thousand blocks is a nice milestone for the pool. Thanks to btc196 for suggesting a competition. May the best minter win! The 5 BTC will be deposited directly in the winner's BitMinter account. For the Bitcurex card we need to get in touch with the winner. Please make sure you have an email address registered on your BitMinter account (see the "account details" page). The home stretch:gigavps got block no. 989 WhitePhantom got block no. 990 Entropy got block no. 991 Entropy got block no. 992 dooferorg got block no. 993 geeojr got block no. 994 btc196 got block no. 995 mybtc1 got block no. 996 micheletegon got block no. 997 bitcoinminer got block no. 998 gazza got block no. 999 Entropy is the winner, block no. 1000 on the BitMinter pool !
|
|
|
|
At height 199506 amazingrando hit bitcoin block no. 988 for BitMinter. Quick competition: 5 BTC prize for the miner who creates the pool's 1000th block. Stale/orphan status ignored. EDIT: Block no. 1000 compo thread: https://bitcointalk.org/index.php?topic=110579.0 |
|
|
|
Is the BitMinter client only suitable for use with the BitMinter pool or can it be used with other pools?
It works only on the BitMinter pool at the moment. Support for backup pools most likely coming in the next version. |
|
|
|
Strange. I just decided to glance at my MiniRigs before going to bed and I found that they had not been mining for 3/4 of a shift. The BitMinter client showed errors about having run out of work. I normally have about 800-1200 work units queued, but it was only showing 200-ish. After I closed BitMinter and relaunched it, they started mining as usual.
This has never happened before. Doc, do you suppose a change in version 1.3 could be the culprit, or is it more likely an inexplicable fluke?
With 200 work units queued they were mining, right? If there was a network problem for a while they should pick right up again after connectivity returns. At the time they were idling, did you also get network errors, like messages about connections timing out? |
|
|
|
DrHaribo, what's your plans about implementing Stratum protocol?
I was going to implement getblocktemplate. I don't see the point in also having Stratum. But if some miners support one and some the other, maybe I will need to support both on the server. Same with the client (after adding support for backup pools) if some pools use getblocktemplate while others use stratum. It's always fun to have two standards for the same thing.  |
|
|
|
ill be shutting my gpu's down sometime this week, after i get one more Jalapeno ordered. it will be nice to get a small power bill again  i think ill leave one rig running and set the donation to 100% though or the good Dr could set up another worker and ill let it mine for him  Thanks - much appreciated You can just set 100% donation and leave the last one mining. Remember to change the setting when the Jalapenos arrive. Alternatively the test account used by the test edition of the BitMinter client ( http://bitminter.com/test) will donate everything to the pool. Username Test, workername Test, password Test (note the capital letter everywhere). Doc, this change is awesome. Starting up BitMinter for my two mini-rigs is a single click now instead of spending 3-4 minutes manually re-adding FPGAs as they drop offline over and over during the startup. Thanks!
Happy to hear this works better for you. Fefox requested this feature because of the issue you describe. Not sure why it would be so messy starting all devices at the same time. But as long as this works better... Also note that automatic rescanning for FPGAs is back in the options. This in combination with automatically starting devices when they connect (also in options) will help keep things running smoothly even if a device should drop off and come back. |
|
|
|
|
Every once in a while something weird happens with the new server version causing some requests to get processed very slowly. This was causing rejects above 1% for many users.
I have reverted back to the old server version to ensure trouble-free mining. I will work on fixing this and rollntime will be back soon.
Sorry for the inconvenience.
|
|
|
|
BitMinter client v1.3.0 just released: https://bitcointalk.org/index.php?topic=31163.msg1196221#msg1196221Also, some users are having more rejects after rollntime was switched on. If you are having problems, please let me know which miner you are running and how many rejects you get (over some time, like a long block). Then we can look into improving it. Rejects on the namecoin side are ridiculously high now. I suspect this is because of a combination of rollntime plus some miners ignoring long polls with namecoin block changes. They will continue using rollable work that is stale on the namecoin side perhaps several minutes after a namecoin block change, which will result in many many rejects. When using GPUmax this is exactly what happens with the namecoin rejects, as GPUmax only observes bitcoin block changes. Not sure it's worth bothering with much, though, as namecoins are not worth much anymore. Edit: Some rejects were caused some hours ago by restarting the mining backend to get the new version up and running. That's normal and nothing to worry about. Bad thing is if you are still getting a high reject percentage. |
|
|
|
BitMinter client version 1.3.0 is out. Thanks to everyone who helped test the beta releases! Changes from 1.2.0 to 1.3.0: - Support Icarus FPGA devices
- Fix "class not found" bug on Raspberry Pi
- Detect CPU model on Raspberry Pi, and hopefully other ARM systems.
- Implemented getwork extension: midstate (calculate midstate on client instead of server, reducing server load)
- Implemented getwork extension: rollntime, with "expire" support (get more than 1 work unit in a single request to the server)
- Dynamic work queue size
- Expire proof of work if undeliverable for 15 minutes
- Expire (non-rollntime) work unit if unprocessed for 5 minutes
- Count X accepted/rejected when the work difficulty was X (X is rounded down)
- Bugfix: don't count as device miscalculation when a proof of work exceeds difficulty 1 but not the (above 1) difficulty given by the server
- Only scan USB ttys on Linux - prevents many error messages about ttySxx.
- Bugfix on Linux: devices detected by a full probe and devices added through probing a specified port were named differently and it was possible to add the same device twice.
- Sort devices (by name) when dynamically adding external devices to device display.
- Default to compact display for anything but the bottom "total" display.
- Do not start CPU when clicking "total" display's start button for the first time after starting the program, unless it is the only device. Would previously start all visible (non-hidden) devices.
- Added X-Mining-Hashrate HTTP header to report hash rate to server.
- Staggered start of devices when multiple devices are started with the button on the status line or the "total" display's start button. Should give a smoother start up of (multiple) BFL minirigs.
- When going to performance mode remember the old window size and restore it when going back to detailed mode.
- Re-enabled comm port interval scanning (FPGA section of config) Can be used to automatically pick up FPGAs when plugged in
- Fixed bug that could cause "probe all ports" to stop working and report "no serial ports found"
- Changed regular poll interval to 20 ms (was 10) for BFL default config. Saves 5-10% CPU usage on testsystem with 2 BFL minirigs, no performance loss
- Changed hammering poll interval to 5 ms (was 1) for BFL default config. Saves 10-15% CPU usage on testsystem with 2 BFL minirigs, < 0.1% perf. loss
- Hopefully works on OpenBSD and FreeBSD as well now. FPGA only, untested.
- Recognize more AMD E-series CPUs
Try it out:  If you have issues with 1.3.0 then you can still get the previous release (1.2.0) at http://bitminter.com/client/1.2.0/bitminter.jnlpI'd be interested in hearing from anyone mining on Raspberry Pi, or with OpenBSD or FreeBSD operating systems. |
|
|
|
Thanks, squid, I always wanted to be a "boss". Shermo, yes, something like that. New server software is now running, with rollntime support for all miners as long as you have a bit of hashrate and stay above very low efficiency. Kano explained earlier how you see this in cgminer: https://bitcointalk.org/index.php?topic=27062.msg1175441#msg1175441Also you should see reduced network traffic from mining. This new version splits requests into two types. Miners with OK efficiency are served by 7 CPU cores as quickly as possible. Miners with very low efficiency are served by a single CPU core. This would be CPU miners, buggy miner programs and DoS attackers. Normally the slow queue will be fast enough, but if there are too many requests there then they will slow each other down. Unless it is very extreme it should not affect the rest of the pool. The new version is running smoothly. GPUmax runs and other big miners are at high efficiency. |
|
|
|
|
Pool is running as normal again.
I put the new version into production and it didn't run very well so I switched back. Have located an issue that I'm looking at now. Unfortunately it's very difficult to test parallel execution of code. Perhaps in the future I can set up a test server and get enough miners testing there to lure out race conditions and other nasty bugs that are difficult to test for.
Sorry for the momentary server hickup. Back to our usual mining.
|
|
|
|
what is wrong with the statistics?
I restarted the backend and they started over blank. Only lasts a couple minutes after a restart. |
|
|
|
|
Disk change went well, everything back up and running again.
|
|
|
|
|
Remember downtime today for a disk change on the server. 12:00 UTC.
I hope the techs do a better job at it this time.
Edit: server now down to have its disk replaced.
|
|
|
|
Just wondering if its normal to use that much CPU?
Yes, unfortunately. On nvidia and on older AMD drivers you'll have one CPU core doing 100% for each GPU you are mining on. If you have multiple GPUs you can reduce this problem by forcing the processes/threads onto the same CPU core. Later AMD drivers should function without this silly "busy waiting". Also I'm not sure if you keep a database of what settings are best for different cards? But for the FX 580, a work item size of 64 yields much better results than 128 default.
No, it just tries to be smart with the default settings for BFI_INT and vectors. Work size is a bit unpredictable, so I left it at 128 default for any GPU. |
|
|
|
Thanks, WhitePhantom, for your input and for supporting the pool all this time. The plan is to first add a worker/personal API with API keys, so that you can use existing third party websites and cellphone apps for supervising workers. Later I will build an email notification system into the BitMinter website. I was thinking of making the worker API a perk that requires 0.5% donation. Currently I need 6 days without orphan blocks to get enough donations to pay for 1 orphan block. It would definitely be a good thing to get donation levels up a bit. On the other hand, workers stopping reduces the pool hashrate, which I don't like. Perhaps the solution is to require a donation for the API but have a primitive email notification on the website that is free. The basic stuff free and the good stuff cheap is the idea. About monitoring individual devices on the same worker separately, I guess this could be done for any miner by detecting a lower hashrate that persists over time (not just the usual ups and downs caused by randomness). I could perhaps also build something into BitMinter client, I'll look into it. Currently development has been delayed a bit. The server as you know has been having hardware issues, and I've also been attending the JavaZone conference. The plan right now, in order of priority: - Finish the new server system with full rollntime support (almost done)
- Worker API (a simple version 1)
- Variable difficulty
- Support for backup pools in BitMinter client
|
|
|
|
|
Show Posts
