Hello,
This says it is litecoin compatible but is using bitcoin difficulty of 1... How can I adjust the share difficulty so it's appropriate for litecoin...?
Thanks!!!
Topic: LTC/ArtForz PushPool Question (Read 2920 times)
Right now my pushpoold is using about 20 MB of memory, and I don't see why it would need much more than that. The Litecoin client, on the other hand, needs a good amount of RAM to run, often over 100 MB.
But even if we add to that the memory needed to run the database and a webserver, 1.5 GB is a lot.
But even if we add to that the memory needed to run the database and a webserver, 1.5 GB is a lot.
Right, that's what I was thinking as well.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3486 ppdu 20 0 287m 113m 992 S 4.0 19.2 6:10.92 pushpoold
I'll try another linux flavor? Perhaps it's one of the libraries in the ubuntu repository causing it?
So then I start to wonder, how much memory does pushpoold use when under good load from litecoin miners? I ask because I'm running my instance on an Ubuntu EC2 small and I'm curious if the 1.5GB RAM isn't enough and THAT'S why pushpoold keeps quitting out after using up all the memory.
Right now my pushpoold is using about 20 MB of memory, and I don't see why it would need much more than that. The Litecoin client, on the other hand, needs a good amount of RAM to run, often over 100 MB.
But even if we add to that the memory needed to run the database and a webserver, 1.5 GB is a lot.
So then I start to wonder, how much memory does pushpoold use when under good load from litecoin miners? I ask because I'm running my instance on an Ubuntu EC2 small and I'm curious if the 1.5GB RAM isn't enough and THAT'S why pushpoold keeps quitting out after using up all the memory.
I've never found memory leaks in pushpool itself (kudos to jgarzik), but it is possible that the issue you are experiencing is caused by one of the dependencies.
Some versions of libevent, in particular, are affected by memory leaks, so try upgrading it.
Some versions of libevent, in particular, are affected by memory leaks, so try upgrading it.
Yeah, I got latest from repo before building. I'm not entirely sure even how to troubleshoot this one, but I guess I could just have bash do a while loop and just restart it on exit. Just sucks
So, perhaps a lower level question. I cloned ArtFortz's pushpoold git and built it on Ubuntu and it would seem that this version has a memory leak?
My friend and I are doing a private pool to combine our resources and I can't seem to keep pushpoold up for more than ~48 hours before it just quits out with no error message. Over that time period, I can see it using more and more memory.
Anyone experienced this? Any ideas?
My friend and I are doing a private pool to combine our resources and I can't seem to keep pushpoold up for more than ~48 hours before it just quits out with no error message. Over that time period, I can see it using more and more memory.
Anyone experienced this? Any ideas?
I've never found memory leaks in pushpool itself (kudos to jgarzik), but it is possible that the issue you are experiencing is caused by one of the dependencies.
Some versions of libevent, in particular, are affected by memory leaks, so try upgrading it.
Digging up an old thread because my question is related 
So PPS for a target.bits 17 pool would be: 50(32768/difficulty)
Correct? My logic being 2^16 is 65536, and 17 would be half as many shares required.
So PPS for a target.bits 17 pool would be: 50(32768/difficulty)
Correct? My logic being 2^16 is 65536, and 17 would be half as many shares required.
No. The higher target.bits, the lower (harder) the target.
If on average it takes 2^17 hashes to find a share, the PPS rate would be: 50 LTC / (2^32*difficulty) * 2^17.
The "2^32" part comes from the definition of difficulty: at difficulty 1 the expected number of hashes to compute in order to find a block is 2^32.
Ah! Perfect. Thank you again for all your help!
So, perhaps a lower level question. I cloned ArtFortz's pushpoold git and built it on Ubuntu and it would seem that this version has a memory leak?
My friend and I are doing a private pool to combine our resources and I can't seem to keep pushpoold up for more than ~48 hours before it just quits out with no error message. Over that time period, I can see it using more and more memory.
Anyone experienced this? Any ideas?
Thanks again for your help!
Digging up an old thread because my question is related
So PPS for a target.bits 17 pool would be: 50(32768/difficulty)
Correct? My logic being 2^16 is 65536, and 17 would be half as many shares required.
So PPS for a target.bits 17 pool would be: 50(32768/difficulty)
Correct? My logic being 2^16 is 65536, and 17 would be half as many shares required.
No. The higher target.bits, the lower (harder) the target.
If on average it takes 2^17 hashes to find a share, the PPS rate would be: 50 LTC / (2^32*difficulty) * 2^17.
The "2^32" part comes from the definition of difficulty: at difficulty 1 the expected number of hashes to compute in order to find a block is 2^32.
Digging up an old thread because my question is related
So PPS for a target.bits 17 pool would be: 50(32768/difficulty)
Correct? My logic being 2^16 is 65536, and 17 would be half as many shares required.
So PPS for a target.bits 17 pool would be: 50(32768/difficulty)
Correct? My logic being 2^16 is 65536, and 17 would be half as many shares required.
That setting also defines how much a share is worth.
If you set it to N bits, miners will need to compute 2^N hashes on average in order to find a share.
So, for example, if you set N=16 you will receive twice as many shares than with N=17, but they will be worth half the value, so the result will be the same.
Bitcoin pools use a standardized value of 32 bits (i.e. difficulty 1); in the Litecoin world, however, no standard exists, although most pools use 16 or 17 bits.
If you set it to N bits, miners will need to compute 2^N hashes on average in order to find a share.
So, for example, if you set N=16 you will receive twice as many shares than with N=17, but they will be worth half the value, so the result will be the same.
Bitcoin pools use a standardized value of 32 bits (i.e. difficulty 1); in the Litecoin world, however, no standard exists, although most pools use 16 or 17 bits.
Hmm, that seems a bit arbitrary, don't you think? Especially for the number of PPS pools that are out there. As a pool operator, I could set it to 18 and pay PPS on a lower volume of shares.
As I said, there would be fewer shares, but they would be worth more. The value (in LTC) of a share must be computed taking into consideration the current difficulty of the network and the target you serve to miners (which is determined by the setting you mentioned in the OP).
An example: suppose the current difficulty is 1. By definition of difficulty, this means that on average you need to compute 2^32 hashes in order to find a block worth 50 LTC. If you set a target of 17 bits, every share should be counted as 2^17 of those 2^32 theoretical hashes. So the PPS rate of a "2^17" pool will be two times the PPS rate of a "2^16" pool.
Of course this computation is only needed for PPS. In a proportional system the value of a share is not important.
That setting also defines how much a share is worth.
If you set it to N bits, miners will need to compute 2^N hashes on average in order to find a share.
So, for example, if you set N=16 you will receive twice as many shares than with N=17, but they will be worth half the value, so the result will be the same.
Bitcoin pools use a standardized value of 32 bits (i.e. difficulty 1); in the Litecoin world, however, no standard exists, although most pools use 16 or 17 bits.
If you set it to N bits, miners will need to compute 2^N hashes on average in order to find a share.
So, for example, if you set N=16 you will receive twice as many shares than with N=17, but they will be worth half the value, so the result will be the same.
Bitcoin pools use a standardized value of 32 bits (i.e. difficulty 1); in the Litecoin world, however, no standard exists, although most pools use 16 or 17 bits.
Hmm, that seems a bit arbitrary, don't you think? Especially for the number of PPS pools that are out there. As a pool operator, I could set it to 18 and pay PPS on a lower volume of shares.
No, you don't need to change it when difficulty changes.
That setting rewrites the target in the work served to miners so that they look for shares instead of blocks.
In practice, you should probably set it to something between 16 and 18. The lower the number, the more shares pushpool will receive.
That setting rewrites the target in the work served to miners so that they look for shares instead of blocks.
In practice, you should probably set it to something between 16 and 18. The lower the number, the more shares pushpool will receive.
Wouldn't the client submitting more shares impact a PPS pool's payout #'s?
That setting also defines how much a share is worth.
If you set it to N bits, miners will need to compute 2^N hashes on average in order to find a share.
So, for example, if you set N=16 you will receive twice as many shares than with N=17, but they will be worth half the value, so the result will be the same.
Bitcoin pools use a standardized value of 32 bits (i.e. difficulty 1); in the Litecoin world, however, no standard exists, although most pools use 16 or 17 bits.
No, you don't need to change it when difficulty changes.
That setting rewrites the target in the work served to miners so that they look for shares instead of blocks.
In practice, you should probably set it to something between 16 and 18. The lower the number, the more shares pushpool will receive.
That setting rewrites the target in the work served to miners so that they look for shares instead of blocks.
In practice, you should probably set it to something between 16 and 18. The lower the number, the more shares pushpool will receive.
Wouldn't the client submitting more shares impact a PPS pool's payout #'s?
I'm trying to setup a private pool for my company and I have one question that I've seen discussed but not entirely in-depth.
The "rpc.target.bits" functionality is my biggest question. Do I need to adjust this manually with each difficulty change (since it seems to impact the # of shares submitted)?
Thanks!
The "rpc.target.bits" functionality is my biggest question. Do I need to adjust this manually with each difficulty change (since it seems to impact the # of shares submitted)?
Thanks!
No, you don't need to change it when difficulty changes.
That setting rewrites the target in the work served to miners so that they look for shares instead of blocks.
In practice, you should probably set it to something between 16 and 18. The lower the number, the more shares pushpool will receive.
I'm trying to setup a private pool for my company and I have one question that I've seen discussed but not entirely in-depth.
The "rpc.target.bits" functionality is my biggest question. Do I need to adjust this manually with each difficulty change (since it seems to impact the # of shares submitted)?
Thanks!
The "rpc.target.bits" functionality is my biggest question. Do I need to adjust this manually with each difficulty change (since it seems to impact the # of shares submitted)?
Thanks!
Jump to: