요새. 실행 질문 - 페이지 4

 
Mikalas :
즉, 지연(내부 네트워크에서) ~ 30ms가 TM-5에 대해 정상이라고 생각하십니까?

내부적으로 고려하는 이유는 무엇입니까?

1) OnTradeTransaction 에서 주문에 대해 얼마나 많은 중간 상태를 얻었는지 확인합니다.

각 거래 트랜잭션은 하나의 패킷(요청-응답)이 아니라 여러 알림입니다. 이는 터미널이 항상 주문이 어느 단계에 있는지 알 수 있도록 하기 위한 것입니다(예: 실행 시간이 오래 걸릴 수 있음).

이제 우리는 상태에 대한 모든 중간 알림을 비활성화하고 스키마를 간단한 형식으로 변환하는 별도의 기능을 MQL5에 포함할 가능성에 대해 생각하고 있습니다. 이것은 실행 속도를 높일 수 있습니다.

2) 거래소와 통신의 두 번째 측면과 실행 속도의 가변성을 완전히 놓칩니다. 분명히 0이 있다고 생각합니다. 그러나 속도에 대한 보장은 없습니다.


생각보다 10배는 더 많은 것 같습니다.

물 위에 튀어나온 석류 조각을 보고 속일 필요가 없습니다.

나는 우리가 실제로 속도를 2배 향상시킨 것이 아니라 20-30ms 정도 빨라졌다는 것을 분명히 할 것입니다. 2는 2배가 아니라 1배보다 1보다 큽니다. 이것은 낮은 기본 효과일 뿐입니다.


어쨌든 우리는 계속 노력하고 더 나은 결과를 얻습니다.

 
Renat :

내부적으로 고려하는 이유는 무엇입니까?

1) OnTradeTransaction에서 주문에 대해 얼마나 많은 중간 상태를 얻었는지 확인합니다.

각 거래 트랜잭션은 하나의 패킷(요청-응답)이 아니라 여러 알림입니다. 이는 터미널이 항상 주문이 어느 단계에 있는지 알 수 있도록 하기 위한 것입니다(예: 실행 시간이 오래 걸릴 수 있음).

이제 우리는 상태에 대한 모든 중간 알림을 비활성화하고 스키마를 간단한 형식으로 변환하는 별도의 기능을 MQL5에 포함할 가능성에 대해 생각하고 있습니다. 이것은 실행 속도를 높일 수 있습니다.

2) 거래소와 통신의 두 번째 측면과 실행 속도의 가변성을 완전히 놓칩니다. 분명히 0이 있다고 생각합니다. 그러나 속도에 대한 보장은 없습니다.


어쨌든 우리는 계속 노력하고 더 나은 결과를 얻습니다.

예, 가상 머신 (LAN)의 지연이 집(인터넷)에서 거래할 때의 지연보다 동일하기 때문입니다(훨씬 더 큼).

Renat, 나는 당신이 이 심각한 문제를 해결하기를 정말로 바랍니다.

진심으로 행운을 빕니다. 우리(사용자)는 오래 기다리지 않아도 됩니다.

P/S 제 질문에 답변해주셔서 대단히 감사합니다.

그리고 너무 빨리 일을 처리해 주셔서 감사합니다!

 
papaklass :

외환. 서버에서 이러한 지연이 발생하는 이유는 무엇입니까? 트루빌드 1010.

104와 146ms를 의미합니까?
 
Mikalas :
104와 146ms를 의미합니까?

대부분 24ms와 146ms 사이

주문이 거의 동시에 터미널을 떠났지만

 
olyakish :

대부분 24ms와 146ms 사이

주문이 거의 동시에 터미널을 떠났지만

이 "플로팅" 버그는 "주문을 할 때 FORTS 큰 지연" 주제에서 논의되었습니다.

(https://www.mql5.com/en/forum/19681) 불행히도 빌드 1035에서도 수정되지 않았습니다.

이 스레드에서 Renat는 다음과 같이 말했습니다.

" 때때로 단말에 대한 응답 전달의 부동 시간이 아직 차단되지 않은 경우, 우리는 이에 대해 계속 작업할 것입니다."

그리고 더:

"어쨌든 우리는 계속 노력하고 더 나은 결과를 얻습니다. "

 
papaklass :

정확히 차이는 24와 146, 30과 104입니다.

그러나 모든 주문 의 실행 시간이 크게 증가하는 순간도 있습니다.

그 순간 거래는 어디로 가고 있었습니까?

나는 이것과 아주 밀접하게 이야기했고 이제 나는 당신이 가지고 있어야한다는 결론에 도달했습니다.

  • 브로커에 더 가까운 전용 서버(정확히 전용이고 가상이 아님)

  • 좋은 데이터 센터의 서버
  • 100Mb/s라도 모든 종류의 미디어 리소스가 없는 매우 안정적인 네트워크(이상적인 것은 인터넷 영역에 액세스하지 않고 교차 연결하는 것)
  • 브로커에 대한 ping은 가능한 한 안정적이어야 하며 급강하가 없어야 합니다. 최대 편차(최소값과 최대값의 차이) 1ms
  • 서버의 총 터미널 수는 최대 작업(EA) 부하에서 25-30%를 초과해서는 안 됩니다.
  • Windows가 서버 2012인 경우(많은 사람들에 따르면 네트워크에서 더 안정적으로 작동함)

그 후에 몇 가지 테스트를 할 수 있습니다 ...

 
papaklass :

가상 서버, Windows - 서버 2012 R, 기가비트 네트워크, ping 7ms. 네트워크는 상당히 안정적입니다.

가상 머신의 로딩은 MT 서버에서의 주문 처리가 아니라 터미널에서의 일괄 주문 전송(타이밍에 차이가 있음)에 영향을 미칩니다.

서버 IP를 알려주시면 제가 직접 확인하겠습니다.

MT5가 주문을 발행하면 가상 머신 이 이 정보를 물리적 머신으로 보내고, 물리적 머신은 이를 네트워크 인터페이스로 보냅니다.

따라서 첫 번째 단계는 다음과 같이 로그에 기록됩니다.

 2014.12 . 23 10 : 44 : 28.630 Trades   '880758' : market buy 0.03 EURUSD.e

(내 생각에)

+ 현재 서버를 시작하는 것이 바람직합니다. ping -t

+ MT5 서버가 어떤 종류의 LP에 대한 파이프 역할을 하는 상황이 여전히 있을 수 있으며 연결에서 MT5server - LP와 주문에 대한 LP의 반응이 총 시간을 늘릴 수 있습니다.

최종 권한으로 MT5 서버 필요(브로커 ala Market maker)

 
서버는 ping 또는 검색되지 않습니다.
 
papaklass :

netstat 명령은 이상한 IP를 제공합니다.

유럽 서버 IP #1을 확인할 수 없습니다.

어쩌면 더 쉬울지도

파일 계정을 열고 거기에서 서버/브로커 이름이 있는 사진

 


마지막 화면에 계속 걸려요...

사유: