[ANN][The Original Multipool - Scrypt/SHA256/Scrypt-N/X11] multipool.us

[flound1129]

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.

[SullyTex]

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.

[juhakall]

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.

[flound1129]

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

[flound1129]

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.

[flound1129]

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.

[juhakall]

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 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:

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.

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.

[flound1129]

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 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:

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.

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.

[ozoner]

Just wanted to add my +1 for MEC on the multiport. Thanks for your efforts Mr Flound

[flound1129]

pool maintenance starting now, eta 5-10 minutes

[flound1129]

pool maintenance starting now, eta 5-10 minutes

maintenance complete

[flound1129]

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.

[jdebunt]

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.

would love to see these added aswell, thanks for the efforts

[flound1129]

The last 5 DGC blocks (212374 - 212273) were paid, however they have no payout data available due to a sql issue in the db..

[jkminkov]

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.

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

[captainfuture]

lucky is on i see 

[Armchair Miner]

Hey, great to see you're adding new coins. Your site is a lazy armchair miner's delight. Also, the sha256 coins such as PPC will be a great addition.

I saw this: 2013-07-07 03:58:16 LKY, ARG and PXC are now available for BETA testing.  Use pool1.us.multipool.in rather than the normal hostname!

and I saw that these new coins will only be available for multiport after BETA. What about during BETA, is multiport on for all these and other coins combined? I'll switch to beta right now if so.

Thanks!

[Armchair Miner]

I'll switch to beta right now if so.

Heck, I switched to beta. See what happens

[docjunior]

NVC, apart from having problems, does not fit into a pool-hopping scheme with its 520 confirmations. It may be "profitable" to mine at the moment the pool switches to NVC, but a lot may happen in the DAYS it takes before payout. The trades for NVC on BTC-e have fallen from 0.043 to 0.038, around 12%, in the past 24 hours, while confirmation takes a lot longer than that. This illustrates how meaningless it is to have such a slow coin as part of a hopping scheme. You chould  consider removing NVC from multiport, and leave it for the dedicated miners.

[juhakall]

My confirmed LTC balance is suddenly negative (-0.2182).