Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Кроме терминала есть очень много этапов, на которых принимаются решения. А терминал лишь указывает финальное время получения подтверждений с той стороны.
Ренат.
Я участник форума Московской биржи.
Я задавал вопрос по поводу задержек исполнения приказов
по Plaza II.
НИ У КОГО не наблюдаются.
Более того, нет ни одного сообщения о задержках.
А скальперы подняли бы такой вой, если бы они были.
Я думаю, что вам нужно искать причину в связке терминал МТ-5 <--> сервер МТ-5
Кстати, до лета 2013 года, их не было.
Посмотрите на картинку:
Задержки наблюдаются, когда над одним инструментом происходят частые операции.
Попробуйте из терминала устанавливать, модифицировать и удалять ордера "руками".
Но только не один раз, а много 2-3 минуты.
И вы увидите что вызывает задержки.
По вопросу о частых сделках на асинхронных запросах мы завершили проверки. Извините за задержки, так как все были сконцентрированы на выпуске MT4 билдов.
Оказалось, что со стороны терминала или сервера ошибок нет. Дело в том, что у нас буфер подтверждения/ожидания на 16 ожидающих транзакций, которые вы полностью использовали и вследствие достаточно большого пинга(50-70 мс) до торгового сервера (+ исполнение/регистрация на бирже) не успевали получать ответы. Поэтому сразу идущие следующие транзакции были отклонены как частые.
Если бы вы торговали с более близкого расстояния и меньшей сетевой задержкой, то получали бы подтверждения быстрее и отказов "частые операции" получали бы меньше.
Вначале при первом взгляде показалось, что в очереди зависли старые блокирующие транзакции, но эта догадка не подтвердилась. С толку сбили логи, которые на самом деле выравниваются чуть по другому. В очереди никаких зависших транзакций нет.
В официальном билде 1010 мы увеличили буфер ожидающих подтверждения транзакций до 64, что дает возможность проводить массовые асинхронные транзакции даже при больших сетевых задержках. Обновитесь на эту версию, подключившись к MetaQuotes-Demo, если ваш брокер еще не обновился сам.
По ограничению очереди подтверждений надо понимать, что это важное условие, защищающее торговые серверы от трейдерских ошибок и перегрузок. Авторам программ нужно аккуратно относиться к доступной мощности и не использовать ее в грубом режиме. То есть, всегда оценивать реакцию брокера/биржи, которым могут не понравиться массовые торговые операции, особенно если они не приводят к сделкам.
К сожалению не удалось избежать ошибок при массовой отправке ордеров.
Брутфорс метод:
При попытки открыть 200 ордеров Выдает ошибки на MQ-Demo: Неправильная цена в запросе, Торговля запрещена, Слишком частые запросы. Засыпание не помогает.
Попытка рассчитать свободные слоты в буфере транзакций:
Видно что метод более интеллектуальный и построен без задержек Sleep. Получив ответ от сервера в OnTradeTransaction или OnTrade увеличиваем количество свободных слотов на единицу. Однако как и в первом случае "Слишком частые запросы", а количество ответов не дотягивает до общего количества выставляемых ордеров.
При попытке установить SlotsTotal = 64, ошибка 10024 выскакивает уже на 60 итерации цикла for:
... чего по идее быть не должно, ведь буфер еще не заполнен.
В общем, пока не совсем не понятно как избежать ошибок и узнать причину отказа в обслуживании.
p/s/ Тестировал массовые запросы на сервере AdmialMarkets. Через некоторое время терминал перестал соединятся с сервером. Пинг есть, а связь пропала. Вот и думаю, может забанили меня?
К сожалению не удалось избежать ошибок при массовой отправке ордеров.
Брутфорс метод:
В общем, пока не совсем не понятно как избежать ошибок и узнать причину отказа в обслуживании.
Прочтите еще раз внимательно:
По ограничению очереди подтверждений надо понимать, что это важное условие, защищающее торговые серверы от трейдерских ошибок и перегрузок. Авторам программ нужно аккуратно относиться к доступной мощности и не использовать ее в грубом режиме. То есть, всегда оценивать реакцию брокера/биржи, которым могут не понравиться массовые торговые операции, особенно если они не приводят к сделкам.
Кроме того:
Возвращаясь к моему предупреждению выше, задайтесь вопросом - по какой причине брокер будет разрешать трейдеру спамить сервер? Я не вижу ни одной причины, даже самой слабой.
p/s/ Тестировал массовые запросы на сервере AdmialMarkets. Через некоторое время терминал перестал соединятся с сервером. Пинг есть, а связь пропала. Вот и думаю, может забанили меня?
А где точные сообщения в журнале о невозможности подключиться?
Но вообще наивность на фоне деструктивного поведения поражает. Мир - не тупая железка, он реагирует и защищается.
А где точные сообщения в журнале о невозможности подключиться?
Но вообще наивность на фоне деструктивного поведения поражает. Мир - не тупая железка, он реагирует и защищается.
Ну зачем же так резко, я все прекрасно понимаю. Мой вопрос не типа "смотрите, шлю пачку тупых запросов - а меня реджектит сервер. Почему сервер такой плохой?". Посмотрите второй пример, там стоит ограничение на количество транзакций. Оно срабатывает, но ошибки все равно появляются, значит код неправильный, но что не верно в коде и как избежать ошибок, я действительно не понимаю, вот и спрашиваю у знающих людей: Вас и всех кто просматривает эту ветку.
Попробую изложить по порядку. Во втором примере в цикле for делается попытка 64 раза отправить торговый запрос через OrderSendAsync. 64 - потому что буфер вмешает 64 транзакции. Прерывать цикл for и ожидать ответа от сервера, как я понимаю, не нужно, ведь лимит не исчерпан, однако в примере выскакивает ошибка при попытке отправить транзакцию №60: слишком частые запросы:
Вот часть кода, которая вызывает это сообщение:
Внизу прикрепляю логи. Там тоже самое. Вот часть лога:
Между двумя маркерами было отправлено как раз 60 транзакций. Если бы ошибка была вызвана на 65 итерации цикла она была бы мне понятна - превышен размер буфера, но почему ошибка выскакивает на 60?
З.Ы. с торговым сервером разобрался. Сервера похоже перезагружались. Сейчас подключился нормально.
p.s.s. Наверное еще надо учитывать время между первым и последним запросом. Но тогда сколько времени ждать? Это секретная информация?
Между двумя маркерами было отправлено как раз 60 транзакций. Если бы ошибка была вызвана на 65 итерации цикла она была бы мне понятна - превышен размер буфера, но почему ошибка выскакивает на 60?
Мы резервируем 4 транзакции из буфера на 64 записи для ручных операций и сигналов.
Иначе может получиться, что эксперты могут полностью заблокировать ручную/сигнал торговлю, когда ожидают на долгом исполнении своих заявок.
Мы резервируем 4 транзакции из буфера на 64 записи для ручных операций и сигналов.
Иначе может получиться, что эксперты могут полностью заблокировать ручную/сигнал торговлю, когда ожидают на долгом исполнении своих заявок.
Спасибо за ответ. Все стало на свои места. Еще пару вопросов:
1. Как не выйти за пределы буфера и контролировать оставшийся его размер при асинхронной отправке? Я пробовал считать аналитически через OnTradeTransaction: выставляем 64 60 транзакций и ждем срабатывания первого ордера в OnTradeTransaction. Когда он срабатывает увеличиваем размер буфера на единицу. Но OnTradeTransaction не надежен (событие может не дойти), и количество отправленных и сработавших ордеров у меня почему-то не совпало.
2. Какие ошибки надо ловить при асинхронной отправке? Заметил что на MQ-Demo приходят ошибки 10017 (Торговля запрещена) и 10024 (Слишком частые запросы) а вот на Admiral-Markets сервере ошибки 10017 не возникает, а есть только 10024. В общем не понятно каких именно ошибок от серверов нужно ждать.
Спасибо за ответ. Все стало на свои места. Еще пару вопросов:
1. Как не выйти за пределы буфера и контролировать оставшийся его размер при асинхронной отправке? Я пробовал считать аналитически через OnTradeTransaction: выставляем 64 60 транзакций и ждем срабатывания первого ордера в OnTradeTransaction. Когда он срабатывает увеличиваем размер буфера на единицу. Но OnTradeTransaction не надежен, и количество отправленных и сработавших ордеров у меня почему-то не совпало.
2. Какие ошибки надо ловить при асинхронной отправке? Заметил что на MQ-Demo приходят ошибки 10017 (Торговля запрещена) и 10024 (Слишком частые запросы) а вот на Admiral-Markets сервере ошибки 10017 не возникает, а есть только 10024. В общем не понятно каких именно ошибок от серверов нужно ждать.
1. Контролировать буфер можно по коду 10024 - это мгновенный ответ самого терминала. То есть, комбинируя OnTradeTransaction и код ответа 10024 можно достаточно точно регулировать скорость, поддерживая ее на максимуме.
2. Нужно контролировать все типы ошибок, обрабатывая известные, а остальные по плану критической неизвестной ошибки.
Главный вопрос - вы уверены, что хотите строить торговую систему на уровне сотен транзакций в секунду так, чтобы упираться в лимиты? Это ведь только для краткосрочного теста годится.