user (Все сообщения пользователя)

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

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

Да.
А если на qpile искать свечку по дате - это заметно нагружало процессор, в случае если количество свечек - тысячи. Если в соотв. настройке уменьшить количество свечей - нагрузка падала. Как потом оказалось - нужная свеча в квике искалась путём итерации по всему массиву свечей, несмотря на то, что они отсортированы по времени! И в направлении от старых к новым, хотя, очевидно, что к последней свече обращаются чаще. Но этой информации несколько лет, возможно, что-то и поменялось с того времени.

Сколько-то лет назад я выковыривал свечки из квика путём прямого чтения памяти. Хотя, возможно, что это касается только тех объектов, с которыми я имел дело, и не следует обобщать.

Я про то, что есть настройка для графиков - "показывать последние N свечек". По моей информации - именно такое количество свечек и хранится в оперативной памяти. С появлением новых свечек - старые стираются.

Да, так тоже было неплохо - настройка - хранить последние N записей в таблице. Кстати, так и сделано для графиков. Непонятно, почему решили ограничить потребление памяти у менее ресурсоёмких объектов, и не ограничивать - у сáмого ресурсоёмкого.

Есть такая потребность - таблица всех сделок, которая не сохраняется в памяти квика. Т.е. пришла сделка в квик, он ее отдал при помощи callback, и забыл.

Зачем? Очевидно, чтобы не занимать память PC мусором. Было бы полезно для роботоводов. Может быть, как опция при заказе всех сделок из скрипта, может как-то иначе эта функция может работать - можно подумать.

Вопрос - есть шанс на реализацию?

На всякий случай, цитата из описания интерфейса биржи

http://s019.radikal.ru/i605/1509/5a/3df31570cf9d.png

В логе из первого сообщения - для ордеров, начинающихся на "num:1394" - всегда "transaction:0"

Ок. Я действительно не знаю, кто был мой контрагент в сделках с биржевой комиссией =0. Попробуем дождаться комментариев ARQA.

Где противоречие в моих словах?

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

Вы вопрос не совсем корректно сформулировали. Не факт, что брокер - контрагент. Вполне может быть, что сводились клиентские заявки.

Через квик, акции. На на срочном рынке такого не наблюдалось.

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

не ту ссылку скопировал.
ftp://ftp.moex.com/pub/info/stats/history/F//2015/FT150806.zip

Можно не гадать
ftp://ftp.moex.com/pub/info/stats/history/F//2015/f150806.ZIP
RIU5;RTS-9.15;82700.00000;10000;2015-08-06 14:41:42.167;1185838445;1

Не  ITInvest реже, а Квик чаще, дергая OnQoute не по делу, когда стакан в процессе изменений.
И пока что не видно способа надежно детектировать такие состояния стакана.

У меня есть записи стаканов от itinvest. Там не наблюдается такого, чтобы bid_count или offer_count стали в какой-то момент больше номинала ( по 50, в каждую сторону). Еще, замечено, что количество событий OnQuote в Квике всегда заметно больше, чем в itinvest (за тот же интервал времени, при одинаковой глубине стакана).

Сделал распечатку стаканов в моменты времени, когда bid_count>50 || offer_count>50.
http://pastebin.com/WfF4FkDg
что там:
-штамп времени
-три стакана в ряд (до проблемного момента, сам момент и следующий за ним)
для каждого стакана в скобках указано bid_count и offer_count, bids - слева от цены, asks - справа. Инструмент - RIZ2, цена -  в шагах.
Что интересного подметил. На примере последней тройки стаканов. Появляется "лишний" 51-ый bid на цене 13866 (средний стакан). Зачем? Ответ - в следующем стакане(справа) исчезает bid на цене 13916, снова все нормально.
Вывод: на момент времени среднего стакана уже было известно, что bid по 13916 исчез, но узнаем мы об этом с задержкой, ничем не обоснованной. Ту информацию, что ближе к спреду надо бы обновлять более приоритетно.

Очень просто все можно понять, бирж - более чем одна, у каждой свое время, у сервера квика - свое. С чем и чего синхронизировать? С какой точностью (и почему именно с такой)?  
Допустим, у вас есть время сервера квика. Там забыли время перевести (осеннее / зимнее) , потом вспомнили, и перевели прямо во время торгов. И у вас робот позицию потерял, или что-то типа того? Ну смешно же ведь?

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