The final driver will be just part of a regular cgminer release so you can do whatever you want with it, so running it from any sort of PC or embedded device that can run cgminer would be fine. To run the stratum server as well as the mining software it'd probably need to be a real PC though, as the RPi isn't really up to that.

Thanks for your approval. Remember I just write the software though and have no control over the how when and what of the hardware performance, delivery, price, schedule etc. etc. My sum input into the hardware is only to do with the communication protocol and some input into how the microcontroller works. For my part, I have been pleased with what I've been involved in. That should not be taken as any kind of comment positive or negative about the hardware.

By default cgminer does not write a single thing to disk so unless you turned on some kind of logging, you're doing something else.

cgminer 3.5.1 is out which should fix this problem.

New release: Version 3.5.1, 11th October 2013

I've temporarily branched the stable code into a 3.5 branch, making this release a stable release update with a few minor improvements and bugfixes while the main code branch undergoes more radical change. The master branch is incorporating asynchronous transfer code and has a new locking scheme designed to allow much better concurrent reading/writing to USB devices.


Human readable changelog:

- Fixed a couple of hangs when shutting down - you will no longer get temps and fanspeeds in the final status line on shutting down, but at least it won't hang.
- Failed connect to stratum as a message will only show in verbose logging now.
- Smoother reporting of hashrate on BF1 devices.
- Fix for the crash when --usb BAS: or similar commands were used when the relevant driver wasn't actually compiled in.
- Fixes for CMR
- Slower USB devices that die/are unplugged will now properly zombie.
- A few more failure checks on starting BF1 devices.
- Serious USB read or write errors will now be accompanied by a message during regular logging describing the error.
- USB errors now use the internal libusb explanations.
- Fixed a bug where some devices would never start hashing if your PC was up for a few days (specifically BF1 devices).
- If we switch away from a pool in failover mode, we will now only switch back to it if it's up for at least 5 minutes to avoid reconnecting to pools that are only intermittently up - good for DDoS situations which we've seen a lot of lately.
- Ztex driver and its bistreams have been REMOVED. No one was maintaining the code, it wasn't working, and it was making release archives much larger than necessary.
- First draft of klondike driver - note binaries do not have this built in since the devices aren't in the wild yet.
- When devices are unplugged on windows, cgminer will cleanly remove them now instead of getting into an endless loop of failing to talk to them with IO errors.
- Statistics on locking delays in usb code (this will be deprecated in 3.6 branch due to changes in the locking design).
- Other internal changes, fixes, low level code for further development.


Full changelog:

- Avoid calling get_statline_before on exit to avoid trying to use it on drivers
in an indeterminate state.
- Avoid calling get_statline on exit.
- Drop logging level for failed to connect to stratum to verbose mode only since
we hit it regularly.
- Use fractional hashrate return values in bitfury_scanhash to minimise the
number of times we return 0 based on hashrate so far to further damp out
displayed hashrate.
- Check for presence of driver name in DRIVER_COUNT_FOUND to prevent strcmp on a
null pointer when a driver is not built in.
- CMR allow sending flash and clock commands
- Kill off threads that have failed using hash_sole_work instead of just
disabling them.
- Make the bf1 getinfo size a macro
- Failing to add_cgpu in bitfury should be a terminal failure.
- Check return values when attempting to open a BF1 device and set the msg size
as a macro.
- Display errors on failed usb read and write and consider sequential IO errors
a permanent failure.
- Use libusb's own error name function instead of hand coding the error names.
- Limit ms_tdiff to 1 hour as a sanity check.
- Try switching pools if for some reason we end up with only idle pools and have
ended up current_pool set to an idle one.
- Check a pool is stable for >5 mins before switching back to it.
- Prevent overflows in us_tdiff and ms_tdiff.
- Change second initialise message on bitfury verbose mode.
- Submitting an ntime offset nonce needs to be done on a copy of the work
instead of the original so abstract out shared components as much as possible,
minimising strdups in copy_work and make submit_work_async work take copied
work, cleaning up code in the process.
- Provide a way for drivers to submit work that it has internally rolled the
ntime value by returning the amount it has ntime rolled to be added.
- Typo in configure.ac
- Remove unmaintained broken ztex driver.
- Icarus CMR2 detect FPGA setup
- Icarus - use a data structure for I/O rather than magic numbers
- klondike correct cvtKlnToC() temperature calculation
- klondike - correct 1st reply debug based on define
- klondike - debug dump structured replies
- klondike - avoid division by zero if maxcount is unexpectedly zero
- klondike store and report errorcount and noise
- klondike - fix chipstats api stats buffer overrun with 16 chips
- klondike add new nonecount only once
- klondike - report mh/s based on nonces found + put old estimate into API stats
- klondike use a memcpy
- klondike fix bracket tabs indenting
- api.c missing Klondike from ASIC list
- Add 2nd CMR to 01-cgminer.rules
- Add Klondike to 01-cgminer.rules
- Klondike to main directory
- Klondike consistent code spacing
- Klondike update driver code to current git
- update firmware for 16 chips, add dist files
- beta final 0.3.0 release
- updated firmware, IOC method
- prevent nonces when not state W
- added driver config option support
- fixes for 300 MHz, fix K1 parts list
- update driver, docs
- update firmware & utils
- updated cgminer driver for 3.3.1
- update firmware and driver, create new cgminer fork
- update klondike driver
- add cgminer driver file as-is
- Get statistics on how long usb reads and writes wait on the devlock.
- Display stats regarding locking delays in API.
- Disable bitfury device thread on it disappearing.

The device doesn't exist yet so no idea where you saw that.

No

No

There's a bug in 3.5.0 where if you start BF1s after your machine has been up for a while, they will refuse to hash. The fix is to reboot your machine until I get a new version of cgminer out. If your BF1s are already hashing you will not have this problem.

I don't understand how the main branch doesn't fix it but you using libusb-1.0.16-rc10 fixes it since it has the same code... unless you are benefiting from using the async code that's in that branch? In that case, the 'async' branch, which uses libusb-1.0.16-rc10 and async code should do what you want without you wedging in another libusb. As for the autogen fix, I know, as I've only said release tarballs work. I'm not an autotool wizard and building on osx is something I rarely get to do when I steal my wife's work laptop.

Master branch uses that exact code. The libusbx branch was for experimenting only. Do you have the timeout error messages with the master branch?

Here's my thread regarding suggested difficulty settings. Read it carefully for there is no right or wrong value and you will not be losing money or efficiency regardless of what the setting is.
https://bitcointalk.org/index.php?topic=274023.0

Use --load-balance with the quota command instead of url and set the quota for each

--quota "1;url1" --quota "1;url2" --quota "1;url3" --quota "7;url4"

As the docs clearly state, it works with arbitrary quotas, so you could have also used "10;url" with "70;url" for the same effect.

Read from here onwards:
https://bitcointalk.org/index.php?topic=18313.msg3294238#msg3294238

Nope. KFC support cgminer on their own fork and have yet to reveal their sauce.

Dupes should be close to zero. Earlier avalon firmware had design problems that caused dupes and updating firmware should fix it.

No

It should not be dramatically different, and the one cgminer driver should run either of them fine based on how the microcontroller design has evolved.

I've only seen emulation hardware so far.

I can answer that: Yes.