First, awesome work there shad... PoolServerJ performance over pushpool is great.
Just got a two short question and a request
1)
atm i'm running poolserverj in screen and it works great, but if anyone got other suggestion please post
2)
When i check the screen it looks like this:
Doing database flush for Shares: 10
Flushed 10 shares to DB in 9.0ms (1111/sec)
Trimmed 14 entries from workmap and 29 entries from duplicate check sets in 0ms
Dropping submit throttle to 2ms
Submit Throttling on: false
Doing database flush for Shares: 7
Flushed 7 shares to DB in 4.0ms (1749/sec)
Submit Throttling on: false
Doing database flush for Shares: 15
Flushed 15 shares to DB in 8.0ms (1874/sec)
Trimmed 16 entries from workmap and 1003 entries from duplicate check sets in 0ms
Submit Throttling on: false
Doing database flush for Shares: 14
Flushed 14 shares to DB in 4.0ms (3499/sec)
I just wonder what does Submit Throttling on: false mean?
Request:
I also got an request about ?method=getsourcestats, it would be nice to have a short description on what each stats really mean, if you could make a short list it would be nice.
Sorry all dumb question
Btw, i run bitcoind 0.4.0, did switch from bitcoind 0.3.24(patched with joelkatz diff4) and it seems to run great with the new bitcoind.
/Best regards
1/ daemonizing poolserverj has been on my todo list since day one but this is actually the first time anyone has asked about it. I'm not much of a bash expert but I think if you do something like this:
normalStartCommand > mylogfile.txt &
that should redirect the output to a file and run it as a background process so you can keep using your shell.
2/ submit throttling is a fairly useless feature. It kicks in if a db flush is triggered and the previous one hasn't finished yet. It was useful during stress testing when I had a fixed number of fake miners so it would effectively throttle the submit rate. In the real world though it won't really have any effect aside from giving the miner a short delay before they receive a response to their share submits... I will get rid of it one of these days.
3/ getsourcestats is also something I built as an aid to testing so I didn't really give much though to making it readable. Most of the stats are useful, some of them do nothing and some give completely rubbish results. I also have a TODO to turn that in proper API probably with JSON output so when that's done and I've stripped out the useless stuff and put some other more useful things in I'll write up some doco...
But for now here's a brief rundown (comments in italics):
Memory used: 4.4375 MB - Freed by GC: 9.900390625MB
This only refers to heap memory. Depending on how many connection threads you've got assigned you can add about 10-30mb to this to get real memory usage. The total of 'used' + 'freed' is approx the currently allocated heap size.State [bitcoind-patch]
these stats are per daemon, if you multiples you see this section repeated Current Cache Max: 1000 - min/max: 1/1000
Current Cache Size: 998
this is the work cache. min/max are meaningless atm. There used to be a dynamic cache sizing algorithm but it was a bit crap so I took it out. The 1000 represent the max number before it will stop calling for more work. The 998 is current number in cache. This can occasionally creep over your max by up to Concurrent DL Requests. Concurrent DL Requests: 10 - min/max: 1/20
This is a gotcha, currently this gets set to 1/2 the value you've set. Another hangover from the old dynamic cache sizing algo which also regulated request rate. DL Request Interval (ms): 0 - min/max: 0/100
Current Ask Rate (works/req): 10
these 2 are rubbish Consecutive Connect Fails: 0
Consecutive Http Fails: 0
Consecutive Http Auth Fails: 0
Consecutive Http Busy Fails: 0
These do actually work but they'll always be zero unless yr daemon crashes or you have network problems between psj and bitcoind. Cache Excess: 1,002.5
Cache Excess Trend: 0.06
rubbish Cache Retreival Age: 13885
avg age of work work when retrieved from cache. measured in millis from when it was retrieved from daemon Incoming Rate: 36.69/sec
how many works/sec you're getting from the daemon. This doesn't represent the maximum but if you look straight after a block change for a few seconds it will probably be close. Incoming Fullfillment Rate: 100%
number request/number received. This will drop under 100% if you have http errors or daemon stops responding to requests for any reason. Outgoing Requested Rate: 0.78/sec
Outgoing Delivered Rate: 0.78/sec
Outgoing Fullfillment Rate: 100%
same thing basically. Except if fullfillment drops below it most likely means psj can't get work from the daemon fast enough.Longpoll Connections: 1 / 1000
Ignore the 1000. There used to be a limit but there's not anymore. Connections will include connections that have been silently dropped by the client but not connection that have expired.WorkSource Stats:
Stats for source: [bitcoind-patch]
Current Block: 147243
Cache:
Work Received: 42965
Work Delivered: 978
fairly obvious, duplicate below Upstream Request Fail Rate: 0%
Upstream Request Fail Rate Tiny: 0%
rubbish Immediately Serviced Rate: 91.2%
This one is worth a comment. Immediately serviced mean miner request work, psj checked cache and found one already available. If the cache is empty it will wait a few seconds for one to arrive and this counts as 'not immediate' In reality it might only be a millisecond or two. MultiGet Delivery Rate: ?%
Delayed Serviced Rate: 100%
Not Serviced Rate: 0%
Expired Work Rate: 100%
rubbish Duplicate Work Rate: 0%
Usually 0 but if you have an unpatched daemon there's a bug that cause duplicates... If you ever see this higher than 0.01% keep an eye on it, it's a definately indicator something is wrong. Cache Growth Rate: 17.228%
Cache Growth Rate Short: 29.76%
rubbish Work Submissions:
Work Supplied: 978
Work Submitted: 0
Work Submitted Invalid: 0
Work Submitted Unknown: 0
Work Submitted Valid: 0
Work Submitted Valid Real: 0
not rubbish but doesn't work. HTTP:
Requests Issued: 42972
Fail Rate: 0%
Success trip time: 24.56 ms
Header trip time: 24.55 ms
Fail trip time: ? ms
Expire trip time: ? ms
These are about the HTTP connection between psj and daemon. Nothing to do with miner side of the server. The trip times are a useful for tuning max concurrent connections... Once the latency start to go up dramatically you've probably got too many. Cache Age:
Entries: 998 Oldest: 10337 Newest: 4032 Avg: 5418 Reject Rate: 0%
stats on the current contents of the cache. Oldest. Newest, Avg are age in millis. Reject Rate is basically the same thing a Duplicate rate except with a different moving average period.
