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

Я, разумеется, могу чего-то не знать(, к чему уже "привык").  ))
Интересует FORTS.
И, как полагал, До последних двух лет там (от биржи до сервера QUIKвозможно, не непосредственно) использовался Plaza 2 (возможно, до сих пор).
А Plaza 2 - это полный анонимный ордерлог, где полный стакан (даже неагрегированный) можно получить единожды (и так его хранят архивы QScalp-a, который потом перестраивает (может перестраивать) стакан по результатам КАЖДОЙ следующей заявки).
Протокол позволяет на случай сбоев (уж не знаю в чем) передавать стакан полностью, чего QScalp НЕ ДЕЛАЕТ (не запрашивает и не получает, а зачем, и никаких сбоев, во всяком случае, в алгоритме не происходит).
Зачем стаканы получать серверу полностью, я не понимаю (так же, как и, признаюсь, с недоверием отношусь к таким заявлениям).
И вот это (лично для меня) мои "догадки" подтверждает.

Sergey Gorokhov написал:
https://forum.quik.ru/messages/forum10/message6732/topic685/#message6732
Добрый день, Мы провели разбор полученной информации и обнаружили причины описанной Вами проблемы. Временное "увеличение строк в стакане котировок" объясняется итеративностью в обновлении стакана котировок, когда обновляются ценовые уровни, один за другим. В связи с этим, при частом обновлении большого количества ценовых уровней, возникает возможность временно наблюдать окно котировок в состоянии, когда обновлена только часть ценовых уровней, а вторая часть ещё не обновлена и соответствует предыдущему состоянию. В этот момент в стакане могут появляться "лишние строки".
https://forum.quik.ru/messages/forum10/message6767/topic685/#message6767
Используется внутренний протокол QUIK который не подлежит разглашению.

НО . . .
дело , ведь НЕ В ПРОТОКОЛАХ.
Поймите, я не требую слать на терминал ЛЮБЫЕ изменения стакана, вызванные КАЖДОЙ меняющей его заявкой.
Опыт непонимания мной Ваших (ARQA) очевидных доводов имеется, а спустя месяца три ARQA признала мою правоту.
Жаль вот только результата ждал  месяцев 9.
К сожалению он оказался (так был реализован) непотребным, но спустя (в седьмой версии), вцелом  пользователи получили лучшее решение.

"Там" много протоколов.
С частью из них знаком. А Вы -- про  какой?

Да, и вот еще нашел:
http://forex.kbpauk.ru/showflat.php/Cat/0/Number/344682/an/0/page/
Цитата:
Еще раз (just for double check), от сервера приходят только изменения, которые собираются в полный стакан самой библиотекой (или терминалом).
Есть еще источники. . .  

А где почитать, -- не подскажете?

https://forum.quik.ru/forum10/topic1502/
"Например" . . . , бывает, -- живем в реальном мире . . .
100%. Компу не нужно будет "оборачивать" в LUA-таблицу весь стакан, а анализ/сравнение стакана с предыдущим его состоянием на нативной стороне на порядок быстрее.Объясните, плиз, чем информация об изменении среза информативнее информации о нем самом? Что мы/я в информации, полученной таким образом можем потерять/упустить. В приведенном Вами примере ИЗМЕНЕНИЯ строки с ценой 1201 (не попавшей в срез) НЕ БУДЕТ  НИ В НОВОМ СТАКАНЕ, ни в запрашиваемом мной изменении его состояния. Чем Ваш стакан информативнее его изменения.
и разумеется, . . . функция getQuoteLevel2 (getQuoteLevel2Ex) НУЖНА.Разумеется, могу, запросив результат через getQuoteLevel2, КОТОРАЯ БУДЕТ "В СЕБЕ" строить ПОЛНЫЙ СТАКАН, после чего мне (программе) надо будет его полностью принять ИЗ LUA на нативную сторону, . . . НА ЧТО И ТРАТИТСЯ  95-99 % времени = нагрузки на комп, СОЗДАННОЙ ИСКУССТВЕННО.
А я прошу Вас реализовать этот анализ на нативной стороне ("на всякий случай", НЕ СЕРВЕРА, а ТЕРМИНАЛА) ДО того, как строить одинаковую на 95% LUA-таблицу.
В результате, таблица сократится до 5%., а, значит, и нагрузка на комп, который СЕЙЧАС (при вызове getQuoteLevel2) обрабатывает не данные а ЛУА-стек.

PS. У меня такое ощущение, что Вы перепутали целесообразность с ответственностью.
Ранее она лежала исключительно на бирже, а сейчас Вы испугались, что она ляжет на Вас (ARQA).
Так вот, уверяю, что ВАША ответственность при реализации моей просьбы НИСКОЛЬКО не выше. ))
(Ваша нынешняя реализация НИЧЕГО не позволяет узнать о состоянии пропущенного среза стакана).
А правильно реализованный алгоритм той функции, о которой я прошу, ДАЖЕ в ответственности (в сравнении) -- гораздо лучший вариант,
чем предыдущие реализации getQuoteLevel2 с ошибками, о которых Вы, я уверен, -- осведомлены.

Скажу (на всякий "пожарный").
Вы что хотите сказать?
Что существующий алгоритм позволяет ИЗБЕЖАТЬ ситуации, при которой возможно  "пропускать цены"???  . . .  )))
Что мы приобретем, я представляю.
Однако, я не очень представляю, что мы теряем.
Может, я чего-то не знаю (не понимаю) ???

УМЕНЬШИТЬ нагрузку на комп

Не страшно.
ПОТАМУШТА.
С таймингами биржи/серверов/брокеров . . .
НАМ о "1201", КОТОРЫЙ в срез НЕ ПОПАЛ, . . . --  ВСЁ РАВНО.
пАчиму, . . . да потому, что нынешний алгоритм ARQA       НИЧЕГО лучшего НЕ ПРЕДЛОЖИЛ.
Мы как НЕ ЗНАЛИ о попадании в срез "1201" так и НЕ будем знать, НО (сократив ВРЕМЯ на обработку)
вместо 10 стаканов сможем себе позволить 100 (например, ИЛИ нагрузку на комп).
И лента нам (не всегда, но) -- в помощь.

Вот и славно.
Калбек придет -- мы будем знать, что изменение было.
А функция вернет пустую таблицу (или вообще nil или bid_count и offer_count = 0).
Результат достигнут,  -- время на построение LUA-таблиц при вызове альтернативной  функции многократно сократится.

Понятно, спасибо.
Однако, не понятно, почему нельзя сохранять предыдущий стакан (его состояние) и с ним сравнивать текущий.
На нативной стороне это гораздо быстрее. После чего на сторону LUA отдавать только строки с измененным количеством лотов.

Добрый день.
Сергей, я правильно Вас понял, что биржа (вероятно, всё-таки сервер QUIK) транслирует стакан каждый раз ПОЛНОСТЬЮ?

Добрый день.
1. Всех - "с наступающим".
2. Учитывая вышеписанное ("Итого, lua_pcall - порядка 99.1 - 99.3% всего времени" ... напомню, call была -- getQuoteLevel2), а также учитывая, что в подавляющем большинстве запросов стакан отличается от предыдущего не более, чем на 15%(а то и -- гораздо менее),
а также учитывая, что нормальный API нам АRQA никогда не предоставит,
Прошу зарегистрировать пожелание по развитию QUIK, а именно
Cделать в Qlua функцию, альтернативную getQuoteLevel2,
Которая будет передавать массив ТОЛЬКО ИЗМЕНЕННЫХ строк в стакане.

ДД
1 ."Затеваю" связанный вопрос в соседней ветке (по тематике ближе)
2. Возможно, "интерессанты" уже с проблемой разобрались,
  НО, как говорится, истина должна быть известна всем интересующимся.
В свете вышесказанного такой вопрос:
Допустим у биржи несколько "торговых площадок" (не я ввел данное утверждение).
Вопрос: А не по принципу ли брокеров с биржей они должны работать?
Поясняю (на всякий случай): Есть "Центральный офис" (ЦО), в котором фиксируются и обрабатываются все заявки по МЕРЕ ПОПАДАНИЯ в этот самый ЦО?
Если заявки должны быть обработаны в соответствии со временем прихода на торговую площадку, ТО:
Варианты развития событий, очевидно, -- следующие:
1. Конечный вердикт по принятию решения в чью пользу состоится сделка решается путем:
     а) по принципу первенства прихода в ЦО;
     б) руководствуясь принципом: если со всех офисов, пришли "следующие" транзакции, то опоздавших -- НЕТ;
     в) назначением таймаута, после которого заявка с какой-либо торговой площадки обрабатывается не по времени заявки, а по времени прихода в ЦО;
     г) "А, ПОФИГ", "используем" заявки, как НАМ "УДОБНЕЕ".
Поэтому несколько изменяю вопрос.
Как же (не синхронизируется время, а) упорядочиваются и обрабатываются заявки не бирже (ЦО), (как это выглядит для сервера QUIK)?

ДД !!!
Связанная ссылка (для интересующихся): https://forum.quik.ru/messages/forum10/message4422/topic496/#message4422
В свете вышесказанного (во всяком случае от меня и ответов на мои вопросы) возник следующий вопрос:
Правильно ли я понимаю, что:
1. в случае, когда изменения в стакане обусловлены лишь конкретной сделкой,
2. учитывая приоритетность потоков данных;
3. ОДНОЗНАЧНО;
              а теперь утверждение:
калбеки, отражающие данное изменение, придут в порядке:
1. заказанный от SetUpdateCallback (от CreateDataSource);
2. OnAllTrade;
3. OnQuote.
И НИКАК ИНАЧЕ?

На всякий случай:
Иными словами:
Изменение состояния, Связанное с одним событием по конкретному инструменту, НЕ МОЖЕТ БЫТЬ ОТРАЖЕНО в "стакане" раньше, чем в ленте?
Заранее спасибо.

Перезаказал данные.
Всё в порядке.   ???

Здравствуйте.
Тоже "обновился".
Сначала до 7.19 (от брокера).
Не понравилось, что в таблице Истории, заказываю показать параметры одного опциона, --
выдает совсем по другому.
в 7.23 -- та же трабла.

Здравствуйте.
Примите, пожалуйста, пожелание по развитию.
Хотелось бы в настройке графиков, для каждого графика/индикатора иметь "галочку" "отображать/не отображать"
Нужно, например, когда кому-нибудь что-то показываешь, но убирать графики индикаторы не хочется (совсем, т.к. в иных индикаторах необходимо много чего настраивать: периоды, идентификаторы и т.п.)
или для того, чтобы не плодить кучу окон, если используешь кучу индикаторов (меньше окон - выше окна).
Спасибо.

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

И третье.
Если Вы, конечно, правы относительно протокола UDP.
Биржа, ЧТО, разными протоколами данные шлет?
Ленту - одним (TCP, БЕЗ пропусков), остальное - другим?

Спасибо.
это ПЕРВОЕ.
Второе:
если речь о синхронизации, есть ли алгоритм ЛУЧШЕ, чем я предложил (даже понимая, что брокер может потерять отдельную  передачу)?

1. изменение таблицы, т.е. приход "новых" сделок (или Вы о другом)
2. а разве сделки могут проходить как-то иначе (не между временными срезами).
Ну, и и к вопросу,
если биржа транслирует сделки и изменения в  стакане последовательно, а сервер брокера их также последовательно ретранслирует, то нарушений в последовательности быть не должно.
Разумеется, стакан претерпевает от среза до среза несколько изменений.
Важно, что все протранслированные сделки были ДО текущего состояния стакана, а те которые будут протранслированы позже, значит -- позже того же состояния стакана.
Также прошу заметить:
1. я на этом не настаиваю, просто хочется понять как работают ваши алгоритмы.
2. разумеется, если я не прав (не так они работают, как я описАл), никто за несинхронизацию претензий к вам предъявлять не собирается.

Хотя как программист, уличаю Вас  в Неполноте описательной информации.
В частности ПРОСТО тейк-профит НЕ МОЖЕТ быть стоп-лимитом.
Так и - наоборот (стоп-лимит тейк-проифитОМ).
НО тейк-профит И стоп-лимит, ТЕМ-то от него (них) и отличается. ("Смекаете")
Если выполнилась СТОП-заявка ПРОСТО тейк-проифит, странно рассуждать, в какую сторону она выполнилась.
"Не находите"?
ТУТ "ВАШ ФЛАГ" да "не особенно-то и нужен". (можно отследить НЕ по одному передаваемому параметру).
т.е. НЕОБХОДИМОСТЬ отслеживания флаги и не НУЖНА
Совсем другое дело при выставлении стоп-заявки тейк-профит И стоп-лимит.
Возникает вопрос.
ПОЧЕМУ БЫ алгоритмам, передающим калбеки при срабатывании:
1. ПРОСТО тейк-проифит
и
2. тейк-профит И стоп-лимит,
НЕ БЫТЬ РАЗЛИЧНЫМИ.
Вы же пишите: ДАЖЕ стоп-заявка изначально обсуждалась НЕ  ПРОСТО тейк-профит

Возникает Очередной  вопрос
Вас, что,
СПЕЦИАЛЬНО к этому "пододвигают"
Чтобы пользователю установить ИСТИНУ, БЕЗ эксперимента НЕ обойтись.
Да мы бы и смирились
Если бы в процессе Вашего "усовершенствования" QUIK, QLUA непредсказуемых "новых" поведений Вашего ПО НЕ РОЖДАЛОСЬ.
Спасибо.

Не надо, вот теперь всё предельно точно и понятно. Спасибо.

Это - "фраза"

Именно так и понимаю.
Но меня интересует может ли быть так, что сработал, а флага "расчет" НЕ БЫЛО?
Во фразе заключена двусмысленность, из нее НЕ следует, что стоп сработал как тейк-профит.
А если это не так (не тейк-профит), то ясно/понятно, что флага и быть не должно.
И, разумеется, мне это известно, вот только . . .
Нужных выводов из фразы сделать НЕВОЗМОЖНО.
Флага не было потому, что:
1. тейк-профит исполнился, НО СРАЗУ, алгоритм в этом случае не предусматривает передачу калбека с флагом "расчет"
2. исполнился сразу, а, значит, - без фазы расчета, следовательно, - в сторону стоп-лимита.

1 Я это спрашиваю только по тому, что Старатель и Вы подразумеваете различное исполнение алгоритма, но Вы прямо не пишите, что Старатель НЕ ПРАВ.
2. я нигде и не писАл про стоп-заявку Стоп-лосс,я писалСТОРОНУ

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

Сергей, я уточню (на всякий пожарный), даже если стоп-ордер исполнился НЕ В СТОРОНУ СТОП-ЛОСС?

Уважаемые разработчики, это действительно так? Калбек с флагом "расчет" может не прийти?

. . .  НА сервере брокера?

Николай, не напускайте туману.
1. В скрипт калбеки по ленте приходят в нужном порядке.
2. Вопрос был адресован3 Я не вчера родился, а Вы про меня мало, что знаете.
4. Для начала бы понять, един ли источник информации, т.е. сервер ли ПРОСТО "перетранслирует" биржевые пакеты или тот стакан, который приходит в терминал, "рождается" по определенному алгоритму не сервере брокера.

Такой сложный вопросили раскрыл САКРАЛЬНОЕ ЗНАНИЕ?

Здравствуйте, "тема уже поднималась", но безрезультатно, или почти так.
Зачем время изменения стакана, чтоб "по максимуму" синхронизировать его с лентой?
Если только для этого, то не проще ли (а, возможно, и - точнее, а может быть даже, это ключ к механизму синхронизации.
Уважаемые разработчики, ответьте, пжлст, на такой вопрос.
Если "мы подписались на ленту" "через CDS", и следим за порядком следования калбеков,
можно ли утверждать, что все сделки в ленте на бирже сработали раньше, чем момент временного среза стакана, ЕСЛИ
калбеки OnAllTrade пришли раньше очередного OnQuotes, и наоборот
сделки прошли позже, если соответствующие калбеки OnAllTrade пришли позже очередного OnQuotes.
Иными словами порядок следования событий свершения сделок и фиксации состояния стакана не нарушается и совпадает
с порядком следования соответствующих калбеков?
Спасибо.

Здравствуйте.
Однако, я правильно понимаю, (возвращаясь к ПЕРВОНАЧАЛЬНОЙ теме обсуждения):
Что, если ПРЕЖДЕ пришел калбек с флагом "расчет", то сохранив "данное знание в переменной",
"по исполнении" мы можем ОДНОЗНАЧНО понимать "в какую сторону" выполнилась стоп-заявка?
Т.е. если с таким флагом калбек был, значит, - в тейк, иначе - в лосс.

Здравствуйте.
Полагаю, не стоит создавать тему для аналогично однозначного ответа на мой вопрос.
Поэтому пишу сюда.
Подскажите пожалуйста, как будет реагировать "система" в случае "несколько нестандартном".
Допустим я разработал ТС, в которой ожидаю повторных "ударов рынка в уровень".
Для этого я использую стоп-заявку TAKE_PROFIT_AND_STOP_LIMIT_ORDER,
в которой защитный спред равен по величине отступу, но отрицателен.
Вопрос в том, останется ли стоп-лосс-половинка этой заявки в активном состоянии после того, как
условия по стоп-цене 1 выполнились (фаза расчета прошла), отступ тоже "сработал".
Если мы рассчитывали на рост (поставили продажу), стоп-заявка должна выставить лимитную по хаю в сделке. Это - ВСЁ?
После того, как срабатывает фаза расчета, защитная часть стоп-заявки снимается?
Спасибо.

Сергей, может "тогда" поясните, что "это" (http://prntscr.com/envnpr) значит?
Или  (110960 тире 113040, т.е. вчера 23.03.17)    >   (БОЛЬШЕ), чем 125000?

И когда это произойдет в калбек какие флаги придут?

"флаг" = флаги: 0х010 or 0х008 or 0х001 = стоп + лимитированная + активная
бит 4 недокументирован, но по факту вот такие флаги приходят
лимитированная, по всей видимости, потому, что признак MARKET_TAKE_PROFIT для TAKE_PROFIT_STOP_ORDER
не устанавливается.
OnStopOrder вызывается, когда заявка исполняется или МЕНЯЮТСЯ параметры.
В какой последовательности придут калбеки И с какими флагами, если статусы могут быть:
1 стоп-заявка установлена;
2 Идет расчет минимума-максимума;
3 выполнено условие подвинуть пределы (цена изменилась при покупке до величины STOPPRICE + OFFSET + шаг цены);
4 исполнена.
И что происходит в процессе: Идет расчет минимума-максимума.
???
Спасибо.

Может, если бы я был "в позе", первый калбек бы содержал флаг "просто" 0х019?

Сергей, а что будет, если цена превысит стопцену+ оффсет?
Я вчера экспериментировал, но ("подальше от греха") стопцена была много больше.
Заявка, действительно, была с флагом 0х8000, НО вне зависимости от исполнения условия.
она сразу приняла статус  "расчета минимума максимума".
Я оговорюсь, что я и в позе-то никакой не был.
А что будет, когда исполнятся условия на тейк?

Здравствуйте.
Подскажите пожалуйста.
С каким флагом будет таблица стопзаявки TAKE_PROFIT_STOP_ORDER в OnStopOrder,
в случае, если превышен OFFSET, т.е. параметры заявки сдвинулись в сторону "улучшения" сделки?
Если  данный признак читается в  другом месте, то в каком?
Изменится ли при этом STOPPRICE или какой другой параметр?
Спасибо.

Спасибо, "конечно".
Скрипт - в вариациях.
И странное дело. Чем больше "размусаливешь":
- sleep добавить между вызовами CreateDataSource
- collectgarbage добавить,
-- ВСЁ мёртвому припарки.
Всё еще немного усложнено:
- разным объемом (в разрезе по бумагам) поставками данных от разных брокеров/их серверов
- сравнительной скоростью поставки данных и скоростью компа
-  объемом  инфы по запрашиваемым графикам (проблем больше на Газпроме и
Сбере, где данных МЕНЬШЕ)
- конфигурацией компа в плане его аппаратной мультизадачности.
Запрос с файлами отправил.
Заранее спасибо

Всем, здравствуйте.
Есть такая незадача.
На определенном этапе работы скрипта CreateDataSource
отказывается вызываться.
Бумаг прилично и еще под их параметры - столько же.
Итог: не хватает памяти.
Изначально для большего быстродействия таблицы были объявлены локальными.
Когда проблема вскрылась, переделал на глобальные, скрипт стал заказывать данных больше, однако, решить надежно проблему не удалось.
Что посоветуете, можно ли заказать памяти для скрипта больше или по другому как-то ей управлять ?
Заранее, спасибо.

Здравствуйте, я правильно понимаю, что в последней версии QUIK (Qlua) CreateDataSource может вызываться не только из main.
Или я что-то придумываю.
Есть ли возможность в последней версии вызывать ее из скриптов индикаторов.
Спасибо.

Здравствуйте, вопрос из той же "песни".
А как тогда объяснить, что при удалении индикатора, который использует данные "предыдущих" индикаторов и выставлении его снова,
для него все уже имеющиеся должны бы быть именно "предыдущими" и пересчитаться.
Однако, его снос и выставление не решает проблему автоматического его пересчета.
Некоторые его линии остаются нерассчитанными, каждый раз приходится его перепривязать к другой оси (левой/правой), чтоб искусственно заставить его пересчитаться.
Спасибо.

Здравствуйте, господа разработчики.
Пытаюсь "чего-то"  написАть, типа коннектор/советник/робот.
Но суть в другом, просто при программировании некоторые траблы всплывают на поверхность, а при работе вручную их не видно (не нужны).
Заметил такую "штуку". Выставлена заявка. Если ее снимать явно - проходит транзакция, а если пытаться изменить, но потом от изменений отказаться (нажать Esc), -- никаких тразакций, но заявка снимается. Считаю это некорректностью алгоритма работы терминала и прошу принять заявку по ее устранению.
Спасибо.

И есть ли в этом разница для калбеков OnAllTrade?
Спасибо.

Здравствуйте, помню, вроде, вопрос поднимался.
Объясните, пожалуйста, в каком случае в калбеки, устанавливаемые SetUpdateCallback (от CreateDataSource) будут приходить все данные, в том числе пропущенные с начала сессии, а в каком только новые?
Спасибо.

Здравствуйте.
Возможно, ранее обсуждался данный вопрос, Да, видимо, остался в архиве, который недоступен.
Суть в следующем.
Порой в OnQuote приходит количество строк на покупку/продажу больше нормального 20/50.
Пожалуйста посоветуйте как интерпретировать такие данные. Какие строки из 52-х bid (например) верны? Как понимать в этом случае спред?
Заранее спасибо.