Is it possible that there may be a problem with the 24hr Rewards reporting by chance ?
I was actually manually monitoring for 24hrs as part of my share/hr testing and I actually made more than what the 24hr Reward was showing. All BTC/Pay was there in the rest of the stats, but the 24hr was reading a bit low, ~4-5% at the time ? Not a big deal though.

Also, with the recent batch of repairs, is there still a chance that the Hall of Fame's 'private' 26th row will be reimplimented for those of us that don't officially make the Top 25 ? .....along with account ID# highlighting ?

Doesn't that kinda defeat the sole purpose of PPS mining ? I don't see how a variance of up to 20% would ever come into play, especially with PPS and the fact that current mining software has built-in work-unit timeouts (60secs by default in CGMiner). I just don't see it.....

Unfortunately I am unable to ping anything on/inside your domain. No reply, all timeouts....obviously security on your end.

However, quick ping stats to the 'other' server (with a bit of anonymity to keep this from looking like a You vs. Them competition):

Hope that helps, atleast a bit.....as again, your servers do not respond to my pings.

Here are the last set of figures, NOT INCLUDING NMC (as it seemed pointless considering the BTC share gap):

NMCBIT (merged mining, but NO NMC added to totals) 9.6% total fees:
13.67hrs = 41507 total BTC shares = 1.5612433725 (1.60952925 minus 3%)
= 3036.36 BTC Shares/Hour @ (PPS-3%) 0.000037613977648747 = 0.1142095771734067 BTC/hr Earnings = 2.741029852161761 BTC/day/24hrs (all fees accounted for)

COMPARISON POOL (no merged mining) 5% total fees:
25.50hrs = 84389 total BTC shares = 3.33079136 (0.0000394694967.../share)
= 3309.37 BTC Shares/Hour @ 0.00003946949672652 = 0.1306191683817773 BTC/hr Earnings = 3.134860041162655 BTC/day/24hrs (all fees accounted for)


2.741029852161761 BTC/day/24hrs (all fees accounted for) ...VS... 3.134860041162655 BTC/day/24hrs (all fees accounted for)
= = = = = = = = = = = = (equals) = = = = = 12.56% or 0.393830189 Daily loss average on BTC.

***NO NMC WAS USED TO OFFSET ANY BALANCE**

So, assuming all of the above to be accurate, my NMC earnings would have to have been OVER 12.56% of total daily BTC to break even.

It still could be a route issue or connectivity though, right ? if you recall, coinserver4 helped me out immensly, in comparison to the main server.

Anyways, the NMCBIT data I used was the first 13hrs 40 mins (13.67 hrs) of BTC block# 22, at which point, I switched things over to compare and the 24hr data I showed above. I will paste the 25.5 hr data from my current pool test as well, as it will be ready in about 10 mins.

Well, in all fairness, my 'statement' is really only a share per hour comparison between what I specificlly get from 2 different pools.

Over a period of 13.67 hrs, I received an average of 3010 valid shares per hour on first pool.

Over a period of 24.00 hrs, I received an average of 3320 valid shares per hour from the other pool (was 3330/hr @ 14hrs).
(current previous '24hr running total' at posting this, 3210/hr after service disruption & maintenance by pool OP)

As far as them being true.....the data and payouts speak for themselves, part of the data you already have access to.

I believe it's different for XP and Win7. Hit up Google for specific examples...that's where I got mine from

That's a good possibility. The NMCBIT stales were also well within acceptable ranges (under 1%) yet the overall valid shares were approx 11.5% lower, compared to the other pool I use as reference (which I am currently mining on & monitoring for fresh data). With everything said and done (using a bit of past as well as current 'other' pool data), I actually profited 8.5% less on NMCBIT (with merged mining) than I would have if I had used the other pool in question, which is not even doing merged mining at the moment.

Again, everything 100% same, except for Pool address.....

My 24hr monitoring of the 'other' pool ends in about 20mins, so I will recalculate everything then and report back.

FYI....both pools I used in the comparison above currently run PoolserverJ  (probably not what you wanted to hear...lol)

I appreciate you looking into this though,
Allan

I've never really monitored it much......but I am sure that heat and additional power consumption would be a result.

If you want to 'solve' this (somewhat), simply launch CGMiner with a bat file, in which you can also assign CPU affinity, overclock/underclock core & mem, set fan speeds etc, all at the same time.....it's a decent solution to the problem and you won't have to worry about it on any of your muti-thread/core machines once setup in the bat file. Throw a shortcut to the bat file into your 'All users' startup folder (assuming you are a Windows user, like myself...lol), set the machine to auto-login.... and have everything fire up at bootup and call it a day. DONE & DONE.

I am looking to buy a few+ (4 to 10 total) Powered PCIe x16/x16, x1/x16 etc. Risers/Cables/Extenders so that I can safely add a 5th (& maybe 6th) GPU to all of my Windows7 mining rigs.

These (or similar, I really don't care what slot size they are, simply MUST BE POWERED):



Please let me know what you have, how much you want ...... and I will require shipping to CANADA (Calgary, AB).

Thanks.
bitlane

I am currently running 11.8 across the board and yes, still 100% CPU issue, but mainly (only) on 5xxx multi-card rigs from what I can tell..

I have since given up on an actual fix and resorted to either scripted or manual affinity settings to a single CPU thread for CGMiner on 5xxx series cards (which seem to be the worst), as none of my 69xx multiple card machines are affected (or atleast not 100% pegged CPU on them anyways).

Oddly enough, For a brief while I ran a machine with 2x 6950's and a single 5830 together....and NO 100% bug, so I guess it's only multiple 5xxx cards that trigger it.

Deepbit includes their 10% PPS fee into the calculation..... so, 1.58 * 1.10 = approx 1.738 (very close to the other number you listed....lol)

Also, here's a much easier calculator to use (just the basics): http://www.alloscomp.com/bitcoin/calculator.php

I was just about to post the same thing...lol
No 'extending' required since 11.7
One GPU shows up in display properties, but all 4 are seen and used by CGMiner in my quad-card setups.
No more dummy plugs either.....

I still recall reading recommendations for cards and CGMiner's intensity value a while back.....

It was suggested that I=8 be used for 5xxx series ATI cards, while I=9 be used for the 69xx series cards.

I did some playing around after a few stalls here and there and actually found that for my quad 6950 rig, I actually get a higher share/min rate ("U" value) when I use I=8 rather than I=9, as suggested.....and no GPU stalling or driver crashing with a much higher overclock.

I am currently still using 2.0.6 and love it......insane performance. I pretty much use I=8 for everything, except for working-workstations, where I use Dynamic Intensity and it all works great.

Is I=9 still suggested for 69xx cards ?

<EDIT>
* I should also add that I am using Windows 7 on all rigs (currently a mixture of 32 & 64bit machines).

I realize now that it would be completely unfair of me to make any statements with specifics and I'd rather not get into those specifics in a public forum, because it will look completely 1 sided and seem as though I am attacking 1 pool while being a fanboy of another. You work hard as both a BTC & NMC supporter as a whole and I respect that.

You and I did stumble across (what I believe to be) the main problem when I first joined up @ NMCBIT last week and that had more to do with geographical location of miner vs pool and the route between them. Once you provided me with an alternate route (to coinserver4) most of the problem went away.

With 100% same hash rates on my end (same settings, equipment etc, only pool address changed) I simply noticed, during my 'calculations' today, that my average share per hour count was approx 3010 shares/hour at one pool, while it was approx 3360 shares/hour at another, using approx 13.67 hours of data initially to come to the conclusion. I am going to re-read a few of my posts and edit them to reflect meaningful info rather than 'heat of the moment' rants etc....lol

Again, I do respect what you have done for the community and to overlook that would be silly on my part.

Allan.

That everyone really needs to calculate their valid share per hour average, regardless of where they are mining.

With so many users (myself included) busy shopping Pool Stats/Fees/Percentages.....they completely disregard their own performance and how they are able to perform on the pool of their choosing.

Using a big chunk of historical data along with more recent stats, I was able to establish that for me (only me), mining with your pool actually resulted in me generating less BTC than my previous pool due to my own real world performance..... and had nothing to do with the generous offering of what was 'on paper' (or, the website as it were).

Low fees & merged mining mean nothing if a miner's hourly share rate average is garbage due to things beyond his/her control and have more to do with either the Pool's performance or connectivity issues.

....yet you still disregard my plea to change the following, further misleading more people (FIRST POST IN THIS THREAD)

...with NO mention of any other fees or percentages.

Shouldn't it read:


? ? ? ? ?

Regardless, I have uncovered far more disturbing statistics that affect me, that make this almost irrelevant.
ENJOY !

That's comforting....as I am not technically inclined enough to understand it fully.

I guess what I really want to say is:

"I am happy that Merged mining has not in fact opened up a Pandoras Box of sorts, where the Proxy technology, rather than being used to submit shares to bitcoinD & namecoinD simultaneously, could instead be used by a smart miner to submit simultaneous identical shares to 2 seperate pools using the same hashing power, effectively DOUBLING his payouts"

I feel better....lol

Is it possible for 2 different miners, located on 2 different pools to submit the exact same hash/share during the same block to each of their pools ?
Would both of these, although identical, count as a valid share for payout by their respective PPS Pools ?

LOL.... atleast I know that jab was directed at me this time
thanks for using quote to help me stay less confused....hehe