엔진은 모든 Expert Advisors에 대해 작은 주소 문자열을 노출합니다. 동일한 인식 주소를 가진 EA의 코어가 리콜되고 엔진-EA의 표준 작업이 자동으로 시작됩니다. 엔진에서 다른 Expert Advisor로 전환할 때 엔진은 그 당시 다른 Expert Advisor와 마찬가지로 주소를 기다리는 상태로 작업하고 있던 Expert Advisor의 코어를 놓습니다. 그러한 순간에 모든 어드바이저는 후크 해제되고 엔진이 엔진이 필요로 하는 다른 어드바이저에 대해 다른 주소를 설정하기를 기다리고 있습니다.
새로운 Expert Advisor의 핵심은 응답하고 표준 작동 상태로 들어갑니다. 다음 메시지까지 엔진의 작업이 끝나고 대기 상태로 전환됩니다. 표준 교환 외에도 Expert Advisors는 스트림에서 작업 종료 라인의 모양에 대해 스트림을 지속적으로 분석해야 합니다. 교환 패킷의 시작 부분에는 엔진에서 전송된 패킷의 주소를 지정하는 행이 있어야 합니다. 그런 다음 코어는 제어 패킷을 수신하고 주어진 주파수에서 해당 상태의 패킷을 보내기 시작합니다.
나머지는 각 어드바이저에 대한 고유한 식별 문자열을 통해 연락을 기다리고 있습니다. 전환할 때 엔진은 작업 종료 문자열을 현재 EA로 보냅니다. EA는 아무 것도 보내지 않고 자체 인식 문자열을 인식하는 상태로 들어가게 됨과 동시에 엔진과의 거래소 표준 동작을 시작합니다.
엔진은 모든 Expert Advisors에 대해 작은 주소 문자열을 노출합니다. 동일한 인식 주소를 가진 EA의 코어가 리콜되고 엔진-EA의 표준 작업이 자동으로 시작됩니다. 엔진에서 다른 Expert Advisor로 전환할 때 엔진은 그 당시 다른 Expert Advisor와 마찬가지로 주소를 기다리는 상태로 작업하고 있던 Expert Advisor의 코어를 놓습니다. 그러한 순간에 모든 어드바이저는 후크 해제되고 엔진이 엔진이 필요로 하는 다른 어드바이저에 대해 다른 주소를 설정하기를 기다리고 있습니다.
새로운 Expert Advisor의 핵심은 응답하고 표준 작동 상태로 들어갑니다. 다음 메시지까지 엔진의 작업이 끝나고 대기 상태로 전환됩니다. 표준 교환 외에도 Expert Advisors는 스트림에서 작업 종료 라인의 모양에 대해 스트림을 지속적으로 분석해야 합니다. 교환 패킷의 시작 부분에는 엔진에서 전송된 패킷의 주소를 지정하는 행이 있어야 합니다. 그런 다음 코어는 제어 패킷을 수신하고 주어진 주파수에서 해당 상태의 패킷을 보내기 시작합니다.
나머지는 각 어드바이저에 대한 고유한 식별 문자열을 통해 연락을 기다리고 있습니다. 전환할 때 엔진은 작업 종료 문자열을 현재 EA로 보냅니다. EA는 아무 것도 보내지 않고 자체 인식 문자열을 인식하는 상태로 들어가게 됨과 동시에 엔진과의 거래소 표준 동작을 시작합니다.
리소스는 다소 쉽습니다. 거기에는 주소가 필요 없고 리소스 이름만 있으면 됩니다. 당신은 복잡한 모델을 가지고 있습니다. 모든 것이 더 쉽습니다.
커널은 값의 배열일 뿐입니다. 각 Expert Advisor는 GUI 요소의 매개 변수 값을 기록합니다. 필요한 경우 EA는 매개변수 커널의 복사본을 리소스에 저장하고 엔진은 이를 읽고 GUI를 다시 그립니다.
원칙적으로 이것은 간단한 작업이지만 많은 작은 뉘앙스가 있습니다. 예를 들어, 고문과의 통신 시작 및 종료에 대한 메시지입니다. 형식을 생각해 내기만 하면 됩니다.
그건 그렇고, 나는 통신 속도를 높이고 제동을 줄였습니다. 그러나 브레이크가 끝날 때까지 이유는 아직 이해되지 않았습니다. 다시 그릴 때 나타나는데 이상한 점은 다시 그리기 자체가 느려지지 않는다는 것입니다. 그리고 리소스를 통해 통신할 때 다시 그리기 속도가 느려집니다. 그 이유는 아직 명확하지 않습니다.
Oleg Papkov : 모니터링이 있습니까? 어떤 작업이 얼마나 오래 걸리나요? 순차적으로 수행해야 합니다. 어드바이저에서 데이터 제거 및 엔진으로의 전송은 예를 들어 30ms의 빈도로 수행됩니다. 스트림이 엔진으로 전송되면 수락할 준비가 되었습니까? 아니면 그는 무엇을합니까?
나는 지금 모든 것을 확인하고 있다.
30ms 주기의 Engine은 Expert Advisor의 메시지 리소스를 읽고, 동일한 주기의 Expert Advisor는 Engine의 메시지 리소스를 읽습니다. 동일한 주파수에서 둘 다 서로에게 메시지를 녹음합니다(녹음할 것이 있는 경우). 이 모든 것이 느려지지 않습니다. 또한 다시 그리기 자체로 지연이 발생하지 않습니다.
단, 엔진측 리소스의 다시 그리기와 쓰기/읽기를 병행하면 랙이 발생합니다. 이유는 아직 불명. 나는 알아.
30ms 주기의 Engine은 Expert Advisor의 메시지 리소스를 읽고, 동일한 주기의 Expert Advisor는 Engine의 메시지 리소스를 읽습니다. 동일한 주파수에서 둘 다 서로에게 메시지를 녹음합니다(녹음할 것이 있는 경우). 이 모든 것이 느려지지 않습니다. 또한 다시 그리기 자체로 지연이 발생하지 않습니다.
단, 엔진측 리소스의 다시 그리기와 쓰기/읽기를 병행하면 랙이 발생합니다. 이유는 아직 불명. 나는 알아.
불일치가 있을 수 있습니다. 어드바이저와 엔진 모두 1- 둘 다 서로에게 전송하고 2 - 둘 다 수신하고 OnTimer 주기가 동기화되지 않습니다. 정상 작동의 임의 동기화 순간을 기다립니다. 아마도 이것 때문에?
일반적으로 작업은 거의 정의됩니다.
예를 들어, 5명의 고문이 엔진이 6번째 패키지와 함께 작동하면 전체 작업 패키지를 전송한다는 사실이 혼란스럽습니다. 나머지 5명은 업무 정보를 전송하는 것을 잠시 금지할 필요가 있다. 그들이 "공기에 귀를 기울이게" 하십시오.
동의한다. 합리적입니다.
즉, 정상적으로 작동하지만 리소스에 메시지를 쓰지는 않습니다. 커널 매개변수의 복사본에만 있습니다. 그리고 연결되면 매개변수 코어를 리소스에 쓰고 엔진이 이를 로드합니다. 연결되면 EA는 엔진에 대한 메시지를 메시지 리소스에 쓰기 시작합니다.
연결 문제.
엔진은 모든 Expert Advisors에 대해 작은 주소 문자열을 노출합니다. 동일한 인식 주소를 가진 EA의 코어가 리콜되고 엔진-EA의 표준 작업이 자동으로 시작됩니다. 엔진에서 다른 Expert Advisor로 전환할 때 엔진은 그 당시 다른 Expert Advisor와 마찬가지로 주소를 기다리는 상태로 작업하고 있던 Expert Advisor의 코어를 놓습니다. 그러한 순간에 모든 어드바이저는 후크 해제되고 엔진이 엔진이 필요로 하는 다른 어드바이저에 대해 다른 주소를 설정하기를 기다리고 있습니다.
새로운 Expert Advisor의 핵심은 응답하고 표준 작동 상태로 들어갑니다. 다음 메시지까지 엔진의 작업이 끝나고 대기 상태로 전환됩니다. 표준 교환 외에도 Expert Advisors는 스트림에서 작업 종료 라인의 모양에 대해 스트림을 지속적으로 분석해야 합니다. 교환 패킷의 시작 부분에는 엔진에서 전송된 패킷의 주소를 지정하는 행이 있어야 합니다. 그런 다음 코어는 제어 패킷을 수신하고 주어진 주파수에서 해당 상태의 패킷을 보내기 시작합니다.
나머지는 각 어드바이저에 대한 고유한 식별 문자열을 통해 연락을 기다리고 있습니다. 전환할 때 엔진은 작업 종료 문자열을 현재 EA로 보냅니다. EA는 아무 것도 보내지 않고 자체 인식 문자열을 인식하는 상태로 들어가게 됨과 동시에 엔진과의 거래소 표준 동작을 시작합니다.
연결 문제.
엔진은 모든 Expert Advisors에 대해 작은 주소 문자열을 노출합니다. 동일한 인식 주소를 가진 EA의 코어가 리콜되고 엔진-EA의 표준 작업이 자동으로 시작됩니다. 엔진에서 다른 Expert Advisor로 전환할 때 엔진은 그 당시 다른 Expert Advisor와 마찬가지로 주소를 기다리는 상태로 작업하고 있던 Expert Advisor의 코어를 놓습니다. 그러한 순간에 모든 어드바이저는 후크 해제되고 엔진이 엔진이 필요로 하는 다른 어드바이저에 대해 다른 주소를 설정하기를 기다리고 있습니다.
새로운 Expert Advisor의 핵심은 응답하고 표준 작동 상태로 들어갑니다. 다음 메시지까지 엔진의 작업이 끝나고 대기 상태로 전환됩니다. 표준 교환 외에도 Expert Advisors는 스트림에서 작업 종료 라인의 모양에 대해 스트림을 지속적으로 분석해야 합니다. 교환 패킷의 시작 부분에는 엔진에서 전송된 패킷의 주소를 지정하는 행이 있어야 합니다. 그런 다음 코어는 제어 패킷을 수신하고 주어진 주파수에서 해당 상태의 패킷을 보내기 시작합니다.
나머지는 각 어드바이저에 대한 고유한 식별 문자열을 통해 연락을 기다리고 있습니다. 전환할 때 엔진은 작업 종료 문자열을 현재 EA로 보냅니다. EA는 아무 것도 보내지 않고 자체 인식 문자열을 인식하는 상태로 들어가게 됨과 동시에 엔진과의 거래소 표준 동작을 시작합니다.
리소스는 다소 쉽습니다. 거기에는 주소가 필요 없고 리소스 이름만 있으면 됩니다. 당신은 복잡한 모델을 가지고 있습니다. 모든 것이 더 쉽습니다.
커널은 값의 배열일 뿐입니다. 각 Expert Advisor는 GUI 요소의 매개 변수 값을 기록합니다. 필요한 경우 EA는 매개변수 커널의 복사본을 리소스에 저장하고 엔진은 이를 읽고 GUI를 다시 그립니다.
원칙적으로 이것은 간단한 작업이지만 많은 작은 뉘앙스가 있습니다. 예를 들어, 고문과의 통신 시작 및 종료에 대한 메시지입니다. 형식을 생각해 내기만 하면 됩니다.
그건 그렇고, 나는 통신 속도를 높이고 제동을 줄였습니다. 그러나 브레이크가 끝날 때까지 이유는 아직 이해되지 않았습니다. 다시 그릴 때 나타나는데 이상한 점은 다시 그리기 자체가 느려지지 않는다는 것입니다. 그리고 리소스를 통해 통신할 때 다시 그리기 속도가 느려집니다. 그 이유는 아직 명확하지 않습니다.
시간 비용을 모니터링하십시오. 속도가 느려지는 위치를 확인합니다. 그리고 그것을 우회하는 방법.
어쩌면 내가 그것을 조금 지나치게 복잡하게 만들었습니다. 엔진 내부에서 어떻게 정리하셨는지 모르겠습니다. 논리를 사용했을 뿐입니다.
시간 비용을 모니터링하십시오. 속도가 느려지는 위치를 확인합니다. 그리고 그것을 우회하는 방법.
어쩌면 내가 그것을 조금 지나치게 복잡하게 만들었습니다. 엔진 내부에서 어떻게 정리하셨는지 모르겠습니다. 논리를 사용했을 뿐입니다.
논리는 요점에 더 가까이 다가갔고 일반적으로 올바르게 이해하고 있습니다.
오늘은 제동이 걸리는 이유에 대해 알아보도록 하겠습니다. 다음은 분명합니다. 다시 그리기 자체가 느려지지 않습니다. 자원을 쓰고 읽기도 합니다. 그리고 함께 - 제동이 걸립니다.
모니터링이 있습니까? 어떤 작업이 얼마나 오래 걸리나요? 순차적으로 수행해야 합니다. 어드바이저에서 데이터 제거 및 엔진으로의 전송은 예를 들어 30ms의 빈도로 수행됩니다. 스트림이 엔진으로 전송되면 수락할 준비가 되었습니까? 아니면 그는 무엇을합니까?
나는 지금 모든 것을 확인하고 있다.
30ms 주기의 Engine은 Expert Advisor의 메시지 리소스를 읽고, 동일한 주기의 Expert Advisor는 Engine의 메시지 리소스를 읽습니다. 동일한 주파수에서 둘 다 서로에게 메시지를 녹음합니다(녹음할 것이 있는 경우). 이 모든 것이 느려지지 않습니다. 또한 다시 그리기 자체로 지연이 발생하지 않습니다.
단, 엔진측 리소스의 다시 그리기와 쓰기/읽기를 병행하면 랙이 발생합니다. 이유는 아직 불명. 나는 알아.
나는 지금 모든 것을 확인하고 있다.
30ms 주기의 Engine은 Expert Advisor의 메시지 리소스를 읽고, 동일한 주기의 Expert Advisor는 Engine의 메시지 리소스를 읽습니다. 동일한 주파수에서 둘 다 서로에게 메시지를 녹음합니다(녹음할 것이 있는 경우). 이 모든 것이 느려지지 않습니다. 또한 다시 그리기 자체로 지연이 발생하지 않습니다.
단, 엔진측 리소스의 다시 그리기와 쓰기/읽기를 병행하면 랙이 발생합니다. 이유는 아직 불명. 나는 알아.
불일치가 있을 수 있습니다. 어드바이저와 엔진 모두 1- 둘 다 서로에게 전송하고 2 - 둘 다 수신하고 OnTimer 주기가 동기화되지 않습니다. 정상 작동의 임의 동기화 순간을 기다립니다. 아마도 이것 때문에?