Сравнение времени открытия и закрытия позиций.

 

Исследуя в тестере работу функции OrderSendAsync(), столкнулся с интересным явлением.

Время, затрачиваемое на отправку ордеров на открытие позиций в среднем меньше времени, затрачиваемого на отправку ордеров на закрытие позиций.

Советник записывал в лог время в микросекундах уходящее на то, чтобы отправить несколько ордеров. То есть счетчик засекался в перед запуском торговой функции, после чего время засекалось, когда три ордера были отправлены. При этом, и для открытия и для закрытия использовалась одна и та же функция (для закрытия позиции в параметры запроса подставлялся номер позиции).

Заметил, что время для закрытия в среднем больше.

Причем разница ощутимо зависит от задержки. С увеличением задержки разница возрастала в разы.

Ниже представлены графики замеров при нулевой задержке:

 Без задержки

и задержке = 100 мс:

Задержка 100 мс. 

 

Вертикальная шкала - время в микросекундах в логарифмическом масштабе.

Средняя разница времени на отправку ордеров при открытии и закрытии:

- без задержки = 42 мкс.

- с задержкой 100 мкс = 612 мкс.

С чем связана такая разница и можно ли с этим бороться? 

 

Думаю, разница связана с особенностями работы сервера.

Но, вам-то какая разница ? Вы крутой высокочастотник ?

По мне - таймфреймы менее М5 - практически непригодны для торговли из-за спредов и проскальзываний...

А на больших таймфреймах - функция OrderSend() куда более разумна.

 
Oleg Shenker:
 

............

С чем связана такая разница и можно ли с этим бороться? 

Да, можно.

Арендуйте место на сервере на стороне брокера.

 
Oleg Shenker:

Исследуя в тестере 

У меня есть подозрение, что вы замеряли время выполнения кода при тестировании. GetMicrosecondCount вряд ли эмулируется в тестере.

Попробуйте GetTickCount. 

 

Мне вот интересно такое.

Берем и замеряем на 5-ти знаке желательно, минимальный период следования 2-х тиков подряд, умноженный на 3. Можно было умножить на 2, но исходящий трафик всегда проходит медленнее входящего примерно в 2 раза.

Я так понимаю - это и будет минимально возможный интервал времени с момента отдачи приказа до его исполнения.

Пробовали сориентироваться относительно такой временной скорости работы Вашей системы?

 
Andrey Khatimlianskii:

У меня есть подозрение, что вы замеряли время выполнения кода при тестировании. GetMicrosecondCount вряд ли эмулируется в тестере.

Попробуйте GetTickCount. 

Возможно, что это действительно время исполнения кода. Но. Время и в случае открытия и в случае закрытия засекается непосредственно перед вызовом функции, которая посылает OrderSendAsync(). А функция в обоих случаях одна и та же, то есть один и тот же код. Разница только в том, что при открытии тикет позиции равен нулю, а в случае закрытия - указывается конкретный тикет позиции.
 
Renat Akhtyamov:

Мне вот интересно такое.

Берем и замеряем на 5-ти знаке желательно, минимальный период следования 2-х тиков подряд, умноженный на 3. Можно было умножить на 2, но исходящий трафик всегда проходит медленнее входящего примерно в 2 раза.

Я так понимаю - это и будет минимально возможный интервал времени с момента отдачи приказа до его исполнения.

Пробовали сориентироваться относительно такой временной скорости работы Вашей системы?

Не совсем понимаю, при чем здесь тики? Алгоритм действует следующим образом:

1. Загружает текущие цены.

2. Анализирует сигнал на вход/выход.

3. Засекает время.

4. Отправляет приказ.

6. Засекает время.

В случае открытия позиции время оказывается чуть короче. Вот и все. 

 
Oleg Shenker:
Возможно, что это действительно время исполнения кода. Но. Время и в случае открытия и в случае закрытия засекается непосредственно перед вызовом функции, которая посылает OrderSendAsync(). А функция в обоих случаях одна и та же, то есть один и тот же код. Разница только в том, что при открытии тикет позиции равен нулю, а в случае закрытия - указывается конкретный тикет позиции.

Ну так я же написал — закрытие позиции может требовать больше ресурсов, потому что нужно добавить сделку в историю (в случае открытия этого не происходит). Это догадка, но вполне логичная.

Но главное другое — зачем вообще вычислять эту цифру?? Это задача MQ.

 
Andrey Khatimlianskii:

Ну так я же написал — закрытие позиции может требовать больше ресурсов, потому что нужно добавить сделку в историю (в случае открытия этого не происходит). Это догадка, но вполне логичная.

Но главное другое — зачем вообще вычислять эту цифру?? Это задача MQ.

Кое что не бьется. Я использую асинхронную отправку ордера. То есть, по идее, время уходит только на проверку параметров запроса и отправку ордера. Время на обработку транзакции пока остается за скобками. 
 
Без исходника - из пустого в порожнее.
 
Oleg Shenker:
Возможно, что это действительно время исполнения кода. Но. Время и в случае открытия и в случае закрытия засекается непосредственно перед вызовом функции, которая посылает OrderSendAsync(). А функция в обоих случаях одна и та же, то есть один и тот же код. Разница только в том, что при открытии тикет позиции равен нулю, а в случае закрытия - указывается конкретный тикет позиции.

Если это тестер, разница может быть из-за следующего.

При добавлении фактически просто вносится запись в список ордеров. Как он устроен - знают только разработчики МТ5. Допустим, это тупой CList. Тогда все происходит быстро.

А теперь надо закрыть ордер - удалить запись. В CList поиск записи происходит путем перебора и на это нужно время. И некоторое время на удаление объекта и сылки на него в CList.

Это всего лишь мое предположение, истина где-то рядом )) 

Причина обращения: