That math is incorrect; it will handle 10 Erupter Sticks just fine.  Look for my post earlier in this thread about that hub.

In fact, I bought that exact hub and it's sitting waiting for my sticks to arrive

My order also shows Priority Mail, but if I still get them Tuesday I see no reason for a partial refund.

Thank you for all your hard work, arklan.

Uh oh ... dogs ... computer fans ... dog hair ...

Very cool stuff, pusle and TheSeven!

It won't get close to current generation ASICs, neither in power nor cost.

With the current open source designs for Kintex-7, a quad board would get ~2GH/s, though I suspect 4GH/s is possible when more hashing cores are rolled into the design.  Power would be less than 100W at 2GH/s.  Price?  Well K160T chips are ~90$USD each so maybe a BOM of 800$USD?

A quick test showed that my silver unit consumed about the same amount of power as the black ones; no significant difference.  All units are running around 600W at 300MHz, Temp3 ~47.

Hello goxed!  I just checked your pull requests.  There are no code changes in them.  One just adds a file named "600MHz" with the text "600MHz" in it.  The other is the same.  There must have been a mistake somewhere.

They shouldn't be hardly close at all.  The toggle rate of a SHA-256 hasher is significantly higher than typical FPGA designs.  Without a simulation to extract toggle rates from, Vivado's power estimator will do a very poor job.

Just a note, that temperature reading is coming from the die itself, so it should be fairly close to the "real" temperature of the fabric.  The chips aren't designed to operate continuously above 85C (though I think they'll tolerate something like 100C without immediately failing).  Personally, I'd throw an extra fan at my KC705 if the Kintex was running near 76C.

Looks normal to me.  Almost all FPGA/ASIC designs have corner cases where they'll produce incorrect results; it doesn't affect actual hashing speed.

I plan to do some maintenance on my farm later, so I can check then, but I distinctly recall EPS_12V_2 not being connected on my Avalons.

The errors you mention:


Those are the same errors one of my Avalons was spitting out.  I narrowed it down to a bad TP-Link.  I have that unit running off a RaspberryPi with no issues now.

So, I would suggest plugging your Avalon into a PC and running cgminer on there, to test and see if your TP-Link is busted like mine seemed to be.

Status Update on my Batch #2 units:

All units are still running smoothly, cgminer hasn't restarted in over two days, and the last restart was performed by me to change the clock to 300MHz.  All units have been running below 50C on Temp3.  I have an A/C unit cooling them to bring the temps down to 45C.  Power consumption at 300MHz is floating around 600W for each unit.

The one unit that was giving me trouble (faulty TP-Link) has been running off my Raspberry Pi with no issues.  I'm even able to work and do some development on the RasPi, while the unit continues hashing away.  I wrapped a start-up script around cgminer to provide it with a YAML configuration file, and hook it into systemd, so it restarts instantly if it dies or the RasPi reboots.  I also developed my own web interface running on the Pi so I can monitor cgminer and a few other things.  The data on the web-interface auto-updates, which has been an amazing feature that LuCI running on the TP-Link seems to lack.

Hey arklan!

You're awesome!

That is all.

Good news regardless! 

cgminer-monitor is looking at the hardware's Diff1Shares, not shares submitted to the server, so difficulty shouldn't matter.

Thank you for your feedback!

The application I'm using in the demo is a modified Bitcoin-QT client; so it's the "stock" Bitcoin software modified to talk to the Titan.

Right now, it's as simple as running a Python script.  The Titan will then ask for a Backup Password.  Once done, the encrypted backup will be saved on your computer as a small file.
Restoring is similar; another Python script.  Specify the backup file, enter Backup Password on the Titan, and it will be restored.

I plan to integrate the backup process into my modified Bitcoin-QT, to make it more user friendly than a Python script.

Also, the wallet is deterministic.  That means a user doesn't need to constantly update their backup.  So typically a user would create the backup when they first use the Titan, keep the backup in a safe place, and then rest assured they are safe from any failures or theft.

Actually, it's 12V@4A.  USB is 5V.  It's best to measure power (Watts) in this case.  12V@4A provides the hub with 48W of power.  Each Block Erupter stick consumes 2.55W, or 25.5W for 10 sticks.  That's well within spec for the hub.

But don't take my order for it, the product description lists the limits:


10 sticks will only draw 5.1Amps at the ports.

That said, anything could happen when the metal hits the electrons, so time will tell.

I got tired of my mining rigs just making "whoooooosh" sounds.  So, I fixed it:

https://github.com/fpgaminer/listen-to-bitcoin-mining

http://www.youtube.com/watch?v=36zCtFHEOrg

I haven't checked the reference design docs yet, but my empirical understanding is that the yellow light (being on) indicates that the ASICs have no work.  (Specifically, I imagine the controller board is out of work to give them).  If that light is coming on a lot, your machine is going to under-perform.

As for cycling on and off, since the yellow light is coming on, then indeed the unit is slowing down its fans because there's less heat being generated.  That said, when you finally do get the units running smoothly, you should still hear a little cycling of the fans.  Mine rev up and down slightly every couple minutes.

As for solving the dread yellow light, you'll need to figure out why the modules are running out of work.  Either A) the pool isn't giving enough work, or B) the software is glitching and constantly restarting.  Pull up your Cgminer Status and check Elapsed Time in the upper left.  If that is consistently below 30 minutes, then the software is glitching and being restarted.  Let me know if that's the case and I can post more steps to diagnose that.  If Elapsed Time looks good, look at the pool stats to see what's up.  Probably try other pools, check your local network connection, wifi, etc.

Does anyone have video of Yifu's talk?

The troublesome unit ran with a RaspberryPi all night and had no issues that I could see.  I don't have a hashrate grapher set up yet, but there were no errors displayed by cgminer, and the average hashrate was a sold 66 GH/s.

I then reconnected it to the TP-Link and let that run for half an hour.  Same problems.  So it's most likely a bad TP-Link.  She's back on the RaspberryPi, and I'll just keep it there.  I may even connect all the Avalons to the RasPi and/or BeagleBone Black.  Thanks to the little holes in the Avalon's case, it's easy to bring out the USB cable and still have the case closed.

So now I'm porting over all the misc. Avalon scripts to the RasPi, and looking around for a useful web interface so I can get quick stats without ssh-ing in all the time.

Little do you know, I have a special anti-static carpet.