Variance at diff 32 is 32^2 times greater, i.e. 1024 times... so in my opinion, diff 32 is too high for current mining hardware in light of that (see my earlier post).

I'm guessing you're getting the crashes once again when running through tor? I don't know the first thing about tor... yet.

New version: 2.7.5, 31st August 2012

Survived a whole week without needing to give a hotfix update yay \o/.

This release is just a minor bugfix update. I've changed my build environment so it is less work to build binaries, so I have included an fpgaonly binary as well as the full feature binary. The windows binary is now compressed with 7z since it's getting so large, and will include a different set of DLLs due to it being built differently.


Human readable changelog

- Hopefully fixed the bug where dynamic intensity gets stuck at -10
- Much less pool-not-providing-work fast enough messages.
- Fixed share leakage to backup pools the way it was supposed to work.
- Properly detect SDK2.7 and choose optimal parameters for it.
- Remove the hardcoded worksize for 256 - it had the opposite effect with the new kernels
- Fix the rare occasion there are many new blocks detected in a row.
- Hopefully fixed the load balance and rotate strategies.


Full changelog

- Adjust opencl intensity when adjusting thread count to prevent it getting
pegged at a value below the minimum threads possible.
- miner.h max_hashes -> int64_t
- Keep the local block number in the blocks structs stored and sort them by
number to guarantee we delete the oldest when ageing the block struct entries.
- Use correct sdk version detection for SDK 2.7
- Revert "Pick worksize 256 with Cypress if none is specified."
- Test for lagging once more in queue_request to enable work to leak to backup
pools.
- There is no need to try to switch pools in select_pool since the current pool
is actually not affected by the choice of pool to get work from.
- Only clear the pool lagging flag if we're staging work faster than we're using
it.
- needed flag is currently always false in queue_request. Remove it for now.
- thr is always NULL going into queue_request now.

Yes it is, and we shall carry on making it longer.

Yep, only on the diff 10 server.

Well done at being the first to implement this.

I quote from another thread I posted if people are trying to decide what difficulty to set:

This is working very nicely for me and I think (variable) difficulty targets are way overdue. One thing which I have noticed, though, is that there seem to be 2 longpolls for every block change, between 15 and 20 seconds apart.

Thanks

Well on the rare chance that cgminer actually *does* die, that mother file will not restart it. However it will not inappropriately kill it off as current bamt does, and I'm pretty confident about the stability of cgminer 2.7.4 anyway.

I can't recall what I did to piss you off, but enjoy your relationship.

It's incompatible with recent versions of cgminer as it doesn't think cgminer is running and kills it off inappropriately. Try replacing the BAMT mother file in the /opt/bamt directory with this one:
http://ck.kolivas.org/apps/cgminer/temp/mother

Note that in the next version of bamt, apparently they're dropping support of cgminer.

Since this is one of the very few pools that has already put higher difficulty shares into trial, I quote my post from another thread that will hopefully help direct your further efforts towards this:


Note that the maximum efficiency of cgminer is about 70,000% with the current code, but likely limited to about half that but even then, >30,000% efficiency, combined with higher difficulty shares means most pools would cope with dramatic rises in hashrates (read ASICS) without any new protocol.

60 seconds per share will be way too infrequently if it's a static value. The variance will be painful. A minirig is the current highest hashrate device available and produces over 350 shares per minute. You would be setting current users to a difficulty of 350. The problem with that is the variance is the square of the difficulty so the variance will be much much higher and it would take weeks to get a stabilised return, when you are already capable of coping with hundreds of shares from the current minirig owners. To not make variance any more painful at high hashrates, make the share return rate proportional to the square root of the hashrate instead of a constant. So a 1 GH/s miner currently returns a share every 4.2 seconds - if you make the 1GH miners difficulty 10 as a baseline, then you make 10GH miners sqrt(10) * 10 ~ diff 30. And you make 100GH miners sqrt(100) * 10 ~ diff 100.

gpu threads 5 is not a good idea with p2pool as it takes 5 times longer to complete any work. On the other hand I doubt dropping your intensity below 8 will improve your reject rate any further either. Intensity 8 is 8.3 million hashes and at 600-700 mhash for a 7970, they're done in 1/50th of a second. That is no longer contributing to your reject rate. High rejects are the norm with p2pool, but yours is higher than normal, and perhaps it's just your p2pool setup and delays elsewhere.

The equation is that approximately every 4.2 GH you will find a (difficulty 1) share on average. So 1GH/s will find a share every 4.2 seconds. With 86400 seconds in a day, this equates to 86400/42 ~ 20,570 shares per day per GH/s.

You haven't been here very long, have you?

Let's see... how can AMD do something stupid? Now for anyone that's been mining long enough, this question is about as rhetorical as they get...

Oh a mac? Use libusbx, not libusb which is almost unmaintained

http://libusbx.org/

Did you try the prebuilt binary I provide?

Thanks. It was definitely a feature that polarised the users. Some people were quite good with it. Others loathed it. Overall because I was very conscious of it not using too much power it ended up donating far less than the percentage specified, so it never really amounted to very much. Finally it became an exercise in support of its own that wasn't really donating much so I gave up and removed it.

On a related note, Graet has also been the most generous donator of the pool ops to cgminer's development. Most pool ops realise that good mining software is also required, however, very very few have even donated, let alone been generous...

Yes, but I haven't done the math to figure out how much. Luck will make it impossible to see on a simple kernel swap since luck's effect on U is greater than the magnitude of increase this may afford.