Добрый день Вопрос к разработчикам QUIK. Наблюдаю следующую картину. 1) В информационном табло Задержка данных при обмене с сервером составляет при малой загрузке сервера брокера (нет торгов или вечерняя сессия) от 63 до 170 мс при большой загрузке (начало торгов активная сессия) 150 ... 250 мс (временами до 1 сек) 2) пинг на ip севера дает 16 мс ---------------------------- Получается, что запаздывание ответа от сервера терминалу в 10-20 раз больше, чем запаздывание за счет каналов связи. -------------------------- Вопрос: 1. Какая возможная причина такого запаздывания ответа сервера брокера? 2.Брокер умышленно создает дополнительное запаздывание? Верно? 3. Это делается средствами QUIK или доп оборудованием? 4. С какой целью это делается? Ваши варианты. Спасибо
а у меня так вообще в информационном окне данные о задержках не выводятся (при включении соответствующих строк - нет данных), вероятно это функция отключена брокером? (квик 6.17.3.6)
Denis написал: в техпо брокера сказали обратиться к разработчику ПО...
Добрый день.
Денис, для того, чтобы данные поля заполнялись, зайдите в пункт меню Связь/Доступные соединения у установите галочку "проверять связь с сервером каждые....", укажите время и дождитесь результатов.
Egor Zaytsev,спасибо, теперь задержки отображаются, а 0.110 это 110 мс? Прошу прощения у топикстартера, что влез в его тему, прошу support ответить и на его вопросы тоже;) Спасибо.
Denis написал: а у меня так вообще в информационном окне данные о задержках не выводятся (при включении соответствующих строк - нет данных), вероятно это функция отключена брокером? (квик 6.17.3.6)
Denis написал: Egor Zaytsev ,спасибо, теперь задержки отображаются, а 0.110 это 110 мс? Прошу прощения у топикстартера, что влез в его тему, прошу support ответить и на его вопросы тоже;) Спасибо.
Цитата
а 0.110 это 110 мс?
Да.
Цитата
Прошу прощения у топикстартера, что влез в его тему, прошу support ответить и на его вопросы тоже;) Спасибо.
Николай Камынин написал: Добрый день Вопрос к разработчикам QUIK. Наблюдаю следующую картину. 1) В информационном табло Задержка данных при обмене с сервером составляет при малой загрузке сервера брокера (нет торгов или вечерняя сессия) от 63 до 170 мс при большой загрузке (начало торгов активная сессия) 150 ... 250 мс (временами до 1 сек) 2) пинг на ip севера дает 16 мс ---------------------------- Получается, что запаздывание ответа от сервера терминалу в 10-20 раз больше , чем запаздывание за счет каналов связи. -------------------------- Вопрос: 1. Какая возможная причина такого запаздывания ответа сервера брокера? 2.Брокер умышленно создает дополнительное запаздывание? Верно? 3. Это делается средствами QUIK или доп оборудованием? 4. С какой целью это делается? Ваши варианты. Спасибо
Добрый день.
Николай, по задержкам рекомендуем обратиться к брокеру. Также обратим внимание, что средствами именно QUIK организовать задержки нельзя.
т е отвечать на поставленные вопросы Вы не хотите. Например, Вы можете показать результаты своих тестов задержки для любого брокера не называя его? или таких тестов вы не делали? Т е вам это по...? для информации привожу результаты мониторинга задержки ответов за вчера:
Добрый день, выкладываю картинку мониторинга канала связи и задержки данных сервером QUIK.
как видно из графиков ( задержка канала фактически постоянна и равна 27 ms) задержка данных сервером QUIK имеет огромные величины. Как говорил классик: Может быть в консерватории пора что-то изменить? ------------------------------------ Налицо ляпы либо в ядре сервера либо в головах технической службы брокера. --------------------------------- Хотелось бы услышать начальника транспортного цеха по данному вопросу.
Николай Камынин написал: т е отвечать на поставленные вопросы Вы не хотите.
Добрый день.
Чтобы ответить на вопросы и понять в чем причина задержек нам потребуются серверные логи Вашего брокера, точную дату, когда вы делали замеры, ваш UID. Поэтому и было предложено обратиться к брокеру и инициировать свое обращение к нам.
Добрый день. Пинг, который Вы смотрите в параметре LASTPINGDURATION, не является пингом в классическом понимании (ICMP протокол). Это определенные данные, которыми терминал и сервер обмениваются в процессе работы. Приоритет таких сообщений очень низкий. Это значит что ответные "понги" клиенту будут отправляться только в том случае, если больше нет торговых данных в очереди на отправку. Этим и объясняется разница между приведенными выше данными.
Michael Bulychev написал: Добрый день. Пинг, который Вы смотрите в параметре LASTPINGDURATION, не является пингом в классическом понимании (ICMP протокол). Это определенные данные, которыми терминал и сервер обмениваются в процессе работы. Приоритет таких сообщений очень низкий. Это значит что ответные "понги" клиенту будут отправляться только в том случае, если больше нет торговых данных в очереди на отправку. Этим и объясняется разница между приведенными выше данными.
Добрый день,Михаил, С тем, что это не пинг а что-то Ваше - это понятно. Теперь просьба на конкретных данных мне объяснить вот наиболее интересные: Я выбрал лишь задежкии более 1 секунды. как видно их тьмы и тьмы. ------------------------------ Как Вы объясните наличие задержки в 10 секунд в 14:23:49 в 16:07:02. ---------------------------- какие по-вашему мнению так интенсивно отсылались по каналу в 100 мбит? ----------------------- И куда эти данные пришли, если я за это вреня не получил эти мегабайты ------------------------ Как сказал классик: "Суха теория, мой друг"
и еще хотел бы заметить, что это время называется - ЗАДЕРЖКА ДАННЫХ т е либо это просто так написано либо этот параметр показывает нам именно то, как его назвали. Ваше мнение?
В последнее время обратил внимание (и не только я) на наличие задержек в получении биржевой информации (также порой до 10 сек), ответов по транзакциям (до 3 сек) при постоянном пинге не более 5-7 мс. В связи с чем наблюдаются такие проблемы: тут и тут.
Надо делать так, как надо. А как не надо - делать не надо.
а вот еще прикол: 2016-02-29; 17:33:57; 16; 26.8 задержка данных 16 ms при пинге 26.8 ms типа терминал с сервером по спец каналам связались, или терминал вообще сам ответ состряпал. (умный терминал, однако)
а вот здесь , сервер очевидно заснул аж на 22 секунды, а потом долго просыпался (умный сервер,Однако) 2016-02-29;17:19:56; 22969; 39.2 2016-02-29;17:20:14;12187;27.3 2016-02-29;17:20:51;20672;27.1 2016-02-29;17:21:28;18172;27.7 2016-02-29;17:21:46;8515;27.5
Michael Bulychev прочитайте ответ Вашего коллеги Sergey Gorokhov https://forum.quik.ru/forum10/topic1169/ который пишет Видимо речь идет о параметре "Задержка данных при обмене с сервером", если так, то этот параметр работает точно так же как и обычная команда ping и обсудите с ним Вашу гипотезу .
Добрый день. В чем-то действительно есть сходство со стандартным пингом. Разница только в уровне реализации. Я имею ввиду сетевую модель OSI. Еще раз повторю - приоритет у таких сообщений в протоколе минимальный. Поэтому большие задержки могут в случае если:
достаточно интенсивный поток торговых данных на сервере и серверу есть что отправить клиенту кроме ответа на пинг;
клиент недостаточно быстро выбирает данные по сети от сервера. Это может быть по причине плохой связи либо "тормозов" терминала;
В общем ничего особенно страшного в больших числах нет, при условии что терминал в это время не испытывает проблем с получением данных.
Michael Bulychev написал: Добрый день. В чем-то действительно есть сходство со стандартным пингом. Разница только в уровне реализации. Я имею ввиду сетевую модель OSI. Еще раз повторю - приоритет у таких сообщений в протоколе минимальный. Поэтому большие задержки могут в случае если: достаточно интенсивный поток торговых данных на сервере и серверу есть что отправить клиенту кроме ответа на пинг; клиент недостаточно быстро выбирает данные по сети от сервера. Это может быть по причине плохой связи либо "тормозов" терминала; В общем ничего особенно страшного в больших числах нет, при условии что терминал в это время не испытывает проблем с получением данных.
т е данный показатель сделан просто так ( кто делал уже уволился , а кто работает, тот точно не знает, зачем это). верно? и почему это меня не удивляет. Спасибо.
Добрый день. Возможно он называется не совсем понятно, но показывает ровно то, для чего был сделан. Если не устраивают результаты - используйте стандартный пинг.
Добрый день, продолжаю исследования скорости поступления информации от сервера КВИК к терминалу КВИК т е от брокера к клиентам. В данном случае брокер - БКС. Приведу лишь кратное описание и результаты для любознательных. Более подробные результаты исследований выложу позже на своем сайте. ----------------------- Описание эксперимента: Компьютер синхронизируется каждые 5 минут от сервера эталонного времени. параметры стабильности синхронизации следующие: -------------------------------- d:+00.0155878s - это задержка получения сигнала точного времени в мs o:-00.0804192s - это отставание часов моего компьютера от часов сервера в мs ------------------------- Т е часы моего компьютера имеют ошибку не более 80 ms. ------------------------------------------------------------------------------------------- Теперь подписываемся на тики Сбербанка и определяем разницу времени сделок с временем моего компьютера. Таким образом, эта разность покажет нам на сколько х.... o сервер брокера транслирует данные с биржи. --------------------------- Что же получили в осадке: ВНИАМНИЕ на ЭКРАН: ВПЕРВЫЕ в МИРЕ проведены измерения запаздывания данных с биржи через сервер QUIK на термина клиента . d -задержка зу-цена сделки q -количество v -объем 03/04/16 13:33:11 d=956, pe=107.36, q=155, v=166408 03/04/16 13:33:11 d=956, pe=107.36, q=84, v=90182.4 03/04/16 13:33:11 d=956, pe=107.36, q=140, v=150304 03/04/16 13:33:11 d=1458, pe=107.36, q=17, v=18251.2 03/04/16 13:33:11 d=1458, pe=107.36, q=121, v=129905.6 03/04/16 13:33:11 d=1452, pe=107.36, q=84, v=90182.4 03/04/16 13:33:11 d=1179, pe=107.35, q=10, v=10735 03/04/16 13:33:11 d=1154, pe=107.35, q=145, v=155657.5 03/04/16 13:33:11 d=1154, pe=107.35, q=35, v=37572.5 03/04/16 13:33:12 d=517, pe=107.35, q=149, v=159951.5 03/04/16 13:33:16 d=602, pe=107.35, q=364, v=390754 Приняв в качестве смещения результата величину 80+15=95 ms (это время отставания моих часов и запаздывание по каналу связи с сервером КВИК получаем: время задержки от 0.5 сек до 1.5 сек --------------------- "Удивительное -рядом, но оно запрещено.."
и еще... Если Вы включите свое воображение, то можете себе представить, что можно сделать за эти секунды имея на руках всю информацию о уже совершенных на бирже сделках ----------------------------- Знал бы прикуп - жил бы в Сочи. Знал бы цену акций - жил бы в Лондоне.
Николай Камынин, проведите измерения задержек получения тиков на срочной секции. Вы будете "приятно" удивлены: сделки по срочной секции иногда запаздывают по сравнению с фондовой на 2 и более сек.
А вот тут не понятно:
Цитата
Николай Камынин написал: o:-00.0804192s - это отставание часов моего компьютера от часов сервера в мs ------------------------- Т е часы моего компьютера имеют ошибку не более 80 ms.
С каким сервером сравниваете? Если QUIK, то время сервера QUIK можно вообще не брать в расчёт. Если сервера времени, то у биржи может быть своё мнение, на то с каким сервером синхронизировать.
Надо делать так, как надо. А как не надо - делать не надо.
сегодня вообще прикол фьючерсы от бкс все еще идут с задержкой на 15 минут, а акции нормально. Это круто. Торгую фьючерсами, а смотрю в акции иначе полный п...
Старатель написал: Николай Камынин , проведите измерения задержек получения тиков на срочной секции. Вы будете "приятно" удивлены: сделки по срочной секции иногда запаздывают по сравнению с фондовой на 2 и более сек.
А вот тут не понятно:
Цитата
Николай Камынин написал: o:-00.0804192s - это отставание часов моего компьютера от часов сервера в мs ------------------------- Т е часы моего компьютера имеют ошибку не более 80 ms.
С каким сервером сравниваете? Если QUIK, то время сервера QUIK можно вообще не брать в расчёт. Если сервера времени, то у биржи может быть своё мнение, на то с каким сервером синхронизировать.
Николай, не забывайте, что время течёт по разному даже на разных этажах и широтах. Потомучто гравитация не везде однородна. Но тут надо квантованного физика подключить к изучению временных задержек.
Правда, уже есть течение среди разработчиков, которые не поклоняються Квику. Ушли в горы, так сказать. Штурмуют фикс-протокол.
читал я фикс и плазу и спектру. это все другого уровня решения (типа надо к затратам дописать справа пару нулей ) и необходимо для HFT роботов. А я ваяю прогнозирующих роботов , а им то и не очень надо быстро бегать. ------------------------------- Вопрос то не в том что есть, а в том сколько точно граммов есть. ----------------------------------- ...За державу обидно
Николай Камынин написал: читал я фикс и плазу и спектру. это все другого уровня решения (типа надо к затратам дописать справа пару нулей ) и необходимо для HFT роботов. А я ваяю прогнозирующих роботов , а им то и не очень надо быстро бегать. ------------------------------- Вопрос то не в том что есть, а в том сколько точно граммов есть. ----------------------------------- ...За державу обидно
Вы спросите брокеров: Кто из них синхронный канал к бирже и к Инету имеет, именно синхронный-оптоволоконный.
А зачем? ----------------------- Проблема не в каналах. Проблема в том, при скоростях в каналах 50-100 Мбит/c и задержке 3-15 мс мы получаем данные с серверов QUIK брокеров c задержкой от 200 до 2000 мс. --------------------------- Лет десять назад в штатах посадили группу брокеров за то, что они некоторым своим клиентам совершали сделки лучше чем другим, естественно за счет других. ------------------------------ Вот меня интересует вопрос: задержка данных в 10-1000 раз большая, чем задержка в канале, - это умысел или просто наплевательское отношение к клиентам? ----------------- Если первое - то это УК РФ, ---------------- если второе - то это нормальный бизнес в РФ
Так в том-то и дело если у брокера просто толстый, но некачественный канал от "своего" другана-братана-пацана, то и отсюда и накладка на его стороне. Ну а потом уже и клиенту всякие отбросы со стола.
Фёдор Сухов написал: забыл упомянуть про пинг, что это не показатель, совсем не показатель.
Ровный пинг, по крайней мере, показывает, что периодические задержки в поступлении информации с сервера не могут быть обусловлены проблемами на канале связи клиент-сервер, как чаще всего, утверждают сотрудники техподдержки брокера. Скорее, проблема в недостаточной инфраструктуре самого брокера.
Фёдор Сухов написал: Так в том-то и дело если у брокера просто толстый, но некачественный канал от "своего" другана-братана-пацана, то и отсюда и накладка на его стороне. Ну а потом уже и клиенту всякие отбросы со стола.
Фёдор Сухов написал: забыл упомянуть про пинг, что это не показатель, совсем не показатель.
Ровный пинг, по крайней мере, показывает, что периодические задержки в поступлении информации с сервера не могут быть обусловлены проблемами на канале связи клиент-сервер, как чаще всего, утверждают сотрудники техподдержки брокера. Скорее, проблема в недостаточной инфраструктуре самого брокера.
Николай Камынин , а чем пинги снимаете?
Давайте разделим в две посуды мух и котлеты. и будем есть котлеты. Расскажу все по-порядку (немного лекбеза , кто знает не ругайтесь). 1) Изучаем каналы связи с помощью пинга. Пинг у меня реализован так - посылает короткий запрос по ICMP_ECHO. Перед посылкой фиксируем время с погрешностью 100 нс. При приеме ответа от сервера фиксируем время прихода ответа. Разность - время задержки. Если сравнить с системной командой ping, то у меня отличие в десятых долях, так как системный измеряет в мкс. Ответ на ICMP запрос отдает ядро ОС сервера и этот ответ фактически не зависит от работы КВИКА. Таким образом, минимальная задержка пакетов от сервера брокера до меня 17-24 ms, в зависимости от выбранного мною сервера. ------------------- 2) Канал сервер-брокер по определению хороший, так как БКС - это крупный брокер в россии, работает давно и сервер его либо на бирже либо рядом. Полагаю что там задержки не более 1-2 ms. 3) пинг, который встроен в терминал КВИК показывает задержки от 50 до 10 000 ms. Как объяснил г-н Михаил, это результат задержки ядром сервера КВИК ответа на пинг. Не возражаю, но из этого следует, что сервер задерживает и более важную информации т е информацию о сделках, что собственно подтверждает следующий эксперимент. ----------------------- 3) Далее я синхронизировал свой комп с сервером точного времени 1-го уровня. В результате получил на сегодня:
вот такую нестабильность. Т е отставание моих часов составляет не более 40 ms от эталонных атомных.
Теперь я считаю, что это время биржи, так как синхронизация часов на бирже полагаю сделана еще точнее.
В принимаемых сделках мы имеем время сделки с микросекундами. ----------------------------- Таким образом, разница времени моего компа и времени в сделках есть величина задержки данных брокером. -------------------------- Клиентам брокера вообще-то без разницы, в каком месте тракта у брокера запор, но если задержки в 500- 1500 ms будут систематически ( а вчера информация по фьючерсам у меня задерживалась аж на 20 минут) , то полагаю, что надо ставить клизму в надлежащий канал такого брокера.
Совсем нехорошо получается. Давно это обстоятельство наблюдаю, но сам не замерял так обстоятельно, как это сделали выше В чёрный список можно добавить ещё одного брокера - Открытие. Итак: 1. БКС 2. Открытие 3. ??? (добавьте своего).
БКС - 4-ый брокер, с которым я связывался. Задержки были у всех, но бкс - "чемпион". Особенно вечером. Сначала наивно думал, что у них сервер тугой, много клиентов, а на нормальное оборудование жмотятся, денег жалко. Но давайте посмотрим правде в глаза. 05.03.16г по каналу РБК была передача про банк "Открытие", где его руководитель в откровенной беседе обмолвился о том, что 90 процентов прибыли банку приносит брокерская деятельность! Так о чем тут говорить! Я никогда не поверю, что их сотрудники (наемники) разбираются в проблеме лучше нас с Вами. Просто тупая задержка времени дает неоспоримые преимущества одним за счет других. Многие брокеры обещали прямое соединение с биржей, минуя их сервер (Плаза2 и тд.), но до самого "прямого" подключения, по разным (их) причинам, так ни у одного брокера дело и не дошло. А Вы не пробовали? Спасибо за реальную поднятую проблему.