Yes, long ago now.

Perfectly normal, there are new blocks being generated in bitcoin world all the time. Do nothing.

Quick, someone say something about "clock buffers" now.

If you gave knc your btc address, they usually set it up for you mining at eligius with your btc address. You probably mined like that until you had set up the miner to your own pool choices.

There is no cgminer-nogpu executable any more. The current version cgminer.exe only supports ASICs and FPGAs. If you're not even successfully getting your device running, then there's a 100% chance you have not yet set up a driver for it. Read the ASIC-README.txt file included for how to do that.

They'll be water cooled from the factory.

No idea then sorry.

It will only build with gcc. Are you trying to build with a different compiler?

The bi*fury devices which are also 2 bitfury chips generate way too much heat to be passively cooled with their heat sinks. It will be interesting to see if this extra heat sink area is enough or whether a fan is still needed. If the latter, then there really isn't much point to the extra area.

Just to clarify in advance - me getting one will NOT count as delivering a working miner to a customer as I'm contracted by them and not a customer.

Still waiting for them to post their current code before I can see if I can do anything with it. Also I don't know if I'll be able to create firmware for it or just cgminer binaries.

I'm not sure how to respond to such a polite request. Perhaps Kano can answer for me since he has a way with words.

I never sign an NDA. I'm not involved with this chip bring up, but hopefully should see one of their first completed pieces of hardware when it's done.

Update to a much newer cgminer. A lot has changed in that time.

Since the topic of other drivers is coming up more and more often, let me clarify/reiterate the situation regarding mainline cgminer driver support and new devices. If a regular contributor was to come along and prove themselves by extensive repeated quality code contribution to cgminer, I would be happy to include them amongst the official devs for cgminer and add them to the people with git push access to cgminer which currently numbers only the two of us.

If Kano and/or I have been offered new hardware, or offered support to develop drivers for hardware, we will develop and include the code in cgminer and actively maintain and develop it. With various manufacturers we have been engaged on this level at wildly different stages in development. Some very early in hardware development (like cointerra and hashfast), some just before distribution of the product (like BFLSC and bi*fury devices), some after the fact when manufacturer code and hardware has been out for a while (like kncminer and much later for avalon). These examples by no means include everyone. Our involvement in the driver has been proportional to the duration of our involvement.

If someone wishes to develop their own driver and are happy to maintain it for cgminer, they are welcome to submit a pull request for their code to the cgminer git tree - Note that it will not be instantly accepted but usually it's simply a matter of making their code consistent with cgminer and Kano and/or I will provide comments about what changes need to be made for the code to be included. While I can keep the code building satisfactorily with changes to cgminer, the onus will then fall upon the person who pushed the original code to maintain it and keep it up to date since neither Kano nor I can test changes to the driver without actually having the hardware ourselves. If down the track the original maintainer has not been keeping up to date with cgminer, and users report that the driver has stopped working, the original driver author will be contacted for fixes. If no fixes are forthcoming, the driver will then be removed from cgminer (this happened in the case of the ztex driver). With the very rapid pace of development of code in cgminer lately, this can happen all too easily. Historically this sort of code does not stand the test of time.

If there are drivers out there based on forked earlier cgminer code that we have never heard about, and the original author makes no attempt to get the code incorporated into cgminer, that code cannot be meaningfully incorporated into cgminer even if we're made aware of its existence for the same reason we cannot maintain code for hardware we don't have.

Yes, the firmware parameters are not compatible so you'd either have to try changing settings and saving them (not sure if this is enough), or resetting settings to default and setting your machine up from scratch (including the whole network setup part).

Jupiters are standalone hardware. You don't need to download any software to get them running, just power them, plug them in and set them up. cgminer is built in.

Thanks. Yes that's the typical windows fail I've been trying to work around: When there's some kind of usb communication lag it affects everything on the bus. To be clear, when you get zombies, do they eventually re-hotplug for you? They do not for JMC

Not enough power.

Done