SMART-LAB
Новый дизайн
Мы делаем деньги на бирже
Информация
Блог им. karat39
Багосимулятор в алготрейдинге
- 27 ноября 2018, 16:35
- |
Сегодня у нас были очередные пожарные учения. К слову сказать, это уже третьи за год. Уже выработался набор правил, что нужно сделать в терминале/ах, прежде чем покинуть помещение.
Вообще это интересная тема. Судя по тому, что у нас иногда происходит в стаканах, не все алгоритмисты посвящают этому большое внимание. Говорю я сейчас про разработанный набор инструкций при возникших исключительных ситуаций в вашем алго. Если алготрейдер давно уже на рынке, то наверное знает, а если не знает, то поделюсь своим мнением, что набор стандартных типичных багов в алго несколько ограничен. А ситуаций, возникающих в следствии этих багов, еще меньше, но они есть и скорее всего и будут. Ну на вскидку, наверное можно вспомнить 8-10 типичных критических ситуаций, к которым может привезти исключительная ситуация.
Я в свое время начал их конспектировать, по мере получения опыта. Потом записывать процедуры поведения, шаг за шагом. А потом их еще проговаривать периодически, чтобы отложилась в памяти. Все это может вылиться в некий тестовый стенд, на котором можно будет оттачивать мастерство поведения при критических ситуациях. Это очень полезно. Это как пилоты оттачивают свое мастерство на реальных симуляторах.
Кто узнал себя, всем привет, кто не узнал, прошу в комментарии поглагольствовать, как нужно писать правильный код =)))
Вообще это интересная тема. Судя по тому, что у нас иногда происходит в стаканах, не все алгоритмисты посвящают этому большое внимание. Говорю я сейчас про разработанный набор инструкций при возникших исключительных ситуаций в вашем алго. Если алготрейдер давно уже на рынке, то наверное знает, а если не знает, то поделюсь своим мнением, что набор стандартных типичных багов в алго несколько ограничен. А ситуаций, возникающих в следствии этих багов, еще меньше, но они есть и скорее всего и будут. Ну на вскидку, наверное можно вспомнить 8-10 типичных критических ситуаций, к которым может привезти исключительная ситуация.
Я в свое время начал их конспектировать, по мере получения опыта. Потом записывать процедуры поведения, шаг за шагом. А потом их еще проговаривать периодически, чтобы отложилась в памяти. Все это может вылиться в некий тестовый стенд, на котором можно будет оттачивать мастерство поведения при критических ситуациях. Это очень полезно. Это как пилоты оттачивают свое мастерство на реальных симуляторах.
Кто узнал себя, всем привет, кто не узнал, прошу в комментарии поглагольствовать, как нужно писать правильный код =)))
теги блога Андрей К
- .Net Core
- Amibroker
- c#
- FAST
- FIX
- FORTS
- fpga
- ISS ММВБ
- linux
- lua
- moex
- mt5
- python
- qlua
- S&P500
- tradingview
- TWIME
- usdtry
- volume spread analysis (vsa)
- акции
- алготрейдинг
- Арбитаж
- баги
- банки
- биржа
- брокеры
- Вечерка
- Волатильность
- вопрос
- Время
- Газпром
- герчик
- гость
- долги
- доллар
- жопа подкралась незаметно
- здоровье
- игры разума
- инвестиции в недвижимость
- инвесторы
- конкуренция
- Константин
- кризис
- кризис 2020
- криптобиржа
- криптовалюта
- крупняк
- кукл
- легкий троллинг
- Лира
- ммвб
- МосБиржа
- Московская биржа
- нг
- Нефть
- облигации
- оборудование
- околорынок
- опционы
- опыт
- открытый интерес
- отчет
- отчеты
- оффтоп
- ошибки
- планы
- порядок
- праздники
- протокол
- Путь трейдера
- пятница
- работа
- работодатели
- рассылка
- резюме
- Риски
- рынок
- рынок труда
- с НГ
- сбой
- серверы
- смартлаб
- сроки
- срочка
- статистика
- судьба трейдера
- терминалы
- тесты
- технологии
- торговые роботы
- торговый софт
- Трейдинг
- Финам
- форекс
- фьючерс ртс
- фьючерсы
- частный трейдинг
- чаты
- юмор
- ютуб трейдеры
Правильный код — это модульная, низкосвязанная конструкция.
Использующая паттерны и реализующая набор структур, описывающих бизнес-сущности.
Пишется, тестируется и наращивается постепенно.
Такие ситуации обычно описаны в документациях биржи, где то глубоко и разорвано и разраб о них по началу никогда не задумывается. Только когда это уже все пройдет в бою
Андрей К, ошибки, которые не обрабатываются в коде отлавливаются при помощи исключений.
Стек и дополнительная информация пишется в лог.
Таким образом место возникновения и примерная причина бага становится ясна.
Далее либо пытаемся воспроизвести ошибку, либо ожидаем её нового появления и собираем больше информации.
Такими образом любая ошибка рано или поздно оказывается локализована и устранена.
«ошибки, которые не обрабатываются в коде» — такого вообще быть не должно.
На первых порах везде где только можно необходимы try-catch и логирование.
В любой программерской команде ЕДИНАЯ система расстановки try-catch должна существовать. Без этого никак.
Если такой системы нет, то со временем ее необходимо разработать
На собеседовании при найме на работу я всегда задавал самый главный вопрос не про классы, а как и где соискатель ставит try-catch. И наблюдал растерянные лица у людей с красными дипломами.
К сожалению этому не учат, а зря.
_sg_, такое есть почти всегда.
Это просто неизбежно.
И чем больше проект, тем больше таких мест.
Слишком часто лепить try catch — это не самая лучшая идея.
Даже по системе.
Достаточно сделать глобальный обработчик в точке запуска программы.
Он отловит любое исключение.
я Вам говорю про правильные технологии программирования, а Вы мне про некоторый тактический прием, который, как бы, все решит.
Почитайте у Microsoft статьи на эту тему. Где, как и когда применять try catch. Библиотеки на эту тему есть.
Если Вы хотите писать Приложения уровня Enerprise, которые работают 24/7, то придется эти технологии применять.
Мои Приложения уровня Enterprise могут работать Годами без перезапуска и это благодаря выработанной временем технологии применения Try catch.
_sg_, пусть так.
Простите, но про «годы без перезапуска» не верю.
не получиться. Потому, что Вы в своих алго-проектах работаете с внешними библиотеками ( коннекторами итд) сторонних разработчиков. Что и как внутри этих библиотек Вы не знаете по определению. Как они ведут себя в критических ситуациях? — Правильно. Генерят Exception. И самая распространенная ошибка начинающих: НЕ СТАВИТЬ try catch при вызове методов библиотек сторонних разработчиков. Это только один из примеров.
есть статья у америкосов, try catch изнутри. Там показывается и рассказывает как он устроен. Что сильно взаимодействует с ОС. А это в таких алго вообще категорически запрещено. Во первых портится постоянно боевой кеш, во вторых никак не получается точно прогнозировать память. В связи с этим скорость исполнения алго выходит из под контроля и разброс результатов во времени очень сильный, а это недопустимо.
незначительное замедление работы Приложения гораздо лучше, чем Приложение, которое падает.
Но зачастую, тогда просто деньги не заработаешь. Раньше пользователь uralpro часто писал о результатах. Он открыто говорил, что разброс скорости у них лежит в диапазоне 2-8 мксек. Я с ним болтал немного, получилось, что все результаты тяготеют чаще к 8, чем к 2. В таких алго это совершенно не нормально. На его примере, нормально, это когда скорость лежит в дипазоне 2-2.2мксек в 90% трейдов. Для этого и приходится так все кастомизировать.
много софтверных проектов полегло в погоне за скоростью, игнорируя устойчивость и надежность софта.
Как правило, авторы после этого говорят: «Хотели как лучше, побыстрее». А получилось как всегда.
Знакомый лозунг: «Пока гром не грянет ...».
Надо изначально учиться писать надежное ПО и выпускать надежную продукцию, и тогда не будет необходимости «отрабатывать технику чрезвычайных ситуаций»
теперь я уже не знаю что вам ответить =). Вы не занимались скоростями, а у меня не получается до вас донести с чем приходится сталкиваться. Во всем остальном я с вами согласен
Antishort, всё верно.
Чем логичнее/проще структура программы, тем легче предположить место ошибки.
Особенно если есть надёжные модули, которые можно исключить из подозрения.
Но писал я чуть не об этом. Иногда могут возникнуть такие ситуации, о которых даже не подозреваешь. Ну например биржа пришлет по определенным канал связи не ту котировку. Из последнего что помню, примерно с год назад, биржа решили перезагрузить часть серверов во время торгов, к слову сказать, именно эти серваки они вообще никогда не перезагружали. В итоге на рынке целый ряд алго нахвтали ошибок и начали вываливать огромный объемы в стаканы, неся очень не малые убытки. На этот случай у трейдера счет идет на секунды, чтобы он предпринял самые правильные действия. И репетировать их, я считаю необходимо. Либо хотя бы разработать алгоритм действий
Андрей К, а как в реальном времени понять, что котировка кривая ?
Для этого как минимум нужно её с чем-то сравнивать и следить за каждым тиком.
Геморой короче.
Тут скорее робот откроет неправильно позу, получит стоп и тогда уже трейдер обратит внимание на ситуацию.
А косяк будет ясен позже.
Когда собранные котировки прошлого дня автоматически сравнят с историческими данными.
поэтому надо уметь реагировать. Такая засада может не вылазить несколько лет у начинающих алгоритмистов, а потом как вылезет, мало не покажется.
Андрей К, иными словами невозможно.
Нет чётких критериев кривой котировки.
квик иногда может по несколько минут не «отдавать» таблицы или вообще лечь на часок другой
Пока нет времени только отрывочные мысли.
1) Учиться, учиться и учиться.
2) Везде и всюду проверять на ошибки.
3) Тотально логгировать все события, вплоть до каждого изменения цены, с указанием точного времени.
4) Вести учет всех сбоев, регулярно осуществлять анализ сбоев и модификацию кода для предотвращения их повторения.
5) Иметь в коде защиту от критических рыночных событий.
6) Не писать на Lua…
Jame Bonds, главное не усложнять, а то код для поиска ошибок будет сам источником ошибок.
Вы пропустили один важный пункт:
7) Не нанимать криворуких студентов.
7а) все делать самому.
Jame Bonds, к сожалению это работает только в мелких проектах.
Что-то более серьёзное в одно лицо не потянуть.
позволяет вполне надежно исполнять и писанины не так много, можно даже со слабым скилом навертеть вполне работоспособного робота
— отсутствие проверок на элементарные опечатки;
— возможность вызова необъявленных функций (мгновенное прерывание выполняемой процедуры) и использования необъявленных переменных (нет ошибки даже при выполнении);
— отсутствие симулятора, на котором можно выявить глюки порожденные пунктами выше (это было бы не так критично, если бы не пункты выше);
— низкая скорость работы.
Резюме: можно писать только относительно простых роботов, при условии их полной отладки в присутствии оператора в реальном времени (то есть медленно).
Jame Bonds,
"— возможность вызова необъявленных функций (мгновенное прерывание выполняемой процедуры)"
не понял в чём тут проблема, ну можно не объявлять функции и что?
низкая скорость работы именно программы написанной на луа?
Был бы компилятор, он бы выдал ошибку на этом моменте и не запустил бы скрипт.
Андрей К, не, в луа не нужно объявлять функцию
про компилятор то понятно, из-за этого сколько раз застревал пока не находил ошибку, например скобки не поставил)) при том скобки не поставлены в одном месте, а квик указывает на ошибку строкой ниже
А напиши, интересно почитать, на что натыкаются опытные трейдеры
Отдельный вопрос: какие терминалы/приводы/ПО вы используете? Какие нарекания по надежности? Вот тут пишут про Quik, Lua, есть еще целое коммьюнити разрабов под MetaTrader. А у вас что?
самое самое основное, это:
1) биржа в силу каких то действий прислала кривые котировки
2) код робота из за ошибки не правильно оценил котировки/объемы
только триггером к подобным ситуациям может быть много чего: сбой биржи, планки, какие то плановые работы биржи, какие то нюансы работы биржи, о которых просто не прочитал и тд… когда алгоритмы имеют не правильные представления о текущих котировках могут пойти в разнос сильнейшей и лить как из ведра. Периодически это происходит у нас на forts, это видно.
cfree0185, здорово, но сделать подобное на порядок сложнее, чем написать робота.
есть торговый алгоритм — сложный, асинхронный, с заточкой на экстремальное быстродействие
рядом — поток с контролирующим простым алгоритмом, который проверяет некоторые метрики торгового.