Just curious as to if anyone has tried this with Klondike units. The change log didn't provide specific references to them and I'm not home to test it out.

Regarding the non-hashing or zombie units - Still using cgminer 3.7.0, I have clocked them back to 300 mhz per unit and still there would be 1-2 non hashing units that would creep up after a few minutes from initialization. The units that stop hashing are physically random (eg: first run unit 9 and 11 would stop; or second run unit 2 and 8 would stop and so forth).

edit:
I've noticed that the unit goes bad due to a usb write error. Don't know if anything came across this usb issue?



Perhaps if there is someone who is running these units with no issues, are you using a usb hub? I'm thinking the hub might be the culprit. Using Dlink 7 port usb 2.0 hub > 5 units per hub.

I agree, 3.7.0 is probably the best one right now for stablity. Currently everything is clocked at 350, there isn't anything unusual about temperatures either.

This is exactly what happens after about 30 mins of running:

Posted this in the Klondike thread, no response yet, try my luck here. Sounds like some problems could be related or similar

I hope someone has an answer to these questions:

Currently I run 14 KLN units. There seems to be 2 issues that I run into.

First is the KLN: went idle before work was sent error:

As far as the resources on the Klondike page http://projectklondike.org/, the reason is known, however, as I run a windows 8 environment there isn't really an easy way for me to recompile the drivers. Is there any other solutions to reduce these errors? Future cgminer updates will address this?


The next issue that I seem to keep running into is stability/performance of the units:

Unless I power up the units a certain way, I tend to get a lot of zombie KLN units, or units that are plugged in, however, does not hash at all (zero hash rate, zero work units). Upon system startup and powering of the KLN units, usually all units hash. Eventually one or couple of units will stop hashing at all after a certain period of time (the unit that goes idle is random, physically speaking). As I have 14 units, cgminer should show the units as KLN0-KLN13. The units that go bad will eventually keep trying to redetect itself, and the ID of the unit will keep climbing in cgminer (eg: from KLN13 to KLN253).

Is it possible that this issue be a possibility of USB overload? I have 3 units connected to USB ports in the back pane, 5 units connected to one USB hub, and 6 units connected to another USB hub. Temperatures are under 50c

Thanks for any assistance or knowledge on these matters Smiley


edit:
Nov 19
-Tried cgminers different versions 3.50+ to latest, no success.
-Only 1 miner was not hashing in the above USB configurations. Plug only 5 USBs in each of the 2 hubs; remainder plugged into the back pane of computer. Currently everything hashes, except two units are hashing at half the rate expected. Using cgminer 3.70.
-1 of the half rate hashers completely stopped hashing after 30 mins.

I hope someone has an answer to these questions:

Currently I run 14 KLN units. There seems to be 2 issues that I run into.

First is the KLN: went idle before work was sent error:

As far as the resources on the Klondike page http://projectklondike.org/, the reason is known, however, as I run a windows 8 environment there isn't really an easy way for me to recompile the drivers. Is there any other solutions to reduce these errors? Future cgminer updates will address this?


The next issue that I seem to keep running into is stability/performance of the units:

Unless I power up the units a certain way, I tend to get a lot of zombie KLN units, or units that are plugged in, however, does not hash at all (zero hash rate, zero work units). Upon system startup and powering of the KLN units, usually all units hash. Eventually one or couple of units will stop hashing at all after a certain period of time (the unit that goes idle is random, physically speaking). As I have 14 units, cgminer should show the units as KLN0-KLN13. The units that go bad will eventually keep trying to redetect itself, and the ID of the unit will keep climbing in cgminer (eg: from KLN13 to KLN253).

Is it possible that this issue be a possibility of USB overload? I have 3 units connected to USB ports in the back pane, 5 units connected to one USB hub, and 6 units connected to another USB hub. Temperatures are under 50c

Thanks for any assistance or knowledge on these matters


edit:
Nov 19
-Tried cgminers different versions 3.50+ to latest, no success.
-Only 1 miner was not hashing in the above USB configurations. Plug only 5 USBs in each of the 2 hubs; remainder plugged into the back pane of computer. Currently everything hashes, except two units are hashing at half the rate expected. Using cgminer 3.70.
-1 of the half rate hashers completely stopped hashing after 30 mins.

224 chips worth ordered. Payment and email has been sent.

Thanks!

Well it would be nice if the board developers will accept BTC as payment. But we'll have to wait and see won't we?

Greetings! Personally I've just started mining recently as well.

I'm curious as to why anyone would like to mine with a large set of these USB farmers when they could simply throw their money for the full blade version for much better performance. These little things are cute and all but as many said, they aren't worth their price to performance... other than for novelty purposes I suppose

Hello and greetings! I should have signed up ages ago...

Newb as well. Hello!

Posting as newbie!