Same here for one of my boards. If I reboot the PC and start cgminer once, this board runs at only 15.4GH/s @ int:53:2:850, but will run 100% stable for weeks at a time. If I restart cgminer something like 15 minutes after PC startup, it will run at 17GH/s (with the same settings), but only last 2 days 6 hours before spitting out LIBUSB errors. My other three boards each run at about 20.4GH/s at 54:2:850, also 100% stable for weeks on end.

I've also updated to cgminer 4.0.1 -- been running smoothly for 12 hours so far, though it didn't fix my stability issues at 950mV like I was hoping it might. So far I'm getting the same performance as I was getting with cgminer_drillbit 3.8.4 r2. You guys with stability issues with linux/rpi etc. might find it more useful, but with my Windows/x86 PC, there's hardly any difference.

Yeah that would be a bummer. I might be lucky that my boards tend to only spit out LIBUSB errors after about 2 days and 6 hours, so I can almost always count on a daily (or once every two days) automatic PC reboot to do the job. Only problem then, is the trouble getting the boards to actually start at 950mV on the first go. Usually doesn't happen... so to avoid stuffing around every 1-2 days, I just leave the boards at 850mV.

On a related note, some power consumption figures if anyone is interested (4x 8-boards):

88.50GH/s @ 130W = 0.681GH/W (all boards at 950mV -- takes many attempts to get started, fails after 2 days 6 hours...)
81.25GH/s @ 105W = 0.774GH/W (one board at 950mV, others at 850mV -- takes many attempts to get started, fails after 2 days 6 hours...)
76.70GH/s @ 95W = 0.807GH/W (all boards at 850mV -- starts reliably, at least a week of uptime, probably more if I just let it run)

The base PC takes up an extra ~30W including fans, so with that included:

88.50GH/s @ 160W = 0.553GH/W
81.25GH/s @ 135W = 0.602GH/W
76.70GH/s @ 125W = 0.614GH/W

It can be done. Reboot CGWatcher every day at the same time, and setup multiple profiles for each clock/voltage setting.

Eg. In the scheduler section:

* Set default profile to 45:1:750
* Restart CGWatcher everyday at 6pm (to start with 45:1:750 as it's the default)
* Change profile to 48:1:850 at 6:10pm
* Change profile to 53:2:950 at 6:20pm

If you get LIBUSB errors after a couple of days that require the PC to be rebooted, then set CGWatcher to automatically reboot the PC each day, and tick the box to run CGWatcher on startup with the default (45:1:750) profile.

This worked great for me for a few weeks, until my boards absolutely needed manual stuffing around to get them running at 950mV... I'm now just running them at 54:2:850 for 76.7GH/s total (three of them at 20.4GH/s each, the last one lagging behind at 15.4GH/s...). It's stable for at least a week at a time, if not more. Just need to stop playing with the settings and let it run for a few weeks.

Nicely done.

What's the hashrate for that 250W figure?

While waiting for the Drillbit team to reply, some pleasant news to report -- 7 days uptime on BTC Guild with 4x 8-boards. I'd also gotten 6 days uptime a few weeks earlier, but thought it might just be a one off...



Three out of four boards running at 54:2:850, the last one at 53:2:950 to keep it at 20GH/s (otherwise it drops to 15~16GH/s at any setting using 850mV...). Rig details here: http://drillbitsystem.com/forum/index.php?topic=45.msg2632#msg2632

When all my boards were at 950mV, the longest they would last was about 2 days 6 hours, before at least one of them spat out only LIBUSB errors. Then a lot of stuffing around to get them working at 950mV again. Just happy for them to reliably hash away a week at a time (or longer), rather than only for 1-2 days max.

Looks like a DFI Lanparty board for AMD (probably Skt939?), and one of the few motherboards out there with nice spacing for three graphics cards, similar to the Asrock X58 Extreme6.

Yeah, I checked out pilotchup's other posts and you're right, they're reference 290's.

My Gigabyte GTX670 OC (WF3 fans) has a max fan speed of 4650RPM, that's why I was thinking they might be 7970/280X's (with the same WF3 cooler).

pilotchup,

Golden 280X's? Or lazy 290's?

If they're 290's, I gather you've got them tuned for efficiency/lower temps instead of all-out hashrate?

Depends on the fan. The GT 1850RPM's are excellent, with ball bearings and below average noise levels considering the air they put out.

Those other fans are my leftovers from years ago. I tend to like sleeve bearing fans in my main PC because I'm a silence freak, and sleeve bearings have virtually no motor noise at low RPM's, whereas other motor types tend to have a tiny bit, enough for me to avoid them. But for a 24/7 mining rig and the higher temps that come with it, I understand the value of using good quality fans, hence the Scythe GT's.

4x Drillbit 8-boards (bitfury chips) @ 81GH/s. They can overclock to 88GH/s with some fiddling around.

CPU: Intel Celeron G530 @ 1.6GHz
Mobo: Gigabyte H77M-D3H
RAM: 1x4GB Kingston DDR3 @ 1066MHz @ 1.2v
HDD: Intel X25-M G2 80GB
Case: Antec P182
PSU: Antec CP-850
Fans: 4x Scythe GT 1850RPM (two on each pair of 8-boards for extra airflow), 1x 140mm 1200RPM for support, and 1x 120mm 1300RPM for exhaust
OS: Windows 7 Ultimate 64-bit

Problem:


Short-term solution:

Your board may need 950mV to get rid of most of those HW errors. You could also try int:53:2:850. I get lower a higher hash rate and lower HW errors (virtually none) on my boards with 54:2:850 than I do at default settings (40:1:850).

And definitely get another fan cooling the line regulator heatsink as well as those teeny little heatsinks, especially if you want to use 950mV.

With cgwatcher, I setup two profiles. One that used a "primer" setting of 48:2:950, and the other with 53:2:950. In the scheduler section, setup cgwatcher to use 48:2:950 on startup. Then get it to switch profiles to 53:2:950 every three minutes (every 0.05 hours). If it's already at 53:2:950, then nothing will change, so in effect the program starts with 48:2:950 to "prime" the boards for 950mV, then three minutes later changes to 53:2:950 for cruising speed. This only works as long as your boards can reliably start this way without spewing out "spurious" errors. My boards worked great like this for a fortnight, but no longer work reliably this way.

Now I've just setup a few batch files to start the boards at 40:1:850, 48:2:950 or 53:2:950. I just manually toggle between them until they get going at 53:2:950. They're stable for at least a day at a time, but I haven't had the chance to try running them for several days yet, because of a 44 degree day yesterday (I turned off my boards of course), and my internet connection was down for the past two days (everyone in the area at home with their aircon on full blast and on the internet lol).

Got them running now, been on for 16 hours and counting. Also had a play with the layout and window size. Got it setup with dark grey text and border lines for minimal distraction, as I've got a little 16" monitor next to my main rig, for keeping an eye on it when I'm on my PC.



For anyone interested and using Windows 7, go into Control Panel --> Personalisation. Use "Windows basic", then customise the colour scheme to use a black background and dark grey lines and text.

-----

Another thing I wanted to do was to install some spare 100x35x10mm heatsinks on the boards for extra cooling. Didn't do it when I realised that the heatsinks would be touching other surface components as well as the bitfury chips. I've only got thin thermal tape on hand, no thick stuff. The main heatsink does the lion's share of the work anyway, and I've now got 4x Scythe GT 1850RPM fans pointing at the boards, so definitely no shortage of airflow (was using a cheap Coolermaster 2000RPM fan before, but it's broken now...). For the airflow they put out, they're pretty damn quiet. No wonder they were a popular choice for radiator fans.

I think that was me? My boards can be a little finicky when setting them to 950mV. What I've done so far is start mining at int:48:2:950 for anything from a few seconds to a few minutes, and then change to int:53:2:950. Got this automated using CGWatcher (in Windows 7) to begin mining on startup at 48:2:950, and then switch to 53:2:950 after three minutes (the smallest time increment possible with that program).

Lately however, they haven't been reliably starting this way. I've had to manually toggle between 40:1:850, 48:2:950 and 53:2:950 before they can run at 53:2:950. Made a few batch files to make this easier.

BTW, got a lovely 42 degrees day coming up on Saturday (EDIT: been updated to 43 degrees, wat...). Either gonna run the boards at 850mV or just turn them off for the day. Yay!

Others with this problem as well: http://drillbitsystem.com/forum/index.php?topic=184.msg1619#msg1619

Reverting to 3.8.1 seems to have fixed it.

Not getting this problem with my boards on Windows 7.

Same here with three 8-boards. All running great for the past three days. No snap crackle or pop. The only minor issue is that one of them is a brat and only runs at int:53:2:950 (gives 20GH/s) if it is first run at int:48:2:950 (gives ~15GH/s) for a few seconds. I've setup cgwatcher to handle this automatically by running it at 48:2:950 for a few minutes on startup, before restarting the miner and switching to 53:2:950.

My dead board has also been posted back to Barn already, with a replacement to be sent out soon thereafter. Thanks Barn.

I didn't get a tracking number. Just turned up on my front step at 9am. No complaints about the speed of shipping of course, but notification that the board was on its way would've been preferable (theft, rain etc.)

Yeah I'm a bit disappointed losing one board, but I've still got three good boards churning out ~56GH/s, and I've added another fan on it which has lowered temps by a few degrees celsius. As long as none of them go kaput as well (touch wood!), I'll still break even dollar-wise within two months. Just need to get the dead board repaired.

Update from Barntech. Linky: http://drillbitsystem.com/forum/index.php?topic=206.msg1332#msg1332

There's no harm talking about it, but there is with finger pointing based on assumptions. *IF* what thomas_s is saying is true, then surely the boards would've been screwed either way.

Fingers crossed.