1) GetTickCount()는 라이브에서 작동해야 합니다. 역사적 데이터에 무의미합니다.
2) mt5_data도 밀리초 단위로 저장되지 않습니다. 그러나 no_problem 라이브.
3) 나는 당신이 그것을 가지고 어디로 가는지 알 수 없습니다. 밀리초 단위의 동일한 시간이라면 밀리초가 도움이 되지 않습니다. GetTickCount()와 다른 시간(밀리초)이 도움이 될 수 있습니다. 코드가 밀리초 미만 내에 현재 틱을 처리한다는 점에서 도움이 됩니다. 모든 것이 얼마나 중요한지는 당신이 성취하려는 것에 달려 있습니다... 제 생각에는.
응답해 주셔서 감사합니다. Rogue Tick Detector라는 코드베이스에 게시된 지표가 있었습니다. 그러나 아직 승인되지 않았습니다. 지금은 여기에서 찾을 수 있습니다.
기본 아이디어는 현재 틱 tick0이 이전 tick-1보다 늦은 타임스탬프와 함께 들어오는 경우가 있다는 것입니다. 그러나 가격은 더 이상 실행 가능하지 않지만 EA 또는 인간 거래자는 사실이 끝날 때까지 이것을 알지 못할 것입니다. 가격 기반 이벤트가 잘못 트리거되는 원인이 되었습니다. Rogue 틱 감지기는 이러한 가짜 틱에 플래그를 지정하고 EA가 이에 대해 조치를 취하는 것을 방지할 수 있었습니다(다음 '좋은' 틱을 기다림).
틱의 타임스탬프를 캡처하는 현재 방법인 MarketInfo(Symbol(), MODE_TIME)은 밀리초 타임스탬프를 반환하지 않습니다. 그래서 우리가 간과하고 있는 대안이 있는지 알아보기 위해 여기에 왔습니다.
불량 틱 감지 기능을 포함하는 EA는 모두 SSD 드라이브, Windows 2008이 있는 뉴욕의 VPS에서 실행되며 일반적으로 브로커 서버에서 2ms 미만입니다. HFT 또는 하이퍼스캘핑 없음(거래 평균 보류 시간은 약 1시간)
내 원래 질문 중 하나로 돌아갑니다 . mt4(및 mt5) 플랫폼 [자체]이 '동시에' 들어오는 진드기를 어떻게 적절하게 구별해야 합니까?
RaptorUK : 당신은 할 수 없습니다. . . 귀하의 브로커는 실제로 동시에 발생하는 여러 틱을 귀하에게 보내나요? 아니면 카운트를 2로 늘리고 후자의 틱을 보내나요? 그들이 그랬는지 어떻게 알 수 있습니까? 브로커 사이에 틱 수에 큰 차이가 있다는 것을 알고 있습니까?
예, 브로커마다 피드가 다르고 틱 수가 크게 다를 수 있음을 알고 있습니다. 그러나 주로 거래가 이익으로 마감되었을 때 특정 시간에 불량 틱이 전송되는 경우가 있습니다. 폐쇄 및 주문 실행에 영향을 미치므로 가능한 한 이를 감지하고 무시할 수 있는 방법을 찾았습니다. 나는 심지어 일부 브로커로부터 의도적인 피드 조작을 의심하기도 했습니다.
그러나 아마도 우리는 총 틱을 계산하는 틱 카운트 비율을 가져야 합니다.
많은 사람들에게 영향을 미치지 않을 수도 있지만 잠재적인 피해가 추가 조사를 정당화하기에 충분하다고 생각했습니다.
당신은 무엇을 염두에 두고 있습니까? mt4 Volume과 어떻게 다른가요? 어떤 두 숫자의 비율 [ count and ??? ].
이 주제는 매우 빠르게 매우 혼란스러워집니다. 나는 진드기에 대한 모든 것, metaQuotes가 그것을 처리하는 방법, 그것이 누군가에게 매우 중요한 이유를 알지 못합니다. 제가 관찰한 내용을 요약해 보겠습니다.
1) metaQuotes는 다음과 같이 말합니다: 당신은 milli_seconds time_stamp를 원합니다. [ 그들은 즉시 tick_data를 생각하기 시작합니다], 누가 이 tick_data 중개인을 보유할 것입니까? 그 1분 안에 200틱이 있다고 말하는 것만으로는 충분하지 않다는 뜻인가요? OHLC+V가 충분하지 않기 때문에 200개의 데이터 항목을 저장하기를 정말로 원하십니까?
2) 상인 번호 1은 다음과 같이 말합니다. 정보를 저장할 사람이 필요하지 않습니다. 오래된 데이터를 결정하기 위해 밀리초 시간 스탬프를 원할 뿐입니다.
3) 상인 번호 2는 다음과 같이 말합니다. 정보를 저장할 필요가 없습니다. 가져올 수 있는 권한만 주면 내 데이터를 얻을 수 있습니다.
4) 상인 3번이 말합니다: 틱 데이터를 저장하고 제공하는 것이 왜 그렇게 큰 일인지 모르겠습니다. 자, 컴퓨터는 요즘 더 많은 성능과 메모리를 가지고 있습니다. 확실히 내 브로커가 어딘가에 데이터를 제공할 수 있습니다.
5) 중개인은 다음과 같이 말합니다. 저는 3_months 이상 동안 m1 데이터를 제공하는 데 충분히 시간을 들이고 있어서 연결하거나 테스트할 때 그 정도의 데이터를 제공할 수 있거나 제공할 의사가 있다고 생각합니다.
6) 상인 4번: 우리는 테스트를 위해 그것을 필요로 하지 않으며 데이터를 위한 작은 부분만 라이브로 충분할 것입니다. 나는 지금 불충분한 m1에 대해 불평하지 않습니다. 그래서 문제가 무엇입니까.
7) metaQuotes: 여전히 불가능합니다. 이것은 밀리초와 표시기 등을 반환하는 기능을 용이하게 해야 한다는 것을 의미합니다. 틱을 구별하는 것입니다... 터미널을 충돌시키려는 건가요?
8) 상인 번호 5: 거래량은 시장 깊이가 아니라 주어진 time_frame 내의 틱 수를 의미합니다 :) . 내가 틱을 놓칠 수 있다는 말입니까? 사이버 공간에서 진드기가 길을 잃거나 지연될 수 있다는 말입니까? 브로커마다 tick_count가 다르다는 말씀이신가요? 중개인이 저장한 데이터가 내가 받은 것과 동일하지 않았음을 의미합니까? 진드기에 대한 모든 소란은 무엇입니까?
9) xxxxxxxxxxxx는 다음과 같이 말합니다. 틱은 일급 비밀입니다. 제공되는 것만으로 충분합니다. 틱 생성기를 설계하는 데 도움을 주었지만 그런 종류의 해상도를 제공하는 데는 거의 관심이 없었습니다. 일어나지 않을 .... 기간.
10) 상인 번호 6: 제공할 수 있는 것, 틱 카운트의 작동 방식, 받을 수 있는 것 등에 대한 기술적인 제한이 있습니다. 이것은 metaTrader 문제가 아니라 대부분의 소매 플랫폼에서 이 문제를 경험합니다. 기관 소프트웨어를 바라보고 큰 돈을 벌 준비를 하십시오.
Trader#3에서 Trader#10: 동의하지 않습니다.
Ubzen의 말: 더 이상 무슨 말을 해야 할지 모르겠습니다.
Ps> 거의 잊혀진 상인 # 7 : 좋아, 나는 내 터미널에 오는 내 자신의 틱을 저장하고이 데이터를 처리하기 위해 내 자신의 지표 등을 프로그래밍 할 것입니다 ... 이것이 내가 질문을 해석 한 방법이며 따라서 GetTickCount를 추천 한 이유입니다 ().
Ps> 거의 잊혀진 상인 # 7 : 좋아, 나는 내 터미널에 오는 내 자신의 틱을 저장하고이 데이터를 처리하기 위해 내 자신의 지표 등을 프로그래밍 할 것입니다 ... 이것이 내가 질문을 해석 한 방법이며 따라서 GetTickCount를 추천 한 이유입니다 ().
불행히도 그것은 여전히 놓친 진드기에 대처하지 못합니다. . . 실제로 자신의 진드기를 저장하는 것은 불가능합니다. 모든 진드기를 얻을 수 없으며 일부를 놓칠 것이기 때문에 이 사실을 기록하지 않으면 저장된 데이터가 부정확하여 잠재적으로 쓸모없는 것보다 더 나빠서 오해의 소지가 있습니다.
RaptorUK : 불행히도 아직 진드기를 놓치는 경우에는 대처하지 못합니다. . . 실제로 자신의 진드기를 저장하는 것은 불가능하고 모든 것을 얻을 수 없으며 일부를 놓칠 것이기 때문에 이 사실이 기록되지 않는 한 저장된 데이터는 부정확할 수 있으므로 잠재적으로 쓸모없는 것보다 더 나쁘게 되어 오해의 소지가 있습니다.
나는 여기에서 주제에 머물기를 희망합니다. :). 즉, 매 틱마다 밀리초의 timeStamps를 보내는 브로커를 상상해 보십시오. 그러나 이 정보를 her_side에 저장하지 않도록 계속 진행하십시오. 일반적으로 중개인에 대한 모든 불신을 감안할 때 이 중개인은 맹공격을 퍼부을 것입니다. 그러나 이번에는 사람들이 밀리초 단위로 증거를 가지고 있지만 브로커는 반박할 기록이 없습니다. 따라서 어떤 의미에서는 tick_data를 요구합니다 | 밀리초 또는 동일한 인수로 이어지는 것은 기본적으로 브로커에게 tick_data를 저장하고 플랫폼이 이를 용이하게 하도록 요청하는 것입니다.
두 번째로, 대부분의 ppl이 수행하는 역 백 테스트를 고려하십시오. 약 일주일 동안 strategy_live를 실행한 다음 동일한 결과를 얻을 수 있는지 확인하기 위해 해당 주에 back_test를 진행합니다. 이 사람은 밀리초 time_stamps가 활성화되어 있고 지연 및 누락된 패킷이 활성화되어 있습니다. 물론 원본 포스터와 마찬가지로 누락된 데이터를 무시하고 지연된 눈금을 무시합니다. 그러나 백 테스트를 수행하면 올바른 타임스탬프가 있는 모든 브로커 데이터가 있습니다. 이것은 분명히 당신이 방금 라이브로 받은 것과 다른 결과를 생성할 것입니다.
그러니 Live를 오도했습니까, 아니면 Back_Test 중에 오도 중이었습니까?
그러나 나는 위의 귀하의 진술에 동의합니다 . Imo, 이 모든 것이 일련의 역설을 만들어내며, 이는 내가 모든 분 과정에서 모두 떨어져 있게 합니다. 플랫폼에는 제한이 있습니다. 저는 그냥 수락하고 이동합니다.
Win 7 PC 및 Windows 2012 VPS에 대한 테스트에 따르면 GetTickCount()는 시스템 타이머 설정에 관계없이 항상 15.6msecs(초당 64개의 인터럽트)의 해상도를 갖는 반면 kernel32.dll을 호출하여 밀리초 시간을 얻을 때의 해상도를 나타냅니다. 함수 GetSystemTime() [또는 GetLocalTime()] 또는 GetSystemTimeAsFileTime()은 시스템 타이머 설정의 영향을 받으며 테스트한 두 컴퓨터에서 모두 0.5msec의 해상도를 제공할 수 있습니다.
GetTickCount() 해상도
다음은 GetTickCount() 확인을 테스트하는 스크립트의 코드입니다.
// Script to test Millisecond Resolution via GetTickCount ()
voidOnStart () {
uint startMsecsU = GetTickCount (), nowMsecsU;
for ( int j= 0 ; j< 1000000000 ; j++) {
if ((nowMsecsU = GetTickCount ()) > startMsecsU) {
MessageBox ( StringFormat ( "GetTickCount %u -> %u diff %u" , startMsecsU, nowMsecsU, nowMsecsU - startMsecsU), "Test Millisecond Resolution via GetTickCount" );
return ;
}
}
이것은 다른 테스트에 대해 아래에 언급된 시스템 타이머 해상도 변경에 관계없이 테스트된 두 컴퓨터 모두에서 항상 15 또는 16(즉, 15.6)을 제공합니다.
GetSystemTime() 해상도
이제 상황이 흥미로워지기 시작합니다. 다음은 GetSystemTime() 확인을 테스트하는 스크립트의 코드입니다.
/* Script to test Millisecond Resolution via GetSystemTime ()
Windows struct for a GetSystemTime() or GetLocalTime() call:
typedef struct _SYSTEMTIME {
WORD wYear;
WORD wMonth;
WORD wDayOfWeek;
WORD wHour;
WORD wMinute;
WORD wSecond;
WORD wDay;
WORD wMilliseconds;
} SYSTEMTIME, *PSYSTEMTIME;
*/// MT4 equivalent struct:struct _SYSTEMTIME {
ushort wYear; // 2014 etcushort wMonth; // 1 - 12ushort wDayOfWeek; // 0 - 6 with 0 = Sundayushort wDay; // 1 - 31ushort wHour; // 0 - 23ushort wMinute; // 0 - 59ushort wSecond; // 0 - 59ushort wMilliseconds; // 0 - 999
};
#import "kernel32.dll"void GetSystemTime(_SYSTEMTIME &time);
#importvoidOnStart () {
_SYSTEMTIME st;
GetSystemTime(st);
int startMsecs = st.wMilliseconds, nowMsecs;
for ( int j= 0 ; j< 1000000000 ; j++) {
GetSystemTime(st);
if (st.wMilliseconds != startMsecs) {
nowMsecs = st.wMilliseconds;
if (nowMsecs < startMsecs)
nowMsecs += 1000 ; // wMilliseconds wrappedMessageBox ( StringFormat ( "GetSystemTime msecs %d -> %d diff %d" , startMsecs, nowMsecs, nowMsecs - startMsecs), "Test Millisecond Resolution via GetSystemTime" );
return ;
}
}
}
다른 소프트웨어를 실행하지 않고 새로 부팅한 PC에서는 15/16msec의 해상도를 제공하지만 PC에서 Chrome이 실행 중인 경우에는 1msec입니다! angevoyageur의 두 번째 링크는 Chrome이 다른 소프트웨어와 마찬가지로 시스템 타이머를 1msec 해상도로 설정한다고 설명합니다.
시스템 타이머 해상도를 설정하기 위한 두 개의 작은 유틸리티를 찾았습니다. 따라서 클린 부팅된 시스템에서 제어된 방식으로 1msec(또는 0.5msec) 해상도를 얻을 수 있습니다.
나는 두 가지 중 첫 번째 것인 Windows System Timer Tool을 선호합니다. 이를 통해 GetSystemTime()을 통해 1msec 해상도를 안정적으로 얻을 수 있습니다. GetLocalTime()도 유사하게 사용할 수 있습니다.
Btw 위의 스크립트 코드는 구조체 덕분에 새로운 MT4 코드가 얼마나 더 나은지 보여주는 예입니다. GetSystemTime()에 액세스하는 이전 MT4에서는 정수 배열과 많은 지저분한 비트 조작을 사용해야 했습니다.
GetSystemTimeAsFileTime() 해상도
마지막으로 Windows용 Microsecond Resolution Time Services에서 GetSystemTimeAsFileTime()이 시스템 시간에 액세스하는 더 빠른 함수이며 더 작고 단순한 구조체가 필요하다고 언급했습니다. 후자는 "구조체"가 단지 ulong으로 축소될 수 있기 때문에 새로운 MT4에 대해 확실히 사실입니다.
다음은 GetSystemTimeAsFileTiime() 확인을 테스트하는 스크립트의 코드입니다.
// Script to test Millisecond Resolution via GetSystemTimeAsFileTime()#import "kernel32.dll"void GetSystemTimeAsFileTime( ulong &SystemTimeAsFileTime); // Returns the system time in 100 nsec units in a ulong
#importvoidOnStart () {
ulong startL, nowL;
GetSystemTimeAsFileTime(startL);
for ( int j= 0 ; j< 1000000000 ; j++) {
GetSystemTimeAsFileTime(nowL);
if (nowL > startL) {
int diff = int (nowL - startL);
MessageBox ( StringFormat ( "GetSystemTimeAsFileTime %llu -> %llu diff %d in 100 nsec units = %.1f msecs" ,
startL, nowL, diff, diff/ 10000.0 ), "Test Millisecond Resolution via GetSystemTimeAsFileTime" );
return ;
}
}
}
Windows 시스템 타이머 도구를 사용하여 시스템 타이머 해상도를 0.5초로 설정하는 경우 이 작은 스크립트는 5000(또는 때때로 5001) 100nsec 단위 = 0.5msec의 해상도를 보고합니다.
GetSystemTimeAsFileTiime() 사용은 실제로 더 간단하고 더 미세한 해상도를 표시할 수 있습니다.
다음은 사용 중인 이 사진의 일부입니다.
클린 부팅 후:
타이머 도구를 사용하여 시스템 타이머 해상도를 1ms로 설정:
시스템 타이머 해상도를 0.5ms로 설정하는 데 사용되는 타이머 도구:
결론
MT4에서 밀리초 타이밍을 얻기 위해 사용하는 가장 좋은 함수는 위의 테스트 스크립트에 표시된 것처럼 GetSystemTimeAsFileTiime()을 호출하는 것이며, 원하는 시스템 타이머 해상도를 설정하는 데 사용되는 Windows 시스템 타이머 도구와 같은 유틸리티를 사용합니다.
모두,
여기서 문제는 틱의 타임스탬프를 얻는 것입니다. 제안된 대로 GetTickCount()를 사용하여 틱이 at 터미널에 도착하는 시간이 아닙니다(즉, start() 함수가 호출될 때마다 ).
MarketInfo(Symbol(), MODE_TIME)은 데이터 피드의 브로커 서버에서 보낸 틱의 타임스탬프를 반환합니다.
문안 인사
VS
모두,
여기서 문제는 틱의 타임스탬프를 얻는 것입니다. 제안된 대로 GetTickCount()를 사용하여 틱이 at 터미널에 도착하는 시간이 아닙니다(즉, start() 함수가 호출될 때마다 ).
MarketInfo(Symbol(), MODE_TIME)은 데이터 피드의 브로커 서버에서 보낸 틱의 타임스탬프를 반환합니다.
1) GetTickCount()는 라이브에서 작동해야 합니다. 역사적 데이터에 무의미합니다.
2) mt5_data도 밀리초 단위로 저장되지 않습니다. 그러나 no_problem 라이브.
3) 나는 당신이 그것을 가지고 어디로 가는지 알 수 없습니다. 밀리초 단위의 동일한 시간이라면 밀리초가 도움이 되지 않습니다. GetTickCount()와 다른 시간(밀리초)이 도움이 될 수 있습니다. 코드가 밀리초 미만 내에 현재 틱을 처리한다는 점에서 도움이 됩니다. 모든 것이 얼마나 중요한지는 당신이 성취하려는 것에 달려 있습니다... 제 생각에는.
응답해 주셔서 감사합니다. Rogue Tick Detector라는 코드베이스에 게시된 지표가 있었습니다. 그러나 아직 승인되지 않았습니다. 지금은 여기에서 찾을 수 있습니다.
기본 아이디어는 현재 틱 tick0이 이전 tick-1보다 늦은 타임스탬프와 함께 들어오는 경우가 있다는 것입니다. 그러나 가격은 더 이상 실행 가능하지 않지만 EA 또는 인간 거래자는 사실이 끝날 때까지 이것을 알지 못할 것입니다. 가격 기반 이벤트가 잘못 트리거되는 원인이 되었습니다. Rogue 틱 감지기는 이러한 가짜 틱에 플래그를 지정하고 EA가 이에 대해 조치를 취하는 것을 방지할 수 있었습니다(다음 '좋은' 틱을 기다림).
틱의 타임스탬프를 캡처하는 현재 방법인 MarketInfo(Symbol(), MODE_TIME)은 밀리초 타임스탬프를 반환하지 않습니다. 그래서 우리가 간과하고 있는 대안이 있는지 알아보기 위해 여기에 왔습니다.
불량 틱 감지 기능을 포함하는 EA는 모두 SSD 드라이브, Windows 2008이 있는 뉴욕의 VPS에서 실행되며 일반적으로 브로커 서버에서 2ms 미만입니다. HFT 또는 하이퍼스캘핑 없음(거래 평균 보류 시간은 약 1시간)
내 원래 질문 중 하나로 돌아갑니다 . mt4(및 mt5) 플랫폼 [자체]이 '동시에' 들어오는 진드기를 어떻게 적절하게 구별해야 합니까?
편집, 명확히 해 주신 kasoftware에게 감사드립니다.
내 원래 질문 중 하나로 돌아갑니다 . mt4(및 mt5) 플랫폼 [자체]이 '동시에' 들어오는 진드기를 어떻게 적절하게 구별해야 합니까?
당신은 할 수 없습니다. . . 귀하의 브로커는 실제로 동시에 발생하는 여러 틱을 귀하에게 보내나요? 아니면 카운트를 2로 늘리고 후자의 틱을 보내나요? 그들이 그랬는지 어떻게 알 수 있습니까? 브로커 사이에 틱 수에 큰 차이가 있다는 것을 알고 있습니까?
예, 브로커마다 피드가 다르고 틱 수가 크게 다를 수 있음을 알고 있습니다. 그러나 주로 거래가 이익으로 마감되었을 때 특정 시간에 불량 틱이 전송되는 경우가 있습니다. 폐쇄 및 주문 실행에 영향을 미치므로 가능한 한 이를 감지하고 무시할 수 있는 방법을 찾았습니다. 나는 심지어 일부 브로커로부터 의도적인 피드 조작을 의심하기도 했습니다.
그러나 아마도 우리는 총 틱을 계산하는 틱 카운트 비율을 가져야 합니다.
많은 사람들에게 영향을 미치지 않을 수도 있지만 잠재적인 피해가 추가 조사를 정당화하기에 충분하다고 생각했습니다.
당신은 무엇을 염두에 두고 있습니까? mt4 Volume과 어떻게 다른가요? 어떤 두 숫자의 비율 [ count and ??? ].
이 주제는 매우 빠르게 매우 혼란스러워집니다. 나는 진드기에 대한 모든 것, metaQuotes가 그것을 처리하는 방법, 그것이 누군가에게 매우 중요한 이유를 알지 못합니다. 제가 관찰한 내용을 요약해 보겠습니다.
1) metaQuotes는 다음과 같이 말합니다: 당신은 milli_seconds time_stamp를 원합니다. [ 그들은 즉시 tick_data를 생각하기 시작합니다], 누가 이 tick_data 중개인을 보유할 것입니까? 그 1분 안에 200틱이 있다고 말하는 것만으로는 충분하지 않다는 뜻인가요? OHLC+V가 충분하지 않기 때문에 200개의 데이터 항목을 저장하기를 정말로 원하십니까?
2) 상인 번호 1은 다음과 같이 말합니다. 정보를 저장할 사람이 필요하지 않습니다. 오래된 데이터를 결정하기 위해 밀리초 시간 스탬프를 원할 뿐입니다.
3) 상인 번호 2는 다음과 같이 말합니다. 정보를 저장할 필요가 없습니다. 가져올 수 있는 권한만 주면 내 데이터를 얻을 수 있습니다.
4) 상인 3번이 말합니다: 틱 데이터를 저장하고 제공하는 것이 왜 그렇게 큰 일인지 모르겠습니다. 자, 컴퓨터는 요즘 더 많은 성능과 메모리를 가지고 있습니다. 확실히 내 브로커가 어딘가에 데이터를 제공할 수 있습니다.
5) 중개인은 다음과 같이 말합니다. 저는 3_months 이상 동안 m1 데이터를 제공하는 데 충분히 시간을 들이고 있어서 연결하거나 테스트할 때 그 정도의 데이터를 제공할 수 있거나 제공할 의사가 있다고 생각합니다.
6) 상인 4번: 우리는 테스트를 위해 그것을 필요로 하지 않으며 데이터를 위한 작은 부분만 라이브로 충분할 것입니다. 나는 지금 불충분한 m1에 대해 불평하지 않습니다. 그래서 문제가 무엇입니까.
7) metaQuotes: 여전히 불가능합니다. 이것은 밀리초와 표시기 등을 반환하는 기능을 용이하게 해야 한다는 것을 의미합니다. 틱을 구별하는 것입니다... 터미널을 충돌시키려는 건가요?
8) 상인 번호 5: 거래량은 시장 깊이가 아니라 주어진 time_frame 내의 틱 수를 의미합니다 :) . 내가 틱을 놓칠 수 있다는 말입니까? 사이버 공간에서 진드기가 길을 잃거나 지연될 수 있다는 말입니까? 브로커마다 tick_count가 다르다는 말씀이신가요? 중개인이 저장한 데이터가 내가 받은 것과 동일하지 않았음을 의미합니까? 진드기에 대한 모든 소란은 무엇입니까?
9) xxxxxxxxxxxx는 다음과 같이 말합니다. 틱은 일급 비밀입니다. 제공되는 것만으로 충분합니다. 틱 생성기를 설계하는 데 도움을 주었지만 그런 종류의 해상도를 제공하는 데는 거의 관심이 없었습니다. 일어나지 않을 .... 기간.
10) 상인 번호 6: 제공할 수 있는 것, 틱 카운트의 작동 방식, 받을 수 있는 것 등에 대한 기술적인 제한이 있습니다. 이것은 metaTrader 문제가 아니라 대부분의 소매 플랫폼에서 이 문제를 경험합니다. 기관 소프트웨어를 바라보고 큰 돈을 벌 준비를 하십시오.
Trader#3에서 Trader#10: 동의하지 않습니다.
Ubzen의 말: 더 이상 무슨 말을 해야 할지 모르겠습니다.
Ps> 거의 잊혀진 상인 # 7 : 좋아, 나는 내 터미널에 오는 내 자신의 틱을 저장하고이 데이터를 처리하기 위해 내 자신의 지표 등을 프로그래밍 할 것입니다 ... 이것이 내가 질문을 해석 한 방법이며 따라서 GetTickCount를 추천 한 이유입니다 ().
Ps> 거의 잊혀진 상인 # 7 : 좋아, 나는 내 터미널에 오는 내 자신의 틱을 저장하고이 데이터를 처리하기 위해 내 자신의 지표 등을 프로그래밍 할 것입니다 ... 이것이 내가 질문을 해석 한 방법이며 따라서 GetTickCount를 추천 한 이유입니다 ().
나는 여기에서 주제에 머물기를 희망합니다. :). 즉, 매 틱마다 밀리초의 timeStamps를 보내는 브로커를 상상해 보십시오. 그러나 이 정보를 her_side에 저장하지 않도록 계속 진행하십시오. 일반적으로 중개인에 대한 모든 불신을 감안할 때 이 중개인은 맹공격을 퍼부을 것입니다. 그러나 이번에는 사람들이 밀리초 단위로 증거를 가지고 있지만 브로커는 반박할 기록이 없습니다. 따라서 어떤 의미에서는 tick_data를 요구합니다 | 밀리초 또는 동일한 인수로 이어지는 것은 기본적으로 브로커에게 tick_data를 저장하고 플랫폼이 이를 용이하게 하도록 요청하는 것입니다.
두 번째로, 대부분의 ppl이 수행하는 역 백 테스트를 고려하십시오. 약 일주일 동안 strategy_live를 실행한 다음 동일한 결과를 얻을 수 있는지 확인하기 위해 해당 주에 back_test를 진행합니다. 이 사람은 밀리초 time_stamps가 활성화되어 있고 지연 및 누락된 패킷이 활성화되어 있습니다. 물론 원본 포스터와 마찬가지로 누락된 데이터를 무시하고 지연된 눈금을 무시합니다. 그러나 백 테스트를 수행하면 올바른 타임스탬프가 있는 모든 브로커 데이터가 있습니다. 이것은 분명히 당신이 방금 라이브로 받은 것과 다른 결과를 생성할 것입니다.
그러니 Live를 오도했습니까, 아니면 Back_Test 중에 오도 중이었습니까?
그러나 나는 위의 귀하의 진술에 동의합니다 . Imo, 이 모든 것이 일련의 역설을 만들어내며, 이는 내가 모든 분 과정에서 모두 떨어져 있게 합니다. 플랫폼에는 제한이 있습니다. 저는 그냥 수락하고 이동합니다.
...
그러나 나는 위의 귀하의 진술에 동의합니다 . Imo, 이 모든 것이 일련의 역설을 만들어내며, 이는 내가 모든 분 과정에서 모두 떨어져 있게 합니다. 플랫폼에는 제한이 있습니다. 저는 그냥 수락하고 이동합니다.
타이머, 타이머 분해능, 효율적인 코드 개발
Windows 타이머 해상도: 메가와트 낭비흥미로운 링크 덕분 에 Windows용 Microsecond Resolution Time Services로 이끌었습니다. 해당 페이지의 정보를 기반으로 몇 가지 테스트를 수행했습니다.
Win 7 PC 및 Windows 2012 VPS에 대한 테스트에 따르면 GetTickCount()는 시스템 타이머 설정에 관계없이 항상 15.6msecs(초당 64개의 인터럽트)의 해상도를 갖는 반면 kernel32.dll을 호출하여 밀리초 시간을 얻을 때의 해상도를 나타냅니다. 함수 GetSystemTime() [또는 GetLocalTime()] 또는 GetSystemTimeAsFileTime()은 시스템 타이머 설정의 영향을 받으며 테스트한 두 컴퓨터에서 모두 0.5msec의 해상도를 제공할 수 있습니다.
GetTickCount() 해상도
다음은 GetTickCount() 확인을 테스트하는 스크립트의 코드입니다.
이것은 다른 테스트에 대해 아래에 언급된 시스템 타이머 해상도 변경에 관계없이 테스트된 두 컴퓨터 모두에서 항상 15 또는 16(즉, 15.6)을 제공합니다.
GetSystemTime() 해상도
이제 상황이 흥미로워지기 시작합니다. 다음은 GetSystemTime() 확인을 테스트하는 스크립트의 코드입니다.
다른 소프트웨어를 실행하지 않고 새로 부팅한 PC에서는 15/16msec의 해상도를 제공하지만 PC에서 Chrome이 실행 중인 경우에는 1msec입니다! angevoyageur의 두 번째 링크는 Chrome이 다른 소프트웨어와 마찬가지로 시스템 타이머를 1msec 해상도로 설정한다고 설명합니다.
시스템 타이머 해상도를 설정하기 위한 두 개의 작은 유틸리티를 찾았습니다. 따라서 클린 부팅된 시스템에서 제어된 방식으로 1msec(또는 0.5msec) 해상도를 얻을 수 있습니다.
Windows 시스템 타이머 도구: http://vvvv.org/contribution/windows-system-timer-tool
타이머 해상도: http://www.lucashale.com/timer-resolution/
나는 두 가지 중 첫 번째 것인 Windows System Timer Tool을 선호합니다. 이를 통해 GetSystemTime()을 통해 1msec 해상도를 안정적으로 얻을 수 있습니다. GetLocalTime()도 유사하게 사용할 수 있습니다.
Btw 위의 스크립트 코드는 구조체 덕분에 새로운 MT4 코드가 얼마나 더 나은지 보여주는 예입니다. GetSystemTime()에 액세스하는 이전 MT4에서는 정수 배열과 많은 지저분한 비트 조작을 사용해야 했습니다.
GetSystemTimeAsFileTime() 해상도
마지막으로 Windows용 Microsecond Resolution Time Services에서 GetSystemTimeAsFileTime()이 시스템 시간에 액세스하는 더 빠른 함수이며 더 작고 단순한 구조체가 필요하다고 언급했습니다. 후자는 "구조체"가 단지 ulong으로 축소될 수 있기 때문에 새로운 MT4에 대해 확실히 사실입니다.
다음은 GetSystemTimeAsFileTiime() 확인을 테스트하는 스크립트의 코드입니다.
Windows 시스템 타이머 도구를 사용하여 시스템 타이머 해상도를 0.5초로 설정하는 경우 이 작은 스크립트는 5000(또는 때때로 5001) 100nsec 단위 = 0.5msec의 해상도를 보고합니다.
GetSystemTimeAsFileTiime() 사용은 실제로 더 간단하고 더 미세한 해상도를 표시할 수 있습니다.
다음은 사용 중인 이 사진의 일부입니다.
클린 부팅 후:
타이머 도구를 사용하여 시스템 타이머 해상도를 1ms로 설정:
시스템 타이머 해상도를 0.5ms로 설정하는 데 사용되는 타이머 도구:
결론MT4에서 밀리초 타이밍을 얻기 위해 사용하는 가장 좋은 함수는 위의 테스트 스크립트에 표시된 것처럼 GetSystemTimeAsFileTiime()을 호출하는 것이며, 원하는 시스템 타이머 해상도를 설정하는 데 사용되는 Windows 시스템 타이머 도구와 같은 유틸리티를 사용합니다.