터미널은 원격 측에서 각 실행 단계의 정확한 시간이 아니라 터미널에서 신호를 등록/수신한 현지 시간을 보여줍니다.
이 경우 모든 응답(MT5 서버의 확인 및 거래소 주문 확인 모두)을 동시에 029 수신했습니다. 귀하 사이에는 많은 네트워크가 있기 때문에 패키지가 즉시 배달된다는 보장이 없습니다. 최소 시간 핑에 당신에게. 네트워크의 작은 플러그 또는 네트워크 채널의 부족(예: 브로커)은 패킷 누적 및 후속 그룹 발행으로 이어집니다.
따라서 네트워크에 질문이 있는 경우 다른 단계의 시간을 셀 수 없습니다. 브로커의 서버에 가까운 이상적인 네트워크에서는 여전히 특정 최소 대기 시간 보장에 의존하고 중간 단계의 시간을 계산할 수 있습니다.
"나는 이상적인 네트워크를 가지고 있으며 불평하지 않습니다"라는 대답 옵션은 적합하지 않습니다. 여기에서 우리는 정상적인 조건에서 인간의 지각에 접근할 수 없는 완전히 다른 타이밍에 대해 이야기하고 있습니다.
실제로, 좋은 인프라를 구축하고 신중하게 수집된 유동성 공급자와 함께 라운드당 3-4ms의 실행을 즐기고 성숙한 브로커인 사람들은 전환 후 700-1500ms의 주기적인 점프를 볼 때 바닥에 주저앉습니다. 생산. 그리고 이상적인 시스템을 구축하는 사람은 그에 맞춰 살아가고 조정해야 합니다.
실제로, 좋은 인프라를 구축하고 신중하게 수집된 유동성 공급자와 함께 라운드당 3-4ms의 실행을 즐기고 성숙한 브로커인 사람들은 전환 후 700-1500ms의 주기적인 점프를 볼 때 바닥에 주저앉습니다. 생산. 그리고 이상적인 시스템을 구축하는 사람은 이에 적응하고 적응해야 합니다.
거래에서 대기 시간이 짧은 프로세스로 작업할 때의 일반적인 생각:
기술자인 브로커와 시스템은 기술 인프라를 개선하기 위해 분명히 노력하고 투자하고 있습니다. 하지만 불행히도 모든 사람이 이렇게 하는 것은 아닙니다.
터미널은 원격 측에서 각 실행 단계의 정확한 시간이 아니라 터미널에서 신호를 등록/수신한 현지 시간을 보여줍니다.
이 경우 모든 응답(MT5 서버의 확인 및 거래소 주문 확인 모두)을 동시에 029 수신했습니다. 귀하 사이에는 많은 네트워크가 있기 때문에 패키지가 즉시 배달된다는 보장이 없습니다. 최소 시간 핑에 당신에게. 네트워크의 작은 플러그 또는 네트워크 채널의 부족(예: 브로커)은 패킷 누적 및 후속 그룹 발행으로 이어집니다.
따라서 네트워크에 질문이 있는 경우 다른 단계의 시간을 셀 수 없습니다. 브로커의 서버에 가까운 이상적인 네트워크에서는 여전히 특정 최소 대기 시간 보장에 의존하고 중간 단계의 시간을 계산할 수 있습니다.
"나는 이상적인 네트워크를 가지고 있으며 불평하지 않습니다"라는 대답 옵션은 적합하지 않습니다. 여기에서 우리는 정상적인 조건에서 인간의 지각에 접근할 수 없는 완전히 다른 타이밍에 대해 이야기하고 있습니다.
즉, 다음과 같습니다.
그리고 왜 귀하의 청구를 종결하기 위해 다음과 같은 간단한 로그를 작성하지 마십시오.
무역 서버가 주문을 받았습니다 - 무역 서버 시간
거래 서버가 거래소에 주문 - 거래 서버의 시간
거래 서버는 거래소에서 응답을 받았습니다 - 거래 서버 시간
그러면 이 오랜 주제를 완전히 닫을 것입니다.
추가되었습니다.
그리고 실행 을 위해 수락되고 배치 되는 대신 이 시간(3개 모두)을 보냅니다.
거래에서 대기 시간이 짧은 프로세스로 작업할 때의 일반적인 생각:
마찬가지로 질문은 수백, 수천 밀리초에 해당합니다.
실제로, 좋은 인프라를 구축하고 신중하게 수집된 유동성 공급자와 함께 라운드당 3-4ms의 실행을 즐기고 성숙한 브로커인 사람들은 전환 후 700-1500ms의 주기적인 점프를 볼 때 바닥에 주저앉습니다. 생산. 그리고 이상적인 시스템을 구축하는 사람은 그에 맞춰 살아가고 조정해야 합니다.
이것이 현실입니다. 최소 대기 시간의 안정성이 보장되지 않습니다.
특히 중간 단계가 너무 많은 환경에서.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
요새. 실행 질문
fxsaber , 2016.10.10 11:38
따라서 개발자는 브레이크를 밟을 좋은 기회가 있습니다!
이제 "우리는 toromozov를 보지 못한다"고 말하는 것은 불가능할 것입니다.
개발자는 세션이 시작될 때 지정가 주문을 시작 하고 실행 시간 을 모니터링해야 합니다. 브레이크가 보이면 현지에서 해결합니다.
현재 상황은 불행히도 비참합니다.
실제로, 좋은 인프라를 구축하고 신중하게 수집된 유동성 공급자와 함께 라운드당 3-4ms의 실행을 즐기고 성숙한 브로커인 사람들은 전환 후 700-1500ms의 주기적인 점프를 볼 때 바닥에 주저앉습니다. 생산. 그리고 이상적인 시스템을 구축하는 사람은 이에 적응하고 적응해야 합니다.
이것이 현실입니다. 최소 대기 시간의 안정성이 보장되지 않습니다.
특히 중간 단계가 너무 많은 환경에서.
죄송합니다. Renat, 하지만 네트워크 지연은 불가능합니다.
그리고 가져가서 확인? 당신의 인프라에. 오픈 마켓의 첫 몇 분의 로그를 레이아웃으로?
거의 아무것도 제어하지 않는지 확인하는 이유는 무엇입니까?
우리는 이미 시장이 열릴 때 규범의 증거로 테스트를 보여주었습니다. 그러나 때때로 그럴 필요는 없습니다.
결국 대기 시간 안정성이 보장되지 않는다는 점을 이미 여러 번 씹었습니다.
우리가 브로커라면 그것은 완전히 다른 문제가 될 것입니다. 우리는 가장 효율적인 인프라에 제한을 두지 않고 최대 경로를 최적화하지 않을 것입니다.
Renat에게 죄송합니다 . 네트워크 지연이 발생할 수 없습니다.
네트워크 지연만 고려합니다 . 당신은 모두 훌륭합니다. 그리고 당신에게서 몇 홉 동안 모든 것이 괜찮습니다.
그러나 문제는 다른 곳에 있습니다. 위의 내용을 모두 읽으십시오. 그리고 줄 사이를 읽으십시오.
죄송합니다. Renat, 하지만 네트워크 지연은 불가능합니다.