Если я не ошибаюсь, то плата за транзакции возникает при более 30 транзакций в секунду. Эту плату берут с брокера, а он берет с Вас, если об этом есть в регламенте. например у БКС введено ограничение на не более 30 в секунду если больше то имеют право вообще отключить. узнайте у своего брокера, что он с Вами сделает.
еще хуже в параметрах транзакций. Отсылаем один формат данных и имена параметров, а принимаем другие и даже бинарные. Полагаю, что как у классика - "пуговицы пришивал один, а рукава - другой." ----------------------------------- "К пуговицам претензии есть? - К пуговицам претензий нет!"
ninjatrader написал: да я и сам могу в пятницу программу запустить, только вот неужели нельзя избежать утомительной процедуры открывания графиков на всех тайм-фреймах? куча ведь настроек в квике, неужели нет такой их комбинации, чтобы быстро скачивались необходимые данные при подключении к серверу? в других программах которыми пользуюсь достаточно скачать данные по меньшему тайм-фрейму, а большие уже строятся исходя из этих данных - здесь почему-то такая логика не работает...
В квике свечи строит сервер, а не терминал. Поэтому надо заказывать все таймы Но в скрипте открывать графики не надо. В скрипте надо просто в цикле открыть источник на каждый инструмент и каждый тайм, после прихода закрыть. ----------------------------------- Т е делаете скрипт, запускаете его на квике навсегда. Он например в вечернюю сессию активируется сам и принимает Вам все данные. Вы даже и не заметите как он это все сделает.
Кирилл Мазеин написал: Я пробовал по вашему совету поменять кодировку текста робота - то же самое. Да и на моем скриншоте искажается только русский текст, который в комментариях.
Хотите помощи? Выложите текст. Или Вы полагаете, что будут с экрана набивать Ваш текст для тестирования?
Николай Бехтерев написал: Да, у меня явно нет ясного понимания КоллБек функций. И к сожалению пока не попалось ни одной подробно разъясняющей статьи.
Попробую объяснить. Про колбек. Колбеком называется функция, которая вызывается из вне Вашей программы(скрипта) Такую функцию обычно определяют для обработки каких-либо асинхронных событий, время прихода которых нам заранее неизвестно. В QLUA колбеки - это функции с зарезервированными именами, которые будут вызваны при возникновения определенного в документации события. -------------------------------------- про main Эта функция, которая вызывается при запуске скрипта и используется для его(скрипта) зависания в режиме активности. Такой способ активации скрипта - это изобретение автора QLUA. Решение вполне работающее, но не очевидное для пользователей и не самое лучшее. но как говорят, дареному коню в ... не смотрят. Поэтому что состряпали, то и кушаем. ------------------------- Так вот, колбеки и функция main никаким образом не связаны между собой. Если Вам надо, чтобы в main обрабатывалось то, что будет получено в колбеке, то Вы должны это передать в майн и осуществить синхронизацию работы колбеков и майн. При этом, надо еще и синхронизировать обращение к общей памяти в колбеках и майн, так как это разные потоки. Т е Вы должны решать 1) синхронизацию потоков 2) синхронизацию обновления информации -------------------------- Т е декларация разработчиков о том, что QLUA сделано для дилетантов в программировании - это такой шутка --------------------- Примерно так
green_X5 написал: Еще чуть проще ) - windows условно многозадачен, и у него по-умолчанию стоит ограничение - переключаться между задачами не чаще чем раз в 15 мск. Этот параметр можно изменить командой для WinAPI, взяв на себя риск возможной потери устойчивости / стабильности системы.
Немного не так. 15 мс - это квант таймера. Поэтому минимальный sleep получается в 1 квант. квант таймера можно изменить сделав его 1 мс. Квант времени для задачи(потока) тоже можно настроить в количествах квантов таймера. примерно так.
Michael Bulychev написал: И как Вы определяете задержки, если на стакане нет метки времени?
для стакана я определяю не задержки а интервал поступления. вопрос: У меня получилось, что на вашем тестовом сервере часы отстают на 0.9 сек. Можете подтвердить либо сообщить на сколько точно отличается время на сервере от атомных. Спасибо ----------------------------------------- Кроме того, сейчас по пингу в терминале QUIK для Вашего тестового сервера получаю вполне объяснимые данные . А именно. получаем значения 32,47,63,78 (в основном) мс - между ними разница 15 мс - это квант таймера OC. Т е встроенный пинг вполне нормально работает и соответсвует 2,3,4 и 5 квантам. а пинг на IP соответствует одному кванту. ------------------------
тот самый написал: вобщем, доля правды - во всём этом есть... у меня было такое - когда у меня:
не хватало оперативки когда была сильная фрагментация в файловой системе - например, когда скачал/удалил игру на 10ГБ когда было зависшее интернет соединение (интернет может быть - но не стабильно [провайдеры знают о чём я])
длительные исследования на реальном сервере показали, что задержки на 4-10 секунд - это обычное дело. Средняя величина запаздывания данных ТВС составляет примерно 0.4-0.6 сек. Что вполне нормально для торгующих руками и моему роботу.
Добрый день, Написал тест для исследования очередей заявок (стаканов). Пустил его на вашем демо-сервере. Понятно, что это тестовый сервер. Но уж больно интересная картинка. Если не военная тайна, может кто объяснит эти периодические зависания обмена на 40 секунд Вот картинка: спасибо
чтобы меньше было ошибок и легче было читать рекомендую написать так: ------------------------ local x=nextWeather == 1; local x1=previosWeather == 1; local x2=previosWeather == 3;
пардон опечатка Попробую пояснить далее Вот примерный алгоритм Вашего робота: ---------------------------- СОСТОЯНИЯ ( S) 1) свободно 2) торгуем 3) ждем ------------------------- OnQuote S==1 - если нет позы, то покупаем, иначе продаем. Выставляем заявку по лучшей цене , S=3 S==2 - цена в заявке хуже лучшей, снимаем заявку, S=3 ------------------------- OnOrder если заявка активна, то S=2, иначе S=1 ---------------------
Попробую пояснить далее Вот примерный алгоритм Вашего робота: ---------------------------- СОСТОЯНИЯ ( S) 1) свободно 2) торгуем 3) ждем ------------------------- Onorder S==1 - если нет позы, то покупаем, иначе продаем. Выставляем заявку по лучшей цене , S=3 S==2 - цена в заявке хуже лучшей, снимаем заявку, S=3 ------------------------- OnOrder если заявка активна, то S=2, иначе S=1 ---------------------
Николай Бехтерев написал: И такой вопрос, допустим выставление лучшей заявки мы засовываем в коллбек OnOrder, в OnTrade мы получаем информацию о том взята заявка или нет, как исключить момент исполнения двух заявок? Без sleep() и ожидания ответа о том, что заявка снята - тут никак не обойтись, я правильно понимаю?
можно и без speep Например запоминать номер выставленной заявки и перед выставлением новой, проверять исполнилась старая или нет через функцию getOrderByNumber
но ведь всё равно будет какая-то разница во времени между sendTransaction для снятия заявки и коллбеком OnOrder?
Вот вы говорите номер... Ну запомили мы номер первой выставленной нашей заявки, далее, когда в стакане появляется цена лучше нашей, мы проверяем по номеру не снята ли заявка (а может быть и взята рынком), если снята, выставляем новую, а если нет? Если заявка стоит и её надо снять, мы тут же в OnQuote кидаем sendTransaction и? Время же тикает пока заявка будет снята и мы увидим это по флагам. Что в это длящееся время будет происходить в OnQuote?
Небольшая лекбес 1) робот - это конечный автомат. т е устройство, которое имеет набор состояний и по событиям переходит из одного в другое. ------------------------------ 2) первоначально надо определить перечень этих состояний Например , хотим играть по очереди заявок состояния: 1.свободно - нет заявок 2. есть заявка - купить.продать 4. есть лучшая цена 5. есть сделка ... 3) потом определяем, в какие состояния переходит робот из каждого состояния
4) потом определяем какие события создают эти переходы
5) и после того, как нам стало понятна логика работы нашего робота, мы переводим эту логику на язык программирования, например луа. ------------------------------------ Это подобно написанию художественного произведения например на японском языке. ---------------------- Придумываем сюжет, героев, пишем на том языке, на котором умеем думать (т е на русском) . Когда все написали и получился хороший рассказ(роман, повесть, сказка), после этого берете словарь японского и переводите на японский (луа) ------------------------------------------------------------ Не в обиду будет сказано, но Ваш пост свидетельствует о том, что Вы пытаетесь, еще не придуманный свой роман писать сразу на японском, без словаря, спрашивая на форуме, как написать на японском ...то или иное слово и зачем это слово надо писать. ------------------ Примерно так.
в main проверяете, если она меньше предыдущей то снимаете старую заявку и ставите новую. Однако, лучше убрать проверку из main и перенести ее целиком в OnQuote, только без sleep
Не понимаю почему проверку в OnQuote если всё равно происходит выставление заявки в main? Т.е. допустим мы в OnQuote будем иметь два ценовых уровня OFFER и LAST_OFFER допустим мы сравнили и выяснили, что наша заявка не лучшая, тогда нам всё равно эту перемену как-то нужно передать в main и получится уже два if-then, а значит большая вычислительная мощность, разве нет?
1) колбек исполняется в основном потоке квик . Поэтому его завершение ждут другие колбеки и основной поток. Если действий мало, то можно все делать в колбеке. Когда алгоритм большой и у Вас есть несколько ядер , то исполнение основных вычислений в майн теоретически даст ускорение вычислений процентов на 10-20. почему теоретически ? потому что переключение потоков имеет накладные расходы и для оптимального переключения надо управлять ос. 2) При играх в лучшую заявку надо учитывать следующее. На ликвидных бумагах спреда может не буть и ваша заявка будет бить в противоположную лучшую, т е Вы будете двигать рынок. Это обычный прием маркет-майкеров заставить двигать рынок чужими деньгами. Забиваю спред , а подобные Вашему алгоритмы начинают съедать встречные заявки.
Как нанести на младший таймфрейм цены закрытия (хая, лоя) предыдущего бара в виде горизонтальных уровней., Например нанести на M15 цены закрытия предыдущего дня, недели, месяца? Это возможно реализовать?
Michael Bulychev написал: Просто есть два подхода в использовании Lua: 1. Вы пишете на Lua и тогда корутины это то что Вам надо 2. Lua используете как язык для связки своих библиотек и QUIK. В этом случае реализация полностью на ваших плечах. Но я все еще не понимаю полностью как Вы хотите вызывать функции одного работающего скрипта из другого. Проблем и ограничений в таком подходе явно больше чем преимуществ.
Добрый день, Хоть и не верю в то, что из этого будет толк, но все же отвечу: -------------------------------------- 1) Я пишу на луа и СИ. Либо любом другом языке, который лучше подходит для решения конкретной задачи. ----------------------------- 2) Полагаю, что Вы не внимательно прочитали то, что я написал ранее. ----------------------------------- Увы без лекции не обойдемся. ------------------------ Корутины - это виртуальный поток. Его задача уменьшить простои процессора при ожидании асинхронных позиций, без которых дальнейшие вычисления невозможны. Это тоже самое, что потоки в одноядерной винде. Такие потоки решают лишь две задачи - уменьшение простоя ядра при ожидании задачей асинхронных событий и исключение зависания задач. Т е в таких системах задачи решаются последовательно. Так как параллельно нет на чем решать. Эти потоки не могут ускорить вычислительные задачи, т е те, в которых используется лишь память и вычислитель(процессор) и нет ожидаемых событий. ------------------------------- Ранее я уже написал , что поток - это фактически вычислитель ( т е процессор и код программы) Так вот, возвращаясь ранее определенным задачам, я решаю задачу параллельных вычислений в роботах на основе Вашей QLUA библиотеки. Поэтому речь идет о реальных потоках в многоядерной (многопроцессорной) системе. ---------------------------------- Вообще-то я эту задачу решил. Поэтому сделаете ли Вы это для других или нет, мне все равно. --------------------------- Корутины я тоже использую, например в системе мониторинга умных вещей на основе чипа ESP. Но это уже другая история. --------------------------------------- Примерно так..
тут уже приводилась ссылка на статью, где товарищ пытался ускорить выполнение расчетной программы разбивкой на потоки на одноядерной машине. и удивился, не получив никакого ускорения.
загрузка процессора КВИКОМ от 7 до 40% ( в зависимости от открытия графиков) торгую лишь 1 инструментом (сбербанк акции и фьючерсы) Подписан лишь на 8 акций и 20 фьючерсов тики не подписываю, опционы не принимаю файл info.log за сутки всего 11 мб.
тот самый написал: задам лишь один вопрос: винчестер - сильно фрагментирован? Оперативка - не маленькая?
винчестер оптимизирован по фрагментации. свобоно на диске, где файл подкачки 30 Гб, где QUIK 30 Гб. оперативка 2 Гб. Обычно свободно не менее 1 Гб оперативной памяти.
Michael Bulychev написал: Добрый день. Если Вы подробнее расскажете о том что хотите нам будет проще принять решение о возможностях и способах реализации.
добрый день, попробую объяснить. ------------------------ Скрипт луа , который создается на основе библиотеки QlUA можно представить как обертку потока. --------------------------------- Таким образом, запуск скрипта - это запуск самостоятельного потока. ----------------------------- В данной версии доступ к потоку имеют лишь функции внутри скрипта и колбеки из QLUA. Поэтому я поставил задачу обеспечить доступ к потоку из других скриптов или индикаторов. это можно реализовать, если создание колбеков разрешить внутри скриптов и индикаторов. ------------------------- Что дает такое решение? ---------------------------- Как известно (по крайней мере я так строю роботов), технология создания торговых роботов, как правило, включает несколько модулей, большая часть которых не зависит от торгуемого инструмента. ---------------------------------- В существующей версии QLUA, для каждого робота необходимо в скрипт включать все модули. ------------------------------ Например, если мы делает роботов для торговли 10 инструментами, то каждый из них будет содержать модули обработки заявок сделок. т е это 10 колбеков onOrder, onTrade, которые в очередь обрабатывают одно и тоже в основном потоке QUIK. ------------------------ можно конечно, все 10 роботов запихнуть в один скрипт. Но тогда будут в очередь в одном дополнительном потоке работать 10 генераторов торговых сигналов. ------------------------------- можно конечно еще создать свои потоки в этом скрипте, но тогда возникает вопрос синхронизации потоков, а скудные сведения о внутренности QLUA и архивов QUIK приводят к танцам с бубном. ------------------------------- Что дает мой вариант. --------------------- 1) колбеки QLUA вызываются однократно вне зависимости от количества роботов 2) генераторы торговых сигналов обрабатываются каждый в отдельном потоке. 3) синхронизация потока с глобальными переменными внутри скрипта решена в QLUA потобезопасными функциями работы с таблицами. ------------------------ Резюме: И будет всем счастье. ----------------------- примерно так.
вот последняя картинка мониторинга. уж БОЛЬНО хороша!!! розовая линия - задержка информации ТВС синяя - погрешность измерения задержки (отставание локальных часов от атомных)
Добрый день, В качестве пожелания. 1) Очень удобно иметь возможность создавать колбеки в скриптах и индикаторах и вызывать их из любого скрипта или индикатора. 2) Очень удобно иметь возможность прочитать любые глобальные данные из любого скрипта или индикатора и вызвать на исполнение любую функцию в любом скрипте из любого скрипта или индикатора. -------------------- Я в настоящее время реализовал у себя эти механизмы в версии 6.17.3.6 Доволен, как кот у миски со сметаной. -------------------------- Благодарю за внимание.
Николай Камынин написал: про потоки я знаю все или почти все.
остаётся, лишь только добавить...: "если ты такой умный - то, почему такой бедный?"
или ещё:
"должны ж быть у талантов - меха и бруллианты!?..."
можно добавить еще "Если ты такой богатый, то почему такой глупый?" ---------------------- Но если ты богатый и умный, то будь скромным. ----------------------- Вот я и скромный.
Michael Bulychev написал: Сервер 10 секунд занимался тем, что отдавал вам очередь более приоритетных данных. По моему, наиболее адекватная оценка будет по времени последней сделки на ликвидном рынке.
так как ТВС - это приоритетные данные, а вечером особо ничего срочного нет, но получаем все теже 0.2-10 секунд, то Ваши рассуждения - это просто Ваши гипотезы, ничем не подтвержденные. -------------------------------------------------------- мечтать не вредно, но бесполезно.
Добрый вечер Всем, Вот и подошел к концу мой мониторинг сервера брокера БКС Как я и обещал себе, провел мониторинг задержки данных, приходящих в ТВС. Вот кусок свежеиспеченных данных
что же мы видем: 03/30/16 20:32:53 -это время лога dt=19.8 - это отставание локальных часов компьюткра от атомных, dms=237 -- это запаздывание данных которые приходят через брокера ,HMS=193252,D=20160330 -- это время и дата свечи Как видим, задержка данных сервером брокера составляет от 0.2 до 10 секунд Т е задержка данных вполне соответствует получаемой величине параметра LASTPINGDURATION ---------------------------------------------- "И вот тут некоторые стали себе позволять нашивать накладные карманы и обуживать рукав. Вот это позволять мы не будем!"
очень слабая статья. В ней пытаются ускорить выполнение задачи с использованием потоков на одноядерном железе. как я уже заметил раньше поток - это вычислитель т е процессор или ядро как модно называть. многопоточность на одном ядре - это виртульное создание вычислителей на которых запускаются исполняемые фрагменты кода по очереди. Для интересующего меня вопроса не имеет значение есть потоки или нет. Информация о тиках одна и та же для обоих колбеков. Вопрос ,в том она отправляется с сервера один раз или два и кому раньше. Но так как начальник транспортного цеха молчит, пусть эти вопросы останутся открытыми.
про потоки я знаю все или почти все. ---------------------------- Но дело в том, что в QUIK все колбеки On... вызываются в одном потоке друг за другом. Сомневаюсь, что для колбека cratedatasource нагородили что-то особенное. -------------------------------------------------- Но хотелось бы по данному вопросу послушать начальника транспортного цеха.
поясняю: возможно... есть 2 потока: главный поток квика и обработка коллбека OnAllTrade и.. возможно, ещё один поток cratedatasource
таким образом, вы никогда не узнаете и не сможете гарантировать, какой из них быстрее сработает и обработает долгожданный коллбек. Бо как помимо потоков - есть ещё и системный планировщик, а также целас система (ОС), которая всё переиграет так - как ей это будет нужно - в данный момент
Попробую объяснить свое понимание. 1) Поток - это в общем случае просто вычислитель. Какой вычислитель из имеющихся в системе будет задействован не имеет значение. 2) есть две функции OnAllTrade и колбек cratedatasource. Каждая из них вызывается по приходу запрошенной с сервера информации. Если для работы OnAllTrade достаточно сделать cratedatasource, то это означает, что обе функции из п 2 работают с одной и той же информацией. Если это не так, то для работы OnAllTrade требовалось бы еще какие-то настройки. 3) Таким образом, будут ли эти функции вызываться в разных потоках или в одном не имеет значение. Вопрос лишь в том в какой последовательности они вызываются. Примерно так.
Николай Камынин написал: 1) В чем отличие обработки этих колбеков.
OnAllTrade - в первую очередь колбек таблицы а SetUpdateCallback создает колбек на график. Это значит что во втором случае Вы можете получить только ту информацию которая есть на графиках (в данном случае речь тиковом графике).
Цитата
Николай Камынин написал: 2) Какой колбек вызывается раньше.
Очередность нигде не прописана.
Цитата
Николай Камынин написал: 3) как во втором случае получить всю информацию первого.
Вы можете обратиться к любому элементу data_source по номеру.
Поясните плиз тогда следующее. Ранее на мой вопрос было сообщение что для работы onAllTrade не требуется открывать ТВС а можно лишь подписаться на источник тиков data_source. Верно? но тогда не понятно, каким образом onAllTrade работает без ТВС если оно для ТВС. А колбек data_source для графиков если график из тиков не рисуем. Спасибо
Николай Камынин написал: Во-вторых, в колбеке CreateDataSource
могу ошибаться, конечно (не работаю с CreateDataSource ввиду его "сырости") - под него, если не изменяет память (читал где-то) - заводится отдельный поток ОС. Поэтому - сравнивать его с OnAllTrade - было бы неверно.
Поясните Вашу мысль. почему не верно. Оба механизма создаются для получения информации о сделках. Полагаю, что так как получается однотипная информация то сравнивать вполне возможно. ------------------------------ По аналогии, можно сравнивать лапшу и кашу. Но нельзя сравнивать кислое и синее. В данном случае - это лапша и каша.
петя петров, Не буду цитировать написанное выше. Простой вопрос - Вы это запрограммировали в КВИКЕ? А я то, что нарисовал на картинке выше - сделал в квике на луа. Когда запрограммируете свой алгоритм покажите картинку.
Зачем смотреть на гланды через зад? Есть луа Это на порядок проще, чем на C# городить огород с DDE или ODBC ------------------------------------ "Нам легкие пути не нужны, мы трудности любим преодолевать. Но для этого мы их сначала создадим." (из дневника начинающего разработчика роботов)
Борис написал: В одной области заведены 2 графика цены в виде линий по инструментам GZ и SR. Как построить разностный график по ним? По сути это спред между ними. Спред = GZ-SR
Соглашусь с михаилом, задача не тяп-ляп и не на полчаса. Проблема в том что данные на графики приходят асинхронно. Поэтому приходится при построении спреда учитывать это и синхронизировать временные ряды. Один из способов упрощения этой задачи - это построить изначально оба исходных графика в одном окне, друг под другом с единым масштабом. Примерно так
Как выставить стоп заявку,чтобы при срабатывании по одному инструменту,сформировалась рыночная заявка по другому инструменту?, Как выставить стоп заявку,чтобы при срабатывании по одному инструменту,сформировалась рыночная заявка по другому инструменту?
Добрый день,Михаил Если есть параметр, то он что-то значит. Я его измеряю как один из .... Где Вы увидели, что я его соотношу с пингом ( вообще-то я даже не понимаю , что Вы понимаете под словом "соотношу") ----------------------------------------- Но любой измеряемый параметр позволяет делать определенные оценки в отношении испражняющего его объекта. ------------------------------- Вот и Ваш параметр, который Вы назвали "Задержка данных при обмене с сервером" что-то показывает. ------------------------------- Назвали бы его горшком, и никаких бы оценок задержек обмена на его основе не делал бы. ----------------------------- А так - я вам верю... относительно Ваших теоретических изысканий, попробуйте объяснить , что может делать сервер 10 секунд, чтобы не отсылать ответ на этот запрос? У лишь оно придумал - сервер пошел курить. А Вы что придумали?