Hah!  This sure helps explain a long-standing mystery.. why my 10,000 khash/sec Linux 64-bit machine is the only one that has never, in two weeks, generated a block.

Nice work!

I'd be very curious to know the system power consumption while mining.

It's not hard to imagine that 10 VIA C7's would consume much less power than some of the 10,000 khash/s server-class machines generating heat.

Someone looking to invest in a super-node might find a unique hardware building block in your work.

To ask it another way -- if you *had* generated 50 BTC for your energy and efforts, what would you do with them?

Sadly, I don't think there's a viable anti-abuse system when you have an automated system dispensing coins for free.  (anonymous, irrevocable coins)

The only countermeasure that makes sense is to slow down the value and pace of the whole faucet to where someone has a chance to manually keep an eye on flow.

But coming back to the roots of why it's neat, and what people reasonably get from it, the specific value is not really important.  I see it as more a "system test", where someone can watch coins come in, transfer them to another computer, and so on.  It's not supposed to be "what can I buy with these", but test coins.  Having 0.02 coins is much more fun than having zero.

To that end, a system that dispenses BTC 0.02 and has a significant delay (30 mins?) is less likely to be attractive to even automated abuse plots.

Man that would be cool -- a simple animated video showing how the bitcoin works, and an example of use.
I really believe that most people could "get it" with a simple explanation of the core principles.

I pledge BTC 100 to the first animated explanation that is accurate and, well, explanatory.

(It sure would be nice if there was a tangible mechanism for pledging.  Even if bytemaster or anyone trusted/reputable would designate a receiving account for pledges, that would be good enough to send the coin out for holding.  This isn't exactly high stakes.)

If I remember right, the "lock in" of checkpoints is a relatively new thing in the client.

Interesting, knight.

I thought nice=19 would allocate (at most) 5% of the CPU: (20 - n / 20)  That's how it used to work, but the scheduler has been through some changes.

NewLibertyStandard: It's not hyper-threading, but I'll try running 4 and see what happens to the rate.  I wouldn't have thought...

I ran into a curious issue with the x64 version of bitcoind for Linux.
I have it running on 8 cores, with the task re-niced to "19" (ie, most nice).

However, it still seems to impact performance of the system for tasks such as compiling and executing, to the tune of 2x speed degradation.

Reducing the number of active cores improves the speed of other tasks, but I have to stop it altogether to let other higher-priority tasks run at full speed.  The impact is not subtle -- things that used to take a minute now take two.

I confirmed that the nice level is "19", and the other tasks are at standard "0", yet bitcoind still causes them to take twice as long.

Memory consumption seems reasonable, and it's not swap-happy.

Any ideas?

With the patch above, I was unable to build the test program.  You?

I got the patch knitted in, and I think I did it correctly.. wasn't complicated.

Regrettably, the hash rate has decreased by almost half.  I'm down from 2071 (stock build, svn tip) to 1150 khash/sec with the patch.

It's an Intel Xeon 3 GHz, Linux, with these proc flags:

Has anyone seen gains?

Did I botch it?  Missing CPU capabilities?  Wrong compiler options?

I went from being unlucky to just highly improbable.

I've got about 15,000 khash/sec running altogether, and generated absolutely nothing for over two weeks.
Then, in the span of 12 hours, one of my slower (linux) machines found THREE blocks.  Go figure.

No joy against SVN tip here.


Trying manually now.

Excellent improvement!  I pulled down the SVN tip and had no trouble building on my headless server.
No X11, no Wx, and RPC password support.. sweet.

Thanks!

Runs fine on the i5 Macbook Pro.  Generates a lot of heat, but it's more stable than the speedy Windows x64 version by far.

That's very fascinating insight,  knightmb.  Some incredible machines on-tap.    I have been doing a lot of btc-per-energy calculations, but outright renting cores for off-peak khash is taking it to the next level.

At the current difficulty level, I've stopped all coin generation on machines where I pay for power or cooling.  Even the highest-end i7 machines had enough of a delta between idle/light-load and full steam that it was not worth the marginal cost.  Not by a longshot.

Recovering bulk coins from the dusty wallets of early adopters is very clever. 

I've thought about dialing BitCoin down to 7 active cores on my desktop machine, just to keep one free for general lightweight UI use.

More interesting than I would have guessed.   I liked the Stonehenge article the best.

14xRWRzqt3bk5LtSeSgeQeTa9spXum2tAA

Um.. Wow.  That last one was a bit of a leap.

Intel Core i7-870 (2.93 GHz) running 4950 khash/s here. (4 cores Turbo'd to 3.2 GHz)
(Intel version)

Anyone seeing a speed difference between VS and Intel?

Interesting replies.

I don't have such a client -- just to clear that up.

What I'm getting at is this:  If BTC were highly valued, and a very clever-but-selfish developer had an exceedingly fast client (say, someone gets CUDU running on all cylinders, or hand-crafts SSSE3 for i7), would they be better off retaining the program for their exclusive use (during inflation), or offering it for 'sale' by effectively charging a fee for every find.

I suspected it would be more profitable to distribute it with a small fee, but the reception sounds a bit... less favorable.

If you could download a Bitcoin client that computed hashes at twice your current rate, but sent 5 of every 50 bitcoins awarded to the software developer, would you run it?