Maybe something got corrupted in the cgminer (or related cgwatcher) settings? Perhaps it's worth trying a 'clean instance' of cgminer, first by itself without cgwatcher. You may want to raise this at the DrillbitSystem forum where it may get more exposure/response from fellow drillbit users/developers.
Cheers
already tried it yesterday made no difference, now the strange part been running the whole day on 54:2:850 and tried 52:2:950 again now....... now the bloody thing works?! running 5min 19 -23 GH/s 32C hw 1.15% now at 0.75% What temp should the board be and which temp is high? ed. fan(s) on heat sink a must but fan on otherside recommended JBT, Congrats, persistence pays....  I agree about the cooling, now have 3 fans 'surrounding' the drillbit8 board. My board was previously connected directly to the PC USB2 port, yesterday I tried it through a hub with other devices and it worked fine with int:53:2:950 (has been running now for about 9 hours). Temp reported by cgminer 3.8.5 is 32.1C. I think that this board reached something like 36 C with poorer cooling and some people on the drillbitsystem forum http://drillbitsystem.com/forum/index.php?topic=230.0 show higher temps. In general running it hotter would reduce reliability and possibly trigger some on-chip protection mechanisms. It would be interesting if you find some consistent method to reach the OC settings reliably. Cheers |
|
|
|
On the previous (pre-mod) board, I sometimes had to disconnect/reconnect the USB cable, or to cycle power to the board to make it start at 950. The present board, in particular after the firmware update has no such problems and consistently starts at 950. I assume that your board has the latest firmware, if not you should consider applying it.
I also found that my current board doesn't 'like' cgminer 3.9.0 and works consistently with the drillbit fork of 3.8.5. It works ok with 3.9.0 on a separate PC, but when connected to my main mining laptop (with a bunch of other USB miners and multiple instances of cgminer and bfgminer), it just wouldn't run on 3.9.0. The cgminer version is another thing that you may try.
Cheers
did a power cycle and usb reconnect even rebooted pc and reflashed latest firmware, it did run at 52:950 when i got it, the problem started when my router did its 24 restart. the first time cgminer just froze, second time the 8baord went nuts. now only 850 is the only thing that works and av 19,8 to 20.4GH/s as reported by CGwatcher. also added a fan blowing on the other side of the board, temp stable at 30C at room temp of 32C Maybe something got corrupted in the cgminer (or related cgwatcher) settings? Perhaps it's worth trying a 'clean instance' of cgminer, first by itself without cgwatcher. You may want to raise this at the DrillbitSystem forum where it may get more exposure/response from fellow drillbit users/developers. Cheers |
|
|
|
Congrats! your board seems to be doing fine Getting cgminer version 3.8.5 - Started: [2013-12-31 09:46:00] DRB 0: E8 32.2C (34.7C) | 22.44G/22.44Gh/s | A:435092 R:1058 HW:14051 WU:313.5 snapshot time [2014-01-01 08:56:47] (abt 23 hours) while running with --drillbit-options int:53:2:950 HNY Cheers well just stop working with those setting back to default int:40:1:850 the other i now just get asc timeouts ed. using int:52:2:850 with lot less hw errors!? edd. using :950 produces asic timeouts Do the asic timeouts at :950 persist or are they just a short time transient? I think that if the configuration is changed for a 'running board', then there is a short time transient until present values from the previous session are cleared. If the timeouts are persistent, then you might try 'incremental' increases as suggested by one of the people on the drillbitsystem forum. Cheers total timeout no hashing message: DRB 0: timing out unresponsive ASIC 0 - 6 any setting with 950 in so using int:54:2:850 for 10 min 19.8GH/s avg 30C a:2072 HW:143 so not to bad but less way less than yesterday On the previous (pre-mod) board, I sometimes had to disconnect/reconnect the USB cable, or to cycle power to the board to make it start at 950. The present board, in particular after the firmware update has no such problems and consistently starts at 950. I assume that your board has the latest firmware, if not you should consider applying it. I also found that my current board doesn't 'like' cgminer 3.9.0 and works consistently with the drillbit fork of 3.8.5. It works ok with 3.9.0 on a separate PC, but when connected to my main mining laptop (with a bunch of other USB miners and multiple instances of cgminer and bfgminer), it just wouldn't run on 3.9.0. The cgminer version is another thing that you may try. Cheers |
|
|
|
Congrats! your board seems to be doing fine Getting cgminer version 3.8.5 - Started: [2013-12-31 09:46:00] DRB 0: E8 32.2C (34.7C) | 22.44G/22.44Gh/s | A:435092 R:1058 HW:14051 WU:313.5 snapshot time [2014-01-01 08:56:47] (abt 23 hours) while running with --drillbit-options int:53:2:950 HNY Cheers well just stop working with those setting back to default int:40:1:850 the other i now just get asc timeouts ed. using int:52:2:850 with lot less hw errors!? edd. using :950 produces asic timeouts Do the asic timeouts at :950 persist or are they just a short time transient? I think that if the configuration is changed for a 'running board', then there is a short time transient until present values from the previous session are cleared. If the timeouts are persistent, then you might try 'incremental' increases as suggested by one of the people on the drillbitsystem forum. Cheers |
|
|
|
Got my 8baord yesterday, flashed ,fitted two fans and its happily hashing away....using cgminer --drillbit-options int:52:2:950 --usb DRB:1,ICA:0 ,38C with 2274HW in 18hours, which i hope is good?  Hash rate? cgminer reports jumping 23.5(21.1) 5s av / 21.66 GH/s avg Congrats! your board seems to be doing fine Getting cgminer version 3.8.5 - Started: [2013-12-31 09:46:00] DRB 0: E8 32.2C (34.7C) | 22.44G/22.44Gh/s | A:435092 R:1058 HW:14051 WU:313.5 snapshot time [2014-01-01 08:56:47] (abt 23 hours) while running with --drillbit-options int:53:2:950 HNY Cheers |
|
|
|
My situation seems to be fixed now.... Thanks and a Happy New Year....  |
|
|
|
something like 3 blocks that were previously in my 'unconfirmed' have now been removed, so the unconfirmed and total reward shrunk. (blocks 23105-21307) It is a mess....  |
|
|
|
Now my 'total reward' on the account page was reduced by about 1/3 (it was correct before).... this is getting worse..... |
|
|
|
|
still strange that the confirmed earnings are not showing up in ´account´[/quote]
Because if they showed up in 'account' that would trigger automated payouts, but the 'wallet is empty'..... so junior-operator-on-duty 'closed the tap' to avert disaster.... (but is that good enough? surly someone could have estimated the needed BTC for pool cash flow before they went incommunicado)
|
|
|
|
For Slush members wondering what is going on with threshold delayed payments...
"Typically, the pool sends confirmed rewards which are over threshold to users every hour.
For security reasons, the server's hot wallet (keeping funds immediately available for payouts) has quite a low balance. When the hot wallet becomes empty, the pool administrator has to load the wallet from the cold storage (a highly secured offline computer keeping pool's bitcoins). Since this process cannot be automated and only very limited number of people has an access to cold wallet, it can introduce a few hours' delay in sending coins to user's wall
if you found this post helpful, feel free to tip. I will have a drink of Jack Daniels in honor of every tipper.
Donations: 16WFsEEfi2Ui6jzXSGhfN5MKokCqoyCZTt
So someone went on holidays, without leaving sufficient petty-cash for those who shovel coal into the Slush boilers.... no reward, no hashing..... |
|
|
|
2013-12-30 20:43 , changed payout amount to match already confirmed before stuck and after some time receive payment
But the additional 'actually confirmed' amounts remain 'unconfirmed' in the Account page? (my 'already confirmed' amount before 'stuck' is below the min threshold, so i probably can't do what you did). |
|
|
|
payouts time depends , i have same issue with confirmed section but receive payment before 3 hours approx
AlexeyK: Did you receive payment 3 hours ago, or 3 hours before the 'confirmation freeze'? (my last payout was more than 24 hours ago) |
|
|
|
confirmations stuck since 21304 they should be at 21311 by now
still stuck should now be at 21314
My reward is still stuck at the same #21304. Does Slush have a 'liquidity problem' or is it just a software glitch? Does this affect just a few individuals or all pool participants? Are you mining without an expectation to get rewarded or hope that the down-under saying of 'she'll be allright mate' will prevail..... !!!! not seen this problem before so its a wait and see situation. My support ticket priority has been elevated from 'normal' to 'critical'. It has been something like 13 hours now, let's see how it goes. |
|
|
|
confirmations stuck since 21304 they should be at 21311 by now
still stuck should now be at 21314
My reward is still stuck at the same #21304. Does Slush have a 'liquidity problem' or is it just a software glitch? Does this affect just a few individuals or all pool participants? Are you mining without an expectation to get rewarded or hope that the down-under saying of 'she'll be allright mate' will prevail..... !!!! |
|
|
|
|
Are people getting reward payouts, if the confirmations are 'stuck'?
I'll probably move my miners somewhere else, until the 'fog clears'....
|
|
|
|
i opened a ticket on the support page as well, but it has been quite a few hours and still nothing. Maybe there is a reason that this is called 'the silly season'.... |
|
|
|
|
What are the 'compulsory conditions' for this GB to succeed - is the 500 number of U1 units a 'must have' or will it happen at the current commitment level?
|
|
|
|
|
There is a new issue that I have not seen before at this level - the "confirmed reward" is stuck at a value appropriate for Slush block 21304, however there have been 4 additional blocks confirmed since, which would have crossed the reward payout threshold.
In the past there have been some short delays of minutes between block confirmation time and update of the 'confirmed reward' on the 'My Account' page, but I can't remember it ever taking so long.
Is someone asleep 'at the helm' of Ship Slush?
|
|
|
|
|
Payment sent for 4.
Please confirm
Cheers
|
|
|
|
|
Beastlymac,
Can you provide links to any specs of the U1 and S1?
PM sent regarding order
Cheers
|
|
|
|
|
Show Posts
