.maxConcurrentDownloadRequests
This setting is the number of miners that can make a get work request or your thread making get work request against the bitcoin daemon. I will assume you create threads here and they do the get work to fill a cache or a request. 20 is a safe maximum but if your system is large and on fiber optics You could do more.
This refers to psj -> bitcoind requests. This side is completely asynchronous with miner -> psj requests. You should increase this value if your network latency between psj and bitcoind is higher than normal. This ensures there's less idle gaps for each end while the packets are traversing the network.
.maxConcurrentUpstreamSubmits
This is same as above but its submit to the bitcoin daemon and not really cashed but uses a thread for each thread.
yes basically the same as above but going to other direction. Unless you've forceAllSubmitsUpstream=true this can be low as you'd only expect to be sending submits when you win a block. Thanks to Eleuthria's testing I'm fairly confident now that it's safe to set forceAllSubmitsUpstream=false
.maxWorkAgeToFlush
When a thread makes a get work request to store in a cache this is how long in seconds that request is valid should no worker grab the cached work it will be flushed and a new get work request is called. The bitcoin network updates the work every 60 seconds or more if there is no new transactions (people sending coins) that will be placed in the work load so this value should not be too high or the pool will have a lot of stales? (<- I'm guessing here need confirmation ->) To small and the bitcoin daemon recieves more requests than necessary reducing performance?
Yes this is the cache 'expiry' time. When a new block is detected the entire cache is dumped however so it's not really an issue with stales. Just ensuring that work is relatively fresh so new transactions are included. As long as the work is from the correct block you could in theory dish out work that is 10 mins old and it wouldn't break anything.
.minIntervalBetweenHttpRequests
A pool receives work requests from miners this settings is the number of milliseconds between ANY request can be made to poolserverj? This means that poolserverj ignores or places in queue any request made under this time threshold? If too many requests are made to the poolserverj they may timeout waiting for poolserverj to accept their request? For example a value of 100 means only 10 requests can be made per second to poolserverj?
NOTE: If the above and bottom settings are what I think it is and you coded this right you are one BAD ASS DEVELOPER.
No this is relevent to the psj -> bitcoind side. It should be set to 0 unless you have an unpatched bitcoind. It just spaces out the requests a little so as not to overwhelm the bitcoind. This does improve a little with an unpatched daemon but will only slow you down if you have the 4diff patch.
The client side throttling you're talking about is actually handled by the QoS filter. And the number of requests it will service concurrently before the filtering kicks in is set by 'QoSMaxRequestsToServiceConcurrently=55'
If the server is under extreme load it will begin prioritizing requests. Priority is determined from lowest to highest:
worker not found
worker found but password is bad
worker found and authenticated
worker found and has submitted at least 1 valid work
worker found and has submitted at least 10 valid works.
low priority requests will probably never get serviced until the server load drops to a more bearable level.
.minIntervalBetweenHttpRequestsWhenFrantic
When a new block is found on the network all previous work becomes invalid and workers need new work thus minIntervalBetweenHttpRequests limit should be lifted to allow a burst of requests. This setting should be lower than minIntervalBetweenHttpRequests if not zero if your system can handle it.
Pretty much... This should be set to 0 in 99.9% of cases.
.maxCacheSize
This number is meaningless by it's self you need to figure out how much load you server can handle then this value is a calculation of that number plus head room for Frantic requests. The data in this cache is removed by workers or timed out by the value of maxWorkAgeToFlush setting however it's all meaningless without knowledge of you hardware and network limits. SEE optimal settings example below
Yes it's a key tuning parameter. If it's too high you will have a lot of work wasted and burn CPU cycles uneccessarilly. Too low and you will not have burst capacity. The right number is essentially dependant on your getwork load and how much burst capacity you want to have.
.cacheWaitTimeout
Your docs say...
### maximum time in milliseconds to wait for the cache to return work before giving up and returning an error result.
Huh? The cache is a separate application or thread that poolserverj waits for when miners make a work request? Thus this the length of time it waits to get that data? I would like to know is this memcache or something else internal to java like .NET cached objects?
It basically looks like this: bitcoind <-> work fetcher -> [cache: work queue] -> work server <-> miner.
However the the fetch and serve sides are async and barely interact. The cache is basically just a queue of works with some metadata attached.
when a getwork request is received the server thread polls the queue. If no work is available it sends a wake up call to the fetcher controller in case it's sleeping (very unlikely) then goes to sleep for cachewaitTimeout. Whenever the fetcher puts new work in the queue it notifies the sleeping server threads. They wake up and try to poll again. They may get beaten by another server thread so they go back to sleep again. If the fetcher can't get a work from the queue for cacheWaitTimeout milliseconds it gives up and returns a JSON-RPC error message.
Optimal Settings ExampleLets say your system has bitcoind installed on it and can only handle 200 requests per second before falling down. [NOTE: this is an example, your results may vary, please call your government official who knows best about everything to regulate what you do.]
So to be safe you say 100 request per second is your limit. The first thing you would set is minIntervalBetweenHttpRequests and its easy to figure out since 100 reqests pers second and there is 1000 milliseconds in a second so the value should be 10. The next setting is (you guessed it) minIntervalBetweenHttpRequestsWhenFrantic and we know our max is 200 so you could put 5 but 6 would be safe. Next settings are maxWorkAgeToFlush and maxCacheSize that should (maxCacheSize / (maxWorkAgeToFlush / 1000)) to equal 200, your systems maximum requests. Keeping in mind the maxWorkAgeToFlush should not be to low or too high.
Firstly I would set minIntervalBetweenHttpRequests and minIntervalBetweenHttpRequestsWhenFrantic to 0. If you bitcoind does not have 4diff patch then apply it.
(maxCacheSize / (maxWorkAgeToFlush / 1000)) <- this will ensure on average you waste very little work, you will still waste some due to variance in the rate of requests. However, you have no headroom for burst capacity. I would recommend you at least double this number. In a high load environment increase it quite a bit more. I hope I'm not giving away trade secrets here but I think BTC guild have their's set to about 10 times this number.
