즉, 거래소에 도달하기 전에(정확성 확인 중에) 브로커는 (이론적으로는 개발자가 제공한 경우) 거래를 "장난"할 수 있는 기회가 있습니다. DMA를 사용하는 거래자와 같은 거래 후 관리는 없습니다.
또는 교환 버전의 경우 요청의 정확성을 확인하는 기능을 단말기 자체에서 수행하므로(모든 트랜잭션의 기록을 서버와 병렬로 유지하고 비동기식으로 상호 작용) 서버에 추가 부담을 주지 않습니다. 계산? 하지만 그렇게 된다면 우리나라에 그렇게 많은 주가 존재하지 않을 것입니다. ENUM_ORDER_STATE.
아니면 이해가 안 가나요?
새 릴리스 및 중개 서버 업데이트 후 트랜잭션 실행 시간 과 거래 작업 의 전체 대기 시간이 몇 밀리초 정도 더 개선됩니다.
우리는 모든 거래 장소를 조정하고 프로세스 체인에서 100마이크로초마다 승리하기 위해 많은 노력을 기울였습니다.
이것은 훌륭합니다. 그러나 IMHO, 모든 것이 실행 속도로 완벽합니다. 왜 더 증가합니까? 속도 측면에서 여전히 "처벌"되는 경쟁 플랫폼은 무엇입니까? 이와 관련하여 Quick은 이미 제공되는 것 이상입니다.
나는 광장의 문서를 살펴 보았고 모든 것을 선물로 정리할 수 있는지 이해하지 못했습니다. 그러면 옵션과 옵션을 연결하는 것이 절대 어렵지 않고 시간이 많이 걸리지 않아야합니다.
2016.07.07 11:47:11.564 거래 '10644': 구매 제한 1.00 Si-9.16 at 65057 (65057) tp: 65457 7ms 후 실행 2016.07.07 11:47:11.557 거래 '10644': 구매 한도 1.00 Si-9.16 at 65057 (65057) tp: 65457
Renat Fatkhullin : 서버는 요청의 일반적인 정확성을 확인하고 게이트웨이로 직접 보냅니다.
감사합니다.. 어쨌든 실행 속도(로그 기준)는 Quick과 비교했을 때 인상적입니다.
똑같이 중요한 또 다른 질문이 있습니다. 당신 외에는 거의 누구도 저에게 대답할 수 없습니다. 답변해주시면 정말 감사하겠습니다.
1) MarketData를 받는 비율입니다. 견적의 유효성을 확인하는 방법은 무엇입니까?
플라즈마를 통해 수신할 수 있는 마이크로초 단위의 교환 브로드캐스트
bid_changed t 현재 베스트바이 견적의 변경 시간.
Ask_changed t 현재 가장 좋은 물음표의 시간을 변경합니다.
그리고 Metatrader - 초 단위의 서버 시간과 최고의 가격 값.
가격 변동의 교환 시간 외에도 MT가 ms 단위의 시간을 독립적으로 브로드캐스트하면 교환 서버의 시간과 주기적으로 동기화됩니다.
- 문제가 해결될 것입니다. 모든 것이 괜찮을 것입니다!
거래 결정이 현재가 아닌 시세에 대해 맹목적으로 내리는 경우 실행 속도는 중요하지 않습니다. 그리고 때때로 (어떤 이유로든) 심각하게 처지는 경우가 있습니다. 그리고 이런 일이 발생했을 때 어떠한 거래 행위도 하지 않았으면 합니다.
//---------------
2) CopyTicks에 의해 모든 틱을 요청할 때 MqlTick 구조 에서 tick.time_msc( 마지막 가격 업데이트 시간(밀리초)) 는 서버 시간과 일치하는 초로 반올림된 시간을 제공합니다. 시간과 동일 // 마지막 가격 업데이트 시간 / . 왜 당신이 필요로하지 않습니다 - 가격 변경의 교환 시간과 거래 등록 시간 ..? 광장을 통해서도 얻을 수 있습니다. 그리고 MT5는 거기에서 정보를 가져옵니다 ... 그들은 서비스 데스크에서이 질문에 대답하지 않았습니다 ((
두 계정의 오프닝에서 모든 것이 정상이며 내 평균 핑에 맞습니다. 다른 리소스에 대한 핑을 확인하십시오. 인터넷 공급자 측에 문제가 있을 수 있습니다.
핑은 괜찮습니다.
데모는 이미 날라가는데 진짜는 뒤쳐지고 문제가 바로 데모와 실제 데모에 있었다는게 이상하다. 서버가 다른데.. 경매장에서 실험을 하다보니 개발자들이 대체로 잔혹하게 굴었다고 생각합니다.)
어쩌면 그들은 나에게 개인적으로 결함을 도입 했습니까?...))
주문 취소 #38968458 판매 제한 1.00 Si-9.16 at 65888, 65606ms 실행
답변 해주셔서 감사합니다. 기이한.
나는 이것을 정리할 것이다.
핑은 괜찮습니다.
데모는 이미 날라가는데 진짜는 뒤쳐지고 문제가 바로 데모와 실제 데모에 있었다는게 이상하다. 서버가 다른데.. 경매장에서 실험을 하다보니 개발자들이 대체로 잔혹하게 굴었다고 생각합니다.)
어쩌면 그들은 나에게 개인적으로 결함을 도입 했습니까?...))
주문 취소 #38968458 판매 제한 1.00 Si-9.16 at 65888, 65606ms 실행
답변 해주셔서 감사합니다. 기이한.
나는 이것을 정리할 것이다.
핑은 어떻게 측정하나요? 서버가 다르기 때문에 이상합니다. 65초는 버그에 가까운 공백 지연입니다. 65초 후에 차트에도 주문이 표시되나요?
핑은 어떻게 측정하나요? 서버가 다르기 때문에 이상합니다. 65초는 버그에 가까운 공백 지연입니다. 65초 후에 차트에도 주문이 표시되나요?
예, 또한 1분 내에, 때로는 더 빠르게 - 20-30초 내에.
그러나 웬일인지 인터넷에서 자동 다운로드 한 후 모든 것이 다시 "비행"하기 시작했습니다. 어떤 서비스가 무엇인지 명확하지 않습니다. 그러나 분명히 이것은 이것과 관련이 없습니다.
아마도 밤에 Windows 10을 이전 어셈블리로 "롤백"했기 때문일 수 있습니다. ..하지만, 그러면 안됩니다. 어떻게든 일치합니다.
나는 그것이 무엇인지 이해하지 못한다.
상황을 지켜보겠다. 다시는 그런 일이 일어나지 않기를 바랍니다.
다음은 실제 계정에서 가져온 것입니다.
구매 제한 설정, 제거, 시장별 개시, 2ms 핑으로 5ms 이내에 시장별 마감. 이것은 모스크바의 MetaTrader VPS 서버 에서 가져온 것입니다.
다음은 실제 계정에서 가져온 것입니다.
구매 제한 설정, 제거, 시장별 개시, 2ms 핑으로 5ms 이내에 시장별 마감. 이것은 모스크바의 MetaTrader VPS 서버 에서 가져온 것입니다.
그래서 지금은 모든 것이 괜찮습니다. 모든 것이 빠릅니다. 그래서, 나의 이러한 지연은 당신이 한 것이 아니며 당신은 어떤 실험도 수행하지 않은 것으로 나타났습니다.
브로커가 개별적으로 "목발"을 던질 수 있는 기술적 능력이 있습니까? (예를 들어 재미를 위해).
이러한 지연이 Windows 10 실험의 "기적"과 관련되기를 바랍니다.
구매 제한 1.00 RTS- 91740 에서 9.16 실행 을 위해 배치 5ms _
예, 이러한 지연으로 하드 차익 거래를 시도할 수도 있습니다!!!
나는 60ms의 핑을 가지고 있습니다. 그리고 그것은 나의 소프트 스캘핑 전략에 충분합니다)
그래서 지금은 모든 것이 괜찮습니다. 모든 것이 빠릅니다. 그래서, 나의 이러한 지연은 당신이 한 것이 아니며 당신은 어떤 실험도 수행하지 않은 것으로 나타났습니다.
이제 거래소는 인프라를 업그레이드하고 있으며 최근에 새 버전의 API를 출시했습니다. 다른 플랫폼과 자체 커넥터의 거래자들로부터 실행 시간이 유동적이기 시작했고 명백한 속도 저하가 있다는 불만이 많이 있습니다.
일시적인 문제일 가능성이 높으며 거래소에서 해결할 것입니다. 그런 지연을 갖는 것은 그녀의 관심사가 아닙니다.
브로커가 개별적으로 "목발"을 던질 수 있는 기술적 능력이 있습니까? (예를 들어 재미를 위해).
이러한 지연이 Windows 10 실험의 "기적"과 관련되기를 바랍니다.
예, 이러한 지연으로 하드 차익 거래를 시도할 수도 있습니다!!!
나는 60ms의 핑을 가지고 있습니다. 그리고 그것은 나의 소프트 스캘핑 전략에 충분합니다)
새 릴리스 및 중개 서버 업데이트 후 트랜잭션 실행 시간 과 거래 작업 의 전체 대기 시간이 몇 밀리초 정도 더 개선됩니다.
우리는 모든 거래 장소를 조정하고 프로세스 체인에서 100마이크로초마다 승리하기 위해 많은 노력을 기울였습니다.
아니요. 게이트웨이는 거래소에 절대적으로 직접적이며 브로커는 이를 방해할 수 없습니다.
따라서 응용 프로그램은 먼저 서버에 도달하여 처리되고 정확성이 확인된 다음 게이트웨이로 이동합니다.
https://www.mql5.com/ru/docs/trading/ordersend
"거래 요청은 거래 서버에서 여러 단계의 확인을 거칩니다. "
즉, 거래소에 도달하기 전에(정확성 확인 중에) 브로커는 (이론적으로는 개발자가 제공한 경우) 거래를 "장난"할 수 있는 기회가 있습니다. DMA를 사용하는 거래자와 같은 거래 후 관리는 없습니다.
또는 교환 버전의 경우 요청의 정확성을 확인하는 기능을 단말기 자체에서 수행하므로(모든 트랜잭션의 기록을 서버와 병렬로 유지하고 비동기식으로 상호 작용) 서버에 추가 부담을 주지 않습니다. 계산? 하지만 그렇게 된다면 우리나라에 그렇게 많은 주가 존재하지 않을 것입니다. ENUM_ORDER_STATE.
아니면 이해가 안 가나요?
새 릴리스 및 중개 서버 업데이트 후 트랜잭션 실행 시간 과 거래 작업 의 전체 대기 시간이 몇 밀리초 정도 더 개선됩니다.
우리는 모든 거래 장소를 조정하고 프로세스 체인에서 100마이크로초마다 승리하기 위해 많은 노력을 기울였습니다.
이것은 훌륭합니다. 그러나 IMHO, 모든 것이 실행 속도로 완벽합니다. 왜 더 증가합니까? 속도 측면에서 여전히 "처벌"되는 경쟁 플랫폼은 무엇입니까? 이와 관련하여 Quick은 이미 제공되는 것 이상입니다.
나는 광장의 문서를 살펴 보았고 모든 것을 선물로 정리할 수 있는지 이해하지 못했습니다. 그러면 옵션과 옵션을 연결하는 것이 절대 어렵지 않고 시간이 많이 걸리지 않아야합니다.
아직 옵션이 없습니다
물론 비밀이 아니라면 말해주세요.
오프닝에서 서버 업데이트 후 말씀드리겠습니다.
대부분의 경우 다음과 같은 것이 있습니다.
2016.07.07 11:47:11.564 거래 '10644': 구매 제한 1.00 Si-9.16 at 65057 (65057) tp: 65457 7ms 후 실행
2016.07.07 11:47:11.557 거래 '10644': 구매 한도 1.00 Si-9.16 at 65057 (65057) tp: 65457
따라서 응용 프로그램은 먼저 서버에 도달하여 처리되고 정확성이 확인된 다음 게이트웨이로 이동합니다.
https://www.mql5.com/ru/docs/trading/ordersend
"거래 요청은 거래 서버에서 여러 단계의 확인을 거칩니다. "
서버는 요청의 일반적인 정확성을 확인하고 게이트웨이로 직접 보냅니다.
감사합니다.. 어쨌든 실행 속도(로그 기준)는 Quick과 비교했을 때 인상적입니다.
똑같이 중요한 또 다른 질문이 있습니다. 당신 외에는 거의 누구도 저에게 대답할 수 없습니다. 답변해주시면 정말 감사하겠습니다.
1) MarketData를 받는 비율입니다. 견적의 유효성을 확인하는 방법은 무엇입니까?
플라즈마를 통해 수신할 수 있는 마이크로초 단위의 교환 브로드캐스트
bid_changed t 현재 베스트바이 견적의 변경 시간.
Ask_changed t 현재 가장 좋은 물음표의 시간을 변경합니다.
그리고 Metatrader - 초 단위의 서버 시간과 최고의 가격 값.
가격 변동의 교환 시간 외에도 MT가 ms 단위의 시간을 독립적으로 브로드캐스트하면 교환 서버의 시간과 주기적으로 동기화됩니다.
- 문제가 해결될 것입니다. 모든 것이 괜찮을 것입니다!
거래 결정이 현재가 아닌 시세에 대해 맹목적으로 내리는 경우 실행 속도는 중요하지 않습니다. 그리고 때때로 (어떤 이유로든) 심각하게 처지는 경우가 있습니다. 그리고 이런 일이 발생했을 때 어떠한 거래 행위도 하지 않았으면 합니다.
//---------------
2) CopyTicks에 의해 모든 틱을 요청할 때 MqlTick 구조 에서 tick.time_msc( 마지막 가격 업데이트 시간(밀리초 )) 는 서버 시간과 일치하는 초로 반올림된 시간을 제공합니다. 시간과 동일 // 마지막 가격 업데이트 시간 / . 왜 당신이 필요로하지 않습니다 - 가격 변경의 교환 시간과 거래 등록 시간 ..? 광장을 통해서도 얻을 수 있습니다. 그리고 MT5는 거기에서 정보를 가져옵니다 ... 그들은 서비스 데스크에서이 질문에 대답하지 않았습니다 ((