Ok, I've figured out why I think people are reporting bad hashrates on Erupters with 3.2.0... First, a summary: it's just your perception, it will take a few hours, at least, before the average hashrate displayed settles down. This is due to the Erupter driver only reporting hash completion once every 12.8 seconds (the time it takes to find 1 share on average). During this time, the average is skewed because while the Erupter has been hashing, it hasn't reported its progress. So for the first 12 seconds, the erupter has "completed" a total of zero hashes. So the average is 0 despite that it's been actually performing hashes the whole time. For the next 12 nexts, it has "completed" 4 gigahashes (total, not per second), which are then divided across the 12 seconds (which gets an accurate 335 Mh/s average); but then across 13, 14, 15, etc seconds; by the time we get to 24 seconds, it's still using the same 4 gigahash "completed" number, so the average (of 4 Gh over 24 seconds) is 178 Mh/s. Once the second 4 gigahash "completed" come back, now the total is up to 8 gigahash, and it once again shows the correct 335 Mh/s average. By 36 seconds, however, the same thing has happened again: we have 8 gigahash divided by 36 seconds now, which is only 238 Mh/s. After a few hours, those last 12 seconds becomes less and less relevant, and your average should begin to settle on 335 Mh/s. The reason this didn't affect 3.1 and earlier as much is that it was abandoning work when a share was found, thus cutting the 12 seconds down to 6 on average. Scanning the whole work is more or less the main thing responsible for reducing hardware errors in 3.2.  There are a few ways to fix this to get a usable average faster: - Only count seconds for which completed hashes are known, when performing averages. This would change behaviour such that averages would not account for time a device is disabled or waiting on failover or other issues. Probably not a good idea IMO.
- Ignore the time after the last "hashes complete" report so long as a device is actively hashing. This is probably ideal, but I need to think what the best way to be sure the device is actively hashing reliably (shockingly enough, this isn't obvious yet internally).
- Upgrade the Icarus driver to the newer API so it can report progress more often. I need to do this eventually anyway, but there are some complex issues to handle on Windows when I do.
All of these solutions have potential to introduce new bugs, so I don't expect to implement them until 3.3 at the soonest. Edit: Original post accidentally said 355 instead of 335. |
|
|
|
Any idea if/when you'll be adding the getwork server to the Windows binaries? No, I'm not prepared to compile myself (my head would explode trying). The main problem here lies with libmicrohttpd, which doesn't really support Windows (some specific versions will build with a POSIX simulation layer, which itself only works on 32-bit). So, someone would need to do one of these: - Port libmicrohttpd to Windows proper.
- Fix PlibC to work on not only just 32-bit Windows.
- Port BFGMiner to support another HTTP server library (I'm not aware of any decent alternatives, unfortunately).
wizkid057 thought he might have time to look into these options. Have a looksie at http://lists.gnu.org/archive/html/libmicrohttpd/2013-03/msg00007.htmlSounds like someone already patched plibc to work on x64 and add utf-8 support but his patch was ignored/forgotten. At least he posted a git where it can be had. Well, latest plibc git didn't compile for me, so  |
|
|
|
So ... why the FUD in your README? (that's rhetorical)
I added this accurate explanation to README because it is a common problem experienced by people who have used cgminer. I'm more than happy to remove it if you fix the problem itself. |
|
|
|
...
"if you run cgminer, it will corrupt the real driver (until re-plug or reboot), which is likely why it isn't working."
...
Sigh, that's FUD. No it doesn't corrupt anything. It simply switches off the kernel module so that I can do direct USB access to the device. And doesn't release it when it quits. That leaves it in a bad/unusable state. I did ask if you would fix this, if you recall... |
|
|
|
Is it possible to compile the OpenWRT binaries smaller if restricting mining support only to Block Eupters?
Probably, but you may need to hack the openwrt Makefile. What do you use for Compiling? I use the official Toolchain but it reports missing libncurses-dev on Debian 6 But it compiles fine if i make directly for my CPU instead of Cross-Compile To build for OpenWrt, you need to use their Buildroot toolkit. |
|
|
|
Is it possible to compile the OpenWRT binaries smaller if restricting mining support only to Block Eupters?
Probably, but you may need to hack the openwrt Makefile. |
|
|
|
How to read the bandwidth numbers:
BW:[ 75/241 B/s]
75 bytes (blocks?) per 241 seconds? This cannot be right.
I see [441/41 B/s] and [292/29 B/s] on my systems but I'm not sure what these numbers mean.
Received/sent, or download/upload. |
|
|
|
cgminer just released a fix for BFL SC that was causing crashes, new version 3.4.2 would this be the same fix bfgminer needs to fix the crashes I have been having with BFL Little SC's from 3.2.0?? Nope, there's no common code there, and BFGMiner 3.2 doesn't have the many bugs that were added in cgminer 3.4.1. If you can post a crash report (printed to debug log or, if none, the console), I can look into it. |
|
|
|
IMO there is no real value for asking the device for its current hashrate. How is the number of jobs it needs calculated then? I mean when we have just started and discovered X unknown devices from unknown manufacturer (otherwise we just won't ask) Also if there are 500 chips and the hardware keeps an eye on them (to know when to pool them), so it has that detailed info - the MS may only keep the overall hashrate and ask. As long as you're having the device request work, might as well have it specify how many it needs. It might be nice if the protocol were prepared to handle non-Bitcoin POW algorithms too, but this could probably be done as an extension. What about ShaWork/ShaNonce in replacement for DoWork/GotNonce and then ScptWork/ScptNonce etc. as each may need it's own parameters? There are a lot of parameters for both SHA256d/scrypt/others that are currently taken forgranted. Of more important note, I think I forgot to mention: There should probably be a single command to cancel all pending jobs ASAP, for use on block changes. |
|
|
|
Luke do we have an update on the stats portion?
I have nothing to do with stats, sorry. I believe wizkid said it was working a few hours ago? |
|
|
|
So what you saying is, GBT solo installation would be easier to deploy but in terms of actually solving a block, GBT would not give me any extra edge over my current stratum setup, right? Correct. |
|
|
|
I was wondering if bfgminer (3.1.4 or 3.2.0) would work with 0.8.2 bitcoind to solo mine using GBT? Yep, see the solo mining section of README. I know it is your baby so you are probably biased, but is there any benefit for using GBT over stratum.
I'm running a bitcoind node on the same subnet as bfgminer, so network is not an issue. The main benefit of GBT over stratum is that GBT supports decentralised mining. But as long as you're solo mining, it really doesn't make a big difference. In practical terms, GBT solo mining is easier to setup (no need for a GBT->stratum proxy server), but it sounds like you're already setup for stratum anyway. |
|
|
|
I've always worked directly with manufacturers, often writing the code myself, so this isn't a real problem for BFGMiner.
And here comes the second problem - someone should do the same for CGminer and then someone else for EasyMiner and then for BitMinter etc. Managing dozens of hardware and software versions is hard if not impossible and the end user (miner) will be left with no choice, but to use a specific miner and version, because of his hardware. I hope you will agree that there is a need in such protocol at least because of this and i aim to design it as flexible as possible. Other software is welcome to adopt a compatible driver API. BitMinter is Java, so that makes some difficulty of course. (EasyMiner is a BFGMiner GUI) Unfortunately, cgminer wants to reinvent the drivers themselves for no gain. It's called not-invented-here syndrome. |
|
|
|
... I am even experiencing lower payments than usual (this pool suppose to have 0% fees)...
and I know exactly what are shelved shares, and no I didn't have any. Then the problem is with your definition of "usual". If you don't have any shelved shares, then you've been paid 100% in full. |
|
|
|
|
Eh, I figured wizkid057 fixed it already. Everything is working fine for me...
Edit: Except for the website, but that's not an emergency and I have almost nothing to do with it.
|
|
|
|
|
Namecoin-Qt works fine for me.
|
|
|
|
One of the problems i see is that for a manufacturer it will be difficult to follow (if at all) mining software development and to back it up with the words of ckolivas from https://bitcointalk.org/index.php?topic=228677.msg3017560#msg3017560"Oh and it's not "the current cgminer", it's the forked code based on an older version." What about the miner in case a (security) bug is discovered in that older version several versions later, which is then fixed, but is missing the manufacturer's code and for him it will mean starting with a new fork? By separating them, a fix or improvement in the mining software will not affect custom hardware module and the opposite an updated module will not require downloading and recompiling of new mining software. I've always worked directly with manufacturers, often writing the code myself, so this isn't a real problem for BFGMiner. |
|
|
|
Just wondering if you know if BFG can run bitfury chips as yet? The "littlefury" branch in git (work in progress, NOT supported yet) can run some platforms. |
|
|
|
The fork of my miner uses the original stratum code I wrote for cgminer which used libcurl to set up the stratum socket connection. When this problem originally occurred, it would crash in libcurl. After tons of debugging I had so many crashes due to libcurl bugs that I decided to abandon using libcurl and just use raw socket code for all stratum code. That fixed the crashes (on both linux and windows) but on windows for some reason a socket just hangs up and never returns without any meaningful failure that should normally happen instead. That's why this bug manifests in two different ways. Older versions of cgminer would also crash during this interruption if you read back through this thread. However so many other crashes were fixed by abandoning libcurl that it was worth it. It's worth noting that improvements to this code keep going in and as recently as 3.3.2 another stratum disconnect issue was fixed, so if you're on an older version I highly recommend upgrading to 3.3.4 (the latest).
Actually, the BFGMiner crash (now fixed) was in entirely independent code that never appeared in cgminer. Nor can cgminer's former crashes be blamed on libcurl. I found the bug in the stratum code, fixed it, and even offered it to you for cgminer. You chose to ignore it. The only reason switching to raw sockets fixed cgminer was because you removed the offending code in the process. BFGMiner 3.2.0 has the stratum crashes fixed while still using libcurl so it's proxy-friendly. |
|
|
|
Here we go....
The problem is that the information from the hardware is unstructured. One piece of hardware may have a board temperature sensor, another piece of hardware may have two. Or, maybe one for the board, and one for the power regulator, and maybe one integrated into each of the 512 chips. It's going to be impossible to find a common way to bind all these different kinds of properties, and find a nice way to format them all in a single line on a screen.
And the bizarre thing is that all the information about LEDs, clocks, voltages, error rates, and chip temperatures goes into the mining software, which doesn't really have a clue what to do with that. So, you need equally complicated config files to tell it that LED A needs to turn color B when temperature sensor C is >= D degrees.
Really, this information is something that only concerns the mining hardware and the user. There's no need to standardize it all, just for the benefit of the middle man who doesn't really care anyway. A better approach would be to create a mining library that's responsible for reliable network communication, and provides a standard get/put work interface. That way, the vendor can just write his own application, communicating with it's own hardware, and just call the mining library to get fresh work and submit the results.
Rather, the driver is the non-common component here. Users don't want different applications and interfaces for each of their devices. BFGMiner has this common driver abstraction already in place. |
|
|
|
|
Show Posts
