MT5와 속도 - 페이지 92

새 코멘트
 
fxsaber :

TimeLocal과TimeCurrent 간의 불일치를 모니터링합니다.

그리고 이러한 상황에서 TimeLocal()이 지연되는 경우 운영 체제에 이유가 있습니까?
 
Vasiliy Pushkaryov :
그리고 이러한 상황에서 TimeLocal()이 지연되는 경우 운영 체제에 이유가 있습니까?

TimeLocal 이 멀지 않습니다. 불일치 - 브로커.

 
Vasiliy Pushkaryov :

누군가가 그러한 정지 또는 제동의 원인이 될 수 있는 것을 발견할 수 있습니까?

가장 먼저 생각나는 것은 코드의 버그로 인해 매우 오랜 시간이 걸리는 계산이 시작됩니다(예: 1에서 10까지의 주기에서 버그로 인해 전체 int가 정렬됨)

 
fxsaber :

TimeLocal 은 그리 멀지 않습니다. 불일치 - 브로커.

고맙습니다. 노력하겠습니다.
 
Andrei Trukhanovich :

가장 먼저 생각나는 것은 코드의 버그로 인해 매우 오랜 시간이 걸리는 계산이 시작됩니다(예: 1에서 10까지의 주기에서 버그로 인해 전체 int가 정렬됨)

도움말에는 루프형 Expert Advisor가 다른 프로그램의 작동을 방해할 수 없다고 쓰여진 것 같습니다. 그런 다음 모든 것이 멈추고 모든 것이 다시 작동하기 시작합니다.

7개의 MT4 터미널과 3개의 MT5 터미널이 병렬로 있습니다. 아마도 힘이 충분하지 않습니까?



 
Vasiliy Pushkaryov :

도움말에는 루프형 Expert Advisor가 다른 프로그램의 작동을 방해할 수 없다고 쓰여진 것 같습니다. 그런 다음 모든 것이 멈추고 모든 것이 다시 작동하기 시작합니다.

예, 이상합니다. 전문가 탭만 보았고 로그를 처음 보지 못했습니다.

7개의 MT4 터미널과 3개의 MT5 터미널이 병렬로 있습니다. 아마도 힘이 충분하지 않습니까?

그렇다면 모든 터미널이 느려질 가능성이 큽니다. 이 경우 프로세서 로딩은 100%로 확장되어야 합니다.

 

TerminalA 세트는 액세스 포인트에 대한 ping 데이터( xxx ms )가 있는 터미널입니다.

TerminalB의 집합은 액세스 포인트에 대한 ping 데이터( n/a )가 없는 터미널입니다.


두 세트의 터미널은 동일한 액세스 포인트에 연결하고 동일한 방식으로 거래할 수 있습니다. OrderSend 는 응답을 보내고 받습니다.


TerminalA는 프로세서를 최소한으로 로드합니다.


터미널B:

  • CPU의 최대 부하.
  • 재부팅 후 TerminalB로 남아 있습니다.
  • "네트워크 다시 검색"(GUI를 통해 수동으로) 후 유형을 TerminalA로 변경합니다. 따라서 CPU 로드를 중지합니다.


설명할 수 없을 정도로 높은 CPU 사용량이 발생하면 다시 검색해 보십시오. 모든 TerminalB가 TerminalA를 만드는 데 도움이 되었습니다.

 

이유는 모르겠지만 내 중개인은 MT4보다 MT5에서 더 많은 회전율, 거래 및 활성 계정을 가지고 있는 것 같습니다.

불행히도 플랫폼에 대한 요약 정보만 있습니다. 

Количество закрытых позиций : 129 714
Торговый оборот ($) :$ 5 747 296 372
Активных счетов : 498

그러나 간접적인 징후는 MT4보다 MT5의 발전에 대해 이야기할 이유를 제공합니다. 이 상황의 이유는 누구나 짐작할 수 있습니다.


내가 클라이언트에 대해 알고 있는 것:

  • 거래의 >95%(매출의 ~99%) - 자동 거래.
  • 일부 클라이언트의 경우 MT5 터미널은 10GB 이상의 메모리(과거 캐시)에서, MT4는 1GB 미만의 동일한 거래에서 살아남습니다. 그러나 이것에도 불구하고 그들은 더 강력한 VPS에 대해 초과 지불할 준비가 되어 있지만 4개가 아닌 MT5에서 거래합니다.
  • 거의 모든 스캘퍼. 주요 이익은 저녁 밤 플랫 거래에 해당합니다.
  • 롤오버 기간 동안 상위(다른 브로커와 비교할 때) 활동(플러스) - 엄청난 스프레드.
 
fxsaber TimeCurrent 간의 불일치를 모니터링합니다.

팁 고마워. 이 상황이 발생했습니다. OnTimer() 에서 TimeLocal() 과 TimeCurrent ( ) 간의 불일치를 추적했습니다.


어제 저녁 21:58 부터 TimeCurrent() 가 같은 시간에 반환되기 시작했습니다. 오늘 00:08에 공개됩니다. 저것들. 2시간이 조금 넘는 시간이 모든 캐릭터에게 그런 상황이었다.

 

성능이 좋고 거래 서버에 대한 핑이 4ms 미만인 비원격 머신(VPS 아님) 은 터미널 로그(b2958)를 볼 때 정기적으로 느려지는 경우를 많이 보았습니다.


나는 여기에서 시연을 위해 만난 첫 번째 것을 가져갔습니다. 

2022.01.18 23:00:09.375  Trades  '': modify order #7133346 sell limit 0.23 USDCHF at 0.91744 sl: 0.00000 tp: 0.91709 -> 0.91741, sl: 0.00000 tp: 0.91709
2022.01.18 23:00:17.752  Trades  '': accepted modify order #7133346 sell limit 0.23 USDCHF at 0.91741 sl: 0.00000 tp: 0.91709 -> 0.91741, sl: 0.00000 tp: 0.91709
2022.01.18 23:00:17.769  Trades  '': modify #7133346 sell limit 0.23 USDCHF -> price: 0.91741, sl: 0.00000, tp: 0.91709) done in 8393.712 ms


리미터 수정은 8초 동안 지속되었습니다. 대부분의 수정은 이 시기에 발생합니다. 

2022.01.18 23:11:00.751 Trades  '': modify #7133346 sell 0.23 USDCHF sl: 0.00000, tp: 0.91711 -> sl: 0.00000, tp: 0.91712
2022.01.18 23:11:00.761 Trades  '': accepted modify #7133346 sell 0.23 USDCHF sl: 0.00000, tp: 0.91711 -> sl: 0.00000, tp: 0.91712
2022.01.18 23:11:00.763 Trades  '': modify #7133346 sell 0.23 USDCHF -> sl: 0.00000, tp: 0.91712 done in 12.422 ms


4ms의 핑이라도 이건 좀 많은데 그래도 8초랑은 비교가 안 된다.


MT5 터미널만 기계에서 작동하며 CPU의 평균 부하는 ~1%입니다. 분석에 따르면 브레이크 동안 강력한 시장 활동과 거래 주문으로 부하가 최대 100%까지 폭발했습니다. 결과적으로 거래 서버에서 터미널로의 응답은 매우 오랜 시간이 걸립니다. 브레이크의 경우 브로커에게 정보를 요청했습니다. 거래 서버 측에서는 모든 것이 즉시 이루어지며 첫 번째 수정 라인을 통해 터미널에서 서버로 주문이 옵니다. 저것들. 주문을 보내는 것은 느려지지 않으며, 응답이 터미널에서 수신될 때 지연이 발생합니다.


개발자들이 여기서 뭔가를 개선할 수 있을지 의심스럽습니다. 매우 활발하게 거래하는 사람은 로그에서 이 주제에 대한 관찰을 공유하십시오.

1...85868788899091929394
새 코멘트