오류, 버그, 질문 - 페이지 2220

새 코멘트
 
1861 - Alpari에서 데모를 열 수 없습니다. 브로커를 선택하면 롤링되지 않습니다.
 
fxsaber :

내 생각에 이것은 무역 서버에 주문이 있을 때의 버그이며, 터미널에서 동기식 OrderSend 이후에는 그것에 대해 숨이 막히지 않습니다.

그런 팬텀 오더의 상황이 얼마나 오래 지속되는지 확인하기 위해 주문은 시스템에 있지만 터미널에는 있지 않습니다.

 // Советник отслеживает длительность ситуаций, когда ордер отсутствует среди текущих и исторических

#define TOSTRING(A)   #A + " = " + ( string )(A) + "\n"
#define TOSTRING2(A) #A + " = " + EnumToString (A) + " (" + ( string )(A) + ")\n"

bool OrderIsExist( const ulong & OrderTicket )
{
   return ( OrderTicket ? OrderSelect ( OrderTicket ) || HistoryOrderSelect ( OrderTicket ) : true );
}

void OnTradeTransaction ( const MqlTradeTransaction &Trans, const MqlTradeRequest &, const MqlTradeResult & )
{
   static bool PrevIsExist = true ;
   static ulong StartTime = 0 ;
   static ulong MaxInterval = 0 ;
  
   const ulong NowTime = GetMicrosecondCount ();
   const bool IsExist = OrderIsExist(Trans.order);
    
   if (!IsExist)
  {
     Print (TOSTRING2(Trans.type) + TOSTRING(Trans.order) +
          TOSTRING( OrderSelect (Trans.order)) + TOSTRING( HistoryOrderSelect (Trans.order)));       
  
     if (PrevIsExist) 
      StartTime = NowTime;
  }
   else if (!PrevIsExist)
  {
     const ulong Interval = NowTime - StartTime;
    
     Print (TOSTRING(Interval) + TOSTRING2(Trans.type) + TOSTRING(Trans.order) +
          TOSTRING( OrderSelect (Trans.order)) + TOSTRING( HistoryOrderSelect (Trans.order)));       
    
     if (Interval > MaxInterval)
    {
      MaxInterval = Interval;
      
       Comment (TOSTRING(MaxInterval) + TOSTRING(Trans.order)); // mcs.
    }
  }
          
  PrevIsExist = IsExist;
}


결과

 2018.06 . 21 00 : 10 : 31.047 Trans.type = TRADE_TRANSACTION_ORDER_DELETE ( 2 )
2018.06 . 21 00 : 10 : 31.047 Trans.order = 2210967406
2018.06 . 21 00 : 10 : 31.047 OrderSelect (Trans.order) = false
2018.06 . 21 00 : 10 : 31.047 HistoryOrderSelect (Trans.order) = false
2018.06 . 21 00 : 10 : 31.047 
2018.06 . 21 00 : 10 : 31.080 Interval = 32643
2018.06 . 21 00 : 10 : 31.080 Trans.type = TRADE_TRANSACTION_HISTORY_ADD ( 3 )
2018.06 . 21 00 : 10 : 31.080 Trans.order = 2210967406
2018.06 . 21 00 : 10 : 31.080 OrderSelect (Trans.order) = false
2018.06 . 21 00 : 10 : 31.080 HistoryOrderSelect (Trans.order) = true


32밀리세컨드 주문이 있는데 터미널에 없습니다! 이 간격에서 거래 로직이 실행된다면 이것이 어떤 결과를 가져올지 상상해보세요...


흥미롭게도 팬텀 주문은 TRADE_TRANSACTION_ORDER_DELETE 및 TRADE_TRANSACTION_DEAL_ADD (훨씬 덜 자주) 거래 유형 에 대해서만 존재하는 경우가 가장 많습니다.


플랫폼의 매우 나쁜 뉘앙스.


ZY 불행히도 상위 5 위의 거래 작업의 의심스러운 성능.

Сравнение MQL5 и QLUA - почему торговые операции в MQL5 до 28 раз быстрее?
Сравнение MQL5 и QLUA - почему торговые операции в MQL5 до 28 раз быстрее?
  • 2016.09.13
  • MetaQuotes Software Corp.
  • www.mql5.com
Многие трейдеры зачастую не задумываются над тем, как быстро доходит их заявка до биржи, как долго она там исполняется и когда торговый терминал трейдера узнает о результате. В результате они не знают, что легко могут улучшить качество исполнения своих сделок за счет более быстрой реакции и скорости проведения транзакций. 12 сентября 2016 года...
 
fxsaber :

그런 팬텀 오더의 상황이 얼마나 오래 지속되는지 확인하기 위해 주문은 시스템에 있지만 터미널에는 있지 않습니다.


결과


32밀리세컨드 주문이 있는데 터미널에 없습니다! 이 간격에서 거래 로직이 실행된다면 이것이 어떤 결과를 가져올지 상상해보세요...

예, 엉망입니다. 보시다시피 이러한 트랜잭션 결과는 다른 패키지로 전송됩니다. 그리고 그들은 하나에 있어야합니다.

 
Alexey Navoykov :

예, 엉망입니다. 보시다시피 이러한 트랜잭션 결과는 다른 패키지로 전송됩니다. 그리고 그들은 하나에 있어야합니다.

OrderSend 직후 주문은 팬텀일 수 있지만 OnTradeTransaction 이 있는 병렬 Expert Advisor는 항상 이 상태를 포착할 수는 없습니다. 저것들. OnTradeTransaction 자체가 때때로 느려집니다.


일반적으로 MT5에서는 서로 다른 위치에 아키텍처 지연이 있어 근절이 거의 불가능합니다. 이것은 틱 도착의 지연이며 현재 거래 거래의 지연입니다. 실행 속도에 의존한다면 플랫폼이 무엇을 할 수 있는지 명확하게 이해해야 합니다. 예를 들어, 적절한 지연과 함께 제공된 틱, 트랜잭션 .. 결과적으로 MT5 또는 다른 플랫폼의 다른 사람이 추월할 수 있습니다. 자신이 거래소 가까이에 있더라도 마찬가지입니다.

 
무역 거래 는 우선 순위 패키지로 이동하여 나머지를 압도합니다. 이것은 대기 시간을 심각하게 줄입니다.
 
Renat Fatkhullin :
무역 거래는 우선 순위 패키지로 이동하여 나머지를 압도합니다. 이것은 대기 시간을 심각하게 줄입니다.

OrderSend 이후의 스크립트는 가상 주문 상황을 감지하는 반면 병렬 Expert Advisor의 OnTradeTransaction 은 그렇지 않습니다(항상 그런 것은 아니지만 발생)?

 
Renat Fatkhullin :
무역 거래는 우선 순위 패키지로 이동하여 나머지를 압도합니다. 이는 대기 시간을 크게 줄입니다.

문제는 TRADE_TRANSACTION_ORDER_DELETE 및 TRADE_TRANSACTION_HISTORY_ADD 트랜잭션 이 서로 다른 배치로 발생하기 때문에 우선순위에 관계없이 네트워크 지연 이 계속 발생한다는 것입니다. 그리고 이러한 트랜잭션은 중간 상태 없이 동기식으로 차례로 실행되어야 합니다. 저것들. 그것은 사실 하나의 원자적 연산입니다. 결국 내역 목록에 삭제된 주문을 넣는 것은 거래소와 아무 관련이 없습니다.

저것들. 두 가지 옵션이 있습니다. 이 두 트랜잭션이 모두 하나의 패키지로 제공되거나 첫 번째 트랜잭션이 두 번째 트랜잭션이 도착할 때까지 터미널에서 실행되지 않습니다.

 
Alexey Navoykov :

저것들. 두 가지 옵션이 있습니다. 이 두 트랜잭션이 모두 하나의 패키지로 제공되거나 첫 번째 트랜잭션이 두 번째 트랜잭션이 도착할 때까지 터미널에서 실행되지 않습니다.

TRADE_TRANSACTION_ORDER_DELETE 트랜잭션 이전에 TRADE_TRANSACTION_DEAL_ADD가 도착하는 상황이 있습니다. 동시에 TRADE_TRANSACTION_ORDER_DELETE 이전에도 주문은 여전히 유령입니다.

 

원격 에이전트가 최적화를 중지했습니다.

 2018.06 . 22 14 : 05 : 24.901 SVA_03  pass 19 tested with error "task rejected by tester agent" in 0 : 00 : 00.000
2018.06 . 22 14 : 05 : 27.387 SVA_03  pass 19 tested with error "task rejected by tester agent" in 0 : 00 : 00.000

새로운 컴파일러로 인해 작동하도록 업데이트하려면 어떻게 해야 합니까?

또한 이러한 오류로 인해 옵티마이저의 일부 패스만 28개 중 13개를 통과했습니다.
 

Alglib 패키지 코드를 보고 있습니다. 코드의 가독성을 복잡하게 만드는 구조가 많이 있습니다. 

         for (i_= 0 ;i_<=nvars- 1 ;i_++)
            tmp[i_]=xy[i][i_];
         for (i_= 0 ;i_<=nvars- 1 ;i_++)
            tmp[i_]=tmp[i_]-ct[xyc[i]][i_];
         //--- calculation
         v= 0.0 ;
         for (i_= 0 ;i_<=nvars- 1 ;i_++)
            v+=tmp[i_]*tmp[i_];

그게 더 쉽지 않니? 

v= 0.0 ;
for (i_= 0 ;i_<=nvars- 1 ;i_++){
   tmp=xy[i][i_]-ct[xyc[i]][i_];
   v+=tmp*tmp;
}

실행 속도가 더 빨라질 것 같습니다.

코드가 왜 그렇게 복잡합니까? 아니면 조정 없이 다른 언어에서 이식한 것입니까? 그러나 여전히 나는 원래 왜 그런 복잡성이 있는지 궁금합니다.
1...221322142215221622172218221922202221222222232224222522262227...3184
새 코멘트