BTC Guild - Pay-per-Share Pool - page 2.

MadHacker

full member

Activity: 235

Merit: 100

Quote from: tysat on September 16, 2011, 07:58:28 PM

Quote from: eleuthria on September 13, 2011, 04:26:46 PM

Over the long run, proportional should pay you more. It's the nature of the mining, given a long enough time frame it will level out to near-0% luck.

Shouldn't PPS and Prop be the same over the long run? Because PPS should be paying 50/(difficulty) per share over the long run you assume the pool has close to (difficulty) number of shares per block solved.... so your earnings should be the same.

Prop has option to have donation of 0%
PPS has a 7% cut off the top...
if in long run luck is 0% then Prop has a better pay out... in the long run...

edit..
IN Long run... in the long run...
am i being redundantly redundant?

tysat

legendary

Activity: 966

Merit: 1004

Keep it real

Quote from: eleuthria on September 13, 2011, 04:26:46 PM

Over the long run, proportional should pay you more. It's the nature of the mining, given a long enough time frame it will level out to near-0% luck.

Shouldn't PPS and Prop be the same over the long run? Because PPS should be paying 50/(difficulty) per share over the long run you assume the pool has close to (difficulty) number of shares per block solved.... so your earnings should be the same.

eleuthria

legendary

Activity: 1750

Merit: 1007

Idle settings are fixed, now you can modify which workers will send warnings and what your threshold is before receiving them.

eleuthria

legendary

Activity: 1750

Merit: 1007

The following features will be added to the PPS Pool tonight:

1) 24 hour earnings + hourly worker speed/earnings graphs.
2) Idle Miner notifications

UPDATE: Idle miners and 24 hour earning stat are now enabled. Worker speed graphs will be delayed while I rewrite how I'm handling the log of worker data to make it able to easily hold and pull up a detailed hourly history of each worker.

eleuthria

legendary

Activity: 1750

Merit: 1007

1) I'm trying to figure out a good way to calculate 24H rewards on PPS Guild right now. BTC Guild does it by taking the sum of your rewards on blocks in the last 24 hours, which is simple. PPS Guild doesn't have that type of reference point [it doesn't bother tracking shares per user per block].

I'll probably just make an hourly log of each user's share count and graph it out for you, which could also be easily referenced for a count of the previous 24 hours.

2) I will be updating the My Account page to use the same variable time [5 / 15 / 30 / 60] minute for average speed calculations, which will keep them in sync.

UPDATE:

1) The logger has been implemented, and this time tomorrow you will be able to view your past 24 hour earnings (updated hourly). I will also work on getting some pretty graphs to accompany the data.

2) The My Account page now calculates worker speeds based on the time range at the top. Unfortunately this means if you've been mining for 1+ hours on some workers, your new workers will take 1 hour before their average speed is accurate. However, you'll end up with consistent reporting across the page.

haploid23

legendary

Activity: 812

Merit: 1002

i'm user ID# 216 in this new pps pool. i have a couple of questions/requests:

1) can you also add the "24 hour rewards" stats like in the regular btcguild? i'd like to see how close the payout is to the theoretical payout. if course, it should be about 7% less than theoretical, but it would be nice to calculate real numbers as well.

2) the total current worker speed has never been above the average speed at the top. if the average speed is correct, then the current worker speed should be above the average speed half the time and below it half the time. and when comparing the average speed to the phoenix miner speed displayed on my computer, my computer shows a few hundred mh/s higher. not sure why the stats on pps-btcguild always estimates it a few hundred mh/s slower. is this "loss of speed" due to network latencies?

3) was there some kind of mathematical analysis of how the arbitrary 7% fees were determined? why was it not 6% or 8%?

eleuthria

legendary

Activity: 1750

Merit: 1007

Over the long run, proportional should pay you more. It's the nature of the mining, given a long enough time frame it will level out to near-0% luck.

However, pool hopping has no measurable affect on your rewards. There are no successful hoppers on BTC Guild that I've been able to find. I've watched a few accounts that I suspected were hopping [speed fluctuations], and they're stab in the dark attempts. They're hopping to us after long polls, but it has nothing to do with whether we found the block or not. My suspicion is they're checking pools that claim blocks in real-time, and if it fails, they make a guess of BTC Guild/Deepbit.

Since they're just erratically hopping and not even close to accurate, their influence on non-hoppers rewards is minimal if any.

haploid23

legendary

Activity: 812

Merit: 1002

when taking into account all the pool hoppers on btcguild, does this pps-btcguild give higher payout to honest miners even with the 7% fees? i don't mind variance from the regular btcguild, but i just don't want to do the dirty work for the hoppers

kano

legendary

Activity: 4466

Merit: 1798

Linux since 1997 RedHat 4

Quote from: eleuthria on September 13, 2011, 10:31:53 AM

Crashed while I was asleep, the server ran out of memory and I had the swapfile turned off previously when it was the SC Guild secondary server. This is why I have the disclaimer at the top saying make sure you've got a failover server!

Back up and running today. When I get off work this afternoon I will be moving bitcoind off the PoolServerJ server so it can have more RAM available. I've also added a script that polls the PoolServerJ stats once per minute. That page forces a garbage collection, so it should help with the RAM issues.

OK now I got a rough idea when you are asleep vs the time here in Aus
(and thus when patience is needed most

Thanks

eleuthria

legendary

Activity: 1750

Merit: 1007

Moved bitcoind to a different server for the PPS pool, giving it [almost] free reign of the RAM on the server. Idle Miners should be in tonight for PPS Guild, but may be delayed due to working on PoolServerJ updates with shadders.

EDIT: Just for clarification, this change caused disconnects for about 2 minutes, sorry for the downtime but it was needed to improve performance.

eleuthria

legendary

Activity: 1750

Merit: 1007

Crashed while I was asleep, the server ran out of memory and I had the swapfile turned off previously when it was the SC Guild secondary server. This is why I have the disclaimer at the top saying make sure you've got a failover server!

Back up and running today. When I get off work this afternoon I will be moving bitcoind off the PoolServerJ server so it can have more RAM available. I've also added a script that polls the PoolServerJ stats once per minute. That page forces a garbage collection, so it should help with the RAM issues.

ShadesOfMarble

donator

Activity: 543

Merit: 500

So the poolserver is offline ATM?

kano

legendary

Activity: 4466

Merit: 1798

Linux since 1997 RedHat 4

Current outage expected to be much longer?
Just wondering when I can connect again

eleuthria

legendary

Activity: 1750

Merit: 1007

Added a Hall of Fame for Fastest Users (Last Hour), Most Shares, and Most Blocks Found.

Updated the top bar to modify how it calculates your average speed. If you submitted shares between 61 and 70 minutes ago, it will use a 60 minute average. 31-40 minutes ago, 30 minute average. 16-25 minutes ago, 15 minute average. Otherwise a 5 minute. Gives you a faster update of your miner speed through the website, and slowly uses a longer time frame for analysis to give you a reliable speed readout.

By the time your miner hits the 60 minute average, your estimated speed should be very stable, outside of minor variance due to individual luck. Faster miners (300 MH/s+) should be seeing estimated speed be within about 5% (+ or -), and very fast miners (1 GH/s) will likely see a much smaller discrepancy between estimated and actual speeds.

Idle Miner warnings will be added this evening, as well as standard APIs from BTC Guild.

darnoth

newbie

Activity: 11

Merit: 0

Quote from: Jack of Diamonds on September 11, 2011, 04:36:00 AM

How will it compete for miners against 0% PPS pools such as btcpool24.com or abcpool.co

And abcpool isn't taking new users as well.

cuqa

newbie

Activity: 40

Merit: 0

Quote from: Jack of Diamonds on September 11, 2011, 04:36:00 AM

How will it compete for miners against 0% PPS pools such as btcpool24.com or abcpool.co or BTCServ

FYP

btw, btcpool24.com is dead.

Jack of Diamonds

sr. member

Activity: 252

Merit: 251

How will it compete for miners against 0% PPS pools such as btcpool24.com or abcpool.co

eleuthria

legendary

Activity: 1750

Merit: 1007

BTC Guild - Pay Per Share

BTC Guild has opened up a beta pool for true pay-per-share. This is not SMPPS/PPLNS where rewards are capped at what the pool has earned to date, or where you have to wait for a block to solve to get your payouts. Every share you submit instantly credits your account with rewards, and they can be withdrawn as soon as you have earned the minimum payout of 0.10.

The new pool server is running on PoolServerJ. Since this pool software hasn't been tested as thoroughly as pushpool, BTC Guild's PPS pool is considered beta. Share submissions and rewards are secure, but if the pool crashes it may not automatically recover like our pushpool servers do. As such, it is recommended you use a miner with the ability to failover to another server when using BTC Guild (PPS Beta).

Our initial testing has been showing significantly faster response times to getwork requests, thanks to PoolServerJ's caching of work in advance, eliminating the relay time where pushpool sends a getwork request and relays theresponse to your miner. Invalid share rates are exceptionally low, and the My Account worker summary gives you a breakdown of the exact reason a share is rejected.

Topic: BTC Guild - Pay-per-Share Pool - page 2. (Read 4575 times)