일반적으로 거의 모든 일반 기능이 브레이크를 유발할 수 있기 때문에 각 OnTick 전투 고문은 수십 밀리초를 수행합니다. Order*+SymbolInfoTick+Position* 등에 대한 호출의 합계가 너무 많이 소모됩니다. 어떤 매트. 계산이 없습니다. 무료 스냅샷이 필요합니다. 그것들이 없으면 LCH는 MT5에서 롤링되지 않습니다.
fxsaber : 일반적으로 거의 모든 표준 기능이 브레이크를 유발할 수 있기 때문에 각 OnTick 전투 고문은 수십 밀리초를 수행합니다. Order*+SymbolInfoTick+Position* 등에 대한 호출의 합계가 너무 많이 소모됩니다. 어떤 매트. 계산이 없습니다. 무료 스냅샷이 필요합니다. 그것들이 없으면 LCH는 MT5에서 롤링되지 않습니다.
접근 방식에 문제가 있습니다... 분명히 OnTrade 기능이 필요하며 매 틱마다 상태를 처음부터 스캔하지 않습니다.
거래 내역에 주문/거래를 추가하면 부분 캐시가 아닌 HistorySelect 캐시가 완전히 다시 작성됩니다. 따라서 지연이 트리거될 때 지연됩니다.
b2595 - 고정, 슈퍼!
잘못된 이야기를 확인했는데 아직 수정하지 않았습니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
MT5와 속도
fxsaber , 2020.09.08 19:46
b2596이 더 빨라진 것 같습니다.
말해봐, 거래하는 동안 이런 일이 발생하지 않으려면 어떻게 하는 것이 가장 좋을까?
마지막 줄은 괜찮습니다.
랙이 병렬로 출시된 EA의 영향을 받을 수 있습니까? 지표가 없습니다.
빈 터미널에서 ZY 프로파일링.
SymbolInfoTick은 값비싼 기능입니다.
병렬로 시작된 Expert Advisors가 지연에 영향을 줄 수 있습니까? 지표가 없습니다.
나는 빈 터미널을 병렬로 실행하고 그것을 시도했다. 같은 그림.
구성.거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
MT5와 속도
fxsaber , 2020.09.01 21:59
설치된 Win10, LatencyMon은 모든 것이 정상임을 보여줍니다.
일반적으로 거의 모든 표준 기능이 브레이크를 유발할 수 있기 때문에 각 OnTick 전투 고문은 수십 밀리초를 수행합니다. Order*+SymbolInfoTick+Position* 등에 대한 호출의 합계가 너무 많이 소모됩니다. 어떤 매트. 계산이 없습니다. 무료 스냅샷이 필요합니다. 그것들이 없으면 LCH는 MT5에서 롤링되지 않습니다.
접근 방식에 문제가 있습니다... 분명히 OnTrade 기능이 필요하며 매 틱마다 상태를 처음부터 스캔하지 않습니다.
접근 방식에 문제가 있습니다... 분명히 OnTrade 기능이 필요하며 매 틱마다 상태를 처음부터 스캔하지 않습니다.
OOP 패러다임은 각 sub-TS가 거래 환경을 스캔한다고 가정합니다. 그러나 정말로 원한다면 OOP 객체의 독립성을 약간 위반할 수 있습니다.
예를 들어, OnTick의 맨 처음에 전체 스냅샷을 찍습니다. 그리고 동기 함수인 OrderSend 및 CopyTicks를 호출한 후에만 반복합니다.
OnTrade*의 경우 OnTrade 기능에서만 스냅샷이 생성될 때 연결이 끊어지면 구성표가 깨집니다. 그렇지 않으면 물론 큰 비용 절감이 있을 것입니다.
OOP 패러다임은 각 sub-TS가 거래 환경을 스캔한다고 가정합니다. 그러나 정말로 원한다면 OOP 객체의 독립성을 약간 위반할 수 있습니다.
예를 들어, OnTick의 맨 처음에 전체 스냅샷을 찍습니다. 그리고 동기 함수인 OrderSend 및 CopyTicks를 호출한 후에만 반복합니다.
물론 스냅샷 개체는 하나만 있어야 합니다.
OnTrade*의 경우 OnTrade 기능에서만 스냅샷이 생성될 때 연결이 끊어지면 구성표가 깨집니다. 그렇지 않으면 물론 큰 비용 절감이 있을 것입니다.
끊어진 연결을 감지하고 다음 틱에서 스냅샷 업데이트를 강제 실행한 다음 절약 모드로 돌아가시겠습니까?