Eloipool locked up while I was AFK and nobody bothered to call - I guess with continuous uptime for 2 months we all just assumed it was stable  What happened in detail was, epoll returned that a socket was writable, but then actually trying to write to it blocked. This was a (miner-side) getmemorypool request, so I'm guessing maybe Python blocks until all the data is written, rather than just trying a single send(). To fix it, I set all the connection sockets to non-blocking, so they should never block under any circumstances. While I was in that code, I also added an attempt to write immediately when Eloipool decides to send data (rather than waiting to check if the socket is readable). There's a chance this may improve longpoll response times slightly. |
|
|
|
bitcoind and Bitcoin-Qt version 0.5.5 are now available for download at: bitcoind version 0.4.6 is now available for download at: bitcoind and Bitcoin-Qt version 0.6.0.7 are also tagged in git, but it is recommended to upgrade to 0.6.1. These are bugfix-only releases. Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr. BUG FIXES- Version 0.6.0 allowed importing invalid "private keys", which would be unspendable; 0.6.0.7 will now verify the private key is valid, and refuse to import an invalid one
- Verify status of encrypt/decrypt calls to detect failed padding
- Check blocks for duplicate transactions earlier. Fixes #1167
- Upgrade Windows builds to OpenSSL 1.0.1b
- Set label when selecting an address that already has a label. Fixes #1080 (Bitcoin-Qt)
- JSON-RPC listtransactions's from/count handling is now fixed
- Optimize and fix multithreaded access, when checking whether we already know about transactions
- Fix potential networking deadlock
- Proper support for Growl 1.3 notifications
- Display an error, rather than crashing, if encoding a QR Code failed (0.6.0.7)
- Don't erroneously set "Display addresses" for users who haven't explicitly enabled it (Bitcoin-Qt)
- Some non-ASCII input in JSON-RPC expecting hexadecimal may have been misinterpreted rather than rejected
- Missing error condition checking added
- Do not show green tick unless all known blocks are downloaded. Fixes #921 (Bitcoin-Qt)
- Increase time ago of last block for "up to date" status from 30 to 90 minutes
- Show a message box when runaway exception happens (Bitcoin-Qt)
- Use a messagebox to display the error when -server is provided without providing a rpc password
- Show error message instead of exception crash when unable to bind RPC port (Bitcoin-Qt)
- Correct sign message bitcoin address tooltip. Fixes #1050 (Bitcoin-Qt)
- Removed "(no label)" from QR Code dialog titlebar if we have no label (0.6.0.7)
- Removed an ugly line break in tooltip for mature transactions (0.6.0.7)
- Add missing tooltip and key shortcut in settings dialog (part of #1088) (Bitcoin-Qt)
- Work around issue in boost::program_options that prevents from compiling in clang
- Fixed bugs occurring only on platforms with unsigned characters (such as ARM).
- Rename make_windows_icon.py to .sh as it is a shell script. Fixes #1099 (Bitcoin-Qt)
- Various trivial internal corrections to types used for counting/size loops and warnings
Thanks to everybody who contributed code or helped test this release: Wladimir J. van der Laan Luke Dashjr Jeff Garzik Pieter Wuille Matt Corallo Philip Kaufmann Dwayne C. Litzenberger Timothy Redaelli freewil Gavin Andresen Chris Moore Patrick Schneider cardpuncher graingert |
|
|
|
He is not going to pay us what he owes us? I highly doubt ARS would do that...
This is a problem with SMPPS, not the pool op being a crook. Yes and no. It's a problem with him apparently giving people the impression that it was owed in the first place. |
|
|
|
[quote author=Hpman link=topic=78192.msg881895#msg881895 date=1336121371]checking for LIBCURL... no
checking for LIBCURL... no
configure: error: Missing required libcurl dev >= 7.10.1
It seems that there is no libcurl.pc existing (for pkg-config) curl-config --version shows libcurl 7.22.0[/quote]It's part of libcurl4-gnutls-dev for Debian/Ubuntu. |
|
|
|
Is there some event that all USB initializations have been processed in Linux to check before cgminer is started? Other than grep-ing dmesg for ttyUSBx ? |
|
|
|
NEW VERSION: 2.4.0 - May 3, 2012Note this is an "upstream changes from CGMiner only" release.However, since BFGMiner has had reasonably accurate Icarus hash measurement from the start, my fix in CGMiner/BFGMiner 2.4.0 makes BFGMiner as ideally accurate as reasonably possible. This version has a fairly significant upgrade to the way networking is done, so there is a minor version number update instead of a micro version, but it has already been heavily tested. Human readable changelog:- A whole networking scheduler of sorts was written for this version, designed to scale to any sized workload with the fastest networking possible, while minimising the number of connections in use, reusing them as much as possible.
- The restart feature was added to the API to restart BFGMiner remotely.
- If you're connected to a pool that starts rejecting every single share, BFGMiner will now automatically disable it unless you add the --no-pool-disable option.
- Once a pool stops responding, BFGMiner won't keep trying to open a flood of extra connections.
- Failing BFL won't cause cgminer to stop; it'll just disable the device, which an attempt may be made to re-enable it.
- Hashrates on FPGAs are now reasonably accurate.
- Longpoll messages won't keep going indefinitely while a pool is down.
Full changelog:- Only show longpoll warning once when it has failed.
- Convert hashes to an unsigned long long as well.
- Detect pools that have issues represented by endless rejected shares and disable them, with a parameter to optionally disable this feature.
- Bugfix: Use a 64-bit type for hashes_done (miner_thread) since it can overflow 32-bit on some FPGAs
- Implement an older header fix for a label existing before the pthread_cleanup macro.
- Limit the number of curls we recruit on communication failures and with delaynet enabled to 5 by maintaining a per-pool curl count, and using a pthread conditional that wakes up when one is returned to the ring buffer.
- Generalise add_pool() functions since they're repeated in add_pool_details.
- Bugfix: Return failure, rather than quit, if BFwrite fails
- Disable failing devices such that the user can attempt to re-enable them
- Bugfix: thread_shutdown shouldn't try to free the device, since it's needed afterward
- API bool's and 1TBS fixes
- Icarus - minimise code delays and name timer variables
- api.c V1.9 add 'restart' + redesign 'quit' so thread exits cleanly
- api.c bug - remove extra ']'s in notify command
- Increase pool watch interval to 30 seconds.
- Reap curls that are unused for over a minute. This allows connections to be closed, thereby allowing the number of curl handles to always be the minimum necessary to not delay networking.
- Use the ringbuffer of curls from the same pool for submit as well as getwork threads. Since the curl handles were already connected to the same pool and are immediately available, share submission will not be delayed by getworks.
- Implement a scaleable networking framework designed to cope with any sized network requirements, yet minimise the number of connections being reopened. Do this by create a ring buffer linked list of curl handles to be used by getwork, recruiting extra handles when none is immediately available.
- There is no need for the submit and getwork curls to be tied to the pool struct.
- Do not recruit extra connection threads if there have been connection errors to the pool in question.
- We should not retry submitting shares indefinitely or we may end up with a huge backlog during network outages, so discard stale shares if we failed to submit them and they've become stale in the interim.
|
|
|
|
On bitcoin.org (registered by Satoshi), I would rather see the Satoshi reference client and perhaps an "other clients" link on the wiki. Bitcoin.org is naturally "default" no matter what anyone does/says. Giving a few clients priority just because they were based on Satoshi's original code just makes Bitcoin more centralized. Bitcoin.org should either have a directory of clients, or none at all. Gavin mentioned the latter as his goal (comparing it to BitTorrent.org), but I think at this stage, people will get lost if they can't find anywhere to go for a client on Bitcoin.org... You don't see people calling for Mozilla to link to other browsers. Rather than fighting over what a particular bitcoin.org page should look like, why not maintain an independently managed BitcoinClients.org website? Or GetBitcoinClient.org or somesuch.
Most of all, solve this problem in a distributed fashion, rather than stuffing it all onto bitcoin.org. Bitcoin.org, IMO, is the home of the "reference project" not the entire bitcoin community. Emphasizing that months ago was why the forum was moved to bitcointalk.org. If anything, this "reference project" should move off Bitcoin.org, to a site of its own, just like BitcoinTalk. |
|
|
|
Is it possible, that I can tell windows in the "cgminer.bat", that the window must be more big (fullscreen) for start? I think ye can do this with a PIF file. |
|
|
|
How is Ufasoft handling the hot-plugging? I'd *really* like to see that functionality in cgminer/bfgminer. It's polling every serial port every few seconds. Too ugly to put in any sane software, IMO. The real problem for CGMiner/BFGMiner is that the initialization has to happen in a certain order right now, so adding devices later isn't possible. Changing that will require some refactoring. I'd argue that this is very acceptable for a dedicated miner, even if it isn't for a non-dedicated miner, therefore I would like the same thing to be implemented in cgminer/bfgminer. It could be an option, such as -S aggressive or similar. I was considering a "-S all"; but in any case, hotplug support still requires a refactor of CGMiner's initialization. |
|
|
|
How is Ufasoft handling the hot-plugging? I'd *really* like to see that functionality in cgminer/bfgminer. It's polling every serial port every few seconds. Too ugly to put in any sane software, IMO. The real problem for CGMiner/BFGMiner is that the initialization has to happen in a certain order right now, so adding devices later isn't possible. Changing that will require some refactoring. |
|
|
|
|
OK, I wrote the code to do it and sent it to Con for CGMiner. Whether he merges it or not, it'll be in the next BFGMiner.
|
|
|
|
I went with the objective comparison table intentionally to avoid all this subjective arguing |
|
|
|
Error: Couldn't open socket for incoming connections (socket returned error 10047).
Same config as official Bitcoin 0.6.1 rc2.
Sounds like you didn't wait long enough for the old version to shutdown...? |
|
|
|
I'd like to request a protection of BFGMiner in case a BFL unit will be disconnected. If you unplug the usb cable the miner crashes as 'BFwrite failed'.
What would you expect it to do? BFGMiner isn't hotplug-capable (yet). Maybe it could disable the device... |
|
|
|
why are there three different versions being maintained? Because new features bring new bugs, and people who don't need those new features might not want to take that chance, especially in production environments (webstores, etc). |
|
|
|
Please, Luke, enlighten me. Unlike the later invention of hexadecimal, which only provides digits for base 8*2 (and hijacks them from the Latin alphabet), Tonal also provides pronunciations (an, de, ti, go, su, by, ra, me, ni, ko, hu, vy, la, po, fy, ton), fractions (forbidden in hexadecimal), and units for measurement of length (the Earth's circumference is 1,0000 millmeters), time/circles/compass (each day is divided into 10 tims), capacity (1 gall = 1 cubic meter), weight (1 pon = 1 gall of water), power (1 effect = 1 pon lifted 1 meter in 1 timmill), money (cents, shillings, and dollars), postage stamps, the calendar (ANuary, DEbrian, TImander, GOstus, SUvenary, BYlian, RAtamber, MEsudius, NIctoary, KOlumbian, HUsamber, VYctorious, LAmboary, POlian, FYlander, TONborious), temperature/heat (10 temps = 100 celcius), music, and abacus/stchoty. Where did you see Tonal (or Hex) in Bitcoins? As no government has adopted Tonal for currency, there has been a void. The day I discovered Bitcoin, it seemed obvious it could fill this void. I see that there is 21000000.00000000 Bitcoins, that's 16 numbers (is it a clue?)
But the units are decimals (0-9), so, where does it fits? Mathematically? (Something tells me that one or another type of measure will have non-round numbers).
I'd like to see examples of simple conversions so maybe I can grasp it. There are technically 2,100,000,000,000,000 actual items in the Bitcoin protocol. For whatever reason, Satoshi chose to set the unit of "BTC" at 100,000,000 of these. TBC, on the other hand, is exactly 1,0000 (tonal, remember) items. Therefore, 1 TBC = 0.00065536 BTC and 1 BTC = 55.1 TBC ( the wiki has a nice chart of units). Since the decimal and tonal units are fundamentally different, they can mostly function as independent currencies (for example, clients can detect whether a transaction is BTC or TBC based on its value) while still being directly exchanged between single-number-system users without confusion (since their client will only show the units they understand) and cooperating on mining efforts, adoption, etc. |
|
|
|
The alternate name to throw people off the fact that it is just hex? Except it's not. |
|
|
|
Superceded with next-test 20120506next-test is a branch of the mainline bitcoind & Bitcoin-Qt with as many pull requests merged as possible, to aid in testing them. This branch can be used to test many pull requests in your daily Bitcoin use. The goal is to help pull requests get the testing they need to be merged into the main tree, so once you test a change, please comment in the relevant pull request (ideally with details). Please note these might possibly corrupt your wallet. No warranty of any kind of provided. BACKUP YOUR WALLETToday's next-test includes the following pull requests (green are merged now; red are disputed): Bugs found:
|
|
|
|
I loaded from kolivas-server
The funny is:
- 10 BFL's with 1 instance working
- 11 BFL's with 1 instance crashing
- 1x 8 BFL's and 1x 7 BFL's together with 2 instances working
@af_newbie
"-S bitforce:COMXX" crashing also with more then 10 BFL's
I will set up an 11-unit cluster with 1 instance of cgminer 2.3.6 when I get home later this evening and try to reproduce the issue you are having (if no solution or confirmation is found by then). I am running Win7/64, not Win8/64, so if it works for me we cannot conclude much. But if I confirm a crash with 11 Singles on Win7/64 (as you've done on Win8/64) then it points to a problem with cgminer. Tinua, This is most likely an issue with your USB hub. I have 15 singles running on one instance of cgminer. Best, gigavps Update: With ufasoft-miner no issue....working with 15BFL's in series including hot-swap......no crash! Can you try with BFGMiner? |
|
|
|
|
Show Posts
