Несколько вопросов при работе с тиками

Тики могут приходить пачками.

Пока ОнТик выполняется в советнике он пропускает все тики что в то время приходят. 

Об утере тиков. Маршруты их доставки разные, вплоть до полной утери пакета. Сама сеть "убивает" пакеты, блуждающие дольше 30 секунд. Когда последовательность прихода тиков в терминал отличается от их исходной последовательности, это уже вопрос, что делать с опоздавшими.

Недавно где-то прочел (забыл, где...), как человек принимал на два компьютера с разными интернет-провайдерами котировки с разных счетов одной компании и затем сравнивал. У него вышло, если мне не изменяет память, что терялись порядка один тик на десять тысяч.

 
 Эксперт получает ВСЕ тики, которые приходят на терминал от сервера.

После получения тика:
- эксперт формирует и отправляет торговый приказ на сервер, 
- сервер обрабатывает этот запрос и сообщает результат терминалу,
- эксперт получает ответ сервера и может проанализировать его.

... все, выше перечисленное, происходит за время ОДНОГО тика.

Практически, за время одного тика, сервер успевает обработать несколько торговых приказов эксперта, 
поэтому остальные ваши вопросы не имеют смысла.

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

Надо учитывать еще и то, что в некоторых ДЦ терминал строит график по другим котировкам, отличным от тех, которые получает эксперт.

по вопросу 4: надо просто посмотреть ЛОГИ в журнале терминала, там должна быть полная информация.

Важное уточнение: если он в это время не занят обработкой предыдущего тика.

Нет. Торговые операции - достаточно медленные (по сравнению с быстродействием современных ПК). На них уходит время от нескольких миллисекунд до нескольких секунд. Логично, что за это время могут прийти другие тики. В итоге эксперт их не получит, т. к. занят отправкой торгового приказа и ожиданием получения ответа сервера.

В справке по MQL4 написано иначе: "OnTick Событие NewTick генерируется только для экспертов при поступлении нового тика по символу, к графику которого прикреплен эксперт. "

Значит, не ВСЕ, а только по символу своего графика. Эксперт, прикрепленный к графику GBPUSD, не запустит обработку прихода нового тика по USDJPY. При этом, конечно же, эксперт может самостоятельно ловить такие моменты. Доступ к текущим курсам всех символов, по которым приходят котировки, у него полный.

Абсолютно все форекс-компании не берут на себя никаких обязательств в секундах по продолжительности реакции сервера на запросы терминала. Большинство резервируют управление временем своей реакции за ситуациями, когда клиент начинает выводить средства или просто торгует слишком, по их мнению, прибыльно. Смотрите, например, http://kroufr.ru/forum/index.php?topic=24733.msg218222#msg218222 : "После первого вывода денег мне установили задержку исполнения ордеров в 40 секунд, после второго вывода задержку поставили больше минуты."

Очевидно, никакой связи с последовательностью прихода тиков и выставления ордеров здесь уловить не удастся.

Но даже в самых комфортных условиях, при самом благоприятном отношении компании к торговле клиента - например, на демосчете - сравнивать эти последовательности смысла нет. Вспомните, что исполнение ордера происходит на сервере, и последовательность "1.08240, 1.08230 (и тут мы выставляем ордер), далее 1.08240," относится не к событиям в терминале, а к событиям на сервере. Не надейтесь на то, что компания предоставит Вам все требуемое для анализа последовательностей, то есть тиковую историю в миллисекундах и логи сервера тоже в миллисекундах, включающие серверное время прихода ордера на обработку и серверное же время рассылки сервером каждого из тиков. Компании это делать не обязаны и не делают. Исключение - рассмотрение споров у регулятора, данные направляются опять-таки не Вам, а регулятору, обычно по его запросу. У Вас же в терминале этих данных нет, ведь задержка как минимум в половину пинга между сетевыми картами терминала и сервера в любом случае отделяет приход тиков от сервера в терминал и ордеров от терминала на сервер. И вряд ли Вы будете протоколировать на диск приход в терминал всех тиков. Тем более что этот протокол ни в каком случае не будет принят во внимание при рассмотрении споров. Об этом компании позаботились, задав в клиентских соглашениях приоритет данных с их сервера в случае споров.

P.S. Есть еще и очередь на исполнение. Если компания скажет, что в этот момент резко выросла нагрузка на сервер (новости или просто быстрый рынок), это уже неопровержимый аргумент исполнять почти как угодно. Есть еще и исчезновение ликвидности, которое тоже опровергнуть никак не удастся.

Я говорил, что эксперт ПОЛУЧАЕТ все тики, про обработку речь не шла. 
Естественно, что время обработки зависит от сложности эксперта.
(Ну, и козе понятно, что речь идет о том символе, на котором стоит эксперт.)  

 Не согласен. 
Проверено на реале: два отложенных ордера ставятся за время одного тика, т.е. по одной котировке. Хоть BUY+SELL, хоть однонаправленные. 
Три не проверял, врать не буду.

Конечно, есть ДЦ, которые искусственно загружают сервер бессмысленными операциями, тем самым увеличивая время обработки, но это проверяется элементарно и уродов вычислить не трудно.

PS. Уточню, эту проверку делал года три назад, экспериментировал с частичным закрытием позиции,
потом нашел более удобный способ с встречным ордером и функцией OrderCloseBy(). 
Так что имейте ввиду, что проверку все-равно надо будет повторить. Это не сложно.