1. Install screen and pgrep
2. Create "cgminer" user (assume /home/cgminer is home directory for new cgminer user). On debian-based systems you probably need to add cgminer to the plugdev group ("adduser cgminer plugdev").
3. Login as cgminer user (possibly via "sudo su cgminer" etc)
4. Setup /home/cgminer/.cgminer/cgminer.conf
5. Test that running cgminer with no command line options does what you expect.
5. Create /home/cgminer/daemon.sh


daemon.sh checks if the "cgminer" user is running a program called "cgminer". If so, then nothing happens. Otherwise it starts a new detached screen session running cgminer. You may have to adjust $HOME/bin/cgminer to your machine. (I use ./configure --prefix=/home/cgminer and make install so my cgminer binaries end up in /home/cgminer/bin/cgminer)

6. chmod +x /home/cgminer/daemon.sh
7. Add the following line to the crontab to run /home/cgminer/daemon.sh every minute (run "crontab -e" as cgminer to edit crontab)

In the future I'd like to add use of a chroot, but I haven't had time to work on that yet.

You can isolate whether it is the Jalapeno startup or changes in 3.4.0 by comparing hash rates with your previous version of cgminer.

I think the margins on hardware are going to be much lower. There was a lot more to throw around when USB Eruptors were 2btc/each (and blades priced equivalently). Margins are going to be crushed.

The biggest threat is that the mining calculators got much, much better so buyers can see what's up.

I've been away for a while and decided to give 3.3 another shot since kano et al are singing its praises everywhere.

3.3.4 using libusb-1.0.16-rc10 compiled from sourceforge still shuts down half of my 4x AM USB eruptors when running on Debian amd64 with USB disconnects. If there's some sort of logs you would like let me to post, let me know what you would like to see, but compiling a newer libusb absolutely *does not* solve the problem.

Back to 3.1.1 where everything works fine.

Allow me to posit a conspiracy...

We do know that AM was the target of the DDoS attacks that were patched recently in bitcoin-qt. So, clearly AM's mining operation is in someone's crosshairs. It's entirely possible that there is a shadowy pool-level collision to preferentially ignore/delay acknowledgment of AM blocks, or perhaps some new form of network attack that disadvantages propagation of AM blocks. That could explain the orphan rate, and AMs use of new IPs and the lack of tagging.  

Volume was up quite a bit even before burnside made that post. But AM ranges 0.3/day quite often. I guess I just wouldn't have called that a "crash" when it still fits within normal variance and doesn't look extraordinary when staring at the charts. I even doubt it's lower than it was this time last week. But if you want to feed a panic so you can buy, by all means go ahead.

Now, if you want better reasons to sell, perhaps the batch of 10,000 Avalon chips buys that were delivered today. http://thegenesisblock.com/10000-bitcoin-asic-chips-arrive-in-switzerland-3-ths/

What crash?

I would expect something like "-I /usr/include/libusb-1.0" in the compile command. Maybe you need to re-run ./configure?

On debian-derived systems you can install the apt-file packages to allow search for packages that provide specific files.

Your error message is about missing libusb.h. I'm not on a pi, but on my machine:

I'm running p2pool/bitcoind/altcoinds/cgminer on an Intel Next Unit of Computing with a Celeron 847 @ 1.10GHz, 4GB RAM with 4x AsicMiner USB Eruptors. I had to move the blockchains (bitcoin, devcoin, namecoin, ixcoin) to an external USB hard drive (system drive is 32GB SSD). It took some tweaking, but my get work latency is ~0.2-0.3 and I see DOA of 1.5% and 101.5% efficiency. CPU load seems pretty low (~80-90% idle mostly). Seems fine to me. Biggest problem is that my share luck seems to be inversely proportional to p2pool's block luck.

Yes, I concluded it was the desired behavior. Just being complete in reporting everything this time. I mostly wanted to clarify that the problem does indeed exist without USB 3.0 anywhere in the picture and it only seems to show up when more than one eruptor is installed. When the other user mentioned a problem when using an eruptor+fpga, it made me think that perhaps there's just some problem using eruptors with multiple devices on 3.2.x.

I know you have a large eruptor setup. Are you running 3.2.x? Your recommendation to someone else to run 3.1.1 a while ago is why I ended up trying that. (I saw you mention your eruptor farm in a p2pool thread and went through your post history to see if I was missing a step--initially I suspected a p2pool problem, but the 3.1.1 recommendation was on the money)

Oh, right. I forgot to mention that I excluded the hub as the problem before going to 3.1.1 by reproducing the findings with the USB Eruptors plugged in directly to the computer. I observed the same behavior where individually they work fine but if two were installed each device would mine for a bit and then enter into some sort of standby mode with solid leds (they don't both enter that state at the same time--one will get there sooner than the other). Then after a few seconds both will start hashing again simultaneously. That pattern of hashing in spurts and stalling just keeps repeating itself. I didn't time it but my guess is ~15-30sec. The computer itself is an Celeron-based Intel NUC that only has USB 2.0 ports.

I don't know if it matters but the the second miner came from BTCguild and was "branded" (I assume via the Luke-JR method) but the first comes from CanaryInTheMine and is unbranded. cgminer's udev rules seem to work fine with both as far as I can tell.

Looking back through the logs did finally notice one thing. When running the 3.2.x or github version, this happens once per reboot when cgminer is starting up:

Jul 16 00:47:02 xxx kernel: [   10.527272] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
Jul 16 00:47:02 xxx kernel: [   10.527304] cp210x 2-1.1.2:1.0: device disconnected
Jul 16 00:47:02 xxx kernel: [   10.588515] cp210x ttyUSB1: cp210x converter now disconnected from ttyUSB1
Jul 16 00:47:02 xxx kernel: [   10.588549] cp210x 2-1.1.4:1.0: device disconnected

When this happens /dev/ttyUSB0 and /dev/ttyUSB1 disappear and never return. But cgminer 3.2.x is still able to hash in spurts. I had to reboot to get 3.1.1 to work.

Opps I think I meant 3.3.1, but mostly I meant latest master from github (805672fb51f4219e8c5848dc761509d32bffde9f -- I think it identifies itself as 3.3.2, sorry I forgot it wasn't released yet). I tried master from github first when I couldn't get 3.3.1 to work. I was about to blame the hub when I decided to try building 3.1.1 as a hail mary.

I've had a similar problem with cgminer from github on x86_64 debian 7.1 (wheezy) trying to get two AsicMiner USB eruptors to work (via Satechi 10-Port 5A USB 3.0 powered hub http://www.amazon.com/gp/product/B00B9KOCYA).

The setup works just fine with a single USB eruptor (either of them). When two are plugged in it behaves as you describe where the USB eruptors will each mine for a bit and then drop into standby mode (solid green LED) for a bit before starting up again. No errors in dmesg or anywhere. The effect for me was that mining with a single eruptor would give 330MH/s, but mining with two would give 215MH/s.

I finally solved this yesterday by downgrading to cgminer 3.1.1 (had to compile from source because libraries were missing in debian 7.1). They now both hash at full speed.

I guess it'll work as an upper bound (the sales dividend could not be greater than that), but we don't know the cost to produce the devices.

I just let mine graze on federal land.

There's a thread on reddit where they think they've found his facebook/photos. The evidence seems somewhat tenuous. It may well be old and discredited news for all I know.

I found the following mildly amusing in this thread's context:

https://en.wikipedia.org/wiki/Sycophant#Shift_in_meaning_in_modern_English

I'm not sure Xian01 intended either meaning, as both could apply only to BFL critics.

Ha! I'll just use it to compute my salt for pretty hashed passwords.