Author Topic: Cross-Market Betting Issue  (Read 1046 times)

Tags:
  • All members
  • Posts: 33
  • Gender: Male
Cross-Market Betting Issue
« on: 14 Dec 2020, 15:16 »
Hello!

I'm having a few issues getting a cross-market setup to work correctly, and was hoping someone may have some solution(s).


My current setup is geared to place bets in three different markets, at the same time, provided certain conditions are met (all calculations are based on available prices in the markets). Both speed and accuracy are critical to the setup working successfully, but I can't seem to get both at the same time.


Speed: I can operate the setup using a single trigger, with three actions (one per market), set to fire when a (relatively dense) single line condition is met. However, if I set the trigger to calculate from a single market then I cannot 'move' certain information into the other markets for use (e.g. the price(s) in the other market(s) that caused the trigger to fire) so any split second price movements can lead to failure (i.e. backing at back_price can produce a lower figure than the one used in the calculation). Alternatively, I can let the trigger run the calculation in every market, so the information needed is available everywhere, but then this also leads to errors as the markets are not refreshed in perfect sync - such that the same calculation can return different values in different markets (even if they're very closely synced). The speed at which things work is as fast as can be, but the inaccuracies which happen mean its either unworkable or unsuccessful.

Accuracy: This uses the above setup to identify that a selection has met the condition, but saves all the relevant information as (event level) user variables which ensures accuracy. A second trigger then places the relevant bets in the three markets on the selection identified using these variables, and a third trigger then resets everything. However, this method means that it can only operate on one selection at a time, and it also adds at least one refresh delay into the process (0.5 delay is probably workable, but I'd be looking to have this running across up to 100 markets at once, and the calculation load is already heavier than I'd like). The method is 100% accurate, but the delay/load means bets don't always hit their targets fast enough. This is better than having inaccuracies, as the bets can wait to be matched if prices have moved, but if any of the bets miss then there are liabilities which I'm keen to avoid (I can implement safeties for if this does happen, but the trigger is set to fire only when all the bets are actually available, so greater delay = greater chance of missing).

Load: The calculation I'm using has quite a lot of variables, and has to be run relatively frequently (i.e. quick refresh rate), which creates quite a bit of load. This may be manageable if the calculation were run in only one market per event, but as that makes it unworkable I need to run in it at least three - tripling the load. This might be workable at a push, but as I can't get the 'speed' version to work successfully, the load is further increased as additional triggers (to bet and reset) are constantly checking to see if they're needed. The 'accurate' setup can handle maybe 9 markets at once without too much trouble, things get sluggish between 10-20, and worse at 20+. (N.B. I'm not sure this is limited by my hardware, as neither my processor nor memory are maxed out during operation, but it'd be useful to know which side the bottleneck is on/whether upgrading my PC would allow MF to handle greater load).


Any suggestions as to what I could do which would maintain accuracy, whilst still making everything as fast and low-load as possible?

Thanks!


  • Administrator
  • Posts: 8821
  • Gender: Female
*
Re: Cross-Market Betting Issue
« Reply #1 on: 15 Dec 2020, 08:58 »
Hello!

Quote
but then this also leads to errors as the markets are not refreshed in perfect sync

Yes, the asynchronous nature of market refresh means that you can never get two markets refresh perfectly simultaneously: one will always has its data ahead of another. If you need to use the information applicable to one market in another market of the same event, you have to be creative. It's hard to suggest anything specific without knowing your goal, but here are some suggestions:

1. Suppose you want to lay on the Draw in Match Odds and cover that liability by backing on 0-0 in Correct Score (the typical Football Cash Generator scenario). Once you have laid on the Draw, you know the exact price your bet was matched at by using the variable football1_s_3_bm_layp. So you use that in Correct Score to calculate the amount of the back bet: 

(football1_s_3_bm_layp-1)*football1_s_3_bm_laya/(1-commission).

2. Alternatively, you can set a user variable, say draw_price, to lay_price in the same trigger where you place the lay bet on the Draw, and set its scope to once per sports event.

You can then use draw_price in Correct Score or in any other market of the same football game -- it will hold the value of the Draw's price at the moment of laying.

Quote
However, this method means that it can only operate on one selection at a time

I can't comment as I don't know the specifics of your strategy/trigger and why you can only operate one selection at a time. Perhaps you could revise the whole trigger design?

Quote
but it'd be useful to know which side the bottleneck is on/whether upgrading my PC would allow MF to handle greater load

Speaking from experience, most of these problems can be alleviated by rethinking your triggers in the first place, e.g. remove redundant triggers or make sure that the easiest conditions are checked first and the math-intensive conditions are the last in list.

If you have multiple triggers with similar actions, try to group them in just one trigger with different conditions/variables.

Also, turning off logging where it is not needed will remove the load on your disk.

Here is an article suggesting the best settings configuration for different scenarios:

What is the optimal configuration for MarketFeeder Pro?

If you are 100% sure that no further logical optimisation is possible, then your CPU is the first key element to upgrade, then RAM.
Always try your triggers in Test Mode before switching to real money!

Follow us on Twitter.

Join our WhatsApp chat!

Присоединяйтесь к официальному Telegram-каналу!

  • All members
  • Posts: 33
  • Gender: Male
Re: Cross-Market Betting Issue
« Reply #2 on: 16 Dec 2020, 10:53 »
Hi Oxa,

Thanks for this, I expect turning off logging will reduce the load considerably. I think it also confirms my current setup is as good as it gets, but just to check:


I (think I) am limited to working on one selection at a time because a) I am working on horse markets, the trigger can fire for any selection, and all bets are placed at the same time on the selection identified; and b) the prices and amounts are specific to the selection chosen.


My current setup consists of three triggers:

1) Conditions specify whether this trigger should fire, if conditions are met it actions the relevant information into user variables (3*prices, 3*amounts, the calculated figure, and 'target = sel_index').

2) This trigger fires on the condition that 'target = sel_index', and actions the bets in the relevant markets at the saved prices/amounts.

3) This trigger closes all 3 triggers on conditions which indicate trigger 2 has fired, and resets 'target' to 0, so the system can run again at the next opportunity.


I think this means the fastest the system can run is capped by the market refresh rate, so it would need at least 1.5s before the first trigger could be reset/before other selections can be checked again (i.e. 1 fires, +0.5s, 2 fires, +0.5s, 3 fires, +0.5s, 1 checks again)?

On a related note, will the future switch to a cloud platform allow for a faster refresh rate (e.g. 0.1s)?

Thanks!



  • Administrator
  • Posts: 8821
  • Gender: Female
*
Re: Cross-Market Betting Issue
« Reply #3 on: 17 Dec 2020, 07:47 »
Quote
3) This trigger closes all 3 triggers on conditions

Unless the trigger is supposed to bet again in the same market, you don't need to close it (or, specifically, the trigger block that contains it).

Quote
I think this means the fastest the system can run is capped by the market refresh rate,

You can add flexibility by changing the refresh rate, i.e. slowing it down when bets are unlikely, or right after a bet is placed, and speeding it up when the triggers are actively looking for an eligible selection to bet on. There are special trigger actions for this, "set market Idle refresh to" and "set market In-Play refresh to".

Quote
On a related note, will the future switch to a cloud platform allow for a faster refresh rate (e.g. 0.1s)?

I can't comment on this as yet, we haven't started testing it.
Always try your triggers in Test Mode before switching to real money!

Follow us on Twitter.

Join our WhatsApp chat!

Присоединяйтесь к официальному Telegram-каналу!

 

Please note, BetFair is seems to be currently OFFLINE