SL/TP 주문 수락 - 페이지 4

새 코멘트
 
Enrique Dangeroux :

https://www.mql5.com/en/forum/341117 은 여전히 실제 문제입니다

내가 마지막으로 확인했을 때 이 문제는 언급된 브로커에서 해결되었습니다.

 

개발자 여러분, 다음 아키텍처 질문에 답변해 주십시오. 전투에 사용하려면 정보가 필요합니다. 소박합니다.


동일한 가격과 다른 로트의 두 가지 제한이 있습니다. 활성화 트리거 시퀀스에서 순서를 결정하는 것은 무엇입니까?

이 질문에 대한 몇 가지 답변이 있습니다.

  1. 많은에서.
  2. 티켓 번호에서.
  3. 시작 가격 의 마지막 수정 부터 .
  4. 주문의 마지막 수정에서(예: 지정가 주문에 대해 테이크 레벨이 업데이트됨).

내가 올바르게 이해하면 개시 가격을 수정한 후 제한 제한기가 공개 가격으로 정렬된 모든 서버 제한 제한 목록 테이블에 적절하게 통합됩니다. 그런 다음 질문에 대한 대답이 요약됩니다. 동일한 가격의 주문 목록 시작 부분에 포함되어 있습니까 아니면 끝에 포함되어 있습니까?


같은 질문은 한계가 아니라 테이크에 관한 것입니다. 동일한 테이크의 트리거 순서를 결정하는 것은 무엇입니까? 위치 ID 또는 다른 것?


전투에 어떻게 도움이 되는지 설명하겠습니다. 예를 들어, 같은 수준에 있지만 로트가 다른 두 개의 지정가 주문(또는 포지션 테이크)이 있습니다. 제한 제한(take)의 실행이 마지막 수정에 의존한다면, 로트의 오름차순으로 제한 주문을 수정하는 것만으로 FillRate를 올릴 수 있습니다.


아마도 해당 MT5 서버 부분의 구현을 작성한 사람만이 이 질문에 대한 답을 알고 있을 것입니다.

 
Andrei Trukhanovich :

브로커와 함께 병목 지점 찾기

마치 벌이 꿀을 반대하는 건가요?)
 
fxsaber :

동일한 가격과 다른 로트의 두 가지 제한이 있습니다. 활성화 트리거 시퀀스에서 순서를 결정하는 것은 무엇입니까?

이 질문에 대한 몇 가지 답변이 있습니다.

  1. 많은에서.
  2. 티켓 번호에서.
  3. 시작 가격 의 마지막 수정 부터 .
  4. 주문의 마지막 수정에서(예: 지정가 주문에 대해 테이크 레벨이 업데이트됨).

4개에는 옵션 4가 있었던 것 같습니다. 즉, 모든 수정으로 인해 해당 가격 수준의 대기열 끝으로 주문이 이동되었습니다.

 
secret :
마치 벌이 꿀을 반대하는 건가요?)

이 특정한 상황에서 이 특정한 순간에 그것은 상호 이익이 되며 완료되었습니다. 드문 상황 집합.

 

MT5의 TP 주문은 FillRate(주문의 어느 부분이 채워졌는지)를 확인할 수 있다는 점에서 주목할 만합니다.

그러한 주문의 수만 개를 분석한 결과 FillRate가 기호에 크게 의존하는 것으로 나타났습니다. TP 주문의 배치가 동시에 트리거되면 배치의 티켓 번호가 증가하면서 FillRate가 떨어집니다.

다른 구체적인 뉘앙스도 확인되었습니다. 그러나 이것은 이미 브로커와 논의 중입니다.


FillRate 증가를 위한 레시피: 모든 동일한 테이크 및 제한을 하나의 공통 MT5 제한으로 결합합니다.


그러나 이러한 데이터는 이 주제에 대한 보너스일 뿐입니다. 브로커와 무관한 문제 - MT5는 틱으로 지연되며, 따라서 보류 중인 주문 (SL/TP 수준 포함) 수락과 함께 지연됩니다.


그리고 거부 후 MT5는 가격이 TP 수준(또는 한도)을 충족하는지 여부를 확인하기 위해 매번 다음 틱을 기다립니다. 몇 초 정도 걸릴 수 있습니다. 확인은 항상 거부(또는 부분 채우기) 직후에 수행되어야 합니다.

파일:
CheckOrders2.mq5  10 kb
 
fxsaber :

OnTick은 틱이 거래 서버에 등록된 것보다 몇 밀리초 늦게 트리거됩니다.

 // Измеряет размер лага между приходом тика на MT5-сервер и MT5-Терминал.
// Запускать на той же машине, на которой установлен MT5-сервер.

#include <WinAPI\WinAPI.mqh>

input int inPeriod = 10 ;   // EMA-period
input int inAmount = 100 ; // Количество тиков для анализа

// Локальное время в миллисекундах.
long TimeLocalMsc()
{
  SYSTEMTIME SystemTime;
  
  kernel32::GetLocalTime(SystemTime);

   MqlDateTime time;
  
  time.year = SystemTime.wYear;
  time.mon = SystemTime.wMonth;
  time.day = SystemTime.wDay;
  time.hour = SystemTime.wHour;
  time.min = SystemTime.wMinute;
  time.sec = SystemTime.wSecond;


   return (( StructToTime (time) * 1000 + SystemTime.wMilliseconds));
}

double EMA = 0 ;
int MaxValue = 0 ;
int MinValue = INT_MAX ;
int Amount = 0 ;

void OnTick ()
{
   static const double Alpha = 1.0 / inPeriod; // EMA-коэффициент для расчета среднего значения.

   MqlTick Tick;
  
   const long time = TimeLocalMsc(); // Локальное время в миллисекундах

   if ( SymbolInfoTick ( _Symbol , Tick))
  {
     const int Value = ( int )(time - Tick.time_msc); // На сколько локальное время отличается от тика.
    
    MaxValue = MathMax (Value, MaxValue); // Максимальное значение.
    MinValue = MathMin (Value, MinValue); // Минимальное значение.
    
    EMA += (Value - EMA) * Alpha; // Среднее значение
    
     if (++Amount >= inAmount) // Если посчитали все тики - распечатываем и выходим.
    {
     #define TOSTRING(A) #A + " = " + ( string )(A) + "\n"       
       Print (TOSTRING(Amount), TOSTRING(MinValue) + TOSTRING(MaxValue) + TOSTRING(EMA) +
            TOSTRING( TerminalInfoInteger ( TERMINAL_PING_LAST )));
      
       ExpertRemove ();
    }
  }
}


결과. 

Amount = 100
MinValue = 1
MaxValue = 8
EMA = 4.344007436833947
TerminalInfoInteger ( TERMINAL_PING_LAST ) = 42


100틱이 처리되었습니다. 서버와 Tick Terminal 사이의 도착 지연은 1밀리초에서 8밀리초 사이입니다. 평균적으로 - 4밀리초가 조금 넘습니다. 이것은 이 분기를 시작한 TP 주문 트리거의 지연과 정확히 같습니다.


지연 자체는 MT5 서버 내부에 있습니다. 서버 -> 터미널 채널은 그것과 아무 관련이 없습니다.


이 지연을 수정하기 위한 개발자의 큰 요청입니다. 이제 핑이 0인 증권 거래소에서 터미널뿐만 아니라 서버에도 틱이 도착하는 데 일정한 지연이 발생합니다. 특히, 영장의 수락.


PS 중재를 통해 주방 중개인의 옷을 벗는 사람들에게 이것은 하늘의 마나와 같은 내장 지연입니다. 저것들. 브로커는 상당한 추가 위험.

 
어떤 서버를 확인하셨나요?

어떤 기기와 어떤 게이트웨이/데이터 피드에서 초기 데이터를 생성했습니까?

시간이 MT5 서버 자체가 아니라 원격 측의 견적 제공자(예: 교환 게이트웨이)에 의해 형성된 경우 실행이 있을 수 있습니다.

수만, 수십만 개의 병렬 거래 작업 에 대한 스트레스 테스트와 같이 어떤 백그라운드 프로세스를 잊어버릴 수 있습니까?
 

Renat Fatkhullin :
На каком сервере проверяли?

많은 서버에서 확인했습니다. MQ-데모 포함 .

거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼

SL/TP 주문 수락

fxsaber , 2020.11.25 00:47

MQ-Demo에서 실행한 결과입니다. 

Total Orders (from 2020.09 . 01 00 : 00 : 00 ) = 58493 , calculated = 439
Calculation time = 00 : 00 : 11.328 , Performance = 38.0 orders/sec.

ServerName: MetaQuotes-Demo

Last Tick 2020.09 . 30 19 : 07 : 32.917 1.80181 1.80205
Accepted Tick 2020.09 . 30 19 : 07 : 32.716 1.80178 1.80202
Accepted Length = 357 ms.
Order 726444166 ORDER_TYPE_BUY GBPAUD 2020.09 . 30 19 : 07 : 33.073 1.80206 ORDER_REASON_TP ORDER_STATE_FILLED 2020.09 . 30 19 : 07 : 33.082 , Position created 2020.09 . 30 17 : 21 : 17.933 , StopLevel = 0

Orders ( 2 ) before 726444166 with PositionID = 725926764 :
------------------------
Checked Orders = 0
------------------------


스크립트는 TP 주문과 생성을 트리거한 틱(텍스트로 강조 표시됨)을 찾았다고 주장합니다. 거래 서버(특히 데모)에서 가격이 오픈 포지션의 TP 수준에 도달했다면 해당 TP 주문이 즉시 생성되어야 합니다(반드시 실행되지는 않음). 그러나 이 상황에서 이것은 즉시 발생하지 않고 357밀리초 후에 발생했습니다!


어떤 기기와 어떤 게이트웨이/데이터 피드에서 초기 데이터를 생성했습니까?

외환 도구를 확인했습니다. RannForex-서버, AMTS-게이트웨이. 다른 구성을 지정해야 합니다.

시간이 MT5 서버 자체가 아니라 원격 측(예: 교환 게이트웨이)의 따옴표 제공자에 의해 형성된 경우 실행이 있을 수 있습니다.

MT5 서버 자체가 ping이 0인 시스템에서 형성되었다고 믿는 경향이 있습니다. 그러나 100% 보장을 위해서는 설명이 필요합니다. 그러나 위의 내용은 귀하의 서버에도 문제가 있음을 보여주었습니다.

 
fxsaber :

TP 주문 실행 문제를 연구하면서 일부 TP 주문이 승인된 틱보다 상당히 늦게 생성되었음을 알았습니다.

디브리핑 결과 이러한 상황은 다른 중개인뿐만 아니라 Trading Server와 동일한 기계에 있는 Terminal에서 거래가 이루어지는 상황에서도 반복되는 것으로 나타났습니다. 저것들. 매우 낮은 핑과 트레이딩 서버의 유일한 트레이딩 계정.

귀하의 계정에서 얻은 결과를 공유할 것을 촉구합니다. MT5 개선에 기여하세요!

아주 작은 세부 사항을 "잊었습니다" - 58,000개의 주문을 확인하고 300ms 동안 하나의 이상값만 찾았습니다. 그리고 이(58,000개 중 1개)는 이러한 검사에서 분명히 강조되어야 합니다.

지난 번 수백만 개의 검사와 마찬가지로 단일 이상값도 찾고 이것이 정상적인 동작인 것처럼 가장했습니다.


우리는 서버 로그를 확인했고 MetaQuotes-Demo 데모 서버가 있는 가상 머신은 약 1,500만 계정이 에서 회전하고 있었기 때문에 그 몇 초 동안(2020.09.30 19:07에서 4초 동안) 분명히 물리적으로 아프다는 것이 분명했습니다. 그 순간과 약 2백만 개의 오픈 포지션 이 있었고, 동시에 이웃 가상 머신과 하이퍼바이저에서 다른 일이 일어나고 있었습니다.

어쨌든 단일 배출은 항상 모든 시스템에 있지만 우리는 계속 이해할 것입니다.

12345678
새 코멘트