Thanks- I updated the first post with the information and gave you credit. 

Seems this thread has made the cryptomining blog as well....sweet!  http://cryptomining-blog.com/2788-should-you-modify-your-zeusminer-blizzard-scrypt-asic-or-not/

Actually I'm using one controller for the gridseeds, and one for the fury's.  The controller on the left is going to the hub right behind it that has all the gridseeds plugged into it.  The controller on the right is the one the Fury's are plugged into.

I am however running 2 instances of cgminer.  1 per fury right now.  If I run 1 instance it seems like 1 fury will run fine, the other runs retarded.  With bfgminer, both fury's run slow and never seem to get above 500khs. 

I did have them plugged into the gridseed controller which is running Minera and the rpi was able to handle running Minera, cpuminer (7 gridseeds), and 2 instances of cgminer...and it never broke 3.8 on the cpu usage. 

Here's a pic of the full cabinet.

Got my second fury finally.  I did the voltmod after a quick test and then sandwiched them together with a small fan on one end to blow through them like the gridseeds blades.  This weekend I may make a shroud to fit an 80mm fan to blow through.


Running in my mining cabinet....son to add more.  Gridseeds are on the shelf below...I had to Make a cabinet with good airflow and doors that can shut to keep the damn cat from playing with the wires.


2nd post updated with the dimensions of the chips and a pic edit reference.

We're WAY passed a low clock speed of 328 in this thread.  Those of us that have done the voltmod are sitting at 381 with low error rates and are working to find a way beyond 381.

Nice review though

It's the way the chips were designed actually.  They were designed to dissipate heat through the bottom of the chips which is why the heatsink portion of the case makes contact with the backside of the circuitboard (albeit a bit poorly...they should have either used a bit more thermal paste or a decent quality thermal pad like the Gridseed units).  This is where the majority of the heat will be dissipated so that's why the tops of the chips were left untouched.

I agree on the poor design....ideally they should have made a heatsink design which sandwiched both sides and was clamped or bolted together by the fan bolts.  Gridseed did it.  Video cards do it.  Many industrial applications do it that way as well.  But it all boils down to compromising performance vs cost. 

I think it's do-able....but the question would be is how much more power would it require?  And would that increased power consumption be worth it?  For those that don't pay for electricity...maybe...

Yes...the clock speed barrier is a real pain in the ass.  These things can handle more than "just" 381Mhz.  Other than the clock speed I can't think of anything...you do an awesome job with fixing what the manufacturer shouldn't have left a mess in the first place.  I'm hoping the limit can be lifted via software...otherwise it looks like we're on the way for a hardware based clock boost.

Also - for whatever reason bfgminer 4.2.1 has an "issue" with manicminer.in pool.  I can point bfgminer to nicehash and things work ok.  Point it to manic and nothing happens.  No accepted shares, no hashrate, nothing.  It's very odd.  I've cloned and compiled from your git source and the same thing happens.  Like a moron I didn't do any debug logs though.  I'll see if I can get those today if you need them.

Remove the overclock limit?  YES PLEASE!!! 
cgminer or bfgminer...I don't care which.

although...it seems that bfgminer has a problem with manicminer pool for whatever reason.  I can point bfgminer to nicehash and it works fine...point it to manicminer and it just sits at 0mhs.

We're here to push the limits...we don't need no stinkin' safety measures!

That looks like the max speed is set to 382.5

I don't think the work units are decreasing because even if I just change the speed to 382 the number of accepted shares plummets.  At 381 I get accepted shares immediately but at 382 it takes a minute before a share is accepted and then a couple more minutes go by before another share is accepted.  At 381 it's a steady stream of accepted shares.

I've tried two different pools.  Nicehash and manicminer.  Manic lets you set the diff manually and I think nicehash is vardiff if you don't set the diff in the password.  Same behavior for both pools.

Looks like raising the max clock doesn't do much.  Past 381 and the hashrate goes up but the number of accepted shares drops like a rock.

There's something about that 381 ceiling....I'm still out but when I get back I'll see if I can find anything else with that 381 limit.  Looking at code on the phone sucks.  It was bad enough remoting into my machine from the phone to change the speed back to 381.

Right now it's compiled for the rpi.  
I think to use it with Hashra would require quite a bit of re-work to the Hashra frontend system itself because right now Hashra uses cgminer.  If the api calls are the same I suppose you could just make a backup of the Hashra cgminer and rename bfgminer to cgminer.  I'm actually using Minepeon right now since bfgminer is the default miner for it and it's a 'drop in' replacement at this point.

Also...it seems to be working.  
Clock is a "conservative" 400Mhz right now....hashrate is 1.65mhs-1.76mhs.


Dropbox link to the rpi binary:
https://www.dropbox.com/s/65qcs6vv5qxi3pv/bfgminer-oc


Enjoy...I have to leave for a while...but I upped my clock speed to 450Mhz and will let that run while I'm away.  Feel free to download my compiled version and test.  The only thing I changed was the max clock speed.  Otherwise it's a direct pull from darkwinde's github.

I'm crazy so I edited the driver file with a max speed of 1000mhz.  I figured that should give a good enough ceiling for testing.  It's compiling now...hopefully no errors.
I'll give it a quick test run and if it works, I'll throw it on my dropbox and give you guys the link.  If not...well...I tried 

call me crazy (and many do)...but that looks like it's hard setting 381 as a max....which would explain why 340mhz gives 1.4mhs....354 gives 1.51mhs...and for whatever reason...500mhz gives 1.52mhs....

Good find....I'm going to set my clock back from 520 down to 381 and see what the hashrate looks like in the minepeon I've been using.  It does report a higher hashrate than Hashra/Cgminer....  I may make a change to that and recompile as well to see if there are any differences.

Nice find

That's correct.  6k resistance, 1.54v, 520mhz.

Now - with Hashra and the version of cgminer it uses I was only getting a reading of around 1.5-1.52Mhs @ nicehash at 520Mhz.  Anything above that was just plain buggy.  Hashrates would be misreported, etc.

I just finished setting up Minepeon and updating the bfgminer it uses to the 4.2.1 from Darkwinde with the new updates for Zeus chips.  At ~20min runtime it is showing 1.634Mhs at 520Mhz.

Both cgminer and bfgminer report around a 4% error rate at the 520Mhz speed.

I'm going to let it run like that for a while as I go do some yardwork.  I'll come back after I'm covered in grass clippings and see where it's at.  I'm also ordering a killawatt meter...'bout damned time 

Right now (with Hashra and cgminer) it seems to top out at around 1.5.  It also depends on the pool I'm mining at.  If I mine at Nicehash, I get a slightly lower hashrate (usually around 1.4-1.5) with a LOT higher number of rejects.  If I mine at Manicminer I get  nearly 0 rejects and my rate locally shows 1.51mhs-1.52mhs while poolside shows a range of 1.5mhs-1.95mhs (and it stays above 1.5mhs quite a bit).

I found Minepeon which uses bfgminer as it's mining software so I'm getting ready to try that this morning and put the new version of bfgminer from Darkwinde on there.  People in that thread at litecointalk were reportedly getting higher hashrates with less errors at lower speeds than we are (something like 1.5-1.6mhs at 340Mhz clock).

I updated the first post with the Minepeon link.

You're welcome!  I'm glad they all arrived intact through the shipping process. 
3Mhs from 6 gridseeds isn't too bad    

Is there an rpi image like Hashra/Starminer/Minera that supports the bfgminer software and not cgminer (or that supports both)?

Newer?  Wow...the one I linked to was from today.  They're working fast.