Efficiency

The In-play refresh rate is 0.2

I have a trigger betting in play every 4 seconds to avoid duplicating bets till the bet list is updated. From time to time I can see perfect conditions which the trigger misses due to only checking every 4 seconds

I want to change the trigger to execute every 0.2, however avoid placing a bet on a selection if it last did so within the last 3 seconds[for only that particular selection].

Hi
I think you are going to struggle a bit on this one. Ideally, you want the list of bets to be updated before the trigger repeats again, so you can use selection variables. Problem is your total RPS will go sky high. Now the data monitor will throttle these, but in doing so will queue the requests, making it inefficient. The key to this method has to be that the bets are updated before the trigger repeats, say: update bets 0.2, trigger no more often than: 0.5
Switch off everything that you don’t need to give all the RPS to the task in hand, though I’m sceptical that the software will handle this.

Another idea to look at (but I think this will work for ALL selections, not a selection) is the Data Request Monitor:
Set the Timeframe setting to 3 seconds
Trigger condition:
Trigger Expression mntr_trans_number is equal to 0
The thinking here is the data monitor should record a transaction long before the list of bets is updated etc.
Out of interest are you using a VPS?

I am using a Server Mark. Intel DualCore 2.2Ghz, 2GB RAM

will try option say .5 for the bet list & 1.5 for the trigger ... I am running 2 instances so need to thread carefully around the request limit. .5 is the minimum for the bet list

Thanks. I asked about the VPS because I think you may have a latency disadvantage at those refresh rates given your location.
On the bets refresh, you could edit the entry in the settings file in your profile (at your own risk): UpdateBets=0.x. As an example, a well known trading application has it's default bets refresh at 250ms

Agreed Mark as soon as I got serious I realized location was a major factor ... I used to sometimes get more than 1 second in the () value next to the timestamp. Nowadays it ranges anywhere between (0.04) & (0.06).

I am monitoring win/place [4.5 minutes to off] @ 1 seconds before the off (so that's 2 requests & 4 for bets @0.5). 6 per sec

Inplay this drops to 0.2 (that's 10 requests just for markets & 4 for bets @0.5) 14 per sec.

With meetings running, I am right on the limit ...
With it being jump season race, from time to time, races overlap for minutes at a time. so it will be interesting. Hopefully I generate enough commission to cover the exceptions ... will let it run for today and see how things pan in terms of charges.

Thanks again Mark.

Hi
Am I correct in thinking a data request for list of bets update is weighted as 5 data requests?

Yes Mark.

Quote

Each "general" request (a
request for data that are not related to any particular market) is weighted 5. That is, for BetFair it is equal to 5
market-related requests. So you are allowed to make maximum 4 general requests per second without being
charged. Considering the fact that you will also need to update your account funds, statement and certainly the
markets, this number gets down to even less than 1 request per second.

I have had no warnings or charges so far so will leave setting as is for now. I have adjusted the bet update list to 0.6.

so it 10 bet updates every 6 seconds = 60
0.2 refreshes is 10 per sec (2 markets) = 60 for 6 secs

120 requests per 6 secs is bang on 20 request per limit.

if you look at the Betfair charges page it shows also how much you can go over based on commission generated.

Generate 10£ commission per day and you can go up to 33 request per second without charges.

Thanks 1oser. That’s what I thought. My query relates more to the title of this topic. If you set the data monitor limit to 20RPS and your actual (weighted) RPS exceeds this, then the monitor must be queuing the excess. Additionally, the number of queued of requests must be increasing as this process continues. The point being your trigger will become inefficient at some stage and miss opportunities / make mistakes (e.g. dup bets).
Now you also mention running 2 instances, which if you have reduced the RPS limit on each, might add even more to the queued (and thus delayed) requests. It is good you have no problems so far. I will be very impressed if MFP handles it all smoothly. Please keep us updated.

do you have trigger logging enabled while all this is going on?

logging was switched off recently as I am happy with the trigger results.

I am also NOT limiting the requests per second. The other instances refreshes @ 4secs so the over head on that is fairly and normally two active markets.

Overall, i do think commission generated is saving my @ss.

I wonder if I can get a per hour request break down from Betfair for maybe Saturday.

Efficiency

Hello Guest