Version 6.4

It is very fast - BUT.....

It eats much more CPU, even when set to the old refresh of 0.3 secs.

I'm maxing out CPU at 0.3 secs, whereas before I was typically below 12%.

I'm going to try it on a much larger dedicated server.

It depends on the triggers does it serve.
But yes, imagine what it has to do in 0.1 second:
1. Send request to the server (it's a secure one, so the data must be encrypted)
2. Receive the response (decrypt it)
3. Unzip the response (if it set so)
4. Parse response into the numbers and set all market's and selection's parameters
5. Parse the triggers, parse each formula within them, replace all variables to the actual data, calculate all formulas.
6. Check the conditions, write logs.
7. Do necessary actions: prepare bets, etc.
8. Update the screen 

I skipped some actions but these ones are enough to make your CPU busy

Sure, I get all of that - BUT... if I set it to the old refresh of 0.3 sec it still maxes out the server.  This version is doing some other things that the previous version didn't, and it's not just the speed of refresh.  The question is - what is it?

That's might be because the old version never refreshed markets with 0.3 seconds rate. The maximum was 0.5
Now it's really does 0.3 and faster and I haven't noticed that the CPU is "eaten" much more. You have complex triggers?

OK I've done some tests.

If I run with the older version on a 0.5 sec refresh my cpu IR sits at about 8%, climbing occasionally to 24-25%

If I run the identical trigger file on the new version with identical settings (including a 0.5 sec refresh) to the older version the CPU sits at 86% climbing repeatedly and sticking at 100%.

My triggers are not complicated, they are about as simple as you could make them.  I have spent years refining them so that they run optimally.  You will see from previous posts that I have worked out ways of improving performance by carefully ordering the conditions.

[ quote = autore McBee link = topic = 906.msg4973 # msg4973 date = 1.286.040,999 mila ]
gshine hi
Ho smesso di usare la nuova versione a causa di utilizzo della CPU.
[/ quote]
Io stò utilizzando la nuova versione sfruttando la velocità del refresh.Con questa grande opportunità come avrei immaginato sto provando un trigger In Play dopo averlo testato.Essendo che lavora In-play apro i mercati solamente 1 minuto prima del off per non andare in eccesso,aprendo un mercato alla volta  .
I isultati sono buoni, ma ancora è presto per tirare delle conclusioni.Se andrà bene publicherò un video di MF su youtube.
alla prox.

Any news on when the patched up 6.4.0.1 Ferrari will be ready??

I missed the news about this new version, and so a installed it yesterday. Again this version is a great step forwards, for me the main improvement is the lower memory usage for complex triggers. Thank you!

But there is an issue, I do not unterstand:

I tried out the refresh rate of 0.1, but the repitition inverval for triggers is still limited to 1 second minimum.

As far as I understand how MFPro works, even with 0.1s refresh rate, the triggers are still executed 1 seconds at least.

Why is it impossible to set repitition inverval for triggers below 1s? How can I use the benefits of fast refresh rate, if trigger is still 1s?

kind regards
Martin

Hello Martin

Instead of to comply setting 1 s "no more often than" , it can simply your condition goes "  clip " with several trigger and to repeat in block  "specific number of times" it - will be more quickly then than 1 second .
This about many more difficult,but showy .

I greet

Hello Ronaldinho,

thanks for your response! Great hint, works fine if repetition limit is a big number. As I reboot my computers at least once a week, a value of 6048000 is enough to guarantee that the trigger never stops even at 0,1 second refresh interval.

Many thanks again!

Martin

Martin

It has not for what to thank, because this nothing concrete.
This  already after for my imagination, then you about what tell. I possess unfortunately " equipment ..." it which was several times  reset every day. What do you have on thought 6048000 ? Programme is not in my language unfortunately .I do not understand all.because I have every question to translate.

I will find out something more

Martin,

The next build of MF pro that's coming next week will get 0.1 seconds repeating limit.

P.S. Tricky idea of the workaround, Ronaldinho!

Hello Ronaldinho,

you wrote "I will find out something more"

Your advise works fine for me. I switched a trigger file to ""no more often than" xxx times and changed market refresh to 0.1s. This caused a heavy load on comuter. (as expected.)  I checked in logfiles that the trigger was executed 8 to 9 times per second, which is much more than before.

6048000 = 7 * 24 * 60 * 60 * 10
7 days per week, 24 hours per day, 60 minutes per hour, 60 seconds per minutes, executed 10 times per second.

So if I set repeat number to 6048000 trigger does not stop working if I do a reboot once per week. In reality, I do a restart of MFPro more frequently, but every sunday evening I do a reboot and remove dust from computer and even the longterm MFPro instances are restarted.

Oxa,
will check your website for updates!

Hi,
i don´t know if this function is already implemented but it is possible to remember the last lost, hist_laya ... between sessions. I mean i exit the marketfeeder on the evening and start it again on the next morning and last loss and hist_1_laya is set the to from the last evening.

OK .  I thought over this and I found .It about this walks probably. Here exactly in Italian.
But I am not certain because I do not use this.Practically really I noticed this now