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. |
|
|
|
|
Xp supports max of 8 of the same devices.
|
|
|
|
|
Scrypt and opencl support is being deprecated in the near future, and development for other coins is not going to happen, so sorry but there is no plan for improving support for other coins.
|
|
|
|
Does sgminer run with Nanofury NF1 USB-sticks?
If yes - how can i get it to work?
No No chance you will implement nanofury support in the near future? I really don't want to use the evil twin of cgminer.  I'll be sent one in the future, and then a driver will be developed for it. No idea of timeframe. |
|
|
|
|
I keep getting asked about the HEX16A driver. At the risk of sounding like a broken record, neither I nor Kano have one so we're not writing drivers for them, and no active maintainer has stepped up to try to push code to us and have us audit that the code is satisfactory enough to include, so there will be no driver for it for the foreseeable future.
|
|
|
|
Anyone know why KLN devices would show up but mine at 0 on latest Ubuntu? Sometimes they work, but mostly not. I'll have a few up then restart cgminer or the computer and then different ones will be at 0. Annoying.
Power? Yeah that would make sense, so I've tried with different hubs and power setups and get the same results. So, since they are in Florida, and there is always plenty of lightning, I'm going to try that as a power source next. At least that will be entertaining  https://bitcointalk.org/index.php?topic=326985.0Hmm that might just give them enough power to recoup their costs. |
|
|
|
Anyone know why KLN devices would show up but mine at 0 on latest Ubuntu? Sometimes they work, but mostly not. I'll have a few up then restart cgminer or the computer and then different ones will be at 0. Annoying.
Power? |
|
|
|
|
You should never need to touch the queue setting when mining at a stratum pool no matter what the hashrate.
|
|
|
|
8 BEs and Jala in Tecknet USB 3.0 hub connected to laptop. No zombies in 3.7.2 but often see this [2013-11-07 14:15:44] AMU0: GetResults (amt=0 err=-7 ern=34)
[2013-11-07 14:15:44] Icarus Read: No data for 12633 ms
BEs has often light solid and HW errors increased in my estimates. Jala is OK. 3.5.1 is best for my setup yet. That's not a bug. It means that work item had no shares in it. There's a reason it doesn't show that message except at higher logging levels. |
|
|
|
|
Show Posts
