Hey I've got my red fury in the mail today. I tried and failed to get the bfgminer to work with them so i am trying with cgminer 3.7.2 . I have used the Zadig app to switch to the WINUSB driver on the BF1 but when I run CGminer-nogpu.exe it says it can't detect any devices. Any idea's on how to correct this?
USB3 slots can be problematic so try USB2 if you can, and sometimes you may need to reboot after changing the driver association to winusb. Also be 100% clear that you're doing the driver switch exactly as it says in the README file. |
|
|
|
Just noticed that ckolivas commited a changeset a few hours ago with an update to the bitfury driver. Re-compiling from source, with those changes, made a difference in the numbers I was seeing in cgminer. Cgminer reported hash rate went from around 1.7-1.8Gh/s to around 2.2 - 2.5Gh/s.
I didn't think the changes would make such a difference, but there will be hardware errors reported now. Anyway in case someone cares, here's an updated windows binary with the changes: http://ck.kolivas.org/apps/cgminer/temp/cgminer-nogpu.exeSeems to be helping my numbers a bit, on two different ubuntu boxes. Recompiling now on a beagle-board xm... will post results after a soak in. Early Results from the beagleboard-xm Before After Well that looks quite significant then. It's probably a minor USB change I made to the code rather than a change to the bitfury driver itself. |
|
|
|
Just noticed that ckolivas commited a changeset a few hours ago with an update to the bitfury driver. Re-compiling from source, with those changes, made a difference in the numbers I was seeing in cgminer. Cgminer reported hash rate went from around 1.7-1.8Gh/s to around 2.2 - 2.5Gh/s.
I didn't think the changes would make such a difference, but there will be hardware errors reported now. Anyway in case someone cares to try it, here's an updated windows binary with the changes: http://ck.kolivas.org/apps/cgminer/temp/cgminer-nogpu.exe |
|
|
|
|
Ah apologies then, for I didn't know you were speaking about compiling it on windows. I agree, compiling cgminer for windows is bullshit as a result of it being primarily developed as a unix program.
|
|
|
|
I have two block erupters that are producing about a Ths for me. That would be great if weren't a Ths of Hardware errors. I have seen others report very high hash rates for BE's but I don't remember what the consensus was. Is this a BE, Hub or CGMiner issue? Any insight would be appreciated.
Sam
It normally takes a 335MH device ~12.8 seconds to check all nonces in a single work item. The BEs use the icarus protocol which means as soon as they find a result, they report it back and then stop working. This can happen anywhere between zero and 12.8 seconds. The driver then gives it more work and the cycle starts all over again. If you can imagine the device coming back with a "result" in say .1 second and does this every time, the driver probably thinks it's running at a terrahash. However if it's a wrong result most of the time, it's meaningless. The driver shouldn't really be reporting it back as 1TH then so it's a mistake in the calculation in the driver. Kano might want to chime in since he wrote most of the driver. This happens when you use the timing option (short or long) and the documentation reference in FPGA-README is:
'short' or 'long' mode should only be used on a computer that has enough CPU available to run
cgminer without any CPU delays (an active desktop or swapping computer would not be stable enough)
Any CPU delays while calculating the hash time will affect the result
'short' mode only requires the computer to be stable until it has completed ~315 difficulty 1 shares
'long' mode requires it to always be stable to ensure accuracy, however, over time it continually
corrects itself
TL;DR - Don't use a timing option any more. |
|
|
|
I have a USB driver question (not a complaint). Have you changed any USB driver components between 3.6.4 and 3.7.2? Because all of a sudden, I cannot for the life of me get CGminer 3.7.2 to work with my USB block erupters at all, while going thru Anker USB hubs (I have two hubs, none of them wants to work with CGminer 3.7.2). If I reboot, and start up CGminer 3.6.4, same machine, different CGminers in different directories, 3.6.4 works fine. I start up 3.7.2, no AMUs get recognized thru the hub. The only way they get recognized by CGminer 3.7.2 is if I plug them into the computer's usb ports directly. The Anker hubs are USB 3.0 hubs, so it seems like there is some kind of issue when going from USB 2.0 to USB 3.0., either with CGminer or the Anker hubs. This is a pure Linux Mint 14 machine, AMD processor, with the each version of CGminer compiled using --enable-icarus --enable-klondike --no-gpu --disable-opencl I don't remember what the flags were for each compile (I think I have them written down somewhere), but the earlier version had a different set...I'm guessing that's important? (I think I loaded libtool, libncurses-dev yasm curl , for the 3.6.4 compilation, but not for the 3.7.2 compilation). The 3.7.2 compile I just did cd cgminer chmod +x ./autogen.sh ./autogen.sh ./configure --enable-icarus --enable-klondike --no-gpu --disable-opencl make Version 3.6.4 used to also recognized Klondikes going thru the Anker hub, but it does not anymore under 3.7.2. Both icarus and klondikes work fine when plugged directly into the usb ports under 3.6.4. Weird, isn't it?  Any thoughts would be greatly appreciated. Thank you for all your work on this. I have heard of issues with USB3 and libusb but this is the first before and after type report like this so it could be helpful for us to find out why. If you're building it yourself from git, can you do a bisect to find when it started? Here is how to do it from 3.6.4 to 3.7.2: git checkout v3.7.2
git bisect start
git bisect bad
git bisect good v3.6.4
Then it will find halfway points between them and you can rebuild it each time to and report back to git If it doesn't detect the devices or if it does. If for some reason one of the steps along the way doesn't build or crashes or hangs or something else due to being in a dodgy commit, just skip it with When it's all over git should report to you something like "The first offending commit is XXXX" and you can report that one back to me here. Once it's over you can reset your git tree back to normal with |
|
|
|
I have two block erupters that are producing about a Ths for me. That would be great if weren't a Ths of Hardware errors. I have seen others report very high hash rates for BE's but I don't remember what the consensus was. Is this a BE, Hub or CGMiner issue? Any insight would be appreciated.
Sam
It normally takes a 335MH device ~12.8 seconds to check all nonces in a single work item. The BEs use the icarus protocol which means as soon as they find a result, they report it back and then stop working. This can happen anywhere between zero and 12.8 seconds. The driver then gives it more work and the cycle starts all over again. If you can imagine the device coming back with a "result" in say .1 second and does this every time, the driver probably thinks it's running at a terrahash. However if it's a wrong result most of the time, it's meaningless. The driver shouldn't really be reporting it back as 1TH then so it's a mistake in the calculation in the driver. Kano might want to chime in since he wrote most of the driver. |
|
|
|
|
Then just use cgminer? The performance is tied to the device, not the software...
|
|
|
|
Win8x64 has never worked with erupters for me. I keep trying every few weeks, its a pile of s...
Win7x86 works first time every time, apart from the driver update(so installed as above)
It is the same PC with 2 drives, so its not hardware.
 |
|
|
|
I will do as suggested. I do have HEX16A. And i am playing with them for the moment
I will let you know if i find out what happens related to your code as long hex16 is not pushed to your git ...
Ah in that case, make sure your report your bug to the hex16 maintainer, not me since it's not cgminer code. |
|
|
|
PS- Why did you disable Avalon lock lately? If everything is ok the lock shall be ok also.
Everything was not okay with the avalon. There are recursive locks called in a different order from the async flush code and the avalon code. Recursive locks in a different order cause deadlocks. If you are having deadlocks then perhaps you have a hardware driver with a similar problem. The one I have not been able to fully audit so far is the klondike driver which may be prone to the same problem. Thank you con!!!! You do not mind to spam the thread now and then do you? I am finding bugs from time to times  I am joking..Thank you very much Absolutely do not mind at all. People auditing code is rare, and reporting meaningful bugs is the key to fixing them. What hardware do you have anyway, if you are having deadlock problems? By the way, if you can reliably reproduce what appears to be a deadlock, make sure you have the absolute latest git, edit miner.h to enable LOCK_TRACKING change line 765 to and start cgminer logging the output and with the API enabled with for example the following extra options: --api-listen --api-allow "W:127.0.0.1" 2>log.txt
and when you see a deadlock send the command to get a summary of the lock status with This should spew extra information into the logging file you generated called log.txt which will allow me to see how the deadlock was caused. |
|
|
|
PS- Why did you disable Avalon lock lately? If everything is ok the lock shall be ok also.
Everything was not okay with the avalon. There are recursive locks called in a different order from the async flush code and the avalon code. Recursive locks in a different order cause deadlocks. If you are having deadlocks then perhaps you have a hardware driver with a similar problem. The one I have not been able to fully audit so far is the klondike driver which may be prone to the same problem. |
|
|
|
Hello
I do think that this piece of code can create dead locks we are waiting to be awaken pthread_cond_wait holding lock mutex_lock(stgd_lock);
mutex_lock(stgd_lock);
ts = __total_staged();
if (!pool_localgen(cp) && !ts && !opt_fail_only)
lagging = true;
/* Wait until hash_pop tells us we need to create more work */
if (ts > max_staged) {
pthread_cond_wait(&gws_cond, stgd_lock);
ts = __total_staged();
}
mutex_unlock(stgd_lock);
From the other side wake_gws needs same lock and so on and so on....Con please take a look at it when you can
static void wake_gws(void)
{
mutex_lock(stgd_lock);
pthread_cond_signal(&gws_cond);
mutex_unlock(stgd_lock);
}
A quick fix might be
mutex_lock(stgd_lock);
ts = __total_staged();
mutex_unlock(stgd_lock);
if (!pool_localgen(cp) && !ts && !opt_fail_only)
lagging = true;
/* Wait until hash_pop tells us we need to create more work */
if (ts > max_staged) {
pthread_cond_wait(&gws_cond, stgd_lock);
mutex_lock(stgd_lock);
ts = __total_staged();
mutex_unlock(stgd_lock);
}
I appreciate you looking over the code, however I guess you don't understand that pthread_cond_wait DROPS the mutex lock associated with it. You are supposed to called a pthread conditional wait holding a mutex lock and it picks up the lock again when the conditional or timeout is over. |
|
|
|
|
Let me get this straight, you can't compile cgminer but you want to write your own mining software?
|
|
|
|
Sorry you have some misconceptions about the effect of mining at different difficulty so let me clear them up once and for all: It makes no difference to these devices what difficulty you mine at in either hashrate, hardware error rate, or reject rate.
If those random hardware errors cause the entire current work unit to fail, then it's best to keep their effect to as small a portion of work as possible. Let's pretend that work diff of 64 takes about 10 mins, on average, to produce an accepted result. If you have a single hardware error in that 10 minutes, you wasted the entire 10 minutes. If you had broken it up into 8 units of 8 diff work, you would have only lost ONE of those work units, not all 8. Instead of losing all 64, you get 7 of the 8, or 56. 56 is better than 0, yes? And if you're churning away at solving a work unit diff 64, and only make it to halfway (32) before a block is found by someone else....you just wasted the progress you did have (32 -- which is 'halfway'), since you can't carry that work over into the next block. I was basing it off of what I was witnessing with my fury in bfgminer 3.5.1. 3.2.0 doesn't report the errors. Neither does your cgminer, as well you know. There may be some sanity checking that allows partial recovery on a HW error, but I wasn't seeing it in bfgminer 3.5.1. I saw much lower effective rates as I increased the work unit's diff. And yes, I let it run long enough. The hardware mines at diff 1. Everything else to do with diff is done outside of that so it makes no difference to how the hardware performs. Anything you're seeing is pure luck and variance related. There is no "progress" or anything else that matters. Every hash is a single hash. At diff 64 you find 64 more when you find a hash good enough, but you lose 64 on a reject etc. It all evens out in the end. If you believe anything else then you're just misunderstanding how this all works. |
|
|
|
reinstall the silab driver, then repeat the normal installation process.
cgminer doesn't use the silab driver What driver do you use for block erupters and cgminer on osx? Osx, like linux, need no drivers at all with cgminer. |
|
|
|
|
Sorry you have some misconceptions about the effect of mining at different difficulty so let me clear them up once and for all: It makes no difference to these devices what difficulty you mine at in either hashrate, hardware error rate, or reject rate.
|
|
|
|
CGminer 3.7.2 on Windows 7 - 32  So does this mean you have 0 HW errors??
and all shows about 2.1 ~ 2.2 with or without 60% hw error.
i dont think the hw error are real per say. 3.0.99 says 0 hw error and 3.4 says 60% but speeds are the sames 2.1 or so
Not really, the hw errors are real. There isn't much point even showing the hardware error count because 60% of the data returned is garbage. It's a design flaw and, alas, monitoring that percentage serves no useful purpose. Looking for subtle inefficiencies when the bulk of the data is garbage is futile, which is why I don't even bother trying to report a hw error rate in cgminer and only show the hashrate by extrapolating it from the valid share return rate. No point saying the hashrate is 5GH when you only get 2.3GH of shares... |
|
|
|
Someone will pick up the slack.
That would be fine by me. I write software either because I enjoy doing it, or I earn money for it, or both. I'm writing/maintaining cgminer because I believe in bitcoin and I like to earn bitcoin. I unashamedly wrote the scrypt support for a generous bitcoin fee a long time ago so it was purely for the payment. I have no interest in altcoins so someone else should be maintaining it. Just because others have an interest in altcoins doesn't mean that I have to. |
|
|
|
|
Show Posts
