By the way, the first official cgminer fully supporting these devices is 3.12.3, and only one command line based on frequency is required instead of the numerous command line options all other software seemed to copy from each other:
--anu-freq 275
will get you 2.2GH. Most will run reliably with much lower hardware error rates at 250 but also lower hashrates.

Intel

I just posted the source into the cgminer git master tree.

I should add the cointerra device+protocol+driver has the most advanced work model designed for p2pool or similar networking and bitcoin transaction propagation with virtually seamless work restarts for rapid frequent block changes such as those required by p2pool, along with flushing of any queued work on a work template update such as that which occurs regularly with stratum update so it will always be working on the most current work - meaning it is optimised for maximum transmission of transactions, provided the pool is updating its work template frequently with new transactions. Kudos to the cointerra team for adopting everything I recommended in their work transmission/protocol.

Cointerra driver now merged into the cgminer master code. Numerous generic fixes from cgminer itself likely are in the cgminer master code based on cgminer 3.12.3 that are not in the standalone software released with the hardware in the beaglebone black. Without actual hardware it is distinctly possible there are bugs I have been unable to reproduce and debug so far, so if you wish to give me access to hardware to mine with it to test the software, please pm me.

Cointerra developed the communication protocol entirely based on my discussions with them and the driver for cgminer I wrote completely. Once hardware is in regular customers' hands I will push the driver to the master cgminer code. They are straight forward USB devices that are connected to a beaglebone black for standalone operation but you can unplug the beaglebone and plug a regular PC into their USB. I personally do not have any hardware yet, as I have only worked on them remotely.

You don't own any mining hardware it seems. Your PC hardware itself does not mine, it runs the mining hardware that you attach to it, and cgminer will connect to the pool happily waiting for you to plug in hardware that it recognises so that it can hotplug it.

Windows XP struggles with devices that look identical to it, and falls over with more than 8 of the same device. You may never get all of them working well on that OS. Furthermore power could well be a problem as said.

Pretty suspect >_>

Sounds like a botnet. No what you want doesn't exist for cpuminer.

That's reassuring. The only change from the one you tried earlier was me generically adding usb resets for when the device has a communication error, which means these resets are probably actually purposeful.

Know nothing about that hardware, maybe Kano might chime in.

Heat's usually not the limiting factor. Without a hardware voltage mod you're unlikely to get them to 300 even.

You don't have any mining hardware attached to your PC... cgminer mines on dedicated mining hardware. The PC is just what drives the hardware, it doesn't do the mining.

That's okay. Firmware release is out of my domain and up to HF so no idea but hopefully very soon.

Yes that's a typo, it's meant to be MHz and I accidentally wrote hex. Why do you need a table when it's a single meaningful value in MHz ? The whole point was to move away from the needlessly complex configuration involving hex values and just type in a value that means something.

Thanks I didn't know that. I meant for you to modify it and report back lol, but I will eventually get around to adding some more frequencies.

If there are backup pools, it won't go back to the first pool until that one has been up for over 5 minutes, as a "stability test". This prevents cgminer from trying to connect to pools that are limping along and dropping out every 2 or 3 minutes during DDoS and so on. It's very easy for your hashrates to dive under those circumstances if you reconnect immediately to a pool whenever it comes back up.

The documentation specifies only certain numbers, have you seen anywhere the values you mention? It's easy to hack the code if you wish to try them and report back

But they're still mining right? So the die - zombie - hotplug is just an ugly cosmetic issue, not that they have failed and stopped mining indefinitely. I've been running mine at 275 (2.2GH) which has been stable but I doubt they're all stable at that speed.

You are in completely the wrong place as this is the main forum thread for the master cgminer code which is purely for bitcoin mining ONLY. We have no keccak code and wherever you downloaded that from is where you need to seek help.