Tweet
One or 2 of you pointed me at a thread spouting absolute BS on the ST forum this morning. So in the spirit of utter bullshit, here is a little send up. { There are subtle changes.}
1. As many threads as required are constantly polling Betfair for current market prices.
2. Timing is interleaved to give maximum benefit & is entirely customisable.. The application is designed to receive as many sets of prices per second as you request.
3. Other threads are constantly getting market-traded volume based upon the interval you set.
4. Other threads repeatedly get the bet status when required.
5. Other threads are responsible for placing bets. It makes maximum use of the API and can place 60 bets in one API call.
6. Other threads are responsible for updating bets. Again maximum use of the API allows as many updates as you need to occur at a time. This is particularly useful for tools or when placing several sub minimum bets or dragging several bets to another price on the ladder.
7. Other threads are responsible for cancelling bets and can cancel up to 40 bets in a single API call. This is noticeable when you kill all bets on a selection or when using tools such as Fill or Kill.
8. Other threads checks the status of other markets you open (status, prices and bets). It cycles through them using spare capacity to yield maximum calls to the foreground market.
9. Other threads monitor tools in use on all markets including the foreground market.
10. Other threads deal with market status, the wallet and more.
11. Screen painting is optimised by holding an in memory image of what the user sees. Only fields that are changed are updated. On a busy market this benefit is particularly noticeable on the ladders. The overall effect is to lower CPU usage for graphics and thus give more power to the application.
12. The application uses asynchronous calls so operations can be happening at the same time. E.g. Open a menu, place a bet, cancel bets on a runner, etc. can all happen at the same time. One operation does not need to complete for the next one to begin.
13. While the speed of the response varies with your internet connection and Betfair’s response time you will invariably get data that is, on average, half the polling interval fresher than BT4. While your screen prices are being updated with the last response the application is already half way through the process of getting the latest prices from Betfair again.
14. Overall there are as many threads in the application as you need for the particular tasks you may be performing.. A thread is like a mini program dedicated to performing a specific task. All threads run concurrently.
15. The Toy has a few optimisations over the above that I never told Adam about, so they haven't copied those at least. Shh. Mums the word.
As stated on RT, more BS to follow soon, but seeing as the competition has not quite caught up yet I can get on with real work.
1. As many threads as required are constantly polling Betfair for current market prices.
2. Timing is interleaved to give maximum benefit & is entirely customisable.. The application is designed to receive as many sets of prices per second as you request.
3. Other threads are constantly getting market-traded volume based upon the interval you set.
4. Other threads repeatedly get the bet status when required.
5. Other threads are responsible for placing bets. It makes maximum use of the API and can place 60 bets in one API call.
6. Other threads are responsible for updating bets. Again maximum use of the API allows as many updates as you need to occur at a time. This is particularly useful for tools or when placing several sub minimum bets or dragging several bets to another price on the ladder.
7. Other threads are responsible for cancelling bets and can cancel up to 40 bets in a single API call. This is noticeable when you kill all bets on a selection or when using tools such as Fill or Kill.
8. Other threads checks the status of other markets you open (status, prices and bets). It cycles through them using spare capacity to yield maximum calls to the foreground market.
9. Other threads monitor tools in use on all markets including the foreground market.
10. Other threads deal with market status, the wallet and more.
11. Screen painting is optimised by holding an in memory image of what the user sees. Only fields that are changed are updated. On a busy market this benefit is particularly noticeable on the ladders. The overall effect is to lower CPU usage for graphics and thus give more power to the application.
12. The application uses asynchronous calls so operations can be happening at the same time. E.g. Open a menu, place a bet, cancel bets on a runner, etc. can all happen at the same time. One operation does not need to complete for the next one to begin.
13. While the speed of the response varies with your internet connection and Betfair’s response time you will invariably get data that is, on average, half the polling interval fresher than BT4. While your screen prices are being updated with the last response the application is already half way through the process of getting the latest prices from Betfair again.
14. Overall there are as many threads in the application as you need for the particular tasks you may be performing.. A thread is like a mini program dedicated to performing a specific task. All threads run concurrently.
15. The Toy has a few optimisations over the above that I never told Adam about, so they haven't copied those at least. Shh. Mums the word.
As stated on RT, more BS to follow soon, but seeing as the competition has not quite caught up yet I can get on with real work.
. I am curious to know what EVO offers if anyone has seen it, if anyone care to explain in layman terms. TG ,you must have some info on it?.......
Comment