MT5 и скорость в боевом исполнении - страница 69
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
как ты себе это представляешь - параллельную обработку в одном потоке?
Цикл событий event loop.
А вообще это проблема разработчиков, почему всё выполняется в одном потоке.
Получается Обзор рынка обрабатывается асинхронно, а обработчики в пользовательских программах, синхронно.
Шикардос просто, слов нет.
Спасибо за отзыв по статистике! Лаги OnTick/OnBook, похоже, есть у всех. Sleep(1) либо 1 ms, либо 15 ms. Отчего зависит - непонятно.
Лаги OnTick/OnBook, похоже, есть у всех.
Я думаю вы знаете, что OnTimer() не может вызываться чаще 10-16 миллисекунд. Логично предположить, что и другие функции OnXXX вызываются не чаще. Может быть из-за этого и ваши лаги беруться ?
Я думаю вы знаете, что OnTimer() не может вызываться чаще 10-16 миллисекунд. Логично предположить, что и другие функции OnXXX вызываются не чаще. Может быть из-за этого и ваши лаги беруться ?
Не логично, обработчики не привязаны к частоте/разрешению таймера GetTickCount. События срабатывают мгновенно в момент совершения.
OnTimer тоже не привязан к погрешности в 16 мс. Запросто можно получать в подавляющем большинстве случаев таймер в 1 мс, если комп не убит и не загружен на 100%.
Проблема практически всех тестов fxsaber в том, что он пытается замерять выбросы одиночных вызовов вместо усреднения множества и не желает понять реальности работы диспетчера потоков.
У него:
Методы борьбы, чтобы приблизиться к рилтайму:
Отсюда мораль - на обычных классических VPS терминалы(как и любые другие программы) всегда будут страдать из-за неожиданных задержек. Чем более дешев/перепродан VPS, тем больше проблем.
Поинтересуйтесь на своих VPS, включен ли SR-IOV и есть ли последние(ставятся только и только вручную) специальные драйвера сетевух под него? В 99% случаев нет, так как это ломает миграцию виртуалок по зоопарку железа. А без него дополнительные задержки гарантированны просто из-за двойной(на хосте и виртуалке) передачи/обработки сетевых пакетов и повышенном количестве прерываний.
Наш VPS сервис этому подвержен на порядки меньше как по архитектуре, так и по облегченным терминалам без GUI.
Не логично, обработчики не привязаны к частоте/разрешению таймера GetTickCount. События срабатывают мгновенно в момент совершения.
OnTimer тоже не привязан к погрешности в 16 мс. Запросто можно получать в подавляющем большинстве случаев таймер в 1 мс, если комп не убит и не загружен на 100%.
Проблема практически всех тестов fxsaber в том, что он пытается замерять выбросы одиночных вызовов вместо усреднения множества и не желает понять реальности работы диспетчера потоков.
У него:
Методы борьбы, чтобы приблизиться к рилтайму:
Отсюда мораль - на обычных классических VPS терминалы(как и любые другие программы) всегда будут страдать из-за неожиданных задержек. Чем более дешев/перепродан VPS, тем больше проблем.
Поинтересуйтесь на своих VPS, включен ли SR-IOV и есть ли последние(ставятся только и только вручную) специальные драйвера сетевух под него? В 99% случаев нет, так как это ломает миграцию виртуалок по зоопарку железа. А без него дополнительные задержки гарантированны просто из-за двойной(на хосте и виртуалке) передачи/обработки сетевых пакетов и повышенном количестве прерываний.
Наш VPS сервис этому подвержен на порядки меньше как по архитектуре, так и по облегченным терминалам без GUI.
А теперь представьте, во сколько раз будет ускорение работы пользовательских программ, на подобной оптимизированной машине, если обработчики в программах будут выполняться асинхронно.
Мне не понятен смысл, супер апгрейда и супер оптимизации железа машины, если обработчики в пользовательской программе априори выполняются синхронно.
Для самого терминала и его внутренней работы, может да, выше описанная оптимизация полезна. Для боевых пользовательских програм сомневаюсь.
Ибо последовательное выполнение обработчиков в пользовательской программе, снижает весь тот возможный потенциал, любой супер оптимизированной машины.
Проблема не в железе, а в архитектуре внутренней работы терминала.
А теперь представьте, во сколько раз будет ускорение работы пользовательских программ, на подобной оптимизированной машине, если обработчики в программах будут выполняться асинхронно.
Мне не понятен смысл, супер апгрейда и супер оптимизации железа машины, если обработчики в пользовательской программе априори выполняются синхронно.
Для самого терминала и его внутренней работы, может да, выше описанная оптимизация полезна. Для боевых пользовательских програм сомневаюсь.
Ибо последовательное выполнение обработчиков в пользовательской программе, снижает весь тот возможный потенциал, любой супер оптимизированной машины.
Проблема не в железе, а в архитектуре внутренней работы терминала.
Не будет никакого ускорения. Представьте Ваши выкладки, хотя бы в приблизительных цифрах, доказывющие многократное ускорение.
Гонки за ресурсы? Бесконтрольное создание новых потоков? Конфликты на ровном месте?
Хотите необъяснимых тормозов?
В событийной модели все события всегда ходили строем, по очереди. Жёвано - пережёвано.
Наш VPS сервис этому подвержен на порядки меньше как по архитектуре, так и по облегченным терминалам без GUI.
Если будут лаги на Вашем VPS-сервисе - будете воспринимать всерьез?
Кто использует VPS от MQ, просьба поделиться результатом работы там следующих программ.
Если будут лаги на Вашем VPS-сервисе - будете воспринимать всерьез?
Интересно, сколько еще раз повторять, что при таком (тысячи) количестве потоков на ограниченное количество ядер вообще безумно говорить о стабильности выделения квантов времени на поток?
Вы всегда гарантированно будете иметь провалы на рандомных одиночных замерах любых команд, включая простейшие ассемблерные типа inc eax. Это архитектурно и объясняется физическими ограничениями "честного распределения квантов времени тысяч потоков на маленькое количество ядер".
Хватит уже тупить и продолжать ловить одиночные выбросы на миллион запросов.
Хватит уже тупить и продолжать ловить одиночные выбросы на миллион запросов.
С одиночными выбросами понятно, спасибо за подробные объяснения. В данный момент все же обсуждаем не SymbolInfoTick, а лаги другого характера, которые сыпятся почти на каждом тике.