From b4430f12472f6dd922df39694dda851374658dd3 Mon Sep 17 00:00:00 2001 From: Con Kolivas Date: Wed, 20 Jul 2011 13:59:34 +1000 Subject: [PATCH] Document changes. --- NEWS | 25 +++++++++++++++++++++++++ README | 24 ++++++++++++++++++++++++ 2 files changed, 49 insertions(+) diff --git a/NEWS b/NEWS index c891c26b..c3d5f25d 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,28 @@ +Version 1.3.1 - July 20, 2011 + +- Feature upgrade; Multiple strategies for failover. Choose from default which +now falls back to a priority order from 1st to last, round robin which only +changes pools when one is idle, rotate which changes pools at user-defined +intervals, and load-balance which spreads the work evenly amongst all pools. +- Implement pool rotation strategy. +- Implement load balancing algorithm by rotating requests to each pool. +- Timeout on failed discarding of staged requests. +- Implement proper flagging of idle pools, test them with the watchdog thread, +and failover correctly. +- Move pool active test to own function. +- Allow multiple strategies to be set for multipool management. +- Track pool number. +- Don't waste the work items queued on testing the pools at startup. +- Reinstate the mining thread watchdog restart. +- Add a getpoll bool into the thread information and don't restart threads stuck +waiting on work. +- Rename the idlenet bool for the pool for later use. +- Allow the user/pass userpass urls to be input in any order. +- When json rpc errors occur they occur in spits and starts, so trying to limit +them with the comms error bool doesn't stop a flood of them appearing. +- Reset the queued count to allow more work to be queued for the new pool on +pool switch. + Version 1.3.0 - July 19, 2011 - Massive infrastructure update to support pool failover. diff --git a/README b/README index 4c4bfb0b..3c522ef3 100644 --- a/README +++ b/README @@ -117,3 +117,27 @@ NOTE: Running intensities above 9 with current hardware is likely to only diminish return performance even if the hash rate might appear better. A good starting baseline intensity to try on dedicated miners is 8. Higher values are there to cope with future improvements in hardware. + + +FAILOVER STRATEGIES WITH MULTIPOOL: +A number of different strategies for dealing with multipool setups are +available. Each has their advantages and disadvantages so multiple strategies +are available by user choice, as per the following list: + +FAILOVER: +The default strategy is failover. This means that if you input a number of +pools, it will try to use them as a priority list, moving away from the 1st +to the 2nd, 2nd to 3rd and so on. If any of the earlier pools recover, it will +move back to the higher priority ones. + +ROUND ROBIN: +This strategy only moves from one pool to the next when the current one falls +idle and makes no attempt to move otherwise. + +ROTATE: +This strategy moves at user-defined intervals from one active pool to the next, +skipping pools that are idle. + +LOAD BALANCE: +This strategy sends work in equal amounts to all the pools specified. If any +pool falls idle, the rest will take up the slack keeping the miner busy.