May I suggest that the pool pay the balance at addresses that no longer being mined at? I used over 6 addresses before I found out about “-minerid”. So all these 6 address have tiny amounts of XPM in them (like 0.2 each). Can you payout these balances once the address has seen no activity for 30 days, and has more than 0.01 balance?
started mining today at http://beeeeer.org/
Intel® Xeon® CPU E5-2650 0 @ 2.00GHz 16 Core HT 32 8GB RAM
Ubuntu 12.04 LTS
Stats
[STATS] 2014-01-23 07:44:44 | 2582 primes/s, 41658 tests/s, 540 5-chains/h, 0.083 chains/d
[STATS] 2014-01-23 07:47:02 | 2551 primes/s, 40768 tests/s, 1140 5-chains/h, 0.083 chains/d
running 2 miners
Any suggestions on how to fine tune?
The Primecoin hardware comparison tool says i should get 1.861 Chains/day for N-Chain 10
Intel Xeon E5-2650 Ubuntu 13.04 64-bit Xolominer v0.8 RC1 10 1.861 3489 9 10
Also where can i set Sieve Extensions , Sieve percentage and Sieve Size??
Will provide XPM for helpful suggestions
no comment on my recent post @ LazySiege/icedaddy :
is that a bad or a good sign?
i also wrote a little bit about the sharelog increase/decrease: here
@jagali2014:
so, you’ve already found the hardware comparison thread 
which is pretty much the best place for your question
commands are the same as for mikaelh’s standalone client:
-sievesize=<#>
-sievepercentage=<#>
-sieveextensions=<#>
- xolokram
[quote=“xolokram, post:1804, topic:342”]@jagali2014:
so, you’ve already found the hardware comparison thread
which is pretty much the best place for your question
commands are the same as for mikaelh’s standalone client:
-sievesize=<#>
-sievepercentage=<#>
-sieveextensions=<#>
- xolokram[/quote]
@xolokram
Thank you the hardware comparison thread @ http://anty.info/primecoin-hardware/ says I must get 1.861 Chains/d, However i am getting 0.166 chains/d. is this correct?
Hi,
for future questions: please PM me or write in a thread, not both
the anty.info hardware comparison is outdated
it was done for difficulty 9.x, we’re now at 10.x
thus the values are not comparable, i -think- your values are alright
compare to the most recent posts in the hardware comparison thread or wait for a answer there
- xolokram
[quote=“xolokram, post:1804, topic:342”]commands are the same as for mikaelh’s standalone client:
-sievesize=<#>
-sievepercentage=<#>
-sieveextensions=<#>
- xolokram[/quote]
sievesize and sieveextensions are not changing they are defaulting to 9 and 1000000.
Any Suggestions
what values do you want to use? here are the min/max values
static const unsigned int nMaxSieveExtensions = 20;
static const unsigned int nMinSieveExtensions = 0;
static const unsigned int nDefaultSieveExtensions = 9;
static const unsigned int nDefaultSievePercentage = 10;
static const unsigned int nMinSievePercentage = 1;
static const unsigned int nMaxSievePercentage = 100;
static const unsigned int nMaxSieveSize = 10000000u;
static const unsigned int nDefaultSieveSize = 1000000u;
static const unsigned int nMinSieveSize = 100000u;
sorry, just copy&paste
Please Help me. It is 4 days I started mining Primecoin with Xolominer in Beeeeer.org pool but there no Payout to my XPM wallets.
I see payouts to my address in beeeer pool payouts pages but I dont receive them in my wallet addresses.
1st wallet: AVkqUdwYTaLWxhQ2Nrk2tsCmSBY2ZXgRRP
2nd wallet: AHWZSWEFL8rZDNPNvVBR8BPvLoKZyWsCcA
AHWZSWEFL8rZDNPNvVBR8BPvLoKZyWsCcA -> balance 2.1 XPM
AVkqUdwYTaLWxhQ2Nrk2tsCmSBY2ZXgRRP -> balance 2.42 XPM
payouts are executed at 3.01 XPM
[quote=“xolokram, post:1804, topic:342”]no comment on my recent post @ LazySiege/icedaddy :
is that a bad or a good sign?
i also wrote a little bit about the sharelog increase/decrease: here
- xolokram[/quote]
Neither. I am trying to walk through the process, and failing; I suspect the beta stats do not give me the granularity needed to do that and I have not been able to access the “raw” stats as you indicated. The block log indicates that in general what I understand you to have said appears true. Please understand I never thought you were misleading us only that my understanding of what you said was incomplete.
I admit the logic behind your statement that a reasonably sized sharelog is a good thing escapes me, but that is probably a lack of understanding on my part. It would seem to the goal would be to pay shares as they are found so ideally you would want zero share log, and perhaps even a slight surplus. I admit it is annoying to find a block and have to wait 5 days for the reward, or even 2 days for the block to mature if solo mining; we live in a world of instant gratification.
For what it’s worth it seems to me this methodology is unnecessarily complex; why not simply add all shares to the sharelog as they are found and pay off shares FIFO from the sharelog as blocks mature?
[quote=“xolokram, post:1782, topic:342”]@TalkCryptoCoin:
i had no problems too… ???
[size=18pt]Hi,[/size]
because of popular demand: say hello to -poolip2, -poolip3 & -exitondisc <-- changelog
linux / bitbucket: source
linux / github: source
windows binary: ‘xolominer’ v0.8 RC2 (32&64bit) (i do not recommend any other source for binaries, be careful!!)
mac user: see this post
usage:
[code]primeminer -pooluser=[xpm-payout-address] -poolip=[choose-from-above] -poolport=1337 -genproclimit=[threads-to-use]
optional:
-poolfee=[1 - 100 (in %), default: 3%]
-minerid=[0 - 65000]
-poolip2= (as fallback, along with -poolport2=)
-poolip3= (as fallback, along with -poolport3=)
-exitondisc=1 (as exit-on-fail, instead of retrying the connection)
alternative ports: 21, 443, 8080, 13337
example:
primeminer -pooluser=AJhA1PGbNM94ZmsJvVVM5FfbE9SdxiMzgd -poolip=176.34.128.129 -poolip2=54.200.248.75 -poolip3=54.251.179.44 -minerid=42 -poolport=1337 -genproclimit=4
or
primeminer -pooluser=AJhA1PGbNM94ZmsJvVVM5FfbE9SdxiMzgd -poolip=176.34.128.129 -exitondisc=1 -minerid=42 -poolport=1337 -genproclimit=4[/code]
compiler problems: go check out (& donate) http://www.peercointalk.org/index.php?topic=798.0
- xolokram
ps. i’m working on a bigger update to remove/clean up the code to make the miner more lightweight, update to mikaelh’s new version & improve the network code, but this is taking longer than i thought so i’ll release this smaller update on the old version first
pps. third-party app/stats creator: use this raw.beeeeer.org
ppps. checkout the first post for more information if you’re new to beeeeer[/quote]
is the new miner better in performance in any way? or is it just some code refactoring version.
i noticed higher rejection rate >20%. is this normal? this comes from all my machines, 3x a vps from different provider.
i use the 176.34.128.129 server
[quote=“ulkas, post:1812, topic:342”][…]
is the new miner better in performance in any way? or is it just some code refactoring version.[/quote]
nope, i just added the new parameters
@ulkas:
that’s not normal. is someone else experiencing the same? i’ll ask the guys (& girls?) on the irc channel.
- xolokram
Neither. I am trying to walk through the process, and failing; I suspect the beta stats do not give me the granularity needed to do that and I have not been able to access the “raw” stats as you indicated. The block log indicates that in general what I understand you to have said appears true. Please understand I never thought you were misleading us only that my understanding of what you said was incomplete.
I admit the logic behind your statement that a reasonably sized sharelog is a good thing escapes me, but that is probably a lack of understanding on my part. It would seem to the goal would be to pay shares as they are found so ideally you would want zero share log, and perhaps even a slight surplus. I admit it is annoying to find a block and have to wait 5 days for the reward, or even 2 days for the block to mature if solo mining; we live in a world of instant gratification.
For what it’s worth it seems to me this methodology is unnecessarily complex; why not simply add all shares to the sharelog as they are found and pay off shares FIFO from the sharelog as blocks mature?[/quote]
you arguments are contrary somehow. you say it’s annoying to mine and see the fractional earning for that 5 days later (sharelog). and then you suggest to use only FIFO. which means if you’re completely new on the pool: you’ll have to 5 days to see the first earning at all. of course this is not the case for you right now. but the payout system shouldn’t be seen only on a individual basis.
FILO is worse (yeah, you didnt mentioned it, but i think it’s good to have a complete overview for this): this was the case before 5th of January, shares got stuck from early December etc.pp. let’s just forget about it now, it was crap 
with the current setup you’ll have instant earnings (new & old miners), and the sharelog is used to conter fluctuation in mining performance. if you’re mining long enough it won’t matter that much for you as you’ll always have your instant earnings and the earnings from the sharelog. new miners will just have the instant earning for the first few days, but it’s better than nothing.
- xolokram
ps. sorry for the late reply 
Neither. I am trying to walk through the process, and failing; I suspect the beta stats do not give me the granularity needed to do that and I have not been able to access the “raw” stats as you indicated. The block log indicates that in general what I understand you to have said appears true. Please understand I never thought you were misleading us only that my understanding of what you said was incomplete.
I admit the logic behind your statement that a reasonably sized sharelog is a good thing escapes me, but that is probably a lack of understanding on my part. It would seem to the goal would be to pay shares as they are found so ideally you would want zero share log, and perhaps even a slight surplus. I admit it is annoying to find a block and have to wait 5 days for the reward, or even 2 days for the block to mature if solo mining; we live in a world of instant gratification.
For what it’s worth it seems to me this methodology is unnecessarily complex; why not simply add all shares to the sharelog as they are found and pay off shares FIFO from the sharelog as blocks mature?[/quote]
you arguments are contrary somehow. you say it’s annoying to mine and see the fractional earning for that 5 days later (sharelog). and then you suggest to use only FIFO. which means if you’re completely new on the pool: you’ll have to 5 days to see the first earning at all. of course this is not the case for you right now. but the payout system shouldn’t be seen only on a individual basis.
FILO is worse (yeah, you didnt mentioned it, but i think it’s good to have a complete overview for this): this was the case before 5th of January, shares got stuck from early December etc.pp. let’s just forget about it now, it was crap
with the current setup you’ll have instant earnings (new & old miners), and the sharelog is used to conter fluctuation in mining performance. if you’re mining long enough it won’t matter that much for you as you’ll always have your instant earnings and the earnings from the sharelog. new miners will just have the instant earning for the first few days, but it’s better than nothing.
- xolokram
ps. sorry for the late reply :P[/quote]
You are correct; using a FIFO what you mine now you would see in about a week. With what we have now you see some of what you mine now and the rest in a week. As you point out FILO “is crap”, which is why I didn’t mention it. In any share based payout system involving a sharelog some portion of what you mine is going to be delayed the duration of the sharelog; it is the nature of the beast. As you point out with the current system if I look back beyond the sharelog my earning are the same no matter how you do it, with patience being the key. I get it, and agree.
As I see it the problem is the size of the sharelog. If the sharelog were at 16 hours and not 160 hours the delay would be hardly noticeable, if it were 1.6 hours it would be imperceptible and if it were zero (on average) there would be no delay.
I think of a water tank with an erratic input flow and a controllable output flow, the share reward being the output control. As an engineer my goal would be to keep the tank at 50% to counter fluctuation; if the level (sharelog) consistently raised I would increase the output (share reward) and if the level (sharelog) consistently dropped I would decrease the output (share reward). The sharelog is much like the tank, with zero being the middle point. If the pool is “lucky” the sharelog increases, and if the pool is “unlucky” the sharelog decreases (even goes into a surplus) with the average being zero. Yes I have my “increases” and “decreases” correct; if the pool is “lucky” it is mining more now than is being matured from past mining. With a pool the size of this one I doubt the sharelog would ever be more than a few hours, and the whole issue of delayed payouts would be moot.
If I understand your goal with the current payout method is to “counter fluctuations”, and you control the size of the sharelog by adjusting the share reward, as we have seen and just as I outlined above. For the reasons you mentioned you have chosen to pay out the sharelog in a manner to favor new miners, and I understand your reasoning even if I don’t agree with it. The real issue isn’t the fine nuances of that, but the size of the sharelog, which you have indicated is too large, something which I agree with you on, and you are working to reduce it, which I applaud. The question is reduce it to what? It is now at about 160 hours. What is your goal for sharelog size? I would be surprised if your goal was zero as I suggested. Block mature time, about 48 hours? 24 hours?
I am curious as I would expect that when we hit that point there will be an upheaval. At the moment share reward is low and miners have gone elsewhere, and when we hit the point of equilibrium, whatever it may be, I would expect the share reward to increase and mining will become more profitable than other pools and miners will flock back to the pool as it is by far the best I have seen and send the sharelog soaring again. Perhaps the share reward needs to be automatically tied to the sharelog size to provide automatic feedback and adjustment? That’s the engineer in me coming out again! 
I don’t know much about mining pools but maintaining an equilibrium in a dynamic system I am familiar with…
my cpu : E3-1240 V2
my os : debian 7 64bit
pool : beeeeer
my chain per day : 0.063
is that normal?
This amount could be higher?
please help
[quote=“mornabo, post:1817, topic:342”]my cpu : E3-1240 V2
my os : debian 7 64bit
pool : beeeeer
my chain per day : 0.063
is that normal?
This amount could be higher?
please help[/quote]
How many CPU’s are you using, and how much of each core?
1 cpu / 8 cores
no comment on my recent post @ LazySiege/icedaddy ::) is that a bad or a good sign? i also wrote a little bit about the sharelog increase/decrease: here
- xolokram
I will come back to this on monday (i hope) i just have some projekt timelines, which i need to hit first.
I think i understand it, but atm i try to think of a way to present it in an easy understandable picture/chart.
An other topic what about the threshold. Please lower the 3 xpm barier Xolo. Tell us what you are going to do !!! You can not let us wait forever.