따라서 모든 것이 느려지는 것은 아닙니다. 따라서 나는 매우 무해하게 winmm::timeBeginPeriod(1)+winmm::timeGetTime()으로 전환할 수 있었고 GetTickCount와 같은 속도를 얻었지만 끔찍한 16ms 제한이 없었습니다. 그러나 이러한 경로는 Market 제품에 대해 주문되기 때문입니다. DLL. 밀리초 일반 버전을 만들 가능성은 거의 없습니다.
따라서 모든 것이 느려지는 것은 아닙니다. 따라서 나는 매우 무해하게 winmm::timeBeginPeriod(1)+winmm::timeGetTime()으로 전환할 수 있었고 GetTickCount와 같은 속도를 얻었지만 끔찍한 16ms 제한이 없었습니다. 그러나 이러한 경로는 Market 제품에 대해 주문되기 때문입니다. DLL. 밀리초 일반 버전을 만들 가능성은 거의 없습니다.
글쎄, 당신은 상관 관계와 합리성을 통제하지 않고 스트레스 테스트를 실행하는 데 마스터입니다.
물론 마이크로초 측정에는 밀리초보다 1000배 적은 간격을 측정할 수 있는 리소스가 필요합니다.
주기적으로 간격을 정확하게 측정해야 하는 경우 마이크로초를 사용하십시오. 그리고 비용은 0마이크로초입니다.
수백만 번 자기 측정을 하기로 결정했다면 자기기만에 빠졌을 가능성이 큽니다.
교살된 VPS에서 timeBeginPeriod를 통해 시스템 타이머를 오버클러킹하는 것은 어렵습니다. CPU 비용을 증가시키기만 하면 됩니다.
이 기능은 전역 Windows 설정에 영향을 줍니다. Windows는 모든 프로세스에서 요청한 가장 낮은 값(즉, 가장 높은 해상도)을 사용합니다. 더 높은 해상도를 설정하면 대기 기능에서 시간 초과 간격의 정확도가 향상될 수 있습니다. 그러나 스레드 스케줄러가 작업을 더 자주 전환하기 때문에 전체 시스템 성능을 저하시킬 수도 있습니다. 고해상도는 또한 CPU 전원 관리 시스템이 절전 모드로 들어가는 것을 방지할 수 있습니다. 더 높은 해상도를 설정해도 고해상도 성능 카운터의 정확도는 향상되지 않습니다.
그렇지 않았다면 그들은 오래전에 운영체제에서 정확한 GetTickCount/GetTickCount64를 만들고 자유로운 정확도에 기뻐했을 것입니다. 그러나 아니요, 이 타이머의 정확성에 대한 비용을 지불해야 합니다.
터미널이 CPU를 100% 로드하여 아무 반응도 하지 않는 상황을 반복적으로 보았습니다.
그런 다음 로그를 보고 OnTick에 거친 틱 건너뛰기가 있음을 확인했습니다. 그러나 Expert Advisor를 올바르게 작성하면 그러한 끔찍한 상황이 거래 결과에 영향을 미치지 않는 것이 현실적입니다. 특별히 분석한 결과 모든 것이 명확합니다.
Market 제품의 지연을 처리하는 일반적인 메커니즘이 어떻게 되는지 궁금합니다. 나는 발사 기계의 힘에 대해 말하는 사람을 본 적이 없습니다. 최소 핑은 예입니다.
그들을 어디로 들여보냈습니까?
2-5달러 에 VPS 를 사용하는 경우 다소 심각한 WinAPI 기능에서 수십 및 수백 밀리초의 지연이 쉽게 발생합니다. 하이퍼바이저 수준에서 모든 것을 느리게 하여 가상 머신을 슬라이드 쇼로 전환합니다.
위에서 설명을 드렸습니다.
이것은 GetMicrosecondsCount 속도를 늦추지 않지만 운영 체제는 교살된 vpsky의 스레드에 대한 CPU 리소스를 양자화합니다. 모든 기능, 모든 작업, VPS 내의 모든 프로그램.
글쎄, 어떤 CPU 스케줄러도 각 복사본에 1500개의 실행 스레드가 있는 20개의(여전히 신성한) 운영 체제가 있을 때 리소스를 정직하게 자르고 배포할 수 없습니다. 8-16개의 코어를 20 * 1,500 = 30,000(물리적 스레드 3만 개)으로 나눕니다.
내 경우(win7 + 2 코어 + 자체 하드웨어에 16GB RAM이 있는 가상 상자, 다른 것은 회전하지 않음), 주기적인 2-3ms는 어디에서 왔습니까?
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
MT5와 속도
Andrey Khatimliansky , 2020.10.05 10:19
정확히 VPS는 아니지만 대여한 철판의 가상 머신:
내 경우(win7 + 2 코어 + 자체 하드웨어에 16GB RAM이 있는 가상 상자, 다른 것은 회전하지 않음), 주기적인 2-3ms는 어디에서 왔습니까?
이것이 이중 가상화의 가격입니다.
또한 VirtualBox는 본격적인 Hyper-V 유형 하이퍼바이저가 아니라 현재 데스크톱 운영 체제(Windows 7도?) 위에 있으며 CPU 스케줄러가 다른 사용 사례에 맞게 조정됩니다.
즉, Windows 7/10 -> VirtualBox -> Windows 7이 있습니다. 사실 가상화의 두 가지 수준과 첫 번째는 VirtualBox의 열망을 알지 못하는 일반 프로그램으로 간주됩니다. CPU 자원 할당(스레드 스케줄러)은 분명히 지옥입니다.
Hyper-V 2016/2019 -> Windows 2016/2019여야 합니다.
이것은 GetMicrosecondsCount 속도를 늦추지 않지만 운영 체제는 교살된 vpsky의 스레드에 대한 CPU 리소스를 양자화합니다. 모든 기능, 모든 작업, VPS 내의 모든 프로그램.
나는 이 주장이 당신을 생각하게 할 것이라고 생각합니다. 조언자.
따라서 모든 것이 느려지는 것은 아닙니다. 따라서 나는 매우 무해하게 winmm::timeBeginPeriod(1)+winmm::timeGetTime()으로 전환할 수 있었고 GetTickCount와 같은 속도를 얻었지만 끔찍한 16ms 제한이 없었습니다. 그러나 이러한 경로는 Market 제품에 대해 주문되기 때문입니다. DLL. 밀리초 일반 버전을 만들 가능성은 거의 없습니다.
모든 창과 애플리케이션 자체를 최소화하는 MQL5 기능은 좋은 아이디어입니다. 해결해 봅시다.
여기 또 다른 것이 있습니다.
VPS에서 스스로 터미널을 시작하면 여기에서 모든 것이 갑자기 줄어들 것이라는 사실에 강력하게 반대합니다. RDP 세션에서 나가면 그 자신이 창을 최소화할 수 있고 최소화해야 합니다.
여기 내가 말하고 싶은 것의 예가 있습니다.
서로 다른 브로커의 두 서버는 같은 영역에 있으며 같은 위치에 있을 수 있습니다.
영국에서 호스팅되는 AMP용 서비스 맵 제공
그리고 Just의 경우 어떤 이유로 그는 NL에서 제안합니다.
왜요? VPS가 더 가깝다면.
나는 이 주장이 당신을 생각하게 할 것이라고 생각합니다. 조언자.
따라서 모든 것이 느려지는 것은 아닙니다. 따라서 나는 매우 무해하게 winmm::timeBeginPeriod(1)+winmm::timeGetTime()으로 전환할 수 있었고 GetTickCount와 같은 속도를 얻었지만 끔찍한 16ms 제한이 없었습니다. 그러나 이러한 경로는 Market 제품에 대해 주문되기 때문입니다. DLL. 밀리초 일반 버전을 만들 가능성은 거의 없습니다.
글쎄, 당신은 상관 관계와 합리성을 통제하지 않고 스트레스 테스트를 실행하는 데 마스터입니다.
물론 마이크로초 측정에는 밀리초보다 1000배 적은 간격을 측정할 수 있는 리소스가 필요합니다.
주기적으로 간격을 정확하게 측정해야 하는 경우 마이크로초를 사용하십시오. 그리고 비용은 0마이크로초입니다.
수백만 번 자기 측정을 하기로 결정했다면 자기기만에 빠졌을 가능성이 큽니다.
교살된 VPS에서 timeBeginPeriod를 통해 시스템 타이머를 오버클러킹하는 것은 어렵습니다. CPU 비용을 증가시키기만 하면 됩니다.
그렇지 않았다면 그들은 오래전에 운영체제에서 정확한 GetTickCount/GetTickCount64를 만들고 자유로운 정확도에 기뻐했을 것입니다. 그러나 아니요, 이 타이머의 정확성에 대한 비용을 지불해야 합니다.
여기 내가 말하고 싶은 것의 예가 있습니다.
서로 다른 브로커의 두 서버는 같은 영역에 있으며 같은 위치에 있을 수 있습니다.
영국에서 호스팅되는 AMP용 서비스 맵 제공
그리고 Just의 경우 어떤 이유로 그는 NL에서 제안합니다.
왜요? VPS가 더 가깝다면.
우리는 우리 서버의 지리적 위치를 알고 있지만 GeoIP 데이터베이스에서 중개 서버의 위치를 구축합니다.
그리고 정보가 사실이 아닌 경우가 종종 있습니다. 따라서 어떠한 경우에도 브로커의 포인트가 정확하게 표시된다고 가정할 수 없습니다.
내일 우리는 질문에 답하기 위해 모든 것을 수동으로 다시 확인하고 다시 스캔해야 하기 때문에 더 자세히 이해할 것입니다.
이것이 이중 가상화의 가격입니다.
또한 VirtualBox는 본격적인 Hyper-V 유형 하이퍼바이저가 아니라 현재 데스크톱 운영 체제(Windows 7도?) 위에 있으며 CPU 스케줄러가 다른 사용 사례에 맞게 조정됩니다.
즉, Windows 7/10 -> VirtualBox -> Windows 7이 있습니다. 사실 가상화의 두 가지 수준과 첫 번째는 VirtualBox의 열망을 알지 못하는 일반 프로그램으로 간주됩니다. CPU 자원 할당(스레드 스케줄러)은 분명히 지옥입니다.
Hyper-V 2016/2019 -> Windows 2016/2019여야 합니다.
아니요, CentOS에서 회전하는 가상 머신이 있습니다. 그러나 나는 이 대화를 계속할 자격이 없습니다.