Indicator1과 Indicator2는 하나의 공통 라인에 두 숫자를 모두 쓸 수 있도록 어떻게든 동기화해야 합니다.
매우 어려운 결정이 될 것입니다.
왜 동기화해야 합니까? user32.dll이 이를 대신합니다. 그들에게 가장 중요한 것은 각각 고유한 번호를 가지며 이 번호가 데이터 배열의 인덱스가 되도록 올바르게 번호를 매기는 것입니다. 이것은 최후의 수단으로 수동으로 수행할 수 있습니다. 그리고 아마도 자동. 그건 그렇고, 나는 최근에 KB( Indicator Сopies )에서 비슷한 것을 하나의 창에 대해 게시했지만 전체 터미널에 대해 다시 만드는 것은 어렵지 않습니다. 자원에 대해 좋아하지 않는 것은 무엇입니까? 제 생각에는 한 터미널의 경계 내에서 최적입니다. 제가 user32.dll을 통해 제안한 버전(저는 10년 전 이 옵션을 구현했습니다. 제가 어렸을 때 중재에 손을 댔을 때)에서 액세스 및 데이터 파싱 시간은 약 50마이크로초입니다(속도를 1.5초 정도 높일 수 있다고 생각합니다. -2 배). 리소스를 더 천천히 사용하시겠습니까?
자원에 대해 좋아하지 않는 것은 무엇입니까? 제 생각에는 한 터미널의 경계 내에서 최적입니다. 제가 user32.dll을 통해 제안한 버전(저는 10년 전 이 옵션을 구현했습니다. 제가 어렸을 때 중재에 손을 댔을 때)에서 액세스 및 데이터 파싱 시간은 약 50마이크로초입니다(속도를 1.5초 정도 높일 수 있다고 생각합니다. -2 배). 리소스를 더 천천히 사용하시겠습니까?
이상적인 조건에서 가정용 기기에서 읽는 데 100마이크로초가 걸립니다. 한 번의 틱에 대한 전문가 고문은 읽기를 백 번 트리거할 수 있습니다. 천천히 나옵니다.
이상적인 조건에서 GlobalVariableGet 은 10 µs 내에 완료됩니다. 그러나 이것은 지표가 아닙니다. 왜냐하면 나에게 새로운 전투 조건에서 이것은 끔찍한 브레이크입니다.
[USDCHF]: 22784 of 22833 ( 99.8 %) ticks were processed ( 0.14 ms delay in average), 49 ( 0.2 %) ticks were skipped ( 103.4 ms delay in average)
[EURUSD]: 22944 of 22974 ( 99.9 %) ticks were processed ( 0.16 ms delay in average), 30 ( 0.1 %) ticks were skipped ( 115.6 ms delay in average)
[USDCAD]: 15331 of 15347 ( 99.9 %) ticks were processed ( 0.13 ms delay in average), 16 ( 0.1 %) ticks were skipped ( 104.6 ms delay in average)
[EURCHF]: 22516 of 22571 ( 99.8 %) ticks were processed ( 0.13 ms delay in average), 55 ( 0.2 %) ticks were skipped ( 127.8 ms delay in average)
[EURAUD]: 66842 of 66924 ( 99.9 %) ticks were processed ( 0.13 ms delay in average), 82 ( 0.1 %) ticks were skipped ( 117.8 ms delay in average)
[GBPUSD]: 41393 of 41393 ( 100.0 %) ticks were processed ( 0.00 ms delay in average)
Total trade requests time: 4.280 sec
Expert Advisor는 GBPUSD에 있었기 때문에 기본 OnTick이 작업했습니다.
"표시기가 너무 느림" 오류가 없었습니다.
그러나 MQ 의 VPS 에서는 놓친 틱의 비율과 평균 지연이 훨씬 더 높습니다(통계는 조금 후에 게시하겠습니다). 그리고 "지표가 너무 느림" 오류가 많이 있습니다.
EA가 누적된 이벤트를 즉시 처리하기 때문에(그냥 반환됨) 대기열 오버플로의 특성이 명확하지 않습니다. 다른 사람이 작업 중입니까?
EventChartCustom 에서 저를 위해 작동합니다. 99.8%의 틱이 0.15ms 이내에 도착합니다.
다음을 통해 표시기에서 틱을 보냅니다. sparam에는 MqlTick, lparam - 틱 번호가 포함되어 있습니다.
OnChartEvent 의 Expert Advisor는 이러한 틱을 포착합니다. 그리고 그는 지금 잡은 진드기가 가장 관련성이 있는지 여부를 이해해야합니까? 저것들. 틱 대기열이 있거나 비어 있습니까?
이를 위해 지표에서 보낸 가장 최근 틱의 번호(작업은 이 번호를 읽는 것)를 읽습니다. 잡힌 틱의 번호가 같으면 대기열이 비어 있고 여러 틱이 작동할 수 있습니다.
음, OnTick 작업 과정에서 브레이크 OrderSend 후 표시기가 더 많은 틱을 보내지 않았는지 확인해야 합니다. 이렇게하려면 표시기에서 숫자를 다시 읽어야합니다. 그리고 하나의 OnTick 실행에 대해 수백 개의 이러한 검사가 있을 수 있습니다. 그렇기 때문에 빨리 읽어야 합니다.
이를 위해 지표에서 보낸 가장 최근 틱의 번호(작업은 이 번호를 읽는 것)를 읽습니다. 잡힌 틱의 번호가 같으면 대기열이 비어 있고 여러 틱이 작동할 수 있습니다.
음, OnTick 작업 과정에서 브레이크 OrderSend 후 표시기가 더 많은 틱을 보내지 않았는지 확인해야 합니다. 이렇게하려면 표시기에서 숫자를 다시 읽어야합니다. 그리고 하나의 OnTick 실행에 대해 수백 개의 이러한 검사가 있을 수 있습니다. 그렇기 때문에 빨리 읽어야 합니다.
초기화.
1. 1 스레드(대부분 쓰기)에서 원하는 크기의 변수에 대해 어떤 식으로든 메모리를 할당합니다.
2. 이 메모리의 주소를 필요한 스레드(리더)로 보냅니다.
본업.
3. 쓰기 스레드는 쓸 변수의 차원에 따라 InterlockedExchange 또는 InterlockedExchange64를 가져옵니다.
4. 읽기 흐름은 읽기를 위해 예를 들어 InterlockedCompareExchange를 가져옵니다.
완성.
5. 할당된 메모리 를 해제합니다. 가급적이면 메모리를 할당한 동일한 스레드에서 해제합니다.
필요한 경우 여러 카운터를 설정하기 위해 반복할 수 있습니다. 단점 중 WinAPI 연결이 필요합니다. 기능 중 할당된 메모리의 주소를 정렬해야 하지만 기본적으로는 이 경우가 일반적입니다.
1 프로세스 내에서 작동하며 메모리는 1 프로세스의 스레드에서 공유됩니다. 필요한 경우 InterlockedDecrement, InterlockedAdd 등과 같은 다른 연동 기능이 있습니다.
기능은 차단되지 않고 아무 것도 기다리지 않으며 자율적이며 여러 asm 명령에서 실행됩니다.
PS 일반적으로 내가 기억하는 한 어셈블러에서 mov를 통한 일반적인 읽기 및 쓰기 작업은 이미 원자적입니다. 그리고 컴파일러가 정원을 차단하지 않는다면(이론적으로는 그렇게 해서는 안 됨) 할당된 메모리에 있는 변수를 어리석게 읽고 쓰려고 할 수 있으며 이는 원자성이 될 것입니다.
작업의 조건에 맞으면 1프로세스 내에서 더 빨리 할 수 있을 것 같지는 않다. Interprocess의 경우 가장 빠른 것이 비슷하지만 공유 메모리의 경우 이 경우 WinAPI가 필수적입니다.
왜 작동하지 않습니까? 그냥 과제 아래에있는 것 같습니다. 세터 게터 원리. 함수를 통해 숨겨진 변수의 값을 가져옵니다. 구조를 MqlTick에 전달하는 경우 MqlTick과 같은 필드 세트로 구조를 정의하고 카운터 필드를 구조에 추가하십시오. 내보내기 함수에서 이 구조를 반환합니다. 표시기의 기본 예입니다. 예제가 스크립트에 제공된다는 사실에주의를 기울이지 마십시오.
Структура для получения текущих цен - Структуры данных - Константы, перечисления и структуры - Справочник MQL5 - Справочник по языку алгоритмического/автоматического трейдинга для MetaTrader 5
Indicator1과 Indicator2는 하나의 공통 라인에 두 숫자를 모두 쓸 수 있도록 어떻게든 동기화해야 합니다.
매우 어려운 결정이 될 것입니다.
왜 동기화해야 합니까? user32.dll이 이를 대신합니다.
그들에게 가장 중요한 것은 각각 고유한 번호를 가지며 이 번호가 데이터 배열의 인덱스가 되도록 올바르게 번호를 매기는 것입니다.
이것은 최후의 수단으로 수동으로 수행할 수 있습니다. 그리고 아마도 자동. 그건 그렇고, 나는 최근에 KB( Indicator Сopies )에서 비슷한 것을 하나의 창에 대해 게시했지만 전체 터미널에 대해 다시 만드는 것은 어렵지 않습니다.
자원에 대해 좋아하지 않는 것은 무엇입니까? 제 생각에는 한 터미널의 경계 내에서 최적입니다. 제가 user32.dll을 통해 제안한 버전(저는 10년 전 이 옵션을 구현했습니다. 제가 어렸을 때 중재에 손을 댔을 때)에서 액세스 및 데이터 파싱 시간은 약 50마이크로초입니다(속도를 1.5초 정도 높일 수 있다고 생각합니다. -2 배). 리소스를 더 천천히 사용하시겠습니까?
왜 동기화해야 합니까? user32.dll이 그들을 대신할 것입니다.
쓰기를 시도합니다. 아마도 당신은 문제를 완전히 이해하지 못했을 것입니다.
자원에 대해 좋아하지 않는 것은 무엇입니까? 제 생각에는 한 터미널의 경계 내에서 최적입니다. 제가 user32.dll을 통해 제안한 버전(저는 10년 전 이 옵션을 구현했습니다. 제가 어렸을 때 중재에 손을 댔을 때)에서 액세스 및 데이터 파싱 시간은 약 50마이크로초입니다(속도를 1.5초 정도 높일 수 있다고 생각합니다. -2 배). 리소스를 더 천천히 사용하시겠습니까?
이상적인 조건에서 가정용 기기에서 읽는 데 100마이크로초가 걸립니다. 한 번의 틱에 대한 전문가 고문은 읽기를 백 번 트리거할 수 있습니다. 천천히 나옵니다.
이상적인 조건에서 GlobalVariableGet 은 10 µs 내에 완료됩니다. 그러나 이것은 지표가 아닙니다. 왜냐하면 나에게 새로운 전투 조건에서 이것은 끔찍한 브레이크입니다.
이것은 HistoryTicks입니다 - Expert Advisors의 모든 진드기를 잡습니다. 따라서 EventChartCustom이 적합하지 않으며 대기열이 있습니다. 버퍼와 동일합니다.
EventChartCustom에서 저를 위해 작동합니다. 99.8%의 틱이 0.15ms 이내에 도착합니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
EventChartCustom => 표시기가 너무 느림
Andrey Khatimliansky , 2019.12.12 09:27
다음은 5가지 도구에 대한 9시간의 작업에 대한 통계입니다.
Expert Advisor는 GBPUSD에 있었기 때문에 기본 OnTick이 작업했습니다.
"표시기가 너무 느림" 오류가 없었습니다.
그러나 MQ 의 VPS 에서는 놓친 틱의 비율과 평균 지연이 훨씬 더 높습니다(통계는 조금 후에 게시하겠습니다).
그리고 "지표가 너무 느림" 오류가 많이 있습니다.
EA가 누적된 이벤트를 즉시 처리하기 때문에(그냥 반환됨) 대기열 오버플로의 특성이 명확하지 않습니다.
다른 사람이 작업 중입니까?
EventChartCustom 에서 저를 위해 작동합니다. 99.8%의 틱이 0.15ms 이내에 도착합니다.
다음을 통해 표시기에서 틱을 보냅니다. sparam에는 MqlTick, lparam - 틱 번호가 포함되어 있습니다.
OnChartEvent 의 Expert Advisor는 이러한 틱을 포착합니다. 그리고 그는 지금 잡은 진드기가 가장 관련성이 있는지 여부를 이해해야합니까? 저것들. 틱 대기열이 있거나 비어 있습니까?
이를 위해 지표에서 보낸 가장 최근 틱의 번호(작업은 이 번호를 읽는 것)를 읽습니다. 잡힌 틱의 번호가 같으면 대기열이 비어 있고 여러 틱이 작동할 수 있습니다.
음, OnTick 작업 과정에서 브레이크 OrderSend 후 표시기가 더 많은 틱을 보내지 않았는지 확인해야 합니다. 이렇게하려면 표시기에서 숫자를 다시 읽어야합니다. 그리고 하나의 OnTick 실행에 대해 수백 개의 이러한 검사가 있을 수 있습니다. 그렇기 때문에 빨리 읽어야 합니다.
1 터미널 내에서 winpipe에서 가장 빠른 것은 메모리 할당 (프로세스 내 전역)이며 https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-와 같은 연동 기능을 통해 작동합니다. 연동 교환
그것들은 비차단적이고 원자적이며 본질적으로 몇 가지 asm 명령에서 실행됩니다.
1 터미널 내에서 winpipe에서 가장 빠른 것은 메모리 할당 (프로세스 내 전역)이며 https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-와 같은 연동 기능을 통해 작동합니다. 연동 교환
그것들은 비차단적이고 원자적이며 본질적으로 몇 가지 asm 명령에서 실행됩니다.
나는 예가 없으면하지 않을 것입니다.
이를 위해 지표에서 보낸 가장 최근 틱의 번호(작업은 이 번호를 읽는 것)를 읽습니다. 잡힌 틱의 번호가 같으면 대기열이 비어 있고 여러 틱이 작동할 수 있습니다.
음, OnTick 작업 과정에서 브레이크 OrderSend 후 표시기가 더 많은 틱을 보내지 않았는지 확인해야 합니다. 이렇게하려면 표시기에서 숫자를 다시 읽어야합니다. 그리고 하나의 OnTick 실행에 대해 수백 개의 이러한 검사가 있을 수 있습니다. 그렇기 때문에 빨리 읽어야 합니다.
초기화.
1. 1 스레드(대부분 쓰기)에서 원하는 크기의 변수에 대해 어떤 식으로든 메모리를 할당합니다.
2. 이 메모리의 주소를 필요한 스레드(리더)로 보냅니다.
본업.
3. 쓰기 스레드는 쓸 변수의 차원에 따라 InterlockedExchange 또는 InterlockedExchange64를 가져옵니다.
4. 읽기 흐름은 읽기를 위해 예를 들어 InterlockedCompareExchange를 가져옵니다.
완성.
5. 할당된 메모리 를 해제합니다. 가급적이면 메모리를 할당한 동일한 스레드에서 해제합니다.
필요한 경우 여러 카운터를 설정하기 위해 반복할 수 있습니다. 단점 중 WinAPI 연결이 필요합니다. 기능 중 할당된 메모리의 주소를 정렬해야 하지만 기본적으로는 이 경우가 일반적입니다.
1 프로세스 내에서 작동하며 메모리는 1 프로세스의 스레드에서 공유됩니다. 필요한 경우 InterlockedDecrement, InterlockedAdd 등과 같은 다른 연동 기능이 있습니다.
기능은 차단되지 않고 아무 것도 기다리지 않으며 자율적이며 여러 asm 명령에서 실행됩니다.
PS 일반적으로 내가 기억하는 한 어셈블러에서 mov를 통한 일반적인 읽기 및 쓰기 작업은 이미 원자적입니다. 그리고 컴파일러가 정원을 차단하지 않는다면(이론적으로는 그렇게 해서는 안 됨) 할당된 메모리에 있는 변수를 어리석게 읽고 쓰려고 할 수 있으며 이는 원자성이 될 것입니다.
작업의 조건에 맞으면 1프로세스 내에서 더 빨리 할 수 있을 것 같지는 않다. Interprocess의 경우 가장 빠른 것이 비슷하지만 공유 메모리의 경우 이 경우 WinAPI가 필수적입니다.
이 계획은 작동하지 않는 것 같습니다. 기본적인 예를 보여주세요.
왜 작동하지 않습니까? 그냥 과제 아래에있는 것 같습니다. 세터 게터 원리.
함수를 통해 숨겨진 변수의 값을 가져옵니다.
구조를 MqlTick에 전달하는 경우 MqlTick과 같은 필드 세트로 구조를 정의하고 카운터 필드를 구조에 추가하십시오.
내보내기 함수에서 이 구조를 반환합니다.
표시기의 기본 예입니다. 예제가 스크립트에 제공된다는 사실에주의를 기울이지 마십시오.
Expert Advisor에서 GetTickStruct를 호출하면 자체 카운터가 있는 전체 구조를 얻을 수 있습니다.
Expert Advisor에서 GetTickStruct를 호출하면 자체 카운터가 있는 전체 구조를 얻을 수 있습니다.
표시기에서 고문에게 숫자의 기본 전송을 작성하십시오.
표시기에서 고문에게 숫자의 기본 전송을 작성하십시오.
구조체를 하나의 변수로 교체))