Счётчик числа сделок в секунду по одному тикеру

Страницы: Пред. 1 2 3 4 След.
RSS
Счётчик числа сделок в секунду по одному тикеру
 
Запустил скрипт на "боевом" сервере по SiM5. Результаты несколько неожиданные:



Получается "пачки" OnAllTrade приходят даже реже, чем обновления в ТТП по параметру "NUMTRADES". К тому же позже.

Интереса ради написал скрипт, считающий колбеки OnQuote. Результат:



Счётчик Count в OnParam увеличивается на единицу при изменении одного из параметров: 'BID', 'OFFER', 'BIDDEPTH', 'BIDDEPTHT', 'OFFERDEPTH', 'OFFERDEPTHT' при условии, что между колбеками прошло более 33 мс (на случай одновременного изменения нескольких параметров)

И в сравнении с OnQuote ТТП даёт информацию об изменении лучших спроса и предложения чаще и раньше.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель пишет:
Получается "пачки" OnAllTrade приходят даже реже, чем обновления в ТТП по параметру "NUMTRADES".
А может картину искажает слишком большое время, заданное для разделения колбэков между пачками? И в итоге за этот интервал времени успевают на самом деле прийти две пачки или даже больше.
Думаю, колбэки OnAllTrade правильней делить на пачки не по времени между ними (или не только по времени), а еще проверяя, не срабатывали ли между ними колбэки другого типа (OnParam и OnQuote).
 
Цитата
Старатель пишет:
Получается "пачки" OnAllTrade приходят даже реже, чем обновления в ТТП по параметру "NUMTRADES".
К тому же позже.
Это вполне соответствует тому, что писала техподдержка на форуме (https://forum.quik.ru/forum1/topic246/):

Цитата
Egor Zaytsev пишет:
Приоритет получения данных выглядит следующим образом:

- таблица котировок,
- далее таблица текущих параметров
- таблица всех сделок,
- графики.
А вот это, похоже, уже не соответствует сказанному техподдержкой:
Цитата
Старатель пишет:
И в сравнении с OnQuote ТТП даёт информацию об изменении лучших спроса и предложения чаще и раньше.
Хотелось бы понять почему... Может неправильно тестировали? Или все же техподдержка ошиблась?
А может получается раньше потому что чаще...?
Хотя насчет подсчета частоты хочу отметить, что сравнивать частоту обновлений стакана и ТТП по перечисленным параметрам не совсем корректно, т.к. 'BIDDEPTHT' и 'OFFERDEPTHT' отражают общий спрос и предложение, изменение которых может происходить и при неизменном стакане (т.к. стакан нам показывает не все заявки).
 
Кстати, не только сделки, но и обновления ТТП и стаканов тоже пачками приходят, по-моему.
А формируются такие пачки, возможно, потому что терминал получает с сервера только изменения параметров или только сделки или только обновления стаканов до тех пор, пока очередь с накопившимися данными одного типа на сервере не опустеет. Только после этого терминал, наверное, переходит к обработке данных другого типа.
 
Цитата
Дмитрий пишет:
А может картину искажает слишком большое время, заданное для разделения колбэков между пачками? И в итоге за этот интервал времени успевают на самом деле прийти две пачки или даже больше.
Уменьшил разницу до 5 мс, но это не изменило сути:


Кстати, со временем наблюдается всё увеличивающаяся разница между количеством сделок, посчитаных по OnAllTrade и OnParam (на демо не было). Очевидно, это из-за того, что в ТТП учитываются сделки, которые не отображаются в ТВС.

Цитата
Дмитрий пишет:
Хотя насчет подсчета частоты хочу отметить, что сравнивать частоту обновлений стакана и ТТП по перечисленным параметрам не совсем корректно, т.к. 'BIDDEPTHT' и 'OFFERDEPTHT' отражают общий спрос и предложение, изменение которых может происходить и при неизменном стакане (т.к. стакан нам показывает не все заявки).
Согласен. Но изменения в стакане чаще всего происходят вблизи спреда.

Цитата
Дмитрий пишет:
Цитата
Старатель пишет:
И в сравнении с OnQuote ТТП даёт информацию об изменении лучших спроса и предложения чаще и раньше .
Хотелось бы понять почему... Может неправильно тестировали? Или все же техподдержка ошиблась?
Раннее я уже проводил исследования на эту тему.
Код:
Скрытый текст
Лог:
Скрытый текст

Согласно логу, OnParam раньше "приносит" новую котировку раньше.
Надо делать так, как надо. А как не надо - делать не надо.
 
однако, я всё же заставил вас задуматься)))
сколько сразу умных мыслей)))

вот только техподдержка почему-то молчит...
 
насчёт разницы в количестве коллбеков м/у OnParam и OnAllTrade:
думаю. тут нет ничего удивительного - т.к. в OnParam - коллбек приходит на каждое изменение параметра и:    параметры изменяются не единой строкой за так называемый "срез", а только те, что реально изменились. Те, что не изменились имеют значение с предыдущего апдейта (что иной раз усложняет жизнь - бо как невсегда понятно: "он уже" или "ещё нет" (если коллбек к тому же пропущен)).
 
Цитата
Старатель пишет:
Согласно логу, OnParam раньше "приносит" новую котировку раньше.
об этом на старом форуме писалось. Но кто-то тут уже говорил, что дескать под ТВС отдельный поток и что он быстрее...
 
Цитата
Старатель пишет:
Согласно логу, OnParam "приносит" новую котировку раньше, чем OnQuote
Уважаемые разработчики, как вы прокомментируете этот факт, с учетом написанного здесь:
https://forum.quik.ru/messages/forum1/message1800/topic246/#message1800
Цитата
Egor Zaytsev пишет:
Приоритет получения данных выглядит следующим образом:

- таблица котировок,
- далее таблица текущих параметров
- таблица всех сделок,
- графики.
 
Добрый день.
Сравнивать частоту обновлений стакана и таблицы текущих параметров не совсем корректно. Они, конечно, будут между собой коррелировать, но стоит учитывать следующее:
1. Стакан обычно поступает ограниченного размера. Любое изменение заявок вне области видимости приводит к изменениям в ТТП;
2. По ТТП формируются временные срезы на уровне торговой системы и сервера QUIK.
3. Некоторые изменения в ТТП могут вообще не отражаться в стакане котировок. Например внесистемные сделки.
 
Цитата
Michael Bulychev пишет:
3. Некоторые изменения в ТТП могут вообще не отражаться в стакане котировок. Например внесистемные сделки.
а это уже действительно интересно...
т.е. у нас появляется небольшое конкурентное преимущество.

Цитата
Michael Bulychev пишет:
2. По ТТП формируются временные срезы на уровне торговой системы и сервера QUIK.
значит ли это, что данные из двух таблиц (ТВС и ТТП) должны сходиться? или...
где 21:18:19?
 
Michael Bulychev, а если нас интересует изменение только лучшей цены предложения/спроса

Откуда в итоге ее лучше брать, чтобы получить новое значение раньше?

Если судить по написанному Egor Zaytsev, то лучше из стакана (OnQuote).
А если по написанному Старатель - то лучше из ТТП (OnParam)/
 
я - про: https://forum.quik.ru/messages/forum10/message5192/topic559/#message5192
 
Цитата
sam063rus пишет:
т.е. у нас появляется небольшое конкурентное преимущество.
Никакого преимущества. они влияют только на открытый интерес. Не помню точно насчет общего количества сделок. В таблице всех сделок они не отображаются.
Насчет сходимости не совсем понятно. Что это такое?
 
Цитата
Michael Bulychev пишет:
Никакого преимущества. они влияют только на открытый интерес.
это многое объясняет...
и этим можно правильно воспользоваться.

Цитата
Michael Bulychev пишет:
Насчет сходимости не совсем понятно.
в том сообщении - всё есть. я пытался считать количество сделок разными путями и на основе ТВС и ТТП с помощью соответствующих коллбеков. Суть в том, что у меня это не получилось. я - считал, что параметр TIME в ТТП имеет своё отражение и на основе сделок в ТВС (столбец "Время")
 
и там и там - это время последней сделки НО! почему-то в некоторые моменты времени - он просто теряется.
 
т.е. возвращаясь в самое начало: в OnParam - пропадают параметры или, по другому: этот коллбек невсегда срабатывает и не успев сработать - теряет данные.
 
ну вот...
опять вся "Арка" разбежалась...  :(
 
Дмитрий, Старатель (ака Серж),

  • хотелось бы уже подытожить: то, считалось, что OnAllTrade даёт более быстрый и достоверный результат то, OnParam. На старом форуме - OnParam. На этом форуме - не менее "жарче" разгорелись мнения за OnAllTrade и в итоге - всё-равно OnParam. Так курица или яйцо???
  • касательно всего того, то я здесь услышал и, с учётом многих новых подробностей - я так и не понял в таком случае, что такое "срез" и как он влияет (и влияет ли) на мои версии скриптов. Хочу заметить, что чтобы тут до этого не говорилось - мы всё-равно работаем в рамках концепции единого хранилища данных.
  • на самом деле, все 3 топика - об одном и том же: CreateDataSource, этот топик и "Вопросы по OnAllTrade"
  • в очередной раз, "Арка" самоустранилась (лень читать топики, "много букАв" и всё такое). В очередной раз, я услышал от Михаила Булычева его "Что это такое?". Он ещё любит говорить "непонимаю о чём Вы?" после долгого обсуждения, чтобы вконец отбить всё желание, что-то обсуждать, а начать пытаться искать ответы другими способами...
 
финалом подобных историй, как правило становится: "проблема изучается. Постараемся дать на неё в ближайшее время ответ" + очередные "милые извинения"
 
Цитата
Дмитрий пишет:
Michael Bulychev , а если нас интересует изменение только лучшей цены предложения/спроса

Откуда в итоге ее лучше брать, чтобы получить новое значение раньше?

Если судить по написанному Egor Zaytsev, то лучше из стакана (OnQuote).
А если по написанному Старатель - то лучше из ТТП (OnParam)/
Michael Bulychev, и не забываем отвечать на вопросы...
 
Цитата
sam063rus пишет:
хотелось бы уже подытожить: то, считалось, что OnAllTrade даёт более быстрый и достоверный результат то, OnParam. На старом форуме - OnParam. На этом форуме - не менее "жарче" разгорелись мнения за OnAllTrade и в итоге - всё-равно OnParam. Так курица или яйцо???
Может, OnParam будет и быстрей немного, но однозначно OnAllTrade будет давать более точные результаты.

Цитата
sam063rus пишет:
я так и не понял в таком случае, что такое "срез"
Возможно, эта ветка форума поможет (ну и вообще поиск по слову "срез" на этом и старом форуме):
https://forum.quik.ru/forum1/topic343/
 
Цитата
sam063rus пишет:
насчёт разницы в количестве коллбеков м/у OnParam и OnAllTrade:
думаю. тут нет ничего удивительного - т.к. в OnParam - коллбек приходит на каждое изменение параметра
При сравнении с OnAllTrade я считал только колбеки OnParam, увеличивающие количество сделок.

Цитата
Michael Bulychev пишет:
Сравнивать частоту обновлений стакана и таблицы текущих параметров не совсем корректно.
Согласен. Это я так, до кучи посчитал количество колбеков. Основной целью же было выяснить, что приходит раньше: OnParam или OnQuote с новой котировкой.

sam063rus, своё мнение, откуда брать данные, я выразил ещё здесь:
если нам нужны только цена последней сделки и/или лучшего спроса/предложения, то эти данные лучше брать из ТТП, т.к. туда они поступают, чаще всего, раньше других.
Надо делать так, как надо. А как не надо - делать не надо.
 
я к тому, что среза никакого может и не быть вовсе. Есть главный источник данных. После каждого апдейта - происходит сравнение новых данных к предыдущем по таблице в памяти квика. Если новое значение не равно старому - вызывается соответствующий коллбек. И далеко не факт, что это будет OnAllTrade - всё зависит от преходящих данных.
 
Цитата
Дмитрий пишет:
Может, OnParam будет и быстрей немного, но однозначно OnAllTrade будет давать более точные результаты.
Объясните. Это если нам нужно обрабатывать все сделки, то - да. Если только цена последней сделки, то - нет.
Надо делать так, как надо. А как не надо - делать не надо.
 
единственное верно - то, что это всё в главном цикле, равно как и коллбеки, а значит последовательно - по определению. И величина "среза" - ненормирована по времени, а зависит лишь от очередной, поступившей от биржи порции данных. Если же квиковцы сделали жёсткий срез по их внутреннему представлению времени - то это уже даже близко нельзя назвать стабильной МТС и даже ИТС.
 
Цитата
Старатель пишет:
Объясните. Это если нам нужно обрабатывать все сделки, то - да. Если только цена последней сделки, то - нет.
Я имел в виду для реализации задачи подсчета числа сделок в секунду
 
Цитата
Дмитрий пишет:
Я имел в виду для реализации задачи подсчета числа сделок в секунду
А, ну, да. По OnAllTrade будет точнее по любому.
Я так и не понял, с чем у автора возникли проблемы: в пределах одной торговой секции OnAllTrade приходят в хронологическом порядке. Если не баловаться галочками в процессе подсчёта, да и то после подкачки дозаказанных сделок хронология восстанавливается.
Надо делать так, как надо. А как не надо - делать не надо.
 
Однако, принимая всё вышесказанное - остаётся открытым вопрос:
если OnParam впереди планеты всей то, куда делось 21:18:19?

Проблема может решиться только если разработчики официально признают, что часть коллбеков всё же теряется. А также то, что модель единого хранилища данных - в корне не верна.
 
Цитата
Старатель пишет:
Если не баловаться галочками в процессе подсчёта
а я и не баловался. Я наоборот, сторонник того, чтоб в скриптах (в отличии от GUI квика) - галочки не играли никакой роли.
 
Цитата
sam063rus пишет:
куда делось 21:18:19 ?
https://forum.quik.ru/messages/forum10/message5226/topic559/#message5226
https://forum.quik.ru/messages/forum10/message5218/topic559/#message5218
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель пишет:
Цитата
sam063rus пишет:
куда делось 21:18:19 ?
https://forum.quik.ru/messages/forum10/message5226/topic559/#message5226
https://forum.quik.ru/messages/forum10/message5218/topic559/#message5218
другими словами, для ТВС - есть внутренний кеш подкачки пропущенных данных, а для ТТП - нет. Если разработчики это признают - то у меня не останется никаких вопросов.
 
Вот пример простого скрипта, который будет считать количество сделок в секунду по заданному классу (точней, сумму сделок за секунду по всем инструментам этого класса, по которым в терминал поступают обезличенные сделки).
При этом архивные сделки по какому-то дополнительно добавленному в ТВС (уже после начала торгов) инструменту из того же класса не исказят текущую статистику.
В лог пишутся те сделки, которые могли бы нарушить нормальный ход подсчетов. Если таковые обнаружатся, то интересно посмотреть, что это за сделки...

Код
local file = io.open("C:\\TEST\\Log.txt", "w+t")
local cur_day = getTradeDate().day
local last_time = 0
local count = 0

function OnAllTrade(tr)
  if tr.class_code == "SPBFUT" then
    if tr.datetime.day == cur_day then
      local time = tr.datetime.hour * 3600 + tr.datetime.min * 60 + tr.datetime.sec
      if time == last_time then
        count = count + 1
      elseif time > last_time then
        message(tostring(count/(time-last_time)))  -- делим на число секунд (на случай, если сделки совершаются редко)
        count = 1
        last_time = time
      else -- (time < last_time) - скорей всего закачка истории сделок по вновь добавленному в ТВС инструменту
        file:write(tr.class_code," ",tr.sec_code," ",tr.trade_num," ",tr.datetime.hour,":",tr.datetime.min,":",tr.datetime.sec,".",tr.datetime.mcs,"\n")
      end
    else
      file:write("Пришла вчерашняя сделка - ", tr.trade_num, "\n")
    end
  end
end

local not_stopped = true

function OnStop(stop_flag)
  not_stopped = false
end

function main()
  while not_stopped do
    sleep(1000)
  end
  file:close()
end
 
а как понять, что он правильно показывает? ))
 
Например, сохранить в файл данные, которые он вычисляет.
В конце дня выгрузить таблицу всех сделок в другой файл, обработать его своим скриптом и сравнить результаты.
 
а Вы его сами пробовали запускать?

Скрытый текст
 
Впрочем, ТВС в файл выгружать не обязательно, можно сразу обработать ее своим скриптом.
И потом Вы ведь как-то поняли, что Ваш скрипт выдавал неадекватные данные. Значит, есть возможность проверить.
 
Запускал. Что-то смущает в результатах его работы?
 
я почему-то всегда считал, что число сделок в секунду - всегда целое по определению. Бо как сделка ну никак не может быть "половинчатой" или "четвертованной"
 
если такое происходит - то это уже усреднение.
 
Цитата
Дмитрий пишет:
И потом Вы ведь как-то поняли, что Ваш скрипт выдавал неадекватные данные. Значит, есть возможность проверить.
только вручную, глядя в ТВС.
 
Проблема в том, что если сделки происходят редко, то интервал между срабатываниями OnAllTrade может превышать 1 секунду.
В таком случае, если при очередном срабатывании OnAllTrade будет обнаружено, что с момента ее предыдущего вызова прошло больше секунды, то число сделок будет разделено на число секунд и получено среднее значение.
Либо можете не делить это значение и не получать среднее, а считать, что в первую секунду прошли все сделки (как и есть на самом деле), а в остальные - 0
 
Цитата
Дмитрий пишет:
Либо можете не делить это значение и не получать среднее, а считать, что в первую секунду прошли все сделки (как и есть на самом деле), а в остальные - 0
я в своём скрипте на среднее вообще не закладывался: нет сделок - нет счёта, нет нулей - просто ничего не выводил.
 
ок
присмотрюсь к скрипту. авось, что и получится. Галки в квике пока не меняю.
 
Если не делить число сделок на число секунд и не выводить нули когда сделок не было, то индикатор будет запаздывать при низкой активности торгов.
 
Цитата
Дмитрий пишет:
Если не делить число сделок на число секунд и не выводить нули когда сделок не было, то индикатор будет запаздывать при низкой активности торгов.
мне главное, чтоб правильно считал: т.е. есть сделка - есть счёт, нет - нет, и без всяких запаздываний.
 
Цитата
Дмитрий пишет:
Если не делить число сделок на число секунд и не выводить нули когда сделок не было, то индикатор будет запаздывать при низкой активности торгов.
То есть фактически выдавать недостоверные данные.
К примеру за 1 секунду у нас было 10 сделок, а потом 5 секунд сделок не было вообще.
Скрипт узнает о том, что 1-я секунда закончилась, только после прихода новой сделки (на 7-й секунде).
Если выдать при этом просто число сделок, не поставив нули за последние 5 секунд (или не поделив число сделок на число секунд), то будет впечатление, будто 10 сделок пришли не 6 секунд назад, а буквально только что.
 
а я и не говорил, что всё это легко. То есть, нужны мгновенные выборки (число сделок в секунду) с дискретностью 1 сек.
 
Код
если выборка == nil then "ничего страшного"
 
как уже говорил - задача бы значительно упростилась, имей мы коллбек: OnServerTime
Страницы: Пред. 1 2 3 4 След.
Читают тему
Наверх