Алготрейдинг. Компьютер для тестов и роботов
Приветствую, коллеги!
Собираюсь переводить рабочие алгоритмы в код, вручную все делать слишком трудоемко. Под тесты и трейд собирается ПК. Прошу подсказать оптимальные для него требования.
Задачи:
1. Несколько терминалов Квик и МТ5.
2. Несложное программирование под Квик и МТ5 на родных языках. Исторические тесты, простые скрипты и автоматическая торговля. Графика примитивная, больше расчеты. Не HFT.
3. В перспективе вероятна установка спецсофта типа TSLab.
4. Стабильная работа в круглосуточном режиме.
Вопросы по конфигурации:
1. Процессор и материнская плата.
Рассматриваю Intel Core i3/5/7 7ххх-8ххх или AMD Ryzen 3/5. Какой минимум по процессору (частоте, ядрам, потокам)? Core i3 8ххх подойдет или уже слаб? Примеры хороших связок процессор + материнская плата очень бы помогли.
2. Минимум по оперативной памяти?
3. Потянет ли встроенная видеокарта (Intel или Vega) графику терминалов?
По остальному примерно понятно.
Что еще важно при сборке ПК под указанные задачи?
PS: Ещё раз скажу, что всё вышеперечисленное вообще не относится к HFT, речь об обычных алго. У меня крутится около 400 роботов на 100-150 эмитентах. Ресурсы довольно среднего ноутбука расходуются процентов на 25, не больше. Если что и виснет, так из-за пинга до брокера. Как и в любом бизнесе в трейдинге надо начинать попроще и минимизировать начальные вложения, а то некоторые купят ПК за 150 тыр, восемь мониторов еще на 150, а потому сливают, потому что не понимают, что дело не в ПК и не в мониторах))
А с чего начать? Скачайте Quick или Transaq или ещё какой-то терминал. Найдите бесплатные примеры кодов, читайте мануалы и пробуйте их модифицировать. Смотрите на результат. Со временем нейронная сеть в мозгу выстроится в нужном порядке и вы сами удивитесь как могли не понимать каких-то очевидных вещей
Компьютер, питание, интернет — это было актуально лет 20 назад. Сейчас за 10 минут с карточки можно купить сервер в облаке, которые изнаально лишен всех этих недостатков. Конфигурирование мощности происходит на лету.
А вы какие то древности обсуждаете. Я сам ИТ специалист. Вам говорю смело — идите в Амазон или Азуру. На дворе 2018 год. И телефоны сейчас умеют мощности, чем большинство персональных компьютеров.
И по рискам вы смотрите не туда. Вы оцениваете технику, хотя с ней проблем и не будет. А вот организационных проблем у вас будет выше крыше. У вас тут и солянка из разных систем, и языки разные. У вас это будет работать нестабильно. Вы все время будете тратить на контролирование, лишь бы что-то не упало или тихо не отключилось. От такой автоматизации нет никакого толку.
У вас есть друг программист? Подарите ему 20-30 т.р., чтобы он вам объяснил в какую сторону идти. Чтобы вы через пол года этот сервер на торги не выставили, со словами — «устал от бессонных ночей».
возникает. Далее будут более четкие определения по способу автоматизации. В любом случае считаю правильным разделение оборудования для трейдинга и всего
остального (офис, серфинг, архивы видео и т.д.), с заделом мощностей для перспективных задач. Спасибо!
Вы опять технику поставили выше остальных моментов. Проблема не в технике и не программах. Но я все выше описал. Имеющий глаза — прочитает.
Для ТСЛаб обязательно х64 (позволяет использовать более 1.5 Гига оперативки) + правильные настройки, плюс процессор приличный (количество ядер имеет значение!).
За счет одной только правильной настройки компа моего друга (с помощью технарей) производительность выросла в разы!
Для тяжелого скрипта это мегасупер! )
Задачка непростая, пришлось повозиться, но оно того стоит и даже большими деньгами такого добиться непросто.
Мы втроём (все трое не тупые) не могли ничего сделать пока спец не взялся.
PS: Машина относительно крутая, а больше 1 Гига памяти брать отказывалась и проц брала всего процентов до 30-40.
Сейчас проц — все 6 камней за 90%, память в зависимости от тяжести скрипта и количества параметров, максимально пока видел 3 гига. Это при том, что на виртуалке для системы с лабой выделено 5 Гигов всего.
2. По МТ не скажу.
Поэтому лучше взять меньше ядер, но выше частоты.
ТСЛаб не так сильно нагружает систему.
Остальное зависит от качества и количества скриптов.
Так что 4 ядра, частота выше 3.5Ггц, ССД и памяти 8 Гб.
У меня вообще все крутиться на серверной платформе.
forum.quik.ru/messages/forum10/message29998/topic3317/#message29998
Если знать особенности динамического распределения памяти в LUA, понимать природу фрагментации памяти и пользоваться управляемой сборкой мусора (collectgarbage), то можно довести занимаемую QUIK виртуальную память до 2 GB, далее чревато. Пока что QUIK — 32-разрядное приложение, с памятью действительно у кого-то может возникнуть напряженка. Но можно использовать несколько QUIKов.
По поводу скриптов, исполняемых отдельно, аозмвозм, что и сделали многопоточность.
На практике не вижу загрузки всех ядер тяжёлым скриптом. Винда 7, 64 бита, 16гб памяти, Ксеон 4 ядерный. При запуске отдельного скрипта чаще квик повисает и не отвечает на тяжёлых скриптах. При этом всего 4 графика на экране, но на каждом есть свой индикатор. И ещё выгрузка таблицы всех сделок на MySQL отдельного сервера через ODBC.
При этом загрузка редко превышает 30% по всем ядрам. Тяжёлый код в свое время пришлось в DLL выводить.
Сейчас уже не запускаю роботов, только индикаторы и потом скрипт трейлинга позиции
QUIK допускает много вариантов использования своих возможностей. Эти возможности допускают свое изучение, измерения и осмысление.
Многими путями, не всегда простыми и очевидными, можно повысить быстродействие своих алгоритмов и системы в целом — на проценты, в разы и даже на порядки. Вынужден был этим заниматься, поскольку мои алгоритмы очень тяжелы в целом, есть даже пока недоступные для современной “бытовой” техники. Другой стимул – желание работать роботами на субминутных ТФ.
Ну, заменю я свой ПК на более мощный (уже присмотрел вариант), ускорю работу в 10-15 раз, но я ведь уже ускорил работу своих алгоритмов почти в миллион раз и хочется еще большего (резервов уже мало(). Вот такое интересное соотношение между аппаратными и программными возможностями. Поэтому я и не тороплюсь с переходом на более мощный ПК – на слабом лучше заметны слабые места.
А загубить производительность можно и без особых усилий. Например, в архитектуре QUIK есть уязвимое место – основной поток, в котором, в частности, последовательно выполняются индикаторы и программы асинхронных вызовов (callback). Достаточно в одном из них затеять длительное вычисление и работа QUIK будет просто блокирована.
Ссылку на другой вариант я давал выше, его можно даже упростить.
Еще и разработчики QUIK помогут, например, добавили возможность накопления 65000 свечек истории. Даже штатные индикаторы стали ставиться с задержкой. Кстати, на всякий случай, MT5 стал держать на периферии зрения, хотя когда-то пришел в QUIK из MT4.
Все-таки строить систему на основе возможностей QUIK нельзя без учета особенностей его архитектуры.
Чтоб не повторяться, дам ссылку на 2-3 моих комментария в одной теме, может кому пригодится.
https://forum.quik.ru/messages/forum10/message30518/topic3568/#message30518
Если совсем коротко – индикаторы роботам не нужны, даже вредны – это потенциальные тормоза для всего QUIK. Оставим основной поток для предельно быстрых функций асинхронных выходов, для скорейшего доведения событий до роботов.
Все роботы (скрипты main) работают в отдельных потоках, одновременно и независимо друг от друга, если только явно не организовать между ними связь. Многоядерность и технология hyper-threading приветствуются. Мне они точно нужны.
Есть возможности QUIK, которые для меня являются анахронизмами, но вполне подойдут под некоторые задачи.
Например, доступ к свечкам графика по его идентификатору – анахронизм.
SLEEP в роботе – тоже анахронизм, лучше я наиграю 15-16 мсек через моментальную передачу асинхронного события (callback, например, завершение сделки или изменение свечки) из основного потока в поток конкретного робота. Кстати, самое несуразное, что я недавно встретил – попытку программиста встроить SLEEP или эквивалентное по времени зацикливание в скрипт индикатора – по факту, попытку заблокировать QUIK.
QUIK дает несколько вариантов доступа к источнику данных (текущим и историческим данным торгов). Их можно оценить по времени или размеру накопления некоторых буферов на бирже или у брокера, по событиям, выталкивающим эти буфера в сторону терминала, по их полноте и по времени поступления в программу пользователя. Есть приятные неожиданности. Можно выбрать оптимальный вариант под задачу.
Оперативная память – ее много не бывает. В первую очередь – откажусь от страничного обмена (я и сейчас на слабом ПК его редко использую). Вообще, издавна узким местом компьютеров, mainframe или ПК, был дисковый ввод/вывод, пока там была механика перемещения головок. И примерно таким же узким местом были очереди операций ввода/вывода. Этими факторами рубилась собственно огромная скорость передачи. Что даст SSD – пока наблюдаю.
у меня есть скрипт. по индентификатору график строит метки. метки — уровни из MySQL. при остановке скрипта квик подвисает на 3-4 секунды. загрузка при этом всего 8% CPU.
Бу с авито, ноуты, это как то вообще не профессионально. Я даже не приветствую колхоз самосборный. Надежнее конечно заводское решение, но это дорого.
Понравилась еще идея, описанная выше — аренда серверов. Очень стабильное решение.
Ну а по надежности… Нет ничего надежней «колхоза самосборного», если он сделан настоящим мастером из протестированного железа, чтоб вы знали.
НИКОГДА конвейер не сравнится с ручной работой.
Аренда серверов — тоже мне «идея». Если депозит приличный, специализированные сервисы для размещения роботов — это единственно верное решение. Но это для торговли и если «приличный», а тут речь идет несколько об иной задаче.
PS: бу за 3К — это бред конечно )
По мне так круглосуточные вещи, точнее хостинг роботов — это облачная тема, с какого-то момента другие варианты именно для этих целей не рассматриваю.
Для тестов тут больше вариантов — тоже можно в облаке (я использую VDS на данный момент), можно на своем компе. Облако в данном случае удобно возможностью масштабирования производительности, доступом с любого устройства и прочим.
Пишу я код на ноуте, тесты гоняю на VDS. Пока такой расклад. В соответствии с моим текущим представлением и для моих текущих задач — оптимальный вариант).