Broke past $6.45 just now 

Does anyone know if there are plans for a p2pool WITHOUT bip16 support come april 1st? Would p2pool be robust enough to work in a mixed client scenario?

It seems to me like there could be quite a few miners who like the idea and lower variance of p2pool but would also like some say in which changes get accepted into the bitcoin protocol.

For those of you who are missing the mining graphs available on the websites of pools like slush's, here's a way to get something similar out of blockchain.info

http://blockchain.info/charts/received-per-day?showDataPoints=true&timespan=30days&show_header=true&daysAverageString=7&scale=0&address=1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4

Just replace the address at the end of the URL with your own p2pool address.

This instance of p2pool had an empty data directory, so your explanation makes sense. Thanks again forestv!

Thank you for the answer forestv. I'm getting ~200GH/s so I guess I'm still on the main pool.

By the way, can you think of a reason why only half of the shares in the chain would be reported as verified? This happened to me only once before and it was during a split, which is why I thought it could be happening again.

Are we having another split? My p2pool is verifying only half of the total shares in the chain at the moment, and estimated current payout is about half of what it usually is.

I'm running p2pool tag 0.8.5.

Thanks.

From the comments in his post it looks like ArtForz had to change the code itself to get it to work. But the changes haven't been sent to the vanitygen git repository (repository hasn't been changed in 6 months), so it looks like I'm going to have to break out the compiler and code editor again.

Yes.

Has anyone managed to get vanitygen working on GCN? I'm only getting failed hashes.

By the way here's a link to all of the blocks that have been mined by p2pool so far:

https://blockexplorer.com/address/1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4

According to the blockexplorer link, 1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4 is associated in the block chain with the public key that is used for donations via the --give-author p2pool command line option. You can see this hexadecimal public key in the p2pool source code yourselves, where it is stored in the SCRIPT variable near the middle of data.py (bitcoin 'script' annotations are mine):


According to the code, this address will always receive at least 1 satoshi per block, plus any donations (~0.25Btc per block w/default settings) and remaining satoshis that are left over after divvying the block's reward & fee amongst the p2pool miners.

So unless the code gets changed, you can expect the 1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4 address to be present in the "To" side of all coins generated by p2pool.

That looks like the new chain. The one from before must have been the older chain.

I find it fascinating how even while being split in two, with roughly ~115GH/s in the group using the new version and ~90GH/s in the group using the old version (if I'm reading things correctly and the Pool GH/s stat counts only verified shares of each fragment), that the p2pool is still correctly solving blocks and doling out rewards (to those that are in the fragment that actually solved the block, of course).

Could fragmentation actually be a good thing in the long run? Maybe the protocol could try to optimally split nodes by hashing capacity or locality? To how many GH/s can p2pool scale before bandwidth starts becoming an issue? Could rewards somehow get shared across these fragments, forming a sort of recursive tree structure? I'm just asking because 10 second rounds doesn't give the network much time to propagate the solved blocks to every node, and it seems possible that with many more miners in the pool there would be a lot of losses due to orphaned blocks.

Looks like the pool may be going through a two-way chain split ATM. There are twice as many shares on the network as there are verified shares.


I suggest that everyone upgrade their versions ASAP!

You could probably shave another 40-60W per card by undervolting. I got 50W off of mine @ 1125MHz which lowered the temps enough (8-9ºC IIRC) to afford running the fans at slower speeds, and others on the forums have been able to undervolt even more than that.

I tried to test your 79xx patch on the git tree following the instructions in the README but after several hours of trying I was unable to get it to actually build on my windows machine.

But it might help you to know that I've found that using the poclbm kernel, setting vector size to 1 and hard-coding the poclbm kernel's BFI_INT to false gives me ~600MH/s (which is much better than the ~540MH/s v2.1.2 kernel with the same settings).

Further gains can be had by changing the definition of ch() and Ma() in the poclbm kernel to use bitselect() instead of boolean operations. Changing this gets cgminer's Radeon HD 7970 performance up to within 3% of that of Diablominer's  (diablo gives me 670MH/s while cgminer gives 650MH/s @ 1125MHz).

The Catalyst GUI will only respect underclocks to 975MHz AFAIK anything lower will get you default memory clocks.

Yeah, it kinda takes the fun out of optimizing if all you can get is 2%.

Any idea if there's a GCN feature that we can exploit for more performance like fixed function hardware or new instructions/amd-specific extensions? I initially thought that using size 16 vectors would help, thinking that the GCN SIMD cores were akin to x64 SIMD registers, but it seems that the card exploits its SIMD cores by running a scalar instruction on 16 threads at once.


Don't even bother until the release a new version because Kernel Analyzer won't even correctly list the kernel stats for tahiti. Running the profiler via command line does give some useful output however, and I have .il, .cl, .isa  and a comma separated value file of a profile run with -v 1 from my 7970 if you're interested.

Thanks, I fixed the link.

Curious about how much room for optimization there is, I made some calculations to see how close Diablominer is to the maximum theoretical performance of the 7970 (see here) and unless I'm missing something in my assumptions I found it to already be within ~2% of the maximum theoretical performance.

Edit: Fixed link.

Short answer: Yes, slightly better performance is possible.

Long answer: You can expect a little more performance, but unless there's a detail I'm not aware of there is really not much left to gain (1-2% ideally). Let me explain why.

To the best of my knowledge, the closest estimate of the number of mathematical operations required to compute 1 hash is ~3375 (according to Phateus). And if we consider an ideally efficient processor to be one that computes mathematical operations at a rate of one operation per cycle, then hashing would take ~3375 cycles on this ideally efficient processor.

Now lets take a look at what kind of performance we can measure with today's kernels. The 7970 has 2048 stream processors and a stock frequency of 925Mhz, and with the best known kernels it is computing 550MH/s. Knowing this, we can measure the average number of cycles it is taking each stream processor to compute one hash using the following equation:


Now if we consider that each stream processor at best can perform one ALU instruction per cycle, then the 7970 is extremely efficient (in cycles per hash) since this 3444 cycle measurement is reaaaallly close to the ideal value of 3375 cycles at one instruction per cycle. This is only a ~2% difference off of ideal and might even be due to measurement error. Its so efficient that unless there is a breakthrough that reduces the amount of operations required per hash, or there's some new GCN instruction that I'm unaware of that allows the GPU to compute several steps of the hashing function in one cycle, or kernels are modified to start taking advantage of fixed-function hardware somehow, then to the best of my knowledge ~550MH/s at stock clocks is pretty much all we're ever going to get.

To give you an idea how efficient the 7970 is at computing hashes we can compare its efficiency (in cycles per hash) with a 6970, which has 1536 stream processors and a stock frequency of 880MHz for the highest reported hashrate of 370MH/s at that frequency (from the mining hardware comparison chart):


At an estimate of 3653 cycles, a 6970 stream processor takes ~6% more cycles per hash than a 7970 stream processor at the same frequency, and ~8% more than the ideal 1 instruction per cycle processor.

Now lets compare to a 5870 which has a highest reported hash rate of 379MH/s with its 1600 stream processors and a stock speed of 850MHz:


This makes the 5870 roughly 2% more efficient (in cycles per hash) than the 6970, but it still uses ~4% more cycles per hash than the 7970, and ~6% more than the ideal processor. So we can conclude that ATI's GCN is already making ~98% efficient use of its stream processors for hashing, which is more than the VLIW4 and VLIW5 of its previous two generations and close to the ideal. This more efficient stream processor usage along with the increased number of stream processors and higher stock frequency explains the increased hashing performance when compared to the previous generations of GPUs.

Disclaimer: I'm not a GPU programming expert (yet) so please take my answer with a grain a salt. But for what its worth, I develop HPC software for a living that solves problems running on thousands of nodes in parallel.