PPS 아무도 GetTickCount를 사용한 에뮬레이션을 통해 밀리초 단위로 메타에서 틱을 수집하는 것을 귀찮게 하지 않습니다. 아주 간단합니다. 유일한 질문은, 그것이 필요합니까?
GetTickCount는 MQL에서 WinAPI를 사용할 필요가 없기 때문에 좋습니다. 그러나 그것의 장점은 다른 방식으로 훨씬 더 강력합니다. 현지 시간이 반드시 무역 서버 시간과 동기화되는 것은 아닙니다. 그리고 틱 도착 시간에 대한 데이터는 여전히 거래 서버의 시간에 수신되어야 합니다. 따라서 GetTickCount를 통해 밀리초가 에뮬레이트됩니다. 따라서 2회 연속 부동 비동기화를 고려하는 것보다 정확도가 더 높습니다.
GetTickCount? 충분히? 날 웃게 하지마
거래 요구 사항은 GetTickCount에 의해 제한되지 않습니다.
물론 메타 프레임워크 내에서 틱 속도 측정의 유용성에 대한 의문은 GetTickCount의 제한된 기능을 통해 완전히 해결됩니다.
논쟁할 필요도 없습니다. 누구나 이 문제를 매우 빠르게 해결할 수 있습니다.
일반적으로 밀리초 및 내 필요에 관해서는 MT5에서 필요하지 않다는 내 의견을 어느 정도 합리적으로 표현 했습니다.
마지막 10개(또는 지정된 수) 틱에 대한 모든 계산..
1분의 tick_volume을 사용하면 다소 다른 것으로 판명될 것입니다.) 기간은 10배 더 큽니다.
분을 살펴보고 60,000밀리초를 tick_volume의 크기로 나누면 1분당 틱의 비율을 가장 가까운 밀리초로 조사하지 않을까요?
컴퓨터의 현재 로컬 시간을 밀리초로 계산하면(WinAPI 사용) 이 밀리초를 현재 누적된 tick_volume으로 나누면 현재 틱 도달률을 얻을 수 없습니까?
물론 메타 프레임워크 내에서 틱 속도 측정의 유용성에 대한 의문은 GetTickCount의 제한된 기능을 통해 완전히 해결됩니다.
논쟁할 필요도 없습니다. 누구나 이 문제를 매우 빠르게 해결할 수 있습니다.
일반적으로 밀리초 및 내 필요에 관해서는 MT5에서 필요하지 않다는 내 의견을 어느 정도 합리적으로 표현 했습니다.
hrenfx :
그러나 GetTickCount는 이 간단한 작업을 완전히 해결합니다. 밀리초는 그것과 아무 관련이 없습니다.
좋은 아이디어입니다. 위의 시도)
그러나 틱 시간이 밀리초라면 모든 것이 더 쉬울 것입니다.
여기에 광고가 허용되지 않습니다 :)
아무도 현재 시간을 밀리초 단위로 가져오는 것을 귀찮게 하지 않습니다. 다음 - 기술 문제
당신은 부주의하게 읽는 것 같습니다:
PPS 아무도 GetTickCount를 사용한 에뮬레이션을 통해 밀리초 단위로 메타에서 틱을 수집하는 것을 귀찮게 하지 않습니다. 아주 간단합니다. 유일한 질문은, 그것이 필요합니까?
GetTickCount는 MQL에서 WinAPI를 사용할 필요가 없기 때문에 좋습니다. 그러나 그것의 장점은 다른 방식으로 훨씬 더 강력합니다. 현지 시간이 반드시 무역 서버 시간과 동기화되는 것은 아닙니다. 그리고 틱 도착 시간에 대한 데이터는 여전히 거래 서버의 시간에 수신되어야 합니다. 따라서 GetTickCount를 통해 밀리초가 에뮬레이트됩니다. 따라서 2회 연속 부동 비동기화를 고려하는 것보다 정확도가 더 높습니다.
이것은 이론적 추론이 아니라 거래 관행입니다.
그리고 틱 도착 시간에 대한 데이터는 여전히 거래 서버의 시간에 수신되어야 합니다. 따라서 GetTickCount를 통해 밀리초가 에뮬레이트됩니다. 따라서 2회 연속 부동 비동기화를 고려하는 것보다 정확도가 더 높습니다.
+ 맞습니다.
터미널 측에서 시간을 측정한다는 것은 이 데이터를 보내는 데 지연이 있음을 의미합니다.
서버에서 시간을 절약하는 것이 필요한 것입니다.
스타니슬라프. 그러나 주문에 관해서는 이미 시스템에 있습니다. 거래자들이 받을 수 있도록 터미널에 주시면 됩니다.
체크 표시 - 문제가 서버 수준에서 해결되지 않습니다. 그래서 귀찮아도 하지 않습니다.
보세요, 진드기가 나타나면 다음 이벤트 중 하나가 발생했음을 의미합니다.
1. 1등급(Bid_1)의 입찰가가 변경된 경우
2. Bid_1이 변경되지 않았지만 주어진 가격 수준의 거래량이 변경된 경우(증가/감소);
3. Bid_1이 변경되지 않았지만 Bid_2가 변경되었거나 Bid_2 가격 수준의 볼륨이 변경된 경우
등.
Ask도 마찬가지입니다. 이제 각 가격 수준에서 입찰, 매도 및 거래량을 모두 함께 사용할 수 있습니다. 얼마나 많은 다른 데이터가 있는지 상상해보십시오. 그리고 그것은 모두 1로 포장됩니다.
이러한 틱은 초당 최대 수십 번 있을 수 있습니다. 그들을 분류하는 방법? 1초의 시간 분해능은 매우 거친 분류이므로 더 미세한 시간 간격(밀리초)이 필요합니다. 일반적으로 명확합니까?
,,, 그래서 뭐... 예를 들어, 서버에 지연이 있고 요청이 있는 모든 입찰은 얼마나 많은 입찰이 있었는지에 상관없이 미래에 계속 올 것입니다.
,,, 정말, 거래에 어떻게 도움이됩니까? ... 내가 따라 잡을 때까지. 음, 변동성을 측정하는 것을 제외하고.
,, 그리고 그건 그렇고, MK가 m.seconds를 추가하면 밀리초 속도로 모든 틱이 초기 소스에서 모니터(최종 시각 지점)에 도달할 것이라고 확신합니까?
나는 스레드를 읽고 밀리초가 스포츠에 대한 관심에만 필요하다는 것을 깨달았습니다. 최대 ms의 정확도로 100m에 대한 가격 실행을 측정하기 위해.
sergeev
거래자들이 받을 수 있도록 터미널에 주시면 됩니다.
이를 제공하려면 datetime 유형이 10바이트가 되어야 하고 MqlDateTime 구조가 필요합니다.
MQL6을 기다리면 밀리초 타이머와 틱 기록 및 기타 많은 기능이 제공됩니다. 이제 추가할 이유가 없습니다. 임호.