Topic: [CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers - page 245. (Read 903150 times)

Yea i still dont get it but i will flow with it for awhile and see how it goes.

The PPLNS stats page shows our luck this difficulty, and also our luck split into 10-shift segments (~8 hour intervals).

How can i view this pools's luck?

.............................. 

Brief attack on the pool affecting one of the US servers.  Most users' mining clients seemed route around it quite quickly before I was even woken up by my alarms.

on a side now i have notice that around 7CST(-6GMT) today i see a dip across all my miners. Did something happen?

PPLNS isn't affected by your connection going on/off.  The expected value of your share is determined over the 8 hours subsequent to submitting that share.  Whether you disconnect or not, that has no effect on the expected value of your shares, which is 4.5% higher than PPS (not counting NMC).

Although I would agree that if you're only using the pool as a failover, PPS would probably be the way to go.

PPS if you've got intermittent connection or miners, PPLNS for solid miners on a good internet connection. 

PPS is good if you're using BTCGuild as a backup pool.  PPLNS if it's your main pool.

That's my take on it.

For miners on BTC Guild, PPLNS will always pay better in the long run.  You get 4.5% lower fee and NMC on top of that.  You just need to step back and look at the bigger picture rather than dwell on day to day luck.  BTC Guild is large enough that we are almost always within the expected variance.  Even when our luck for an entire difficulty is pretty bad, it almost alwaysl pays out ahead of PPS in the same period.

For me, PPS is obviously better since I make more off you, but the flip side of that is I have to keep a larger hot wallet, and then stop my head from exploding if I lose 100-200 BTC in a day due to bad luck.  I'm much happier making less and not having to go through the stress of ups & downs on pool wide variance.

Side note: What is truly better PPS or PPLNS?

Funny looking back, was so happy at the first 30 GH/s, and 300 GH/s .  300 GH/s was one of the first big bottlenecks for the old pool software!

BTC Guild is offically at 300,323Gh!      

Thanks for the props!! Glad to know I was able to help you get them going in the end....  If anyone else happens to need some technical assistance, feel free to PM me. 

Just a note... buyer99 helped me get my Blades running.  It literally took him all evening to crack my thick skull.  He well-earned the bounty and my many, many thanks!  He's a very patient man indeed.

Yup I've seen those responses to others before, and I did notice the bad luck recently.  But Bad luck for PPLNS never affected the displayed estimated speed before.

Speed shown is back to normal now, and I'm not claiming any "singling out", but there was an hour and a half of showing low estimated speed BEFORE I did any restarts. I did the usual verifications first of looking at any potential network, software, or mining device issues first.

1. All miners were hashing away (usual blinky blinky).
2. All hubs were functioning normally.
3. BFGMiner did not show any errors in stdio display or in each device. Hashrate showed normal. And normal submissions to Pool 0 with no issues.
4. BFGMiner RPC interface showed normal Hashrates/accepts/reject ratios.
5. Debug calls to RPC interface showed no issues.
6. Debug logs showed no issues.
7. Only after exhausting all debug options on my side and still watching Pool hashrate fluctuate in a speed range that was half my usual (not plummet slowly, which I've seen when something is wrong on my side, but actually fluctuate up and down on either side of half my farm strength), did I actually initiate a restart.

Hashrate remained the same on site (low) for 14 minutes but all was well on my side. Restarted again, and now hashrate is back to normal.

I'm not saying pool server was discriminating against me... Because obviously it was accepting work at the time or else I would have seen errors coming from the servers in BFGMiner or my logs.  They were obviously accepting work.  Something else between "accepting work" and "calculating hashrate" went wonky though. It sure as hell wasn't on my side of the fence (at least this time)

Update for the 24 hour earnings statistic:  PPS users had their 24 hour earnings counters reset during the database migration, so please do not freak out over the fact that it is only showing a fraction of what it should be showing.

Luck went pretty bad during/after migration, so PPLNS hasn't moved much much.  We had 3 bad blocks - 1 hour between 19995 and 19996, 1 hour 40 minutes between that and 19997, 1 hour between that and 19998.  In that time frame we should have had 6-8 blocks.  

Restarting multiple times will definitely impact your estimated speed, since it uses 1 hour worth of data to estimate your speed and all that time lost restarting just means you're going to have to wait for the dead time to leave the average window.

As normal, my usual response:  The pool speed estimate uses the same data your workers do for their estimated speed.  As of this moment, it's showing 281 TH/s.  There's no way for the pool server to discriminate against you, so if there was an issue with the pool it would affect every user on that same server (or all servers if it was database related).  Obviously that isn't the case.

Seeing a huge drop off in estimated speed, by about half. BFGMiner on my worker showing all devices are ok and hashing away, no issues or errors. The estimated speed on the site was ok after the db migration and this is hours after that so I don't think it was directly tied to that.  This did start happening around midnight Eastern Time, so any chance this could have anything to do with the time zone issues you mentioned?  I've restarted my miners and OS a few times, but all indications from BFGMiner and my PHP RPC status page shows hashrate is normal and healthy with no errors in stdio display and logs.

Also account balance for PPLNS seems to have been moving at a snails pace and should have hit my auto-payout setting hours ago by my reckoning.

That gap is because you have an extremely small payout.  The scripts limit the number of total payouts made with each batch.  If too many payouts are trying to trigger each hour, some are skipped and picked up on the next cycle.

What abou payments?
I see huge gap there...


2013-09-11 01:37:15 PM.   Link   0.02000000   
2013-09-10 09:37:42 PM   Link   0.02000000   
2013-09-10 08:37:41 PM   Link   0.02000000