Topic: [ANN][The Original Multipool - Scrypt/SHA256/Scrypt-N/X11] multipool.us - page 230. (Read 424294 times)
July 07, 2013, 04:26:12 AM
lucky is on i see
July 07, 2013, 04:23:54 AM
Well, the problem is that our pool is different from the others in that there is some inherent 'hopping' involved in just using the pool (for those on the multiport, anyway).
We need to strike a balance between paying the multiport users fairly and also paying the dedicated coin miners fairly.
We need to strike a balance between paying the multiport users fairly and also paying the dedicated coin miners fairly.
you can't please poolhoppers w/o hurting dedicated miners, unless you force all to hop by removing dedicated pools
btw ltc stats show that pool is prop atm
July 07, 2013, 04:04:37 AM
The last 5 DGC blocks (212374 - 212273) were paid, however they have no payout data available due to a sql issue in the db..
July 07, 2013, 03:19:08 AM
Alright, I am setting up LKY, ARG and PXC on a set of 2 new, load balanced pool servers. After testing, these three coins will be *multiport only*. I.E. you won't be able to mine them directly.
ETA for testing is tonight. Tomorrow I hope to add PPC and FRC.
ETA for testing is tonight. Tomorrow I hope to add PPC and FRC.
would love to see these added aswell, thanks for the efforts
July 07, 2013, 03:04:35 AM
Just wanted to add my +1 for MEC on the multiport. Thanks for your efforts Mr Flound
still thinking about it.. I took a look at their thread(s) today and it seems like the devs don't really have their shit together. But I will consider it.
July 07, 2013, 03:03:57 AM
pool maintenance starting now, eta 5-10 minutes
maintenance complete July 07, 2013, 02:54:34 AM
pool maintenance starting now, eta 5-10 minutes
July 07, 2013, 02:43:35 AM
Just wanted to add my +1 for MEC on the multiport. Thanks for your efforts Mr Flound
July 07, 2013, 02:15:08 AM
At the suggestion of one of our hero members, I am switching from fixed Last-N based payouts to time-based payouts. I think it makes a bit more sense considering the nature of our pool.
I am setting the following time periods for each of the coins currently on the pool:
LTC: 24 hours
TRC: 6 hours
FTC: 8 hours
MNC: 30 minutes
WDC: 30 minutes
DGC: 30 Minutes
NVC: 12 hours
Please respond with any comments or concerns.
I am setting the following time periods for each of the coins currently on the pool:
LTC: 24 hours
TRC: 6 hours
FTC: 8 hours
MNC: 30 minutes
WDC: 30 minutes
DGC: 30 Minutes
NVC: 12 hours
Please respond with any comments or concerns.
I don't completely understand the implications myself yet, but I had a vague feeling that time-based PPLNS had some problems, and the PPLNS thread seems to confirm:
Quote
The most naive implementation is to have a fixed N and simply pay the last N shares equally. However, this makes it more profitable to mine before difficulty decreases, and less profitable before difficulty increases - the number of blocks that are expected to be found in your window depends on the future difficulty, while the payout you can receive elsewhere depends on the current difficulty.
It doesn't help if N is chosen to be a given multiple of the difficulty at the time a block is found. If the difficulty is about to increase, it is more profitable to mine a short while before. For example, if N is set equal to the difficulty D, a share submitted D shares before the increase will be paid the full expectation in the D-window, and then when difficulty increased it will once again go inside the window and have more expected reward. And, like the previous case, shares submitted just before the difficulty change will be rewarded similarly to shares submitted after it.
Another incorrect implementation is to pay all shares in a window given in units of time (sometimes called PPLNM or PPLNH). In addition to the problems above, it has a problem common to all reward systems that use time as a factor, which is that it is more profitable to mine when the current hashrate is higher than the average.
It doesn't help if N is chosen to be a given multiple of the difficulty at the time a block is found. If the difficulty is about to increase, it is more profitable to mine a short while before. For example, if N is set equal to the difficulty D, a share submitted D shares before the increase will be paid the full expectation in the D-window, and then when difficulty increased it will once again go inside the window and have more expected reward. And, like the previous case, shares submitted just before the difficulty change will be rewarded similarly to shares submitted after it.
Another incorrect implementation is to pay all shares in a window given in units of time (sometimes called PPLNM or PPLNH). In addition to the problems above, it has a problem common to all reward systems that use time as a factor, which is that it is more profitable to mine when the current hashrate is higher than the average.
Now that I'm actually mining on a pool which uses this method, I might give it more thought, and perhaps understand the problem. Not a lot of money at stake here, and I don't mind being motivated to do some research
Shift-based PPLNS would be the best PPLNS implementation based on that thread. It's used on BTC Guild and BitMinter.
Well, the problem is that our pool is different from the others in that there is some inherent 'hopping' involved in just using the pool (for those on the multiport, anyway).
We need to strike a balance between paying the multiport users fairly and also paying the dedicated coin miners fairly.
July 07, 2013, 01:25:46 AM
At the suggestion of one of our hero members, I am switching from fixed Last-N based payouts to time-based payouts. I think it makes a bit more sense considering the nature of our pool.
I am setting the following time periods for each of the coins currently on the pool:
LTC: 24 hours
TRC: 6 hours
FTC: 8 hours
MNC: 30 minutes
WDC: 30 minutes
DGC: 30 Minutes
NVC: 12 hours
Please respond with any comments or concerns.
I am setting the following time periods for each of the coins currently on the pool:
LTC: 24 hours
TRC: 6 hours
FTC: 8 hours
MNC: 30 minutes
WDC: 30 minutes
DGC: 30 Minutes
NVC: 12 hours
Please respond with any comments or concerns.
I don't completely understand the implications myself yet, but I had a vague feeling that time-based PPLNS had some problems, and the PPLNS thread seems to confirm:
Quote
The most naive implementation is to have a fixed N and simply pay the last N shares equally. However, this makes it more profitable to mine before difficulty decreases, and less profitable before difficulty increases - the number of blocks that are expected to be found in your window depends on the future difficulty, while the payout you can receive elsewhere depends on the current difficulty.
It doesn't help if N is chosen to be a given multiple of the difficulty at the time a block is found. If the difficulty is about to increase, it is more profitable to mine a short while before. For example, if N is set equal to the difficulty D, a share submitted D shares before the increase will be paid the full expectation in the D-window, and then when difficulty increased it will once again go inside the window and have more expected reward. And, like the previous case, shares submitted just before the difficulty change will be rewarded similarly to shares submitted after it.
Another incorrect implementation is to pay all shares in a window given in units of time (sometimes called PPLNM or PPLNH). In addition to the problems above, it has a problem common to all reward systems that use time as a factor, which is that it is more profitable to mine when the current hashrate is higher than the average.
It doesn't help if N is chosen to be a given multiple of the difficulty at the time a block is found. If the difficulty is about to increase, it is more profitable to mine a short while before. For example, if N is set equal to the difficulty D, a share submitted D shares before the increase will be paid the full expectation in the D-window, and then when difficulty increased it will once again go inside the window and have more expected reward. And, like the previous case, shares submitted just before the difficulty change will be rewarded similarly to shares submitted after it.
Another incorrect implementation is to pay all shares in a window given in units of time (sometimes called PPLNM or PPLNH). In addition to the problems above, it has a problem common to all reward systems that use time as a factor, which is that it is more profitable to mine when the current hashrate is higher than the average.
Now that I'm actually mining on a pool which uses this method, I might give it more thought, and perhaps understand the problem. Not a lot of money at stake here, and I don't mind being motivated to do some research
Shift-based PPLNS would be the best PPLNS implementation based on that thread. It's used on BTC Guild and BitMinter.
July 07, 2013, 01:13:23 AM
At the suggestion of one of our hero members, I am switching from fixed Last-N based payouts to time-based payouts. I think it makes a bit more sense considering the nature of our pool.
I am setting the following time periods for each of the coins currently on the pool:
LTC: 24 hours
TRC: 6 hours
FTC: 8 hours
MNC: 30 minutes
WDC: 30 minutes
DGC: 30 Minutes
NVC: 12 hours
Please respond with any comments or concerns.
I am setting the following time periods for each of the coins currently on the pool:
LTC: 24 hours
TRC: 6 hours
FTC: 8 hours
MNC: 30 minutes
WDC: 30 minutes
DGC: 30 Minutes
NVC: 12 hours
Please respond with any comments or concerns.
July 07, 2013, 12:56:43 AM
Was there some hashing on NVC that didn't get credited? Just askin but I was having network issues so that might have affected my outcome.
Yes, the last 3 blocks on NVC were scored incorrectly, they have been re-scored and repaid.
July 07, 2013, 12:56:15 AM
MNC server seems like it may be overloaded again. Manually switching to MNC pool instead of multiport worked for a little while, but not long... I've switched over to LTC again manually in the mean time.
I tried setting the diff to 16 for MNC so we would get fewer stales, but it's too much for the server to handle when the multiport is on it..
Once we move to the two load balanced servers this should no longer be an issue and I would expect we will be able to scale well past 2+GHash on the scrypt pools.
Why do you think that the share difficulty would have an effect on stale rates? AFAIK, it just has an effect on the variance of stales rates. With a higher difficulty, it's less likely to get rejects on block changes, but the rejects that do happen have more impact. This should result in exactly the same stale rate, no matter which share difficulty is used.
When the block changes, the current share being worked on is abandoned and if submitted it's rejected. Since the miner submits target 16 shares (approximately) twice as fast as target 32 shares, reducing the difficulty should result in the same number of stales, but the percentage of stales should be half since the total number is higher.
The unavoidable latency between issuing a work restart and a miner receiving it results in a small window where the miner is effectively working to produce stale shares. Some devices (like BFL ASICs) also have additional latency on restarts, but let's ignore that. The latency window is always the same, no matter which share difficulty is used. If a miner is using diff16 shares, the probability of producing a stale share is twice that of another miner which is using diff32 shares. Not the same, as you are implying in the bolded part of what I quoted.
Reducing share difficulty makes it more likely that stale shares are produced during block changes, because the chance to produce a share that matches the target during the latency window is higher. But since all shares have lower value, expected total stale difficulty is the same.
Hmm, I'll have to think about this more, but I see what you are saying
July 07, 2013, 12:17:30 AM
MNC server seems like it may be overloaded again. Manually switching to MNC pool instead of multiport worked for a little while, but not long... I've switched over to LTC again manually in the mean time.
I tried setting the diff to 16 for MNC so we would get fewer stales, but it's too much for the server to handle when the multiport is on it..
Once we move to the two load balanced servers this should no longer be an issue and I would expect we will be able to scale well past 2+GHash on the scrypt pools.
Why do you think that the share difficulty would have an effect on stale rates? AFAIK, it just has an effect on the variance of stales rates. With a higher difficulty, it's less likely to get rejects on block changes, but the rejects that do happen have more impact. This should result in exactly the same stale rate, no matter which share difficulty is used.
When the block changes, the current share being worked on is abandoned and if submitted it's rejected. Since the miner submits target 16 shares (approximately) twice as fast as target 32 shares, reducing the difficulty should result in the same number of stales, but the percentage of stales should be half since the total number is higher.
The unavoidable latency between issuing a work restart and a miner receiving it results in a small window where the miner is effectively working to produce stale shares. Some devices (like BFL ASICs) also have additional latency on restarts, but let's ignore that. The latency window is always the same, no matter which share difficulty is used. If a miner is using diff16 shares, the probability of producing a stale share is twice that of another miner which is using diff32 shares. Not the same, as you are implying in the bolded part of what I quoted.
Reducing share difficulty makes it more likely that stale shares are produced during block changes, because the chance to produce a share that matches the target during the latency window is higher. But since all shares have lower value, expected total stale difficulty is the same.
July 07, 2013, 12:14:44 AM
Was there some hashing on NVC that didn't get credited? Just askin but I was having network issues so that might have affected my outcome.
July 06, 2013, 11:53:24 PM
MNC server seems like it may be overloaded again. Manually switching to MNC pool instead of multiport worked for a little while, but not long... I've switched over to LTC again manually in the mean time.
I tried setting the diff to 16 for MNC so we would get fewer stales, but it's too much for the server to handle when the multiport is on it..
Once we move to the two load balanced servers this should no longer be an issue and I would expect we will be able to scale well past 2+GHash on the scrypt pools.
Why do you think that the share difficulty would have an effect on stale rates? AFAIK, it just has an effect on the variance of stales rates. With a higher difficulty, it's less likely to get rejects on block changes, but the rejects that do happen have more impact. This should result in exactly the same stale rate, no matter which share difficulty is used.
When the block changes, the current share being worked on is abandoned and if submitted it's rejected. Since the miner submits target 16 shares (approximately) twice as fast as target 32 shares, reducing the difficulty should result in the same number of stales, but the percentage of stales should be half since the total number is higher.
July 06, 2013, 09:13:04 PM
MNC server seems like it may be overloaded again. Manually switching to MNC pool instead of multiport worked for a little while, but not long... I've switched over to LTC again manually in the mean time.
I tried setting the diff to 16 for MNC so we would get fewer stales, but it's too much for the server to handle when the multiport is on it..
Once we move to the two load balanced servers this should no longer be an issue and I would expect we will be able to scale well past 2+GHash on the scrypt pools.
Why do you think that the share difficulty would have an effect on stale rates? AFAIK, it just has an effect on the variance of stales rates. With a higher difficulty, it's less likely to get rejects on block changes, but the rejects that do happen have more impact. This should result in exactly the same stale rate, no matter which share difficulty is used.
July 06, 2013, 06:07:26 PM
MNC server seems like it may be overloaded again. Manually switching to MNC pool instead of multiport worked for a little while, but not long... I've switched over to LTC again manually in the mean time.
I tried setting the diff to 16 for MNC so we would get fewer stales, but it's too much for the server to handle when the multiport is on it..
Once we move to the two load balanced servers this should no longer be an issue and I would expect we will be able to scale well past 2+GHash on the scrypt pools.
July 06, 2013, 03:45:09 PM
Alright, I am setting up LKY, ARG and PXC on a set of 2 new, load balanced pool servers. After testing, these three coins will be *multiport only*. I.E. you won't be able to mine them directly.
ETA for testing is tonight. Tomorrow I hope to add PPC and FRC.
ETA for testing is tonight. Tomorrow I hope to add PPC and FRC.
Just a reminder for the thread that PPC has a 520-confirm protocol like NVC, but is SHA-256. Still a very interesting coin! Will it be a direct mine like TRC?
July 06, 2013, 01:43:34 PM
MNC server seems like it may be overloaded again. Manually switching to MNC pool instead of multiport worked for a little while, but not long... I've switched over to LTC again manually in the mean time.
Jump to: