I'm running a Bitfury miner with a stratum proxy (on the EU pool), and there haven't been any interruptions.

The site has been operating for ~3 months now. That's the total profit. Nobody can guarantee what the future profits (or losses!) will be.

Allowing users to set a minimum difficulty would be great. I can't be the only miner who doesn't like the idea of constantly changing difficulty. On BTC Guild, I can practically use a fixed difficulty by setting my minimum difficulty high enough. On BitMinter, I often ended up close to the threshold of two difficulties, and kept flipping between them indefinitely. I'm pretty sure cgminer handles that situation well, but being able to set a minimum difficulty would guarantee it.

I renamed a worker over 30 minutes ago, but the change still hasn't taken effect. I can only connect using the old name. I'm using the EU server.

EDIT: Funny, the rename finally took effect after I posted

User id: 2137

I'll gladly gamble the bitcent.

It's almost impossible to view or toggle some of the coins on the last pages of the list under the graph, because it resets to the beginning constantly (and also after each toggle). Using FF24

I tried that first, but the configure script doesn't pick it up, presumably because I need to have a version compiled for arm. I'm no cross compilation expert, but that's what worked for me with libusb and libncurses. I downloaded those libraries, cross compiled them for arm and installed them to a specific directory. After pointing the configure script to search for libs and headers from that directory, the dependencies were detected.

If you have managed to cross compile cgminer without having to cross compile libudev too, I'm obviously doing something wrong here.

Does anyone know a good way to cross compile libudev, so I could keep on cross compiling cgminer for ARM? I had no trouble compiling libncurses and libusb previously, but it looks like libudev has been integrated to the massive systemd project. Obviously I don't need to compile the whole systemd, but I just can't figure out how to compile libudev only.

At least have the decency to say why you're asking this, mr. Integrity:

https://bitcointalk.org/index.php?topic=289316.0

Is it just the hashrate reported by the pool that drops, or does the device itself become slower?

Thanks! I set my minimum difficulty back to 32 and restarted the proxy, working correctly now.

You could be having a different issue, but I noticed the stratum proxy is behaving strangely with BTC Guild. If my minimum worker difficulty is set to 1, the proxy correctly picks up when the difficulty quickly increases, and doesn't try to send shares which don't meet the requirement. However, if I set the minimum difficulty so high that it never has to be increased by the pool, the proxy keeps on thinking that the target is diff 1, and sends every share to the pool. Obviously most of them get rejected, and this might even overload a router.

I didn't have any actual problems with this, though. BTC Guild always reported my full hashrate, even when I was flooding it with tons of rejected shares. Of course flooding the server isn't exactly nice for the pool OP

pool.coinlab.com:8332
redeem_yourusername

I've been mining on this pool with a 46 GH/s Bitfury ASIC miner for a few days now. I noticed that my hashrate reported by Bitminter dropped occasionally, all the way down to 900 MH/s. These drops coincided with my share target dynamically dropping to a very low number. Then I noticed that the stratum proxy on the Bitfury ASIC wasn't submitting shares any faster with the lower target. The share submission rate stayed the same as the difficulty target slowly climbed back up to maximum level, and my reported hashrate rose back up to normal levels with exactly the same pace.

After removing the -rt (or --real-target) flag from my stratum proxy, this hasn't happened again. This change results in a slightly higher load on the Raspberry Pi that's controlling the ASIC (because the miner now tries to send every diff1 share to the proxy), so I'm not recommending anyone to do this unless you are actually experiencing the above problem.

From the OP: "After donating, please PM me the transaction ID, or paste it to this thread, so that I know who has donated."

Please go through the threads too.

512MB

Order 220 just received. The august delivery promise was kept, but it was a close call. Got a starter kit with two H-boards, which greatly overdelivers the promised hashrate. The unit is hashing at around 40GH/s (+-3GH/s). Setup was really easy with the simple web interface, I just input my pools there and restarted the miner.



Highest temperature I could read from the H-boards with that handheld meter was 63C.

I'll hopefully post tomorrow, got confirmation that my order #22x was sent today.

Has anyone noticed speed differences between 1.2.5 and 1.2.6 with the same frequency index settings?

2 Units
~8.08 GH/s, frequency index 7, PROCESSOR 3: 15 engines @ 265 MHz PROCESSOR 7: 15 engines @ 274 MHz - Does not start with a higher frequency index, but only 0.5% HW errors with this setting.
~8.75 GH/s, frequency index 8, PROCESSOR 3: 15 engines @ 292 MHz PROCESSOR 7: 15 engines @ 285 MHz - 1.1% HW errors. Results were not so great with index 9: an engine dropped when testing for just 1 valid nonce. HW error rate spiked up greatly, the clocks were a little over 300MHz.