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

새 코멘트
 
이 정보는 모든 mega-HFT-shniks MT-shny에 전송됩니다. 농담입니다. 농담입니다.)) 비용은 저렴합니다.
 
fxsaber :

다른 스레드에서는 터미널조차도 엄청난 수의 요인으로 인해 느려진다고 반복해서 언급되었습니다. 결과적으로 훨씬 더 복잡한 Trade Server는 훨씬 더 느려질 수밖에 없습니다. 그러나 알고리즘 최적화가 여전히 가능하기를 바랍니다. 5ms 지연조차도 이미 매우 나쁩니다. 수백 밀리초에 대해 무엇을 말할 수 있습니까?

데모에 있는 내용은 그다지 흥미롭지 않습니다(모든 플러그인을 디버그하고 새 하드웨어를 테스트할 수 있습니다 ...).

그리고 라이브 계정에서 최대 17ms를 찾았습니다(이것이 충분하지 않다고 말하는 것이 아니라 30초와 비교할 수 없습니다).

따라서 사용자 정의 서버 설정이 의심됩니다.

 
Andrey Khatimlianskii :

데모에 있는 내용은 그다지 흥미롭지 않습니다(모든 플러그인을 디버그하고 새 하드웨어를 테스트할 수 있습니다 ...).

그리고 라이브 계정에서 최대 17ms를 찾았습니다(이것이 충분하지 않다고 말하는 것이 아니라 30초와 비교할 수 없습니다).

불행히도, 그들은 얼마나 많은 주문을 확인했는지 표시하지 않았습니다.

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

SL/TP 주문 수락

fxsaber , 2020.11.25 01:23 

Total Orders (from 2020.11 . 01 00 : 00 : 00 ) = 21725 , calculated = 10465
Calculation time = 00 : 04 : 33.609 , Performance = 38.0 orders/sec.

따라서 사용자 정의 서버 설정이 의심됩니다.

브로커가 문제를 확인하고 문제를 찾아 수정할 수 있었습니다(주말 이후에 사용 가능). 하지만 MT5 때문이라고 단정짓기는 어렵다.


그러나 MT5 방향으로 돌을 던지는 것은 정확히 이런 상황일 수 있습니다.

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

SL/TP 주문 수락

fxsaber , 2020.11.25 00:47

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



터미널과 서버가 같은 컴퓨터에 있습니다. 제로 로딩. 신선한 테이크가 그러한 경고를 받았습니다. 

Accepted Tick 2020.11 . 25 16 : 05 : 11.522 10.15469 10.15668
Accepted Length = 4 ms.
Order 212 ORDER_TYPE_SELL EURSEK 2020.11 . 25 16 : 05 : 11.526 10.15462 ORDER_REASON_TP ORDER_STATE_FILLED


서버 로그. 

2020.11.25 16:05:11.526    '': take profit triggered #168 buy 0.01 EURSEK 10.19022 tp: 10.15462, activation price 10.15469 [#212 sell 0.01 EURSEK at 10.15462][10.15469 / 10.15668]


서버에서 틱을 수락합니다.


문제가 있다는 스크립트 데이터의 전체 확인. 부하가 0인 서버 내부에는 4ms의 지연이 있었습니다.

 
Andrei Trukhanovich :

fxsaber의 또 다른 뇌 폭발.

당신이 얼마나 많은 시간을 죽였는가를 깨달을 때 특히 강하게 느껴집니다. 그리고 아무도 당신을 위해 그것을하지 않을 것입니다.
 

정말 서버에 문제가 있는 것 같습니다. MT5 데모 계정입니다.

 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  Total Orders (from 2020.01 . 01 00 : 00 : 00 ) = 5417 , calculated = 755
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  Calculation time = 00 : 00 : 14.656 , Performance = 51.0 orders/sec.
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  ServerName: RannForex-Server
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Last Tick 2020.11 . 23 19 : 59 : 30.634 104.341 104.341
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Accepted Tick 2020.11 . 23 19 : 58 : 57.044 104.336 104.336
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Accepted Length = 33592 ms.
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Order 1747932 ORDER_TYPE_SELL USDJPY 2020.11 . 23 19 : 59 : 30.636 104.336 ORDER_REASON_TP ORDER_STATE_FILLED 2020.11 . 23 19 : 59 : 30.658 , Position 1747924 created 2020.11 . 23 19 : 58 : 35.556 , StopLevel = 0
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  Orders ( 3 ) before 1747932 with PositionID = 1747924 :
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  ------------------------
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  Checked Orders = 0

동일한 브로커가 있는 실제 계정 에서 스크립트는 0개의 결과를 반환합니다. 계정에 3000건 이상의 거래가 있습니다.

 
Enrique Dangeroux :

동일한 브로커가 있는 실제 계정 에서 스크립트는 0개의 결과를 반환합니다. 계정에 3000건 이상의 거래가 있습니다.

이것은 의심스럽습니다. 내 계정 어디에도 지연이 없다는 것을 발견하지 못했습니다.

 

이것이 관련이 있는지 확실하지 않습니다. 하지만 나는 많은 것을 얻는다. 

2020.11.25 16:52:52.992 Trades  '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error]

위치 변경 이 Take를 트리거하는 오류입니다. 그래서 불을 붙이고 몇 번을 거부한 다음 중단합니다. 저는 안전한 편에 있기 위해 tp를 0으로 변경하고 충돌합니다.


변경하기 전에 나는 이것을 확인한다

 if ( OrderCloseReason() >= ( int ) ORDER_REASON_SL )

상황이 얼지 않도록.

 
fxsaber :

이것은 의심스럽습니다. 내 계정 어디에도 지연이 없다는 것을 발견하지 못했습니다.

나도 그렇게 생각했지만 더 조사한 결과 Take가 닫은 곳은 100개 정도에 불과했다.

그래서, 작은 표본 크기.

 

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

SL/TP 주문 수락

Enrique Dangeroux , 2020.11.25 17:20

이것이 관련이 있는지 확실하지 않습니다. 하지만 나는 많은 것을 얻는다. 

2020.11.25 16:52:52.992 Trades  '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error]

나는 또한 그러한 메시지에 전체 로그인을 가지고 있습니다. 주말이 지나면 상황이 바뀔 수도 있습니다.

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

SL/TP 주문 수락

fxsaber , 2020.11.25 16:30

브로커가 문제를 확인하고 문제를 찾아 수정할 수 있었습니다(주말 이후에 사용 가능). 하지만 MT5 때문이라고 단정짓기는 어렵다.

 

거래 플랫폼의 일부 알고리즘을 개략적으로 고려하십시오. 단순화를 위해 하나의 LP (유동성 공급자)만 있다고 가정합니다.


주문 제한.

  1. LP의 가격은 거래 플랫폼의 지정가 주문 가격을 충족합니다.
  2. 게이트웨이는 이 제한을 짧은 만료 시간과 함께 LP로 보냅니다.
  3. 제한 제한 볼륨의 일부에 대해 거부를 받으면 게이트웨이는 제한 제한 처리 시간 동안 LP의 틱이 변경되면 나머지 볼륨에 대해 1단계부터 모든 것을 반복합니다.

지정가 주문이 실행될 때 좋은 게이트웨이(위의 알고리즘 포함)는 거래 플랫폼의 기능에 의존하지 않습니다.

알고리즘은 거의 반복적이고 플랫폼에 독립적입니다. 스팸 방지 LP는 3항에 포함되어 있습니다.


오픈 포지션의 TP 레벨.

  1. LP에서 틱이 왔어
  2. 가격은 새 틱으로 MT5에 전송됩니다.
  3. 포지션이 잠겨 있지 않고 새 틱의 가격이 TP 수준을 충족하면 MT5 자체가 해당 TP 주문을 생성합니다.
  4. 게이트웨이는 TP 오더가 생성되었음을 확인하고 포지션을 차단하고 지정가 오더 알고리즘의 2단계를 수행합니다.
  5. 거부를 수신하면 MT5에서 거부 상태의 히스토리에 TP 주문을 보냅니다. 위치가 잠금 해제됩니다.

알고리즘은 반복되지 않으며 플랫폼에 따라 다릅니다. LP 스팸 방지 기능이 있습니다.


이 알고리즘은 Gateway-MT5 연결 비용을 고려하지 않으면 두 가지 단점이 있습니다.

  • 이 스레드 에서 MT5에서 TP 주문(3번 항목 참조)의 생성이 지연과 함께 발생하는 것으로 나타났습니다. 따라서 이행될 확률은 지연이 없는 경우보다 낮습니다.
  • MT5의 TP 주문은 새 틱 없이 생성될 수 없습니다. 즉, 거부를 받으면 게이트웨이는 TP 수준을 충족하는 새 틱이 MT5에 도착할 때까지 아무 작업도 하지 않습니다. 그리고 이로 인해 TP 레벨을 실행하기 위한 귀중한 시간을 잃게 됩니다. 또한 FillRate를 저하시킵니다.


개선.

오픈 포지션 의 TP 레벨 알고리즘의 스마트 게이트웨이는 항목 6을 가집니다:

6. 거부 시간 동안 LP에서 새 틱이 수신된 경우 현재 값이 새 틱으로 MT5에 다시 전송됩니다. 2단계로 이동합니다.

알고리즘의 이 추가 단계에는 여전히 LP 스팸 방지 기능이 포함되어 있지만 MT5가 3단계를 수행하도록 속입니다. 그리고 새로운 진드기를 기다리는 소중한 시간은 낭비되지 않습니다.


현실.

이 두 알고리즘에서(두 번째 알고리즘에 항목 6이 있는 경우에도) 다음 정렬이 따릅니다.

MT5 지정가 주문은 동일한 이름인 Open Position TP 레벨보다 FillRate가 더 높습니다. 이러한 이유로 MT5-Hedge 에서 후진할 때 제한 한도가 채워지지만 TP 이름이 채워지지 않은 상황이 종종 발생할 수 있습니다. 이 경우 CloseBy가 이루어지고 적절한 볼륨으로 제한 제한이 재설정됩니다.


결론.

MT5에서 FillRate를 높이려면 열린 위치의 TP 수준을 MT5 지정가 주문으로 전송하십시오.

12345678
새 코멘트