Не в обиду будет сказано, но хотелось бы услышать не пересказ ликбеза их интернета , а конкретные данные из Вашего опыта. -------------- Начну со своего. ----------------- В настоящее время у меня есть вклад на 6 месяцев под 24.2%, есть вклад на 3 месяца под 23.2%, есть вклад накопительный под 19.2%, с которого можно снимать и класть любую сумму, а процент начисляется на остаток на конец дня . Вклады в разных банках (это как разные облигации) --------------- относительно налога. Ставка ЦБ сейчас 21%, т е налог равен нулю. ---------------- Относительно облигаций. Да, доходность по ним должна быть больше, чем по вкладу, за риск потерять деньги, который на рынке всегда больше, чем в банке. ----------------- Пример про доходность по облигациям Самолета не катит. Эта доходность не длительная, а краткосрочная с очень большим риском. ----------------- Для большего риска у меня есть торговля вечным фьючерсом, у которого плечо 5. Например вчера. Доходность за день, которую я смог забрать с рынка составила 4.5% в день. ========= Интересно было бы почитать про реальный результат торговли облигациями.
VPM написал: nikolz, Ну здесь то логика простая, Вы посмотрите на да ты погашения, то есть инвестиционный горизонт огромный. То есть фиксируем доход. Ну дело тут не в текущей доходности даже, а в чувствительности облигации к снижению ставки. То есть сегодняшние 16%, завтра 70% дадут, именно эту оценку я пытаюсь провести. Например, у меня получается, если дюрация облигации составляет 5 лет, то при снижении ставки на 1% цена облигации вырастет примерно на 5%.
Идея понятна. Но Вы не пробовали посчитать в сравнении с депозитом в банке и учетом сложного процента. Недавно читал статью в инете где говорится что высокие проценты по облигациям на длительный срок реально дают более низкий процент чем депозит если разложить эти процента по годам с учетом сложного процента.
VPM написал: На рынке сложилась уникальная ситуация! Акции как сжатая пружина, того и смотри, разожмётся и обгонит "биток" , за 2 месяца отыграна прошлогодняя просадка. Но мой взгляд прикован к облигациям, как "кролик на удава", я смотрю на них. Задача сводится зафиксировать часть доходности в инвестиционном портфеле.
Для анализа отобрал 4 длинных облигаций ОФЗ-ПД (облигации федерального займа с постоянным купонным доходом)
Код
Инструмент Номинал Доходность Размер купона Длит. купона НКД Дата выпл. куп. Дюрация До погашения Погашение Ср. взв. цена Оборот Коэфф. Выплат в год раз Годовой доход Купонный поток % От погашения к дюрации Кол. Шт. приобрести Инвестиция в одинаковое количество %
ОФЗ - ПД 26233 18 / 07 / 35 SUR 1000 15.76 30.42 182 4.35 30.07 . 2025 2437 3799 18.07 . 2035 53.148 967 , 621 , 780 1.9 2 61 р. 36 , 504 р. 11.45 % 1362 600 318 , 888 р. 1.50 900 54 , 753 р. 11.45 %
ОФЗ - ПД 26238 15 / 05 / 41 SUR 1000 15.27 35.4 182 15.95 04.06 . 2025 2658 5927 15.05 . 2041 53.254 1 , 751 , 734 , 568 1.9 2 71 р. 42 , 480 р. 13.29 % 3269 600 319 , 524 р. 1.50 898 63 , 590 р. 13.29 %
ОФЗ - ПД 26243 19 / 05 / 38 SUR 1000 15.78 48.87 182 22.02 04.06 . 2025 2330 4835 19.05 . 2038 69.341 1 , 084 , 655 , 642 1.4 2 98 р. 58 , 644 р. 14.10 % 2505 600 416 , 046 р. 1.15 690 67 , 420 р. 14.10 %
ОФЗ - ПД 26248 16 / 05 / 40 SUR 1000 16.42 61.08 182 27.52 04.06 . 2025 2264 5563 16.05 . 2040 79.718 1 , 820 , 239 , 989 1.3 2 122 р. 73 , 296 р. 15.32 % 3299 600 478 , 308 р. 1.00 600 73 , 296 р. 15.32 %
Наиболее доходная облигация: ОФЗ-ПД 26248 16/05/40 с доходностью 16.42% и годовым доходом 122 рубля. Наименее доходная облигация: ОФЗ-ПД 26238 15/05/41 с доходностью 15.27% и годовым доходом 71 рубль. Наибольший купонный поток: ОФЗ-ПД 26248 16/05/40 с купонным потоком 73,296 рублей. Наименьший купонный поток: ОФЗ-ПД 26233 18/07/35 с купонным потоком 36,504 рублей.
Вывод: В целях — максимизация дохода, то ОФЗ-ПД 26248 16/05/40 является наиболее привлекательной. Если важна меньшая дюрация и меньший срок до погашения, то ОФЗ-ПД 26233 18/07/2035 может быть предпочтительнее.
Но в штопор вводит, ожидаете понижения ключевой ставки ЦБ РФ, то есть облигации с большей дюрацией и более длительным сроком до погашения будут более выгодны, так как они сильнее реагируют на изменение ставок. То есть наиболее выгодной становится облигация ОФЗ-ПД 26238, так как имеет более высокий потенциал роста благодаря большей дюрации. Ну и как тут быть? Как в штопор не впадать?
В банке вклад с доходностью 24%. В чем фишка брать облигации с доходностью 16%?
Кирилл написал: Могут ли программисты пояснить, для чего нужен ОТРИЦАТЕЛЬНЫЙ объем торгов? ( -500 000; - 1 000 000, доводилось видеть и -2 000 000) См. скриншот:
Также, пару лет назад была указана еще одна проблема отображения таблиц:
Округлялась дробная часть. Это касалось только графиков ФосАгро и Норникеля. Наконец-то, Норникель починили. А с Фосагро надо, наверное, еще несколько лет подождать.
alex24 написал: Я так понимаю что половина всех валяющихся платных скриптов для терминала - дело рук самих разработчиков QUIKа иной причины, кроме подобного рода конфликта интересов, я и представить себе не могу. Рассчитывал что буду пользоваться софтом, но почитал форум, посмотрел программу (юзерфрендли интерфейс прямиком из 96-го года намекает что софт пишется одним человеком на коленке в выходные дни). Это все конечно шутки и ирония. Пользоваться не стану и никому не посоветую просто из-за отношения разрабов к потребностям и просьбам пользователей. Очень грустно что комьюнити такое терпеливое. Могли бы проголосовать ногами (уйти в другие торговые системы оставив разрабов думать, что не так и как следует выстраивать взаимодействие с пользователем, а то видите ли больно умные эти пользователи и базовый функционал требуют!)
Приведите пример других торговых терминалов для российского рынка.
Anton Belonogov, Вы читали сообщение биржи, что на рынке более 30 млн частных инвесторов. --------------------------- Вместо того, чтобы сделать подробную инструкцию к вашей поделке для разных систем, Вы решили издеваться над ними, заставляя делать миллионы человек одни и те же действия по копированию строк из вашего творения? --------------------------------- Вам не совестно это предлагать? ------------------- Cделали поделку -сделайте подробную документацию, а не предлагайте костыли. -------------------- Экономьте электроэнергию и берегите природу.
Это как через зад смотреть гланды. Очень увлекательно для разработчиков, но непонятно для пользователей. -------------------- У Вас в приложении в документации QUIK приведены названия параметров на русском языке (зачем эти названия на русском?), а на англ написать эти названия никто не догадался за 25 лет существования QUIK?
unikum33 написал: update: залогинился в субботу, торгуется только LQDT от ВТБ брокера. Даже при отсутствии торгов загрузка ЦП 5%. Получается, что именно открытые графики дают нагрузку ЦП? Или может быть то, что они выведены на отдельный монитор(с зажатым ctrl)?
__spb13__ написал: Добрый день, Скрипт вызывается из окна "Доступные скрипты". В скрипте все как обычно: получаю цену, открываю заявку. Но, и цена и заявка срабатывают только если в таблице "Текущая таблица параметров" выбран инструмент соответствующий инструменту заданному в скрипте. Что это, такое запрограммированное поведение Quik? Или все-же существует метод как получить цену и открыть заявку без какой-либо связки скрипта с окнами инструментов?
Можно использовать колбек Onparam. этот колбек вызывается , когда приходят какие-либо изменения в ТТП Например, совершилась сделка или изменились лучшая цена в стакане. При этом Вы получаете код инструмента и можно прочитать текущую цену этого инструмента и решить выставлять или нет заявку или изменить положение стоп-заявки
VPM, Возможно Вы это знаете, но я просто напомню. Данные в терминал приходят блоками. Если Вы используете высокоточный счетчик ПК для измерения времени (дискретность 0.1 мкс) то обнаружите, что одновременно могут прийти десятки сделок между которыми сотни миллисекунд. ----------------------- Есть данные, которые рассылаются биржей в широковещательном режиме. Они рассылаются с интервалом сотни миллисекунд. ========================== Кроме того, если вы не в дата центре и не в Москве, то задержка получения данных с биржи будет примерно 50 ms. ---------------------------- Все это создает запаздывание данных с биржи и на биржу порядки сотен миллисекунд. ======================= Меня интересует быстродействие скриптов не для того, чтобы посылать 1000 заявок по одному инструменту, а для того, чтобы максимально быстро прогнозировать изменение цены по 1000 инструментам, чтобы отправить заявку по каждому из них не более, чем за 1 секунду.
Alexander, Не стремлюсь Вас в чем-то убедить или спорить с Вами. ------------------------- Рассказал Вам свой опыт, так как Вы задали вопрос на форуме. ------------------------------------ Делайте как хотите.
nikolz написал: Возможно не понял, но полагаю что Вы ошибаетесь.---------------------------Синхронизировать потоки надо при обращении их общим данным. -------------------------Четыре различных квика не имеют общих данных. Поэтому непонятно, что Вы пытаетесь синхронизировать.--------------------------DLL - это не данные а код.Не надо синхронизировать потоки при обращении к коду.-----------------------Не надо синхронизировать потоки при обращении к константам.--------------------- Смысл синхронизации в том, что в момент чтения данных одним потоком, второй их непредсказуемо изменит.
Да не поняли. Теорию знаю. По DLL тоже, и что и как там и в каком контексте работает, и переменные общие и т.п. Мне синхронизировать нужно работу вывода в консоль. Функции принтов есть в DLL и есть варианты, чтобы они разным цветом печатала в консоли есть функции и для скрипта - для захвата секции и много там ещё чего разного. Даже например внутри одного квика, допустим один поток колбэк выводит в консоль цветной текст - своим цветом последовательно по ходу работы функции принт за принтом. Далее этот поток прерывется и запускается другой поток, который тоже последовательно выводит в консоль своим цветом принт за принтом по ходу работы его функции. Что будет? Будет каша разноцветных принтов в перемешку, да ещё и цвета возможно сбиваться будут. Общие данные - захват консоли на время работы функций потока. Консоль и есть общий ресурс. Функции колбэка быстрые и захватывают консоль в начале функции и освобождают в конце, весь их вывод в консоль одним цветом получается, для каждого колбэка свой цвет, другой поток ждёт и не может ничего вывести пока колбэк не отработает полностью. Т.е. даже когда прерывается поток колбэка и запускается основной - это не страшно, основной кашу не сделает, ибо ждёт, потом возврат в колбэк и он продолжает свой цветной вывод своим тем же цветом. Отработал отпустил. Потом уже основной поток может продолжить и печатать своим цветом. У основного потока каждый принт - захват и освобождение консоли для своего цвета принта через захват секции(не в начале и в конце функции(как у колбэка) в которой принты основного потока - так можно бы было, но кое где логика не позволяет ибо ждёт результата колбэка и можно зависнуть, когда один захватит секцию и ждёт данных от колбэка, а колбэк не может захватить секцию, либо не логика, а просто нельзя тормозить надолго всю функцию основного потока по захвату консоли, ибо колбэки хрен тогда отработают, поэтому захват только на время работы одного принта основного потока). При таком построении каждый колбэк отписывает в консоль своим цветом даже если его прерывают, ну и основной поток спокойно себе печатает своими цветами и не пересекаются их выводы с выводами колбэка. Без этого такая каша, что даже выводы разных колбэков пересекаются, не что что с принтами основного потока и такое читать просто жопа.
Вы плохо изучали теорию. Повторю еще раз. Синхронизируют не код, а общие данные. Функция принт - это код. --------------------------- Зачем Вы выводите в консоль? Выводивыводите в лог файл и будет вам счастье. Лог файл позволяет анализировать ошибки и логику выполнения программы при длительном тестировании софта. Например , тестировал скрипт на QUIK 6 часов. При интенсивном потоке данных или длительном тестировании от консоли мало толку. ------------------------- Чтобы при выводе на консоль ничего не съедалось надо ставить задержку после оператора вывода. Обычно sleep(10) достаточно. -----------------------
nikolz написал: мьютексы излишне использовать, так как всего два потока.Ранее уже говорил, что это решается гораздо проще через Event.
Если рассматривать вариант использования только одного экземпляра квика, то да. Но вот у меня, например, на данный момент рабочих целых 4 варианта самостоятельных квиков. Все они используют в работе всегда одну и ту же DLL, которая обеспечивает мне консоль для вывода, ну и разные функции для работы с этой консолью, в том числе и цветной вывод. Для цветного вывода хош-не хош нужна синхронизация, иначе всё идёт в перемешку, хоть и разным цветом, что очень неудобно воспринимать, хотя и можно смириться с этим, но я решил не мириться. Так вот, коли 4 квика, то по сути это уже и 4 разных процесса. И поэтому либо мьютекс нужен, либо быстрая критическая секция. Но секция одна на разные процессы не пойдёт. Я выбрал для себя в реализации именно секции, но приходится хранить массив из секций (для каждого потока своя секция), которые инициализируются при подключении процесса в DLL. Сейчас всё работает как положено. Ну пришлось чуток добавить кода, но оно того стоит думаю.
Возможно не понял, но полагаю что Вы ошибаетесь. --------------------------- Синхронизировать потоки надо при обращении их общим данным. ------------------------- Четыре различных квика не имеют общих данных. Поэтому непонятно, что Вы пытаетесь синхронизировать. -------------------------- DLL - это не данные а код.Не надо синхронизировать потоки при обращении к коду. ----------------------- Не надо синхронизировать потоки при обращении к константам. --------------------- Смысл синхронизации в том, что в момент чтения данных одним потоком, второй их непредсказуемо изменит.
АлексейМ написал: Попытался подключить самодельный индикатор. Индикатор не запускается, выдается сообщение об отсутствии lua-модуля. Посмотрел в папке Квика как указано было в пути ошибки - там нет таких файлов и папок с именем lua. Где их брать непонятно и как их устанавливать тоже. И почему их нет тоже непонятно.
VPM написал: nikolz, Да Вы совершено правы, я лишь хотел подчеркнуть особенность подключения
Цитата
VPM написал: Функция dofile выполнит Lua-скрипт, и все переменные и функции, определённые в нём, будут доступны в текущем окружении. И смысл здесь в подключении новой задачи!
Ведь есть еще способ local Utility = require("Utility").
require - это способ подключения готовых (не собственных) библиотек в том числе на С. Но при этом вы не можете передать в из них данные через глобальный стек. ------------------- Повторю свое мнение. dofile -не для подключения новой задачи, а для разделения длинного скрипта на отдельные куски, чтобы было проще читать и отлаживать. --------------------- Аналогия на книжках примерно такая: подключение библиотек с помощью require - это как сборка коллекции различных книг. а применение dofile - это как сборка книжки их листов.
VPM написал: nikolz, Не совсем понял Ваш вопрос? Применяя Вашу аллегорию, можно пояснить смысл. Если выпитый стакан вчера был с алкоголем, сев сегодня за руль, и подышав в трубочку представителю закона, результат выявлен. Так и в нашем случае, данные какие получили такие и есть. А задача подхода оценить кто заправляет в стакане, деля резултат алгоритма на 3 категории покупатель, продавец или нейтрально. Могу добавить что этот модуль, только часть большей задачи. Стакан это настроения, выставляя лимитки мы подменяем ММ и говорим о намерениях, рынок двигают рыночными ордерами это и оцениваем. В большой задаче, примерно также оцениваю Спрос/Предложение, и Настроение на рынке. Сейчас задача объединить анализ настроений с анализом сделок, в сделках уже есть время сделки.
Попробую пояснить. Недавно написал по заявке робота для торговли в стакане. Алгоритм простой, но по уверению заказчика работает эффективно. ----------------------------- Кроме того, использую стакан для торговли вечными фьючерсами. Из своего опыта, который не противоречит публикациям различных гуру в интернете, стакан - это инструмент скальперов или HFT роботов, ----------------------------------- По стакану нельзя ничего прогнозировать на завтра. Вы же применяете правило Фишера (непонятно зачем) и еще пытаетесь делать какую-то обработку статистики. Статистика - это всегда накопление данных и их усреднение. --------------------------- Вот я и спросил Вас, а Вы уверены, что Ваша статистика актуальна. -------------------------- Стакан, выпитый вчера, с похмелья не поможет. -------------------------------- Я обычно любую идею или алгоритм торговли сначала исследую на исторических данных, а потом лишь решаю применять или нет. ---------------------------- Вы можете доказать, что написанное Вами имеет практический смысл?
VPM написал: В стратегии реального времени, для автоматической торговли, в системы принятия торговых решений внес изменения, добавил использование данных о ликвидности в стакане. Давно "руки чесались", алгоритм не сложный, но мест где наделать ошибки достаточно. Вкратце следующий, получаем данные о ликвидности из стакана, проводится нормировка для преобразования к нормальному распределению, выделяем пиковые значения с помощью преобразования Фишера, создаем правила на основе нечеткой логики . Думаю еще прикрутить правило 3 сигм для стабилизации результатов, но пока без сигм покручу нужно добиться стабильности. Пока хорошей торговли!
Не критики ради, а дискуссии для. Полагаю, что Вы это делаете для торговли в реальном времени. Данные в стакане меняются существенно быстрее чем совершение сделок. Можете доказать, что предлагаемые вами расчеты данных по стакану являются актуальными в момент принятия решения? Иначе получится так, что решения сегодня принимаются по выпитому стакану вчера. Не актуально.
nikolz написал: И еще...Нет смысла запускать скрипты с помощью dofile (особенно как в приведенном VPM примере)Так как это лишь замедляет исполнение.---------------dofile имеет смысл применять для разделения большого скрипта на блоки, чтобы упростить чтение и отладку скрипта.
nikolz, Пример выше это просто демонстрация возможностей, ни на что не претендующая. К примеру у себя использую следующий вариант (кусочек из рабочего код):
Код
-- Пытаемся загрузить библиотеку
local fuzzy;
local success, err = pcall(dofile, path .. '\\luafuzzy.lua')
if not success then
Log:error( "Ошибка при загрузке файла luafuzzy: " .. err)
else
-- Если библиотека успешно загружена, используем её
local fuzzy = luafuzzy()
Log:info( "Библиотека luafuzzy успешно загружена!" )
end
while WORKING_FLAG do
Перед основным циклом while WORKING_FLAG do 1 раз вызываем "Пан или пропал!" :: , ни чего не замедляем, просто Функция dofile выполнит Lua-скрипт, и все переменные и функции, определённые в нём, будут доступны в текущем окружении. И смысл здесь в подключении новой задачи!
Вообще-то загрузка библиотеки и запуск скрипта в вашем примере это две большие разницы. Поясняю. Загрузка библиотек делается как правило один раз при запуске скрипта. Это необходимая операция, так как библиотек много разных и разумно не изобретать велосипед, а использовать готовый. Так как загрузка изначально и однократно, то не имеет значение время загрузки. ----------------------- В вашем примере Вы грузите и запускаете скрипт не однократно, так как используете флаг загрузки. Но нет смысла грузить и запускать скрипт т. е. многократно его грузить. Я через dofile загружаю свои библиотеки функций с целью разделить большой скрипт на части и отлаживать эти части отдельно. Фактически это вариант создания библиотеки, с упрощением обмена данными через глобальный стек.
Станислав написал: В скриптах используются всего 2 потока , один для колбэков и один в main.
В main для каждого скрипта создается отдельный поток, а вот колбэки находятся в некой очереди и вызываются синхронно, т.е. каждый колбэк ждет возвращения управления перед вызовом следующего.
Из-за этого имеем 2 особенности: 1. Нет нужды синхронизировать колбэки. 2. Надолго блокировать или производить тяжелые расчеты в колбэках не стоит, это приводит к подвисанию всех скриптов и даже терминала.
Если я ошибаюсь, поправьте.
немного поправлю. Для колбеков не создается специально новый поток. Колбеки вызываются в VMLua, которая создается в основном потоке терминала QUIK. --------------------------- Функция main запускается в отдельном потоке, в котором создается VMLua, дочерняя к VMLua колбеков.
Да похоже как-то так и есть. Факт только один - надо синхронизировать поток main() с потоком колбэков, кто бы его не запускал. Можно конечно поюзать всякие процесс мониторы и т.п., посмотреть процессы и их потоки, но и так понятно по вызовам стало, что main() и колбэки живут в разных потоках и что колбэки вызываются последовательно. Всем спасибо за ответы.
мьютексы излишне использовать, так как всего два потока. Ранее уже говорил, что это решается гораздо проще через Event. ------------------ Прикольно, что недавно реализовал работу этих потоков без элементов ОС синхронизации. Работает существенно быстрее даже относительно Event.
Станислав написал: В скриптах используются всего 2 потока , один для колбэков и один в main.
В main для каждого скрипта создается отдельный поток, а вот колбэки находятся в некой очереди и вызываются синхронно, т.е. каждый колбэк ждет возвращения управления перед вызовом следующего.
Из-за этого имеем 2 особенности: 1. Нет нужды синхронизировать колбэки. 2. Надолго блокировать или производить тяжелые расчеты в колбэках не стоит, это приводит к подвисанию всех скриптов и даже терминала.
Если я ошибаюсь, поправьте.
немного поправлю. Для колбеков не создается специально новый поток. Колбеки вызываются в VMLua, которая создается в основном потоке терминала QUIK. --------------------------- Функция main запускается в отдельном потоке, в котором создается VMLua, дочерняя к VMLua колбеков.
И еще... Нет смысла запускать скрипты с помощью dofile (особенно как в приведенном VPM примере) Так как это лишь замедляет исполнение. --------------- dofile имеет смысл применять для разделения большого скрипта на блоки, чтобы упростить чтение и отладку скрипта.
Станислав написал: Ну вы конечно очень глубоко копнули, а человек спросил просто можно ли одним скриптом в окне "доступные скрипты" перевести второй скрипт из состояния "остановлен" в состояние "запущен".
Штатными средствами сделать этого нельзя. Понятно что имея возможность запускать любой код в подключаемых библиотеках можно сделать вообще все что угодно , однако это не будет хорошим решением.
Задача решается с помощью механизма Event (ранее об этом говорил как альтернатива использования sleep в main).
Saturn написал: Возможно ли с помощью одного скрипта запустить другой ?
Полагаю, что вопрос не о запуске lua функций из файлов, а именно скриптов QUIK на основе библиотеки QLua так как это две большие разницы. ------------------------ Запуск функций из файлов с помощью dofile в вызывающем их потоке. Т е сколько бы функций не запустили будет основной поток с колбеками и поток main. ------------------------- При запуске скриптов QUIK будет создаваться новый поток main. Таким способом можно запустить столько потоков сколько хочется. ------------------------------ Сделать это можно.
SetUpdateCallback - как определить что начали приходить Не исторические данные., SetUpdateCallback - как определить что начали приходить Не исторические данные.
nikolz написал: еще проще сравнивать время свечи и текущее время компа.
Тоже не вариант, так как свечи могут приходить немного с опозданием и в итоге на границе времени интервала - эти свечи будут отбрасывается.
Вы ошибаетесь. В любом случае свечи истории - это свечи прошедших торговых дней. и как минимум не могут быть в предыдущем отсчете.
В чем же я ошибаюсь то :) Это факт - онлайн свечи могут приходить с примерно с 3 секундной задержкой. Вчерашний пример который я заметил на тестировании: 3 минутная свеча:
-время пришедшей свечи в callback 20:00, время сервера 20:01:34 (пока все нормально, треxминтная свеча укладывается в диапазон сервера с 20:00:00 - 20:02:59, поэтому эта свеча считается онлайн) -время пришедшей свечи в callback 20:00, время сервера 20:02:47 (пока все нормально, треxминтная свеча укладывается в диапазон сервера с 20:00:00 - 20:02:59, поэтому эта свеча считается онлайн) -время пришедшей свечи в callback 20:00, время сервера 20:03:02 (ТОЛЬКО ЧТО Пришедшая свеча все еще находится в 3 минутном диапазоне с 20:00:00 - 20:02:59 ,НО время сервера уже вышло из этого диапазона, то есть Квик или сервер брокера прислал запоздавшую сделку на несколько секунд, и если сравнивать это временем сервера, то получается, что эта сделка относится к исторической свече, хотя по факту - эта последняя онлайн сделка присланная с сервера)
Так что повторю без всяких ошибок: К сожалению Тоже не вариант, так как свечи могут приходить немного с опозданием и в итоге на границе времени интервала - эти свечи будут отбрасывается.
Поясняю. Запоздалыми свечи не бывают. сервер не может прислать Вам предыдущую свечу, если он Вам уже присылает текущую свечу. Запоздалыми бывают обезличенные сделки, когда Вы их либо начинаете принимать либо допринимаете после разрыва. И это происходит лишь тогда, когда этих сделок очень много. Относительно свечей такого быть не может в принципе. Сервер всего хранит 3000 свечей и он их Вам будет посылать, если Вы все стерли в архиве или подписались на совершенно новый инструмент или новый тайм, которого у вас не было раньше. ---------------------------- В остальных случаях. Все свечи истории уже есть в вашем архиве, либо их относительно мало и они догрузятся одним несколькими пакетами буквально за секунды. ------------------------ Перейдем к Вашим примерам: ---------------------- -время пришедшей свечи в callback 20:00, время сервера 20:01:34 (пока все нормально, треxминтная свеча укладывается в диапазон сервера с 20:00:00 - 20:02:59, поэтому эта свеча считается онлайн) -время пришедшей свечи в callback 20:00, время сервера 20:02:47 (пока все нормально, треxминтная свеча укладывается в диапазон сервера с 20:00:00 - 20:02:59, поэтому эта свеча считается онлайн) -время пришедшей свечи в callback 20:00, время сервера 20:03:02 (ТОЛЬКО ЧТО Пришедшая свеча все еще находится в 3 минутном диапазоне с 20:00:00 - 20:02:59 ,НО время сервера уже вышло из этого диапазона, то есть Квик или сервер брокера прислал запоздавшую сделку на несколько секунд, и если сравнивать это временем сервера, то получается, что эта сделка относится к исторической свече, хотя по факту - эта последняя онлайн сделка присланная с сервера) ------------------ Вы ошибаетесь. Это не время пришедшей свечи. Это время пришедшей сделки. Если свеча в момент пришедшей сделки не закрыта, то это текущая свеча, вне зависимости от времени сервера. Но если Вы проверяете время сделки, а с временем текущей свечи. Собственно параметр Size и позволяет определить есть новая свеча или это текущая.
SetUpdateCallback - как определить что начали приходить Не исторические данные., SetUpdateCallback - как определить что начали приходить Не исторические данные.
не уверен, но у сбера цена имеет 2 знач десятич знака , должно быть 270.00 -------------- Но лучше покажите как это записано в скрипте. ------------- Кроме того должно быть сообщение уточняющее причину ошибки ( в колбеке OnTransReply )
SetUpdateCallback - как определить что начали приходить Не исторические данные., SetUpdateCallback - как определить что начали приходить Не исторические данные.
SetUpdateCallback - как определить что начали приходить Не исторические данные., SetUpdateCallback - как определить что начали приходить Не исторические данные.
SetUpdateCallback - как определить что начали приходить Не исторические данные., SetUpdateCallback - как определить что начали приходить Не исторические данные.
Saturn написал: Подскажите пожалуйста, вот я вызываю SetUpdateCallback - предположим по Газпрому по дневному интервалу и в колбек начинают приходить данные, но сначала приходят исторические данные, а не реальные онлайн изменения цены сделки. И вот вопрос: а как мне тогда определить, что данные которые начали приходить в колбек - уже реальные изменения цены купли/продажи - чтобы я на них реагировал, а не исторические данные ?
Использовать счетчик свечей не предлагать - так как он естественно работать не будет: потому что ну пришел индекс последней Дневной свечи к примеру 100 датированная сегодняшним днем, начала пришли за половину дня исторические данные, а потом начали приходить онлайн изменения - НО индекс свечи все равно будет тот же - так как день еще не прошел.
используйте OnParam или OnAllTrade
Не хочу, у меня уже настроено все под SetUpdateCallback - вот только единственная проблема есть описанная. С OnParam или OnAllTrade - есть еще большая проблема - потому что там нужно самому формировать данные в интервалы, а это вообще капец неудобно, потому что нужно учитывать ночные переходы времени, выходные, праздники - геморрой короче один только.
Вы не поняли. OnParam или OnAllTrade использовать для определения, что приходят реальные данные, а не исторические.
SetUpdateCallback - как определить что начали приходить Не исторические данные., SetUpdateCallback - как определить что начали приходить Не исторические данные.
Saturn написал: Подскажите пожалуйста, вот я вызываю SetUpdateCallback - предположим по Газпрому по дневному интервалу и в колбек начинают приходить данные, но сначала приходят исторические данные, а не реальные онлайн изменения цены сделки. И вот вопрос: а как мне тогда определить, что данные которые начали приходить в колбек - уже реальные изменения цены купли/продажи - чтобы я на них реагировал, а не исторические данные ?
Использовать счетчик свечей не предлагать - так как он естественно работать не будет: потому что ну пришел индекс последней Дневной свечи к примеру 100 датированная сегодняшним днем, начала пришли за половину дня исторические данные, а потом начали приходить онлайн изменения - НО индекс свечи все равно будет тот же - так как день еще не прошел.
Nikolay написал: Да, оба терминала версии 11.4.0.54
ip адрес у Вас один. Очевидно приходит пакет в два терминала. Другой клиент не придет. Разработчики не учли, что у одного брокера можно открыть два счета и для каждого отдельный терминал. Я полагал, что два терминала на один IP не имеет смысла. По идее один терминал должен работать с несколькими счетами. А так прикол нормальный.
Михаил Понамаренко написал: Брокер ВТБ. Если QUIK был запущен ранее,то с началом утренней сессии, выставление заявок на срочном рынке недоступно. Проблема решается отключением/подключением сервера QUIK.
Данная проблема возникает примерно раз в неделю. Но. очень неудобна, т.к. QUIK работает круглосуточно на удалённом сервере. Роботы не могут совершать сделки на срочном рынке. Впервые была замечена после открытия ИИС. У других брокеров такой проблемы не наблюдаю.
Думаю, как временное решение, перезапускать или переподключать QUIK каждое утро через скрипт или планировщик. Но этот "костыль" применять не хочется.
Что делал? 1. Менял все доступные сервера ВТБ. 2. Экспериментировал с настройкой "Очищать данные при смене даты" на "Локальной машине", на "Сервере". 3. Проверял настройку счетов. Все счета добавлены (также при недоступности торгов на срочном рынке) 4. Переустанавливал QUIK, загрузив файл настроек .wnd. 5. Писал в поддержку ВТБ, обещали решить ещё месяц назад, но проблема не решена.
Просьба помочь с решением проблемы.
Идея такая: Можно разорвать соединение ПК с интернетом(не терминала) вместо перезапуска. Потом соединение ПК восстановить. КВИК автоматом должен восстановить соединение с сервером . При этом обычно не требуется повторная авторизация.
На сервере QUIK-Junior заявок с таким параметром нет.
Конкретный пример затруднимся привести, однако если параметр доступен для заявки, можно сформировать транзакцию ввода заявки с этим параметром в "Кармане транзакций" и сохранить ее описание в tri-файл.
А как узнать что параметр доступен? Где об этом написано? Какой инструмент или рынок допускает этот параметр? Кроме метода тыка в тысячи инструментов, есть еще какой-то способ?
Время окончания срока действия заявки может быть задано, если торговая система предоставляет такую возможность для данного типа заявок. В таком случае параметр может быть установлен на форме ввода заявки в терминале, либо передан в строке с описанием транзакции.
Можете показать конкретный пример как записать и указать для какого инструмента это можно сделать на демо или в реальных торгах?
Время окончания срока действия заявки может быть задано, если торговая система предоставляет такую возможность для данного типа заявок. В таком случае параметр может быть установлен на форме ввода заявки в терминале, либо передан в строке с описанием транзакции.
Нигде не нашел конкретное описание и установку данного параметра ------------------------ В документации по QUIK параметр указан на русском языке : Время истечения=124141 ------------------------ В документации по QLua аналогичный параметр есть лишь в описании таблицы заявок :
expiry_time
NUMBER
Время окончания срока действия заявки в формате <ЧЧММСС DESIGNTIMESP=19552>. Для GTT-заявок, используется вместе со сроком истечения заявки (Expiry)
---------------------- Просьба объяснить каким образом установить данный параметр на Lua и при ручном вводе заявки. Если это есть в документации, то дайте ссылку.
VPM написал: nikolz, Все я прекрасно понял. Смею предположить, Ваши торговые стратегии, видимо не выходят за пределы технологий "скальпинга", отсюда и кругозор. Выше Вы опубликовали участников заключивших договора, Вам наименования организаций не о чем не говорят? Именно они гоняются за тиками? Вы просто посмотрите на ликвидность в стаканах, и на финансовые возможности компаний обеспечивающих эту ликвидность. Что делать с остальными финансами? Могу предположить, что под скапинг выделяется не большая доля активного капитала на котором и крутятся HFT-алгоритмы, выдели 1% а что делать с 99% средств? Кстати, на эту же проблему эффективности, натолкнулся у себя в своих среднесрочных стратегиях, суть в следующем: есть 100% торговый капитал, по правилам риск менеджмента активный не более < 25%, что означает > 75% т. капитала лежит просто в обеспечении сделки, не плохо бы часть покрутить в скальперских стратегиях. Касаемо придумок все за долго до меня, стратегии опубликованы, на классику жанра указал выше. И никаких кличек, терминология применяется разная но это для упрощения в пониманиях, сегодня модная есть "смарт мани", там своя, у классиков своя, Суть одна. Касаемо следов не только на ценовых графиках отслеживаются, но часто в стакане, такой объем можно видеть, так как рассчитываемся по определенным правилам для данного эмитента то есть алгоритмический. Такие объемы определяются, и от них строятся разные стратегии. Платная услуга биржи, это не признак ММ, это один из источников дохода ММ. Даже мне раньше прилетало от биржи.
Не надо переходить на личности. Вы не угадаете , какими стратегиями я занимаюсь. смею заверить Вас, что все что Вы написали на форуме, как некоторое открытие для вас я изучил примерно 20 лет назад и все это уже применял в своих стратегиях. Я вам пытаюсь сказать что термин "маркет-мейкер" никак не связан ни со стратегиями ни с тиками ни с HFT Он связан лишь с оказанием услуг бирже. И ВСЕ --------------------- В той таблице, которую я вам привел с сайта биржи есть брокер БКС . Вы полагаете что БКС гоняется за тиками и поэтому Вы его называете ММ? ----------------
VPM написал: nikolz, Все это верно, это не предмет обсуждения. ММ это прежде всего коммерческий проект, целью которого является извлечение прибыли, как и любой другой коммерческой организации. Обладая значительными средствами, набирают большие позиции которые, оставляя следы на графике, а значить могут повести рынок за собой или держать его в диапазоне. Это интересует трейдера, отвечая на вопрос в какую сторону держать позицию, и уж совсем не интересно сколько заработал ММ. Именно это поведение как крупного игра их отличает. Вы можете даже конкретные алгоритмы найти в сети. Обладая дополнительной информацией они строят свои торговые стратегии, свой бизнес.
Вы не поняли. Я утверждаю, что понятие (кличка) "MM" связано лишь с оказанием платных услуг биржи. Это никак не связано ни со следами, ни с размером ни с чем другим . Если игрок не оказывает платные услуги бирже, то он не ММ. ---------------- Вы напридумывали кучу признаков для ММ, а реально существует лишь один - платная услуга бирже.