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

Выбрать дату в календареВыбрать дату в календаре

Страницы: Пред. 1 2
Минимальный размер видимой части у айсберга
 
Привожу для сообщества список инструментов на TQBR с размером лота (параметр есть в Квике) и минимальной видимой частью айсберга заявки (последний аргумент, измеряется в лотах). Данные из таблицы А-5.
Было бы логично иметь соответствующий параметр и в самом Квике.

Код
"ABRD", 10, 10
"AFKS", 100, 100
"AFLT", 10, 10
"AGRO", 1, 100
"AKRN", 1, 100
"ALBK", 10, 100
"ALNU", 1, 1
"ALRS", 10, 10
"AMEZ", 100, 100
"APTK", 10, 100
"AQUA", 10, 100
"ARSA", 1000, 100
"ASSB", 1000, 100
"AVAN", 1, 100
"AVAZ", 100, 100
"AVAZP", 100, 100
"BANE", 1, 100
"BANEP", 1, 100
"BELU", 1, 100
"BISV", 100, 100
"BISVP", 1000, 10
"BLNG", 100, 100
"BRZL", 1, 10
"BSPB", 10, 100
"CBOM", 100, 100
"CHEP", 10, 100
"CHGZ", 100, 10
"CHKZ", 1, 100
"CHMF", 1, 100
"CHMK", 1, 100
"CLSB", 10000, 100
"CLSBP", 10000, 100
"CNTL", 100, 100
"CNTLP", 100, 100
"DASB", 10000, 100
"DIOD", 100, 100
"DSKY", 10, 100
"DVEC", 1000, 100
"DZRD", 1, 100
"DZRDP", 1, 100
"ELTZ", 1, 100
"ENPL", 1, 100
"ENRU", 1000, 100
"FEES", 10000, 100
"FESH", 100, 100
"FIVE", 1, 100
"FTRE", 1, 100
"GAZA", 10, 10
"GAZAP", 10, 10
"GAZC", 10, 100
"GAZP", 10, 100
"GAZS", 10, 100
"GAZT", 10, 100
"GCHE", 1, 100
"GEMA", 1, 100
"GMKN", 1, 10
"GRNT", 1000, 100
"GTRK", 10, 100
"GTSS", 100000, 100
"HALS", 1, 100
"HIMC", 1000, 10
"HIMCP", 1000, 100
"HYDR", 1000, 100
"IDVP", 1, 100
"IGST", 1, 100
"IGSTP", 1, 10
"IRAO", 1000, 100
"IRGZ", 100, 100
"IRKT", 100, 100
"ISKJ", 100, 100
"JNOS", 100, 100
"JNOSP", 100, 100
"KAZT", 10, 10
"KAZTP", 10, 10
"KBSB", 10, 100
"KBTK", 10, 100
"KCHE", 10000, 100
"KCHEP", 10000, 100
"KGKC", 10, 100
"KGKCP", 10, 10
"KLSB", 100, 100
"KMAZ", 10, 10
"KMEZ", 1, 100
"KMTZ", 10, 100
"KOGK", 1, 1
"KRKN", 1, 10
"KRKNP", 1, 10
"KRKO", 100, 100
"KRKOP", 100, 100
"KROT", 10, 100
"KROTP", 10, 100
"KRSB", 1000, 10
"KRSBP", 1000, 10
"KSGR", 10, 100
"KTSB", 10000, 10
"KTSBP", 10000, 10
"KUBE", 10, 100
"KUNF", 100, 100
"KUZB", 10000, 100
"KZMS", 10, 100
"KZOS", 10, 10
"KZOSP", 10, 100
"LIFE", 100, 100
"LKOH", 1, 100
"LNTA", 1, 100
"LNZL", 1, 10
"LNZLP", 1, 100
"LPSB", 100, 10
"LSNG", 100, 100
"LSNGP", 10, 100
"LSRG", 1, 100
"LVHK", 100, 100
"MAGE", 1000, 100
"MAGEP", 1000, 100
"MAGN", 100, 100
"MERF", 100, 10
"MFGS", 10, 10
"MFGSP", 10, 10
"MFON", 1, 10
"MGNT", 1, 10
"MGNZ", 1, 10
"MGTS", 1, 10
"MGTSP", 1, 10
"MISB", 100, 10
"MISBP", 100, 10
"MNFD", 1000, 100
"MOBB", 100, 10
"MOEX", 10, 100
"MORI", 1000, 10
"MRKC", 1000, 100
"MRKK", 10, 100
"MRKP", 10000, 100
"MRKS", 10000, 100
"MRKU", 10000, 100
"MRKV", 10000, 100
"MRKY", 10000, 100
"MRKZ", 10000, 100
"MRSB", 10000, 100
"MSNG", 1000, 100
"MSRS", 1000, 100
"MSST", 100, 100
"MSTT", 10, 100
"MTLR", 1, 100
"MTLRP", 10, 100
"MTSS", 10, 100
"MVID", 10, 100
"NAUK", 10, 100
"NFAZ", 10, 100
"NKHP", 10, 10
"NKNC", 10, 100
"NKNCP", 100, 100
"NKSH", 100, 100
"NLMK", 10, 100
"NMTP", 100, 100
"NNSB", 1, 100
"NNSBP", 1, 100
"NPOF", 1, 10
"NSVZ", 10, 100
"NVTK", 1, 10
"OBUV", 10, 100
"OGKB", 1000, 100
"OMZZP", 1, 100
"OPIN", 1, 100
"PAZA", 1, 100
"PHOR", 1, 100
"PIKK", 10, 100
"PLSM", 1000, 10
"PLZL", 1, 100
"PMSB", 10, 100
"PMSBP", 10, 100
"POLY", 1, 100
"PRFN", 1000, 100
"PRMB", 1, 10
"PRTK", 10, 10
"QIWI", 1, 100
"RASP", 10, 100
"RAVN", 100, 10
"RBCM", 100, 100
"RDRB", 10, 100
"RGSS", 1000, 10
"RKKE", 1, 10
"RLMN", 10, 100
"RLMNP", 10, 100
"RNFT", 1, 100
"ROLO", 1000, 100
"ROSB", 10, 100
"ROSN", 10, 100
"ROST", 10, 100
"RSTI", 1000, 100
"RSTIP", 1000, 100
"RTGZ", 1, 10
"RTKM", 10, 100
"RTKMP", 10, 10
"RTSB", 10000, 10
"RTSBP", 10000, 10
"RUAL", 10, 10
"RUGR", 10, 100
"RUSI", 100, 10
"RUSP", 10000, 10
"RZSB", 1000, 100
"SAGO", 10000, 100
"SAGOP", 10000, 100
"SARE", 10000, 100
"SAREP", 10000, 100
"SBER", 10, 100
"SBERP", 10, 10
"SELG", 100, 100
"SELGP", 100, 100
"SFIN", 10, 10
"SIBG", 100, 100
"SIBN", 10, 100
"SLEN", 100, 100
"SNGS", 100, 100
"SNGSP", 100, 100
"STSB", 1000, 100
"STSBP", 1000, 100
"SVAV", 10, 10
"SZPR", 1, 10
"TANL", 10, 100
"TANLP", 1000, 100
"TASB", 10000, 100
"TASBP", 10000, 100
"TATN", 1, 100
"TATNP", 1, 100
"TGKA", 100000, 100
"TGKB", 1000000, 100
"TGKBP", 1000000, 100
"TGKD", 100000, 100
"TGKDP", 100000, 100
"TGKN", 1000000, 100
"TNSE", 1, 100
"TORS", 10000, 10
"TORSP", 10000, 100
"TRCN", 1, 100
"TRFM", 10000, 100
"TRMK", 10, 100
"TRNFP", 1, 10
"TTLK", 10000, 100
"TUZA", 10, 100
"UCSS", 1, 100
"UKUZ", 1, 100
"UNAC", 1000, 100
"UNKL", 1, 100
"UPRO", 1000, 100
"URKA", 10, 100
"URKZ", 1, 100
"USBN", 10000, 100
"UTAR", 100, 100
"UWGN", 1, 100
"VDSB", 100, 100
"VGSB", 1000, 100
"VGSBP", 1000, 100
"VJGZ", 1, 10
"VJGZP", 10, 10
"VLHZ", 10, 100
"VRSB", 100, 10
"VRSBP", 100, 100
"VSMO", 1, 10
"VSYD", 1, 100
"VSYDP", 1, 100
"VTBR", 10000, 100
"VZRZ", 1, 100
"VZRZP", 10, 100
"WTCM", 100, 100
"WTCMP", 100, 10
"YAKG", 100, 10
"YKEN", 10000, 100
"YKENP", 10000, 100
"YNDX", 1, 100
"YRSB", 10, 10
"YRSBP", 10, 10
"ZILL", 1, 10
"ZVEZ", 1000, 10
Минимальный размер видимой части у айсберга
 
Коллеги, есть ли возможность в параметрах инструмента увидеть это значение?
По умолчанию это 100 лотов, но в таблице А-5 приведены исключения: https://fs.moex.com/files/5877/32604Из интерфейса Квик мне непонятно - проводится ли проверка на клиенте или на сервере биржи?
ODBC-экспорт. Мониторинг, Проверка флагов ODBC-экспорта.
 
Используем ODBC экспорт вполне успешно для экспорта данных из alltrades и котировок. Проверка состояния (идет экспорт или нет) производится в получающей базе. Буквально на уровне сравнения последней записи и текущего времени. Если данных нет или перестают поступать, во время торговой сессии, то срабатывает мониторинг. Исправлять приходится вручную, так как пока не знаем как включить ODBC экспорт программно. В редких случаях приходится производить перезаказ данных. Для alltrades также отслеживаем задержку - дельту между временем получения записи и временем регистрации сделки на бирже.
Добавление параметра lasttrade в LUA getParamEx
 
Функция getParamEx уже предоставляет доступ к информации о последней сделке, а именно о ее цене, количестве и времени.
Однако при высокочастной торговле, когда почти одновременно происходит большое количество сделок, эти параметры не дают однозначной идентификации сделки.
Предлагаю добавить поле lasttrade, которое будет содержать trade_num сделки.
Также рассмотреть вопрос об увеличении точности времени последней сделки до долей секунды. Речь идет о поле time.

Эта информация (микросекунды) уже транслируется в таблице alltrades.
OnTrade flags - направленность сделки
 
Цитата
TRADE_MAKER = 32; /**< Пассивная (сделка образована по ранее выставленной заявке). */
TRADE_TAKER = 64; /**< Активная (сделка образована по заявке выставленной для ее образования) */

Это как раз то, что нужно, и совпадает со значением в all_trades.
Прошу добавить эту информацию в документацию по интерпретатору.
В 7.27информация по этим полям понятно описана только для заявок.
OnTrade flags - направленность сделки
 
1) Таблица trades, поле flags.

У меня встречаются строки со значениями флагов: 32, 36, 64, 68 (в десятичном виде).
Соответственно варьируется 2-ой, 5-ый и 6-ой биты.Смотрю на docs (приложение).
Расшифровка 5-ого и 6-ого бита непонятна. К сделкам FOK и market maker order не применимы. Подскажите, как правильно интерпретировать 5-ый и 6-ой биты таблицы trades.

2) Был бы полезен getAllTradeByNumber по аналогии с getOrderByNumber, для быстрого получения строки с использованием индекса. Таблица all_trades большая и в отсутствие индекса поиск через SearchItems скорее всего будет медленным.
OnTrade flags - направленность сделки
 
Сергей, интересует расшифровка flags таблицы trades, то есть таблицы с моими сделками.
Из этого флага нужно получить направленность сделки аналогично тому, как она кодируется в AllTrades.
Иначе придется искать мою сделку по идентификатору в таблице обезличенных сделок.
OnTrade flags - направленность сделки
 
Предположение оказалось неверным. Хотелось бы услышать от коллег из Арки, что значают биты flags в таблице trades (кроме второго, который задокументирован).
OnTrade flags - направленность сделки
 
Похоже, что 5-ый бит содержит данную информацию.
bit.test(flags, 5) - если true, то продажа
OnTrade flags - направленность сделки
 
По второму биту flags таблицы trades (или OnTrade) я получаю информацию, купли ли терминал инструмент или продал.

бит 2 (0x4) Заявка на продажу, иначе – на покупку. Данный флаг для сделок и сделок для исполнения определяет направление сделки (BUY/SELL)

Можно ли также из flags достать информацию о направленности сделки, то есть была это продажа по биду или покупка по офферу?

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

Скорость обработки заявок при помощи OnTransReply gate_reply_time
 
Получается, если date_time предшествует gate_reply_time, то системное время сервера Квик отстает от времени шлюза. Такая ситуация в Финаме. Если системное время синхронизировано, то date_time >= gate_reply_time.
Скорость обработки заявок при помощи OnTransReply gate_reply_time
 
Используя разных брокеров (Сбер и Финам) обнаружил, что разница между полями date_time и gate_reply_time зависит от брокера.
В одном случае gate_reply_time всегда больше date_time, в другом случае наоборот.
Что же все-таки означает это поле? В документации указано, что это "Дата и время получения шлюзом ответа на транзакцию".
Тогда не совсем понятно почему оно предшествует date_time, да и само поле date_time требует уточнения.
Является ли это поле временем получения транзакции Quik сервером у брокера?
В целом планирую использовать дельту между gate_reply_time и date_time для целей мониторинга и выбора оптимального Квик сервера в зависимости от стратегии.
SearchItems - потокобезопасная итерация
 
Решил задачу поддержанием в памяти начального индекса, с которого производится поиск (вместо 0). По ходу торгов индекс постоянно увеличивается и большую часть снятых заявкок искать не нужно.
Сервисные функции для отключения терминала типа disconnect()
 
В итоге сделали через файлы. При наступлении условия контрольный скрипт создает lock файл, который проверяется на наличие торговым скриптом. При обнаружении файла, торговый скрипт останавливается.
Сервисные функции для отключения терминала типа disconnect()
 
Понятно, мне конечно хотелось бы обойтись без зависимостей, не столько от пакетов луа, но от внешнего ПО. Если AllocTable не подходит, наверное из-за того, что таблицы не являются совместно доступными нескольким скриптам?
Сервисные функции для отключения терминала типа disconnect()
 
Это может быть интересно! Имеется ввиду пользовательская таблица, созданная при помощи AllocTable?
Сервисные функции для отключения терминала типа disconnect()
 
Для мониторинга ключевых показателей использую выделенный скрипт.
Торговые стратегии реализованы в отдельных скриптах.

Есть определенные пороги, при превышении которых небходимо остановить исполнение всех lua скриптов, кроме контрольного.
Также необходимо при определенных условиях отсоединить терминал.

Контекст: для тех кто не сталкивался с доп. вознаграждением биржи за гиперактивные торговые алгоримты, советую ознакомиться и поставить на мониторинг!

Из сервисных функций есть isConnected. Функции disconnect() похоже нет. Сейчас вызывается os.exit(), но это брутально.
Есть ли еще варианты, которые следует изучить?
SearchItems - потокобезопасная итерация
 
Разницы во времени выполнения работу функции не наблюдаю. Попробовал следующие:

1) Отключить фильтр Отмененные
2) Убрать цветовую кодировку
3) Минимизировать кол-во колонок
4) Убрать таблицу из интерфейса


Измеряю в виде расчеты дельты между датами sysdate.

Правильно я догадываюсь, что таблицы в интерфейсе могут как-то влиять на скорость выполнения функции SearchItems?
SearchItems - потокобезопасная итерация
 
  • На данный момент я использую только таблицы orders и depo_limits.
  • Большое кол-во строк только в таблице orders.
  • Замена заявки производится программно путем отправки транзакции KILL с последующим NEW_ORDER
Поиск активных заявок в таблице размером 26000 (практически все неактивные) занимает около 75 мс, хотелось бы сократить.
SearchItems - потокобезопасная итерация
 
Я пользуюсь нижеприведенным вариантом для получения подвыборки строк из таблицы, в данном примере из таблицы orders.
Код
function find_active_orders(class_code, sec_code)

    function matchItem(_flags, _class_code, _sec_code)
      return bit.band(_flags, 0x1) ~= 0
        and _class_code == class_code
        and _sec_code == sec_code
    end

    local indexes = SearchItems("orders", 0, getNumberOf("orders")-1, matchItem, "flags,class_code,sec_code")
    if indexes == nil then return {} end
    local res = {}
    for i=1, #indexes do
      local item = getItem("orders", indexes[i])
      if matchItem(item.flags, item.class_code, item.sec_code) then
        res[#res+1] = item
      end
    end
    return res
end

В строке if matchItem(item.flags, item.class_code, item.sec_code) then я дополнительно проверяю, что полученная заявка соответствует изначальному фильтру на случай, если таблица orders будет изменена и в нее будут добавлены новые заявки в произвольном порядке.

Два вопроса:

1) Необходима ли повторная проверка или можно полагаться, что а) строки не удаляются,  б) новые заявки помещаются в конец таблицы и в) порядок строк не меняется в течение торгового дня? Если так, применима ли такая модель ко всем таблицам в Quik (строки никогда не удаляются, новые добавляются в конец, порядок строк зафиксирован).

2) По ходу биржевого дня количество строк в таблице постоянно увеличивается и доходит до 20000, в результате постоянного изменения лимитных заявок по цене (снять старую, выставить новую по другой цене). При этом активных заявок только несколько сотен. При каком размере таблицы имеет смысл задуматься о производительности функции find_active_orders и как ее можно было ускорить для случая когда практически все заявки неактивные?
Страницы: Пред. 1 2
Наверх