Блог. StockSharp

Где и как скачать маркет-данные по американскому рынку. Решение.

2016-12-02T11:58:44Z

В нашей сегодняшней статье мы расскажем о том где можно бесплатно или за относительно небольшие деньги скачать исторические данные по американскому рынку, а также об универсальном способе скачивать, сохранять, анализировать и использовать в собственных алгоритмах любые типы рыночных данных.
Прежде всего давайте коснемся основных источников маркет-даты по американским ценным бумагам с кратким их описанием. В целом можно выделить три типа источников:
1. Источники исторических данных, например биржи, которые поставляют историю торгов на собственной площадке (конечно оставляем за гранью прямые подключения которые относятся к типу 2).
2. Источники рыночных данных, например брокерские терминалы, через который конечно можно загрузить в том числе и определенную историю, но основной интерес представляет то, что происходит прямо сейчас.
3. Универсальные источники, которые объединяют в себе тип 1 и тип 2, и как правило представлены специализированными сервисами.

К первому типу источников можно смело отнести такие сайты как Google и Yahoo Finance:

Несомненным достоинством этих сервисов является их полная бесплатность, однако, с другой стороны, интрадей маркет-данные скачать будет невозможно, также как невозможно получить, что либо кроме свечей. Под что-либо мы конечно подразумеваем такие данные как Level1, Order Log, Market Depth и т.д.
Это практически исключает возможность использования полученных данных для тестирования стратегий, предполагающих торговлю внутри дня. С другой стороны, если ваша стратегия предполагает среднесрочную торговлю, например, основана на подходе “Черепах”, либо вы практикуете портфельное инвестирование без слишком частого перетряхивания портфеля, то использование данных с этих источников будет очень обоснованно и целесообразно.

К источникам рыночных данных как уже написано выше, относятся, прежде всего, брокерские терминалы или другие подключения к брокеру, которые есть у каждого практикующего трейдера. Например: Fusion/Blackwood, Rithmic, Gain Capital, OEC Trader, Sterling и т.д.

Плюсы от использования данного источника видны практически сразу. Во-первых, это бесплатно (конечно без учета тех комиссий, которые вы платите брокеру). Во-вторых, это множество данных которые можно получить: некоторые типы свечей, тики, Level1, DOM и т.д. К минусам можно причислить отсутствие глубокой истории и необходимость хитрого сбора нужных данных, когда без специализированного ПО не обойтись.
При таком подходе, ваши возможности для тестирования значительно расширяются. Появляется возможность создавать не только внутридневные стратегии, но и высокочастотные алгоритмы, основанные на найденных исторических закономерностях.

Универсальные источники - это в большинстве своем специализированные сервисы, которые поставляют как реал-тайм маркет-дату, так и любую запрошенную историю, например IQFeed.

Главным плюсом подобного источника является его универсальность и наполненность данными, т.е. в любой момент по запросу пользователя можно получить любые нужные данные, тиковые, свечи, стаканы и т.п. Минусом такого подхода является платность данного сервиса, цена на который начинается от 50$ в месяц в базовой версии. Если возникает желание получить несколько больше, то потребуется подключить дополнительные функции, которые как вы уже поняли тоже будут стоить денег. Но, как и предыдущий вариант, вам потребуется специальная программа для сбора и хранения данных. Ведь по окончанию действия подписки вы потеряете все данные. Плюс глубина истории, хоть и больше, чем у предыдущего способа, но все равно она ограничена. Особенно для тиковых данных.

Теперь мы можем перейти к самому интересному, а как же нам оптимально получать историю и при этом не тратить много денег. На наш взгляд, здраво выглядит следующий подход:
- скачать дневные свечи с бесплатного источника, и протестировать свою стратегию предварительно на этих данных;
- скачать интрадей данные через своего брокера, и протестировать уже более детально стратегию
- покупка подписки на платный сервис и выкачивание всего интересующего массива данных,
Для того, чтобы реализовать подобное, потребуется специализированное ПО, которое будет за вас вначале загружать нужные данные с нужного сервиса, а затем в едином формате продолжит сбор их от вашего брокера. Таким образом, единство данных не будет утрачено и их можно будет легко использовать в дальнейшем анализе.
Для таких задач мы создали программу S#.Data (Hydra) (ознакомиться с инструкцией и примерами по работе с программой можно здесь). Это бесплатная программа, доступная для скачивания. Hydra предоставляет множество различных функций, но основной ее задачей является скачивание и накопление данных.

Hydra поддерживает загрузку не только свечей любого таймфрейма, но и тиков, ордер лога, level 1, стаканов по множеству инструментов. При этом программа умеет не только скачивать, но и накапливать данные, идущие от брокера, например из OEC Trader, Sterling и т.д.

Hydra хранит данные в форматах CSV или BIN (сверх компактный формат хранения данных - 7 байт на 1 снимок стакана или 2 байта на тик). Данные располагаются локально, как файлы, и к ним есть доступ из любых программных языков , а также позволяет в конечном итоге пользователю хранить и использовать огромный массив рыночных данных на домашнем компьютере, сервере или в облаке (поддерживается AWS).

Подводя итоги настоящей статьи, надеемся, что методы изложенные в ней позволят вам, получить маркет-дата за адекватные средства и немного приблизиться к профессиональным участникам.
Они давно так делают!
Желаем удачи на рынке!

S#.Data (Hydra) - инструкция и примеры по работе с программой.

2016-12-01T16:37:31Z

Гидра - программа для скачивания и накопления маркет-данных. В данной статье расскажем, как скачивать историю с Google Finance, брокера Gain Capital и сервиса IQFeed.
Для начала расскажем немного об интерфейсе программы. После первого запуска вы увидите главное окно, которое предложит вам выбрать источники данных.

Обратите внимание на описание каждого источника, если рядом с ним написано:
Source is designed to get history data … - то это означает возможность скачивания исторических данных,
а если написано:
Source is designed to get market-data .. - то это означает возможность подключения к реалтайм источнику данных и самостоятельному сбору истории. Забегая вперед, подобный способ зачастую дешевле простой покупки данных у дата-вендора.

Теперь выберем ряд источников и попробуем получить маркет дату. В качестве таковых мы предлагаем использовать: Google (как источник исторических данных), OECTrader (как источник реал-тайм данных, который вам даст брокер при открытие счета), IQFeed (как источник реал-тайм данных с максимальным количеством одновременных подписок).

Ставим галочки напротив выбранных источников.
После нажатия кнопки ОК, программа предложит вам включить дополнительные возможности.

Они достаточно полно описаны в самой программе, поэтому не будем здесь вдаваться в описание каждой из них.
Для того, чтобы двигаться дальше достаточно будет просто нажать ОК, не выбирая в данном окне ничего. При необходимости всегда можно вернуть данную настройку через кнопку ADD -> Tools и выбрать необходимое.
После всех проделанных процедур мы получаем в левом окне добавленные источники, каждый из которых теперь необходимо настроить.

Google Finance

Делается это простым нажатием на кнопку карандаша, которая открывает окно настроек.

Быстренько пробежимся по каждой из них, чтобы сложилось полное понимание. Итак:
Start date - дата с которой Hydra будет получать рыночные данные
Time Offset - смещение времени. В данном случае 1 означает, что данные за сегодняшний день скачаны не будут. Это нужно для того, чтоб не скачать половину дня, когда торги еще не завершены.
Weekend - когда галочка установлена выходные дни игнорируются.
Time interval - hydra скачивает данные по частям. Данный параметр позволяет указать насколько большие части будут использованы. При значении 30 программа будет скачивать данные пакетами по 30 дней.
Header, work from, work until, work interval - настройки по работе самой программы, в течение какого времени она должна загружать данные (от и до)
Data directory - папка в которой будут храниться скачанные данные, можно оставить по умолчанию, можно выбрать любую собственную. Рекомендуем создавать под каждый источник отдельную директорию, чтобы данные не перезаписывались.
Format - формат сохраняемых данных. Поддерживается BIN - специальный формат Hydra позволяющий получать уникальную степень сжатия (2 байта на тик, 7 байтов на стакан) либо всем известный CSV (тут объем обычный)
Max.errors - максимальное количество ошибок в источнике.
Dependency - указывает на добавленную задачу, которая должна быть выполнена до текущей (в нашем случае это может быть либо IQFeed, либо OEC Trader)
Logging level - уровень логирования.

Давайте оставим все данные по умолчанию и выберем бумаги по которым будет происходить скачивание данных. Допустим выберем штук 5 тикеров, входящих в S&P500 индекс, например: MMM, AFL, GOOG, AAPl, T.

Для этого все эти инструменты нужно добавить:

Поскольку источник Google не поддерживает автоматическое добавление инструментов, то потребуется добавление их в базу вручную

Далее повторяем процедуру для каждой бумаги и перемещаем их в раздел Selected

После этого просто подключаем источник и нажимаем Start.
По окончании скачивания вы должны получить вот такие результаты

OpenECry (Gain Futures)

Источник рыночных данных для клиентов Gain Capital, который вам дает брокер бесплатно при открытие счета. Ключевые настройки источника во многом аналогичны настройкам, которые мы сделали в Google с той лишь разницей, что теперь нужно вносить логин/пароль от вашего аккаунта для доступа к потоку данных и выбрать правильный адрес с которого эти данные будут идти. Предустановлено 3 возможности: тестовый сервер (к которому подключаемся мы и который предназначен для разработчиков), симулятор (сервер для демо счетов), реальный сервер (сервер, имеющий подключение к реальному рынку и реальным счетам). Если у вас открыт счет, то ваш выбор реальный сервер.

Параметр Candle from data нужен для указания начальной даты, с которой необходимо скачивать историю в виде свечей.
После того, как вы это сделаете добавляем инструменты данные по которым мы хотим получить, поскольку OEC поддерживает автоматическую загрузку и поиск инструментов, делаем это через кнопку Download Securities, с последующим добавлением их через код инструмента. Наш выбор ESZ6 (мини S&P) и NQZ6 (мини Nasdaq).

В результате добавления у вас должно получиться тоже самое, что представлено на картинке.
Теперь обратите ваше внимание на нижнюю часть окна. В самом начале статьи мы говорили о том, что Hydra поддерживает загрузку и хранение множества типов рыночных данных, настройки о том какие данные загружать можно сделать с помощью соответствующей панели:

On Ticks - означает, что будут загружаться тики
On Market Depth - означает, что будут загружаться стаканы
Candles имеет дополнительную настройки при нажатии на кнопку можно выбрать типы свечей которые будут загружаться, вот как это выглядит:

On Level 1 - означает, что будут загружаться лучший бид/аск, а также ряд полей фундаментальной статистики тикера.
Теперь достаточно нажать кнопку Start и Hydra начнет получать данные и сохранять их локально. При этом, получаться будут как исторические, так и рыночные данные по торгам, которые идут прямо сейчас!
Таким образом, можно самостоятельно накапливать и сохранять рыночные данные, а затем использовать их при тестировании собственных стратегий.

IQFeed

IQFeed предоставляет, как и OpenECry, интрадей данные. Но, в отличие от OEC, IQFeed поддерживает очень большой диапазон параллельных подписок, а также значительно большую глубину истории, как по свечам, так и по тиковым данным.
Настройки источника аналогичны OpenEcry:

Параметр Candle from data нужен для указания начальной даты, с которой необходимо скачивать историю в виде свечей.
Параметр Ticks from data нужен для указания начальной даты, с которой необходимо скачивать историю в виде тиков.
Все остальные действия аналогичны описанным выше.

Работа с данными

Теперь после всех манипуляций, нужно понять, а как же с этими данными работать и что еще может программа. Напомним, что данные сохраняются в той папке, куда вы их скачали, но как посмотреть, что получилось.
Для этого обратимся к источнику OEC Trader по которому было скачано множество данных, выделим его и нажмем правую кнопку мыши.

После этого из менюшки можно выбирать то, каким образом работать с инструментом. Давайте выберем Market Depths и затем в открывшемся окне нажмем кнопку с лупой.
В результате мы получим подобную картинку

Далее аналогично выбираем Level 1, а потом Candles 1 min, только в окне работы со свечами выбираем не лупу, а кнопку “Построить график”. Результаты показаны на рисунках ниже

Вот таким образом можно просматривать данные и работать с ними прямо из программы.
Надеемся наш продукт поможет вам в трейдинге и разработке прибыльных торговых систем.

S#.Designer - доступна beta 4

2016-10-03T17:44:28Z

Выложена новая бета Дизайнера.

Прежде всего - что мы добавили:

1. Выделение линий при наведении на них + выделение всех линий, соединенных с выделенным блоком:

2. Автоматическое переименование элементов. Действует для элементов: Формула, Переменная, Условие, Индикатор и Свечи.

3. Элементы для снятия заявки, ее замены. Самое время начать делать котирование на кубиках![flapper]

4. Авто-сохранение стратегий. Кнопки сохранить теперь нет (разве только для экспорта стратегии для своего коллеги).

5. Точки-остано на весь элемент в случае пользования отладчиком.

6. Подсвечивание ошибочного элемента в случае возникновения ошибки с последующим отображением ошибки ввиде подсказки.

7. Открытие-сокрытие сокета с ценой у элемента открытия позиции (если идет регистрация меркетной заявки).

Исправленные ошибки:

1. Фикс ошибки редактирования настроек свечек http://stocksharp.ru/posts/m/36987/
2. Фикс загрузки портфелей после перезапуска в случае ранее произведенного подключения к торгам http://stocksharp.ru/posts/m/36982/
3. Фикс элемента Защита позиции http://stocksharp.ru/posts/m/37055/
4. Фикс ошибки http://stocksharp.ru/posts/m/36990/

Надеюсь вам всем понравится использование нашей программы! Огромное спасибо за Иван З. и Senex-у за их неоценимый вклад в развитие Дизайнера!

Конкурс раздачи плюшек за бета-тестирование еще действует.

Предыдущее обсуждение здесь.

>> Скачать <<

Знания для всех! Даром! И пусть никто не уйдет обиженным!

2016-11-01T10:29:47Z

Команда StockSharp совместно с Инвестиционным Холдингом Финам представляет базовый курс по алгоритмическому трейдингу и использованию платформы StockSharp!

Мы открываем двери для новичков!
Даже, если вы ни разу не программировали и не знаете, с чего начать, этот курс поможет вам сделать первые шаги. На вебинарах мы расскажем, какие программы вам потребуются для разработки и как их можно получить бесплатно, каким образом быстро и просто установить все необходимое программное обеспечение на ваш компьютер. Вы познакомитесь с основами языка программирования C# на котором создана платформа.

По итогам серии вебинаров каждый участник сможет самостоятельно написать простой привод, и совершить через него самую настоящую сделку.

Мы уверены, что после этого курса каждый из участников станет на шаг ближе к самостоятельной алгоритмической торговле.

При этом мы будем использовать только лицензионное и бесплатное программное обеспечение. Откройте для себя неограниченные возможности с платформой StockSharp!

Записаться прямо сейчас! Курс уже идет!

Почувствуй себя Колумбом! Америка близко как никогда!

2016-10-25T16:10:24Z

В то время, как комиссии на российских площадках продолжают расти вверх, а наш любимый ЦБ решает, что же делать с вами, трейдерами, мы всем предлагаем открыть счет у брокера Optimus Futures (Gain Capital).

Открывая счет через нас, вы получаете специальные условия от брокера: размер минимального депозита для наших клиентов ВСЕГО 2 500$, комиссия 1,2$ per trade. Кроме того вы получаете стандартную техническую поддержку от нашей компании навсегда, и все плюшки, доступные по расширенной лицензии!

Наша компания 2 года сотрудничает с брокером Optimus Futures, и мы можем оценить высокое качество торговли, и индивидуальный подход. Вы можете убедится сами в отзывах реальных трейдеров аж с 2010 года на сайте futeres.io https://futures.io/broke...ding-broker-review.html (бывший БигМайк форум).

Со своей стороны, мы поможем вам с первичной информацией, переводом с английского, решением возникающих вопросов.
Надеемся, что вы высоко оцените нашу работу с брокером Optimus Futures.

Открыть счет прямо сейчас!

Задать вопрос и получить ответ!

S#.Designer. Скачивание данных и тестирование на истории. Видео 2.

2016-09-07T13:12:56Z

Документация в новом месте

2016-09-26T12:30:27Z

Всех с понедельником!

Теперь документация располагается по адресу http://doc.stocksharp.ru

Ссылка на старое рапроложение будут перенаправлять в новое место.

Внимание!

Если вы пользуетесь алгоязычной версией сайта, то по адресу http://doc.stocksharp.com аналогично будет англоязычная версия документации.

Colocation преодолевает скорость света. 3 часть

2015-07-11T13:07:28Z

Перейти к части 2

Colocation обеспечивает лучшее решение для высокоскоростных приложений
Мы показали, что механизм центрального компьютера может быть заменен на функционально идентичный механизм с использованием группы компьютеров, размещенных с серверами биржи. Парадоксально, но в целях достижения эквивалентного результата мы должны были использовать абсурдные на первый взгляд генераторы искусственных задержек, что тормозило передачу информации от каждого сервера к компьютеру на задержку равную задержке полного круга между сервером и центральным компьютером – d (плюс дополнительная задержка сервера в общем механизме, совмещенных групп). Для большинства алгоритмов "центрального компьютера" удаление генераторов задержки в похожем сценарии позволит дизайнерам разработать алгоритм распределения, который не только соответствует, но гораздо лучше, чем алгоритм "центрального компьютера". Природа и значение улучшения будет зависеть от алгоритма и его функции. В большинстве случаев, алгоритм "центрального компьютера" придется переписать с нуля, чтобы воспользоваться преимуществом предвидения на местном рынке. (Однако, в некоторых случаях, улучшение невозможно. Рассмотрим это на примере неких ежечасных "слепых" аукционов. В таком случае, использование одного центрального компьютера будет оптимальным. То есть более экономичным, чем в группе совмещенных компьютеров.).
Вспомним наш пример "Нью-Йорк-Лондон" из предыдущего раздела. Что было бы, если бы замедлили передачу информации в дата-центре Нью-Йоркской биржи с коэффициентом 10 000 (с типичных двух микросекунд до 20 миллисекунд). Ни один уважающий себя высокочастотный трейдер не станет мириться с таким положением вещей. Удаление генератора задержки позволило бы размещенным компьютерам "заглянуть в будущее на локальных рынках" по сравнению с тем, что видит центральный компьютер. Это позволило бы развить значительное превосходство торговой стратегии. Фирмы, занимающиеся высокочастотной торговлей готовы платить миллионы долларов в месяц, чтобы увидеть 20 мс. в будущем. Другими словами, если компьютер находится в середине между финансовыми биржами, то это лучший способ приблизиться к скорости света, а с помощью компьютеров, размещенным в дата-центрах разных бирж можно "преодолеть скорость света" - откуда и название этой статьи.
Но даже и без каких-либо дополнительных усовершенствований, стратегии на механизме совмещенных групп должны быть развернуты только в N финансовых центрах по всему миру, а не n⋅ (N-1) / 2 "серединных торговых точек", показанные в статье Nature. Наконец, самая хорошая новость: нам никогда не понадобятся страшные "корабли для высокоскоростной торговли"!

Вариант полноценного Colocation решения может эмулировать любое другое решение
Мы показали, что механизм "центрального компьютера" может быть всегда заменен на функционально эквивалентный механизм или более эффективный, при использовании группы компьютеров, размещенных в дата-центрах бирж. Один вопрос, который остается: может ли быть улучшено данное решение? Можем ли мы, добавив несколько дополнительных компьютеров в середине и/или удалив некоторые из размещенных компьютеров, получить любое лучшее решение, чем то, которое может быть реализовано с помощью механизма "совмещенных групп"? Ответ: - нет. Полная группа N компьютеров совместного размещения с серверами N обеспечивает оптимальную конфигурацию, которая не может быть улучшена.
Для того, чтобы заявить об этом официально, мы определяем новый термин: "агрегирующая конструкция". Агрегирующая конструкция - это группа компьютеров, работающих под распределенным алгоритмом, включая каналы коммуникации между членами группы и все входные и выходные каналы связи с внешним миром (состоящая из "серверов"). В отличие от одного компьютера под управлением алгоритма, спецификация агрегирующей конструкции должна включать сведения, касающиеся пространственных расположений входов и выходов, а также компьютеров-членов, и задержки ограничений на связи между этими местами. Агрегирующая конструкция более официальный термин для того, что мы называли "черный ящик" в предыдущих разделах.
Данные N серверов, полноценного colocation решения агрегирующей конструкции – это объединение N компьютеров, совмещенных с соответствующими им серверами.
В заключении, чтобы продолжить наше доказательство, нам нужно будет провести операцию по "объединению" компьютеров. Если C1 и C2 два отдельных, совмещенных компьютера под управлением алгоритма A1 и A2, соответственно, то C1^C2 обозначает компьютер, на котором запущены те же алгоритмы и используются в сочетании входящих/исходящих каналов обоих компьютеров как входящих / исходящих каналов одного объединенного компьютера, соответственно (см. рисунок - "Операция по созданию объединенного компьютера C1 ^ C2"). Операция соединения является чисто косметической. Два алгоритма работают независимо друг от друга на объединённом компьютере и сохраняют все их свойства (например, смещение времени, входные задержки и т.д.). Сообщения, полученные и отправленные от двух алгоритмов, также остаются прежними. Операция по объединению позволяет рассматривать два размещенных компьютера, как один компьютер, который функционально эквивалентен обоим, будучи объединенными. От перестановки компьютеров суть операционного объединяющего компьютера не изменится. (В соответствии с правилами commutative и associative.).

Теперь мы готовы сформулировать и доказать основной результат.
Следствие 1. Любое объединение компьютеров, подключенных к нескольким серверам, может быть повторно реализовано с использованием полноценного colocation решения агрегирующей конструкции таким образом, что поведение агрегирующей конструкции (как зафиксировано серверами) неотличимо от исходной совокупности.
Для доказательства используем метод математической индукции (mathematical induction ) по числу K компьютеров совокупности, которые не совмещены ни с одним из серверов.
Очевидно, что вывод верен для К = 0. Здесь каждый компьютер агрегирующей конструкции находится в colocation связке с одним из серверов. Для того, чтобы сформировать эквивалент полноценного colocation решения агрегирующей конструкции, мы добавляем компьютеры, не совершающие никаких действий, к серверам, у которых нет подключенных компьютеров, и мы заменяем все компьютеры, находящиеся в colocation связке с данным сервером на их Joined версию (см. рисунок выше), чтобы обеспечить единый объединенный объект на каждый сервер.
Предположим теперь, что следствие верно для некоторого K ≥ 0.
Рассмотрим агрегирующую конструкцию D* подключённую к N-серверам (X1, ..., Xn), так чтобы K+1 компьютеров, которые не находятся в colocation связке ни с одним из серверов.
Мы начинаем с нормализации D*: добавляем компьютеры, не совершающие никаких действий, к серверам, у которых не было подключенных компьютеров D*, и мы заменяем все агрегирующие конструкции, находящиеся в colocation связке с данным сервером на Joined версию (см. рисунок выше), чтобы обеспечить единый объединенный объект на каждый сервер. Это не меняет количество, не находящихся в colocation связке компьютеров D* или поведение агрегирующей конструкции.
Отныне, мы предполагаем, что Di является одним из компьютеров D*, находящийся в colocation связи с сервером Xi для i = 1, ..., N. и что компьютеры DN+1, ..., DN+K+1, не находятся в colocation связи ни с одним из серверов.
Таким образом, мы предполагаем, что объект DN+K+1 не связан напрямую с любым сервером Xi. Если он был подключен непосредственно к Xi, мы всегда можем поручить компьютерам, находящимся в Colocation связке c Di стать сквозным посредником между Xi и DN+K+1.
Рассмотрим теперь все D1, …, DN+K компьютеры, как "серверы" в теореме 1. Пусть C = DN+K+1 будет центральным компьютером связующим с "серверами" D1, …, DN+K. По теореме 1, мы можем построить функционально идентичную систему, которая заменяет C на N+K компьютеров Xi, размещенным с соответствующими компьютерами Di.
Наконец, определим новую агрегирующую конструкцию E* работающую на компьютерах E1, …, EN+K, где мы устанавливаем Ei = Ci ^ Di..
Очевидно, что агрегирующую конструкции E* - это эквивалент D* (когда под присмотром серверов Xi), но имеет только К участников, которые не находятся в colocation связи ни с одним из серверов. Таким образом, по методу индукции, E* является эквивалентом полноценного colocation решения агрегирующей конструкции. Это завершает (предыдущий) шаг и доказывает следствие.
Примечание: Доказательство данного следствия может рассматриваться как предоставление метода, который позволяет удалить один за одним в любой последовательности не связанные colocation связью участников совокупности D* без изменения функциональности агрегирующей конструкции (как это зафиксировано серверами).

Colocation предоставляет оптимальное решение
Рассуждая об "оптимальности" мы можем только предположить, что пользователь имеет в виду измеримую меру полезности, которую можно будет применить к любой совокупности агрегирующих конструкций с определенным набором серверов. Мы предполагаем, что функция "полезности" может базироваться только на данных, полученных с серверов. (Например, можно было бы оценить торговую стратегию по ее средним дневным результатам на основе некоторого эталона, используя исторические исходные данные, собранные серверами). Теперь мы можем перефразировать Следствие 1 и констатировать, что:
Следствие 2. Полноценное colocation решение агрегирующей конструкции является оптимальным вариантом для HFT арбитражеров. Другими словами, нераспределенный алгоритм может обойти другие алгоритмы, используя агрегирующую конструкцию и colocation связку с серверами бирж.
Примечание: в итоге, в высшей степени важно учитывать нашу ненавязчивую позицию в определение того, что является "лучшими" средствами. Независимо от того, как вы оцениваете работу вашего алгоритма (например, желаете ли вы заработать или потерять больше денег), вы не можете обогнать распределённый вариант описанный выше. В качестве примера: Не начинайте интервенцию йены, если не находитесь в Токио (а также если не находитесь в Лондоне, если на то пошло)!

Реверсивные роли – распределенные биржи преодолевают скорость света
До сих пор мы рассматривали теорему 1 в сценариях, состоящих из торгового компьютера, подключенного к серверам нескольких бирж, потому что это схема укладывается в сценарий "серединной точки" из статьи журнала Nature. Теперь мы переформулируем теорему 1, поменяв местами роли бирж и финансовых центров.
Традиционные биржи располагают центральным matching (мэтчинг/матчинг) движком для компьютеров клиентов HFT, размещенным в одном центре обработки данных. Удаленные клиенты могут находиться по всему миру, используя компьютеры, расположенные в точке доступа дата-центров (либо самой биржи, либо сторонних компаний), которые предлагают безопасное, надежное и естественно с малой задержкой подключение к центральной системе (ядру биржи).
Рассмотрим теперь мэтчинговый движкок бирж как “центральный компьютер” и точку доступа в дата-центры, как "серверы", приведенные в теореме 1. Используя эту хитрость, теорема 1 может быть сформулирована следующим образом:
Следствие 3. Любой центральный мэтчинговый движок биржи подключенный к N ≥ 1 точки доступа дата центров может быть воспроизведен с использованием группы N соединенных между собой мэтчинговых движков, которые находятся в соответствующих дата-центрах таким образом, что поведение новой реализации (как зафиксировано в дата-центрах) ничем не отличается от оригинального решения на одном мэтчинговом движке.
В результате, следствия 1 и 2, могут быть преобразованы таким же образом. В частности архитектура биржи, которая использует полноценное colocation решение агрегирующей конструкции мэтчинговых движков (один мэтчинговый движок на каждую точку доступа дата центра) является оптимальной!

Кейс для распределенных бирж
Очевидно, что участники, торгующие HFT алгоритмы, давно выяснили преимущества colocation, когда торгуют арбитраж AAPL между различными серверами бирж Нью-Джерси, или когда торгуют арбитраж E-Mini на CME в Aurora, IL versus SPY, Arca в Secaucus NJ. Так почему же биржи упорно используют центральные мэтчинговые движки?
Основной причиной является производительность и прибыль биржи. По сравнению с одним центральным биржевым компьютером, распределенная биржевая архитектура добавляет проблем с точки зрения дизайна и сложности устройства, увеличивает задержки сделки, а также дополнительные затраты на инфраструктуру. Эти эффекты могут ощутить на своем опыте все клиенты биржи, даже те, которые не участвуют в арбитражных операциях и рады торговать в одном месте совместного размещения с простым, быстрым и относительно недорогим центральным мэтчинговым движком. Распределенная архитектура биржи также будет способствовать снижению (или сведет на нет) необходимость арбитража, что в результате снизит огромные объемы торговли арбитражеров, которые приносят пользу бирже.
На фондовом рынке США, торговля географически сосредоточена в одном месте. Начиная с NYSE и Nasdaq, практически все фондовые торги в США осуществляются на серверах в Нью-Джерси, которые находятся в нескольких десятках километров друг от друга. Несмотря на то что (благодаря 1998 SEC Regulation ATS) одна и та же акция может торговаться на нескольких биржах, каждая биржа, как правило, имеет только один мэтчинговый движок для данного эмитента. Несмотря на все это еще можно было утверждать, что, в целом, американский рынок акций использует распределенную мэтчинговую архитектуру:
1. Акции биржи и ATS (альтернативные торговые системы) требуют отправки заявок на разные площадки, чтобы получить лучшую цену (благодаря 2007 SEC регулирования NMS).
2. Распределители для умных заявок расположенные в точках доступа отправляют заявку на ту биржу, где заявка имеет наибольшие шансы пройти по лучшей цене.
3. Брокер/банк, выполняющие внутренние внебиржевые сделки и "дарк пулы" можно рассматривать как расширение основного мэтчингового механизма биржи.
Конечно, дьявол кроется в деталях и если посмотреть внимательно, то существующая биржевая архитектура Фондового рынка США (если рассматривать в совокупности как единый механизм) является чудовищно сложной и неэффективной. Компьютеры HFT трейдеров, имеющие colocation связку с несколькими ближайшими биржами процветают, торгуя арбитраж и другие интеллектуальные методы, эксплуатирования неэффективностей.
На рынках акций, опционов и фьючерсов, в силу исторических причин, восходящих к торговле фьючерсами на кукурузу или пшеницу, большинство американских фондовых фьючерсов и опционов торгуются в Чикаго (на CME и CBOE, соответственно). Здесь логично было бы просто переместить мэтчинговые движки CME и CBOE в Нью-Джерси. Но это вряд ли произойдет, учитывая, что пока еще нет конкурентного давления на биржи Чикаго, которое мотивировало бы их на этот шаг. Высокочастотные трейдеры этому только рады и конкурируют друг с другом, чтобы построить лучше дешевле, быстрее, распределенные арбитражные стратегии (используя Spread Networks tunnel и its true-speed-of-light successors[9]).

Поистине распределенная архитектура биржи
Наконец, давайте зададим обратный вопрос: почему и где были бы полезны распределенные биржевые серверы мэтчинга заявок для конкретного инструмента в отдалении от самих бирж? Первый ответ в том, что распределение биржевых серверов в пространстве было бы полезно, если клиенты были бы географически "рассредоточены" и не желали заказывать colocation своих торговых компьютеров с центральным мэтчинговым движком биржи.
До сих пор, единственная область, где распределенная биржевая архитектура нашла свое применение - это торговля на рынке Forex. Например, когда вы торгуете USD (доллар США) против JPY (Японская иены), необходима локальная информация о состоянии экономики каждой из двух далеко расположенных стран. Кроме того, есть политические аргументы против торговли своей валютой с помощью мэтчинговых движков далеко за рубежом.
Когда впервые была представлена электронная заявка на спот рынке Forex, что впервые произошло в 1990-х годах, были первоначально две USD/JPY биржи: Reuters (в Лондоне) и Майнекс (в Токио). Лондон - Токио задержки в те дни были порядка 300 мс, которые легко заметны невооруженным глазом. Также, были политические причины против торговли свей валютой на зарубежных площадках.
Когда мне была поставлена задача разработки новой глобальной биржи EBS Forex exchange, я выбрал распределенную архитектуру с тремя синхронизированными мэтчинговыми движками - в Лондоне, Нью-Йорке и Токио[10]. Это при условии отличной производительности во всех трех регионах и удовлетворении требований мировых банков. В 1996, EBS вошла в состав Minex, став доминирующей мировой USD/JPY площадкой на межбанковском электронном рынке - позиция, которую она занимает и по сей день. (Хотелось бы мне в то время обладать информацией из этой статьи, иметь представление о данной работе, когда пытался убедить своих коллег поверить в распределенную архитектуру бирж... но, в конце концов, мы использовали наше шестое чувство -, - и оказались правы)
Другой пример распределенной Forex площадки является Fastmatch, которая также имеет три мэтчинговых движка: в Лондоне, Нью-Йорке и Токио. Ее архитектура значительно отличается от EBS, однако, заявки распространяются не прозрачным способом и мэтчинг осуществляется по трем регионам.

Литература по данной тематике
Чтобы узнать больше о чудесах распределенных торговых систем, исследуйте ссылки [11] и [12] .

Благодарности автора
Я благодарю Michael Merold, Schalk Steyn, Alec Schmidt, Mark Reece, Wlodek Stankiewicz, Ewa Howorka, и всех, кто предоставили полезные комментарии по первоначальному проекту этого документа.

Ссылки
1. Mark Buchanan, Physics in finance: Trading at the speed of light, Nature, Feb 11, 2015.
2. A. D. Wissner-Gross and C. E. Freer, Relativistic statistical arbitrage, Physical Review E 82, Nov 5, 2010.
3. World Federation of Exchanges, WFE 2009 Annual report and statistics, Dec 2009.
4. Stock Trades at the Speed of Light, PhysicsCentral, Nov 11, 2010.
5. Eric Garcia, Physicist says it is possible to use ships to facilitate high-frequency trading, MarketWatch, Feb 19, 2015.
6. M. Rohan, Dark pool and HFT: It is possible to use ships for high-frequency trading, International Business Times, Feb 19, 2015.
7. Timothy B. Murray, HFT’s Oceanic Moment, WatersTechnology, Mar 11, 2015.
8. M. Rohan, Dark pool and HFT: BoE says high-speed trading helps markets, International Business Times, Feb 24, 2015.
9. Scott Patterson, High-Speed Stock Traders Turn to Laser Beams, Wall Street Journal, Feb 11, 2014.
10. Michael Togher, Michael F. Dunne, Richard Hartheimer, Credit management for electronic brokerage system, U.S. Patent No. 5,375,055, issued Dec 20, 1994, assigned to EBS.
11. Edward R. Howorka, Andrew P. Foray, Architecture for anonymous trading system, U.S. Patent No. 7,184,982, issued Feb 27, 2007, assigned to EBS.
12. Edward R. Howorka, Method and apparatus for enhancing market data feed using proprietary order flow, U.S. Patent No. 8,296,217, issued Oct 23, 2012, assigned to MarketFactory.
13. Edward Howorka, In brief, colocation beats the speed of light, The Trading Mesh, Apr 9, 2015.

Ссылка на первоисточник данной статьи
Перевод: Николай Флёров

Colocation преодолевает скорость света. 2 часть

2015-07-06T00:08:22Z

Перейти к части 1

В данной части мы подробно рассмотрим арбитражные механизмы на базе центрального компьютера и механизмы с применением Colocation. А также разберем конкретный алгоритм арбитражной стратегии в действии.

Механизм с применением центрального компьютера
Во-первых, давайте определимся с формально базовым "механизмом централизованного компьютера". Обратите внимание, что это гораздо более распространённое решение, чем сценарии "средней точки", рассматриваемой в статье Бьюкенена.
Рассмотрим N серверов X1, ..., Xn и центральный компьютер С может располагаться где угодно в мире на нем работает алгоритм А (например, торговая стратегия). С подключением ко всем серверам - он получает входные сигналы от респондентов и дает обратную связь каждому из них. Мы считаем, что этот механизм напоминает "черный ящик", где входные и выходные данные могут быть отслежены и проанализированы наблюдателями, расположенными на серверах N. См. картинку "Механизм с применением центрального компьютера".

На центральном компьютере С, и каждом из серверов N настроены часы, синхронизированные с временем UTC (UTC time). (Современные технологии, обеспечивающие средства для синхронизации часов в течение малой доли микросекунды).
Пусть di обозначают задержки передачи между C и сервером Xi. Пусть di,j обозначим задержки между Xi и Xj. Эти задержки предполагаются постоянными и не меняются от сообщения к сообщению. Мы предполагаем, что задержки в сети удовлетворяет свойствам метрики (metric), в частности: di,j = dj,i (симметрия) and di,j ≤ di + dj (аксиома треугольника).
Для того, чтобы осуществить видоизменение нашего "черного ящика" (с центрального компьютера к эквивалентной группе компьютеров, размещенных в дата-центрах бирж), мы должны сделать некоторые дополнительные предположения:
1. После настройки, алгоритм А реагирует только на текущее время и сообщения, полученные от серверов Xj. (Конечно, алгоритм А может использовать также память о прошлых событиях в принятии своих решений.).
2. Каждый из N серверов отправляет зафиксированные во времени потоки данных с определенной степенью детализации времени. Это означает, что принимающий получает периодические синхронизированные сигналы от каждого сервера, которые характеризуют и "закрывают" каждый интервал времени - будь то миллисекунды или микросекунды. Алгоритм управляет этими сигналами. (Например, сообщение, полученное в момент времени t по алгоритму А, может быть использовано данным алгоритмом только после того, как все синхронизированные во времени сигналы с временными метками, полученными от всех серверов Xi по шкале времени больше или равны t – di . Данная ситуация не является препятствием в случае, если она будет учтена в сценарии центрального компьютера. Это главное требование для достижения эквивалентности наших "черных ящиков", несмотря на любое время или неустойчивость задержки.
3. Выходное значение алгоритма А состоит из сообщений, отправленных серверам. Все сообщения с временными метками, по местному времени алгоритма А. Данное сообщение может содержать любую информацию, в том числе внутренние отчеты о состоянии, относящиеся к текущим или к прошлым событиям.

Механизм совмещенных групп
Здесь мы представляем механизм, который будет дублировать поведение механизма центрального компьютера с использованием N компьютеров C1, ..., CN совместного размещения (colocation) с соответствующими серверами бирж X1, ..., XN. Как и в предыдущем случае, мы считаем, что этот механизм как "черный ящик", где входные и выходные данные могут фиксироваться и синхронизироваться наблюдателями, расположенными на N серверах. См. рисунок "Механизм совмещенных групп".

Для простоты, задержка передачи данных между компьютером Ci и размещенным Server Xi принимается равной нулю. Задержка передачи данных между Ci и Xj берется di,j - такой же, как задержка между Xi и Xj.
На каждой компьютере Ci работает алгоритм Ai, который является модифицированной копией алгоритма A, работающем на центральном компьютере C, описанным в предыдущем разделе. Отличия модифицированной версии:
1. Время, используемое алгоритмом Ai, устанавливается с запозданием на величину di, то есть, он показывает время UTC – di вместо UTC. Например, когда алгоритм A решает прекратить торговлю на время UTC t, Ai то он прекратит торговлю в момент UTC t + di. (Данное изменение удобнее воспринимать, как модификацию алгоритма Ai, нежели как изменение хода часов на Ci).
2. Каждый алгоритм Ajj принимает сообщения со всех N серверов. В частности, сообщения от сервера Xi, которые будут направлены в исходный центральный алгоритм A реплицируются и рассылаются по всем алгоритмам Аj.Репликация сообщений может быть выполнена в аппаратных средствах или в программном обеспечение компьютера Ci, находящемся в связке с Xi.
3. Искусственная задержка di + dj – di,j вводится для всех сообщений, поступивших на Aj от сервера Xi. Задержки сообщений могут быть реализованы либо в аппаратных средствах, либо в программном обеспечении, работающем на Cj. (Данный генератор задержки удобнее воспринимать, как модификацию алгоритма Aj.). Обратите внимание, что, когда i = j, то задержка равна i + di – di,i = 2⋅di. То есть, задержка для всех сообщений, отправляемых сервером Xi в расположенный по соседству компьютер равна Ci это 2⋅di.
4. Алгоритм Ai посылает свое сообщение с выходными данными только в Xi сервер, находящийся в colocation связке. Когда оригинальный алгоритм будет отправлять сообщение на другой сервер Xj, Ai бездействует \ - вместо этого, алгоритм Aj , находящийся в связке с Xj, посылает идентичное сообщение именно в нужное время. Aj может зафиксировать это событие в логе, тем не менее, будет действовать так, как было описано ранее.

Механизмы "центрального компьютера" и "совмещенных групп" эквивалентны
Чтобы убедиться, что механизм "совмещенных групп" работает так же, как механизм "центрального компьютера", нужно удостовериться, что отосланные входные данные приводят к тем же выходным данным, полученным серверами в одно и то же самое время, обоими механизмами "черных ящиков".
Очевидно, что для любого j, алгоритм Aj принимает одно и то же сообщение с входными данными, которое будет получено алгоритмом A, но Aj принимает их после задержки dj по отношению к времени, использующимся в алгоритме А. Именно во время t, алгоритм А получит сообщение от сервера Xi, которое было отправлено в момент времени t – di. Это же сообщение посылается от Xi к Aj с применением генератора искусственной задержки (di + dj – di,j), а затем через линию передачи, которая имеет задержку di,j. Таким образом, поступление данных на Aj происходит в момент времени (t – di) + (di + dj – di,j) + di,j = t + dj.
Задержка di устраняется путем установки времени Aj назад на величину dj. Это означает, что при времени UTC t + dj, все выходные данные Aj (в том числе и время) идентичны выходным данным из A в UTC времени t. Таким образом, Aj делает одни и те же решения в момент t + dj, как и A в момент времени t. Хотя решения, принятые алгоритмом Aj сделаны с задержкой dj, ее выходные данные доставляются мгновенно на сервер Xj (без задержки dj, которые были потеряны при отправке выходных данных с алгоритма A на Xj), что означает, что обе временные метки, поставленные алгоритмом Aj и время доставки сообщений, отслеживаемые Xj, идентичны тем, которые получены алгоритмом А. Это доказывает теорему 1.

Пример:
Чтобы получить некоторое представление о том, как хитро работает механизм совмещенных групп, мы будем использовать пример из статьи журнала Nature. Мы начинаем с одного компьютера - "срединной точки" C, расположенном в геодезическом центре между серверами двух финансовых центров X1 и X2 (Нью-Йорка и Лондона) и представим торговлю EUR / USD на спот рынке Forex). См. рисунок "Механизм с применением центрального компьютера".
Используя простые обозначения, d = d1,2 (около 20 миллисекунд со скоростью света) и h = d1 = d2 = d/2, и, вооружившись базовым методом, изложенным выше, мы сформируем простой функционально эквивалентный механизм, состоящий из пары компьютеров, размещенных в дата-центрах двух бирж, показанных на рисунке "Механизм пары компьютеров, находящихся в Colocation связке с разными биржами".

Далее мы покажем конкретный алгоритм арбитражной стратегии в действии, прослеживая его шаг за шагом в обоих сценариях. Наш алгоритм арбитражной стратегии "серединной точки" выглядит следующим образом: если цена Ask, с одной стороны (например, X1) точно меньше, чем цена Bid на другой стороне (X2), тогда отправляем лимитную заявку на покупку типа FOK (fill-or-kill) на сторону X1 и аналогичную лимитную заявку на продажу на сторону X2. Если оба ордера успешно заполнены, мы добились своего и сделали прибыль. В противном случае (если, скажем, продать на X2 не удалось) - мы отступаем, ликвидируя свою позицию, используя рыночную заявку. Она отправляется на биржу, которая предлагает лучшую цену Bid. (Это не самый умный алгоритм арбитража, однако, этого достаточно, чтобы проиллюстрировать то, что происходит внутри двух "черных ящиков").

В следующей части мы разберем, какой же из вышеописанных вариантов представляет оптимальное решение для HFT арбитражных стратегий. Почему Colocation "преодолевает скорость света" и что по мнению профессиональных арбитражеров - "поистине распределенная архитектура биржи".

Перейти к части 3

Ссылка на первоисточник данной статьи
Перевод: Николай Флёров

Colocation преодолевает скорость света. 1 часть

2015-06-28T21:48:32Z

В данной статье мы рассмотрим вопрос, получают ли трейдеры преимущество, базируя свой компьютер между двумя финансовыми биржами. Например, на корабле в середине океана - вопреки рекомендации из статьи "Physics in finance: Trading at the speed of light" (Mark Buchanan, Nature, 11 февраля 2015 г.). Или же лучший результат покажет торговая стратегия, использующая два взаимодействующих компьютера, размещенных в дата-центрах разных бирж. В доходчивой форме будет рассмотрен вопрос о том, является ли преимуществом распределение торговых стратегий. Либо же наоборот лучше использовать распределенную архитектуру биржевых серверов, которые устраняют необходимость в распределенных арбитражных стратегиях.
Изучив данную статью целиком, вы откроете для себя, какой метод расположения серверов является наиболее эффективным, при работе с HFT арбитражными стратегиями, работая одновременно на нескольких биржах.

Статья из журнала Nature (авторское замечание)

Цитата:

В будущем, когда надводные лазерные сети охватят океаны, изменения в трейдинге могут стать еще более необычными. Место, в котором трейдеры могут получать наиболее актуальную информацию от двух бирж одновременно, находится в их средней точке - между Чикаго и Лондоном, то есть в середине Атлантического океана. В данном месте, трейдеры могут использовать технику, называемую "релятивистский арбитраж", чтобы получить прибыль от сиюминутного дисбаланса цен между Чикаго и Лондоном.
Объяснение: специальная теория относительности говорит, что ничто не может двигаться быстрее скорости света С. Таким образом трейдер, находясь на расстоянии D от биржи может узнать, что там произошло, в лучшем случае, не раньше чем - T = D/C после того, как событие произошло. Между крупными торговыми центрами по всему миру, такие задержки могут быть от нескольких до десятков миллисекунд. Если трейдер стоит на полпути между двумя биржами, он будут получать информацию с обеих сторон после, Т = D/C. В любом другом месте, если расстояние, по крайней мере, одной из бирж будет более удалено, то информации потребуется больше времени, т.е увеличится задержка.

Другими словами, в течение нескольких лет может стать прибыльным устанавливать корабль или платформы для трейдинга на участках ровно между парами финансовых центров по всему миру (см. Fast-trading hotspots).

Статья из Nature предоставляет карту мира с указанием всех мировых финансовых центров и более тысячи точек, лежащих ровно посередине, где высокочастотные трейдеры должны будут устанавливать свои компьютеры, чтобы оптимально использовать данные возможности для арбитража. Как и ожидалось, многие из этих "оптимальных" мест, в действительности "места глухие" (одна точка находится в пустыне, где исчез рейс MH 370). Карты не указывают на важность центров или значение "перспективных точек для трейдинга", но ясно, что наиболее значимые точки лежат где-то в северной части Атлантического океана.

Карта наиболее удобных точек для арбитражного трейдинга

Карта наиболее удобных точек для арбитражного трейдинга [1]. Используется с разрешения издательской группы Nature.

Карта впервые была представлена в издании Relativistic statistical arbitrage[2]
В той статье "серединные точки" взвешивали по скорости оборачиваемости (отношение стоимости акций, обращающихся на бирже в общей рыночной капитализации) – там использовались не истинные геодезические средние точки, как это подразумевается в статье издательской группы Nature. Кроме того, "финансовые центры", определенные в статье как 52 биржи, перечисленные в Всемирной федерации бирж из Годового отчета за 2009г. (World Federation of Exchanges 2009 Annual Report[3] ) - и не включают Forex площадки, которые превосходят все другие торговые центры по показателю величины объема торгов.
Новости относительно оптимального размещения компьютеров для HFT (высокочастотной торговли) была широко освещена профессиональными средствами массовой информации; см. статьи в PhysicsCentral[4], MarketWatch[5], International Business Times[6], и WatersTechnology[7]. Некоторые эксперты приняли данный "факт", как само собой разумеющееся, некоторые же выразили сомнения. Билла Хэртс(Bill Harts), генеральный директор Modern Markets Initiative, группы, которая занимается высокочастотной торговлей, отвергнул данную идею, высказав мысль в электронном издании MarketWatch: "Даже если трейдер может получать данные с обеих бирж быстрее в средней точке, то воспользовавшись преимуществом, имея только один компьютер в средней точке, они будут посылать заявки на рынок с достаточно большого расстояния – и будут всегда медленнее, чем трейдеры, размещенные на локальных рынках".

Головоломка серединных точек.
В статье Nature тривиально утверждается, что середина между двумя биржами является точкой, где наиболее быстрым образом может быть обнаружена возможность арбитража. Что менее очевидно - учитывая, что Марк Бьюкенен, уважаемый физик и автор ошибся - это то, что серединное расположение особенно неблагоприятное место, для принятия торговых решений.
Здесь "шестое чувство” Билла Хэртса является правильным. В своей статье follow-up IBT article[8], он подчеркивает: "Если бы это было возможно, поставить дата центр в Янгстаун, штат Огайо, (примерно на полпути между биржами Нью-Йорка и Чикаго), если бы это место было бы самым благоприятным для HFT, все высокочастотные трейдеры базировались бы там. Но знаете что? Там нет HFT трейдеров в Янгстауне, штат Огайо".
Таким образом, HFT арбитражеры знают, что торговля с средней точке расположенной между биржами - это плохая идея. Тем не менее, заявление Хэртса не совсем корректно – трейдер, торгующий с серединной точки на самом деле, достаточно быстр, чтобы воспользоваться нарушением паритета цен между двумя биржами. Недостатком же, по сравнению с "системой компьютеров, размещенных на реальных рынках", является то, что – компьютер в серединной точке после подачи заявки как бы "слеп" и не может контролировать заявку достаточно хорошо. Читайте дальше, чтобы осознать действительно невероятное преимущество размещения серверов в дата-центрах бирж и распределенных торговых стратегий.

Решение задачи.
Для универсальности далее по тексту термином "серверы", будет заменен термин "биржевые-серверы", потому что наш результат относится к сценариям носящим более общий характер, чем просто алгоритм связи с финансовыми биржами. Мы будем использовать термин "компьютер", когда говорим о не серверных компьютерах под управлением программного обеспечения, которое взаимодействует с серверами (например, алгоритмическая торговая стратегия).
В следующих нескольких разделах мы докажем одну фундаментальную теорему. (Пожалуйста, не беспокойтесь - доказательство будет так же просто, как строительство из Lego блоков.)

Теорема 1. Любой алгоритм, который работает на одном центральном компьютере, расположенном в любой точке мира и соединен с одним, или большим количеством серверов (N≥ 1), может быть воспроизведен с использованием нескольких компьютеров, работающих в связке с серверами, таким образом, что такая реализация (зарегистрировано серверами) функционально ничем не будет отличается от оригинального одно-компьютерного решения.
Доказательство довольно просто. Во-первых, мы формально определяем единый центральный механизм компьютера. Затем мы покажем, как построить эквивалентный механизм, который использует группу компьютеров, размещенных в дата-центрах бирж, без необходимости центрального компьютера. Другими словами, мы начинаем с черного ящика реализованного с помощью центрального компьютера и покажем, как можно построить эквивалентный черный ящик без центрального компьютера.

В следующей части статьи, мы подробно остановимся на свойствах распределенных вычислительных решений. Сравним арбитражные механизмы на базе центрального компьютера и механизм с применением Colocation*.

*Colocation (MICEX)

Перейти к части 2

Ссылка на первоисточник данной статьи
Перевод: Николай Флёров

Создание торгового робота на Plaza2

2013-03-13T10:36:09Z

Введение.

В последнее время широкую популярность приобретает разработка торговых роботов с использованием платформы Plaza2. Основной причиной популярности этой платформы является минимальное количество звеньев между торговым роботом и серверами биржи, что позволяет добиться более высокой надежности системы, высокой скорости передачи рыночных данных и обработки транзакций. Таким образом, робот, использующий протокол Plaza2, имеет более реальную картинку торгов и может оценивать рынок более точно, чем роботы, подключенные через Quik, SmartCom и т.д. Описание протокола и набора транслируемых данных можно найти на сайте Московской биржи, а так же по следующим ссылкам здесь и здесь.

Роутер.

При использовании торгового терминала Quik подключение производится непосредственно к терминалу на локальной машине. Когда используется Plaza2, то подключение происходит к клиентскому роутеру, который может находить как на локальной машине, так и на удаленной. Роутер позволяется подключаться к нему из нескольких приложений одновременно, что является большим преимуществом. Например, можно упростить инфраструктуру торгового робота и запускать каждую стратегию в виде отдельного приложения, это так же позволит повысить устойчивость каждого отдельного робота.

Из недостатков можно выделить отсутствие, какого бы то ни было, пользовательского интерфейса, т.е. невозможность ручного управления позициями при работе робота. Для этих целей можно использовать простой «самописный терминал», с помощью которого можно будет просматривать стаканы, списки заявок и сделок, портфели и лимиты, а так же выставлять заявки в случае необходимости. В качестве каркаса подобного терминала может служить S# пример Plaza\SampleGUI.

Роутер представляет собой самостоятельное приложение, единственной функцией которого является передача данных от биржи клиенту и наоборот. Есть два варианта запуска локального роутера: в виде службы и консольного приложения. Способ запуска роутера выбирается при его установке. При использовании консольного приложения, пользователь может сделать несколько конфигурационных файлов и запускать роутеры для разных логинов или серверов с помощью простых командных файлов. Полное детальное описание процесса установки и настройки роутера вы можете найти в файлах документации здесь и здесь.

Подключение к роутеру.

В настоящее время роутером поддерживаются два вида соединений:

Соединение посредством протокола TCP/IP. Медленнее, удобно для отладки, может связываться с роутером, установленным на другой машине
Соединение посредством разделяемой памяти (lrpcq). Быстрее, оптимально для боевых систем, работает исключительно в рамках одной машины.

Платформа S# поддерживает оба типа соединение и по умолчанию используется TCP/IP соединение. Для использования lrpcq подключения необходимо до подключения к роутеру выставить флаг:

Код

Trader.UseLocalProtocol = true;

Следует отметить, что использование lrpcq подключения в некоторых случаях сопряжено с определенными трудностями, например, при обрыве связи с роутером и переподключении может возникнуть ситуация, когда переподключиться не получится, т.к. роутер будет считать, что подключение с таким именем приложения еще установлено. Связано это с довольно большим таймаутом для данного типа подключения на стороне роутера и возможно будет исправлено в новых версиях роутера.

Для подключения к роутеру, установленному на другой машине, необходимо внести дополнительные изменения в конфигурацию роутера. По умолчанию, конфигурация роутера хранится в файле client_router.ini в директории, куда был установлен роутер. Чтобы иметь возможность подключаться к роутеру удаленно, необходимо указать имена приложений, с помощью которых будет выполняться удаленное подключение и пароль для каждого из имен, для этого в файл конфигурации необходимо добавить следующие строки:

Цитата:

[AS:Local]
префикс_0=пароль
префикс_1=пароль
префикс_2=пароль

Т.к. одно приложение может одновременно использовать несколько подключений к роутеру, то к имени, указанному в AppName добавляется его номер, таким образом, соединения именуются как {префикс_номер}, поэтому в конфигурации роутера необходимо указать все названия имен с учетом их номеров.
После настройки роутера, необходимо дополнительно указать пароль для S# коннектора, который был сохранен в файле конфигурации роутера. Для указания сетевого пароля используется поле Password, которое может использоваться в двух вариациях:

в случае если было задано поле Login, то поле Password используется для указания пароля для подключения серверам биржи или брокера;
если поле Login задано не было, тогда Password будет использоваться как пароль для локального соединения.

При необходимости подключения к роутеру нескольких торговых роботов, для каждого робота необходимо задать уникальный префикс приложения с помощью поля AppName. Имя приложения используется в сети для идентификации конечного отправителя-получателя сообщения. Не рекомендуется использовать слишком длинные имена – при работе размеры пакетов данных невелики, и служебная информация, частью которой является AppName, может превысить полезную нагрузку в пакете.

Схемы данных.

В платформе Plaza2 все данные транслируются сервером на клиентов в push-режиме, клиент постоянно получает последовательность изменений данных в соответствующих таблицах. Все данные, получаемые роутером, группируются в таблицы, которые в свою очередь сгруппированы в потоки.

Для определения набора полей, которые будут транслироваться в каждой таблице, используются схемы данных. Протокол Plaza2 позволяет использовать два варианта схем данных:

Серверная схема данных
При открытии потока пользователю не требуется задавать какое-либо описание получаемых данных, в момент подключения роутер получит схему данных с сервера, и все данные будут приходить согласно полученной схеме. Таким образом, перед пользователем не стоит задача поддержания схемы в валидном состоянии, т.к. набор доступных полей для каждой таблицы может меняться с течением времени.
Пользовательская схема данных
В случае, когда стандартный набор полей в таблицах содержит лишние или не содержит необходимых полей, пользователь может задать свои схемы данных для каждого потока и таблицы отдельно. Пользовательские схемы описываются с помощью ini-файлов, в которых указывается название схемы данных, названия таблиц и список полей для каждой таблицы. Далее, при открытии потока данных, передается путь к соответствующему файлу с настройками схемы и ее название, и роутер отправляет схему на сервер для согласования. В случае если схема была принята на серверной стороне, все данные будут приходить с указанным набором полей. Если в схеме есть недопустимые поля или типы полей, то с сервера придет соответствующее сообщение, поток данных при этом открыт не будет, более детальное описание ошибки будет записано в клиентский лог-файл, который располагается в папке \StockSharp_Plaza\Logs\.
Полное описание формата данных для всех транслируемых таблиц можно найти в файле документации 2, а так же в описании схем данных, которое устанавливается вместе с роутером.

Для того чтобы исключить необходимость постоянного обращения к документации Plaza2, возможные опечатки при задании схем данных, не оперировать непонятными сокращениями в названиях полей и их типами, в S# было введено понятие метаданных, которые содержат описания всех доступных таблиц и полей, которые могут быть в этих таблицах. Описание метаданных находится в пространстве имен StockSharp.Plaza.Metadata. Например, все доступные таблицы представлены полями класса PlazaTableRegistry, а все доступные поля для таблицы сделок по фьючерсам - ColumnRegistry.TradeFuture.
Набор таблиц, данные из которых необходимо будет получать при подключении к серверу, задается с помощью свойства PlazaTrader.Tables, куда необходимо добавить нужные таблицы и удалить ненужные. Для ручного добавления и удаления таблиц можно необходимо вызвать соответствующую функцию у PlazaTrader.Tables и передать в качестве параметра одно из полей PlazaTrader.TableRegistry, например, для добавления полного ордерлога необходимо выполнить:

Код

PlazaTrader.Tables.Add(PlazaTrader.TableRegistry. AnonymousOrdersLog);

В определенных ситуациях, выбор необходимого набора таблиц для получения данных можно оставить конечному пользователю, для этого в S# присутствует специальный графический компонент PlazaTableListComboBox, который представляет собой выпадающий список с набором всех доступных таблиц (рис. 1). Каждая строка представлена в виде трех столбцов: описания таблицы, названия потока репликации, в котором транслируется таблица и названия самой таблицы, последние два столбца соответствуют названиям потока и таблицы в документации по Plaza2.

Для того чтобы передать список выбранных таблиц в PlazaTrader, в библиотеке S# присутствует специальный метод расширения SyncTables, который можно использовать следующим образом:

Код

PlazaTrader.SyncTables(Tables.SelectedTables);

при этом нет необходимости в очистке списка таблиц, т.к. все лишние таблицы будут удалены автоматически.
Для всех таблиц можно указать набор полей, которые должны транслироваться в них. Описание полей для таблиц так же находятся в метаданных, в классе PlazaColumnRegistry для каждой из таблиц есть соответствующее поле, например, все доступные поля для таблицы сделок по фьючерсам описаны в PlazaColumnRegistry.TradeFuture.

Поля таблицы, для которых нет соответствующих полей у объектов S#, будут записываться в специальный словарь ExtensionInfo объекта S#. Например, если нам необходимо получать данные по сбору по сделке продавца, то в таблицу TradeFuture необходимо добавить столбец SellFee:

Код

PlazaTrader.TableRegistry.TradeFuture.Columns.Add(PlazaTrader.TableRegistry.ColumnRegistry.TradeFuture.SellFee);

далее, в момент обработки данных по сделке, данное поле можно будет получить следующим образом:

Код

var fee = trade.ExtensionInfo[PlazaTrader.TableRegistry.ColumnRegistry.TradeFuture.SellFee];

Подробное описание работы с дополнительными полями и произвольными таблицами можно найти в документации по S# в разделе Российские коннекторы - Plaza2.

После того как были выбраны все необходимые таблицы и их поля, в момент подключения к серверу будут сгенерированы соответствующие файлы схем данных, которые будут записаны в .\StockSharp_Plaza\Configs\ и будут использоваться при открытии соответствующих потоков. Нет необходимости в ручном изменении этих файлов, т.к. при следующем подключении они снова будут перезаписаны данными, сгенерированными по набору таблиц и их полей. Но эти файлы могут быть использованы в случае ошибки при открытии потока, чтобы понять, где была допущена ошибка.

При подключении к роутеру, все выбранные таблицы группируются по потокам, которые, в свою очередь, группируются по разным соединениям. Каждое подключение к роутеру может использоваться для передачи данных по одному и более потоку репликации. Разделение потоков по разным соединениям необходимо для уменьшения влияния процесса обработки одних данных на другие, например, разделение потоков с таблицами сделок и агрегированных заявок по разным подключениям, позволяется обрабатывать стаканы, не дожидаясь пока будут обработаны все пришедшие сделки. В библиотеке S#, все получаемые потоки изначально сгруппированы таким образом, что наиболее нагруженные потоки репликации обрабатываются в различных подключениях. Если, по каким-либо причинам, стандартная группировка потоков не подходит для решения поставленных задач, ее можно изменить с помощью ConnectionGroupping. Например, если необходимо получать все потоки репликации в одном подключении, то необходимо для каждого потока указать одинаковый индекс подключения:

Код

var streamRegistry = PlazaTrader.TableRegistry.StreamRegistry;
var groupping = PlazaTrader.StreamManager.ConnectionGroupping;

groupping[streamRegistry.Aggregation5Future] = 0;
groupping[streamRegistry.Aggregation5Option] = 0;
groupping[streamRegistry.Aggregation20Future] = 0;
groupping[streamRegistry.Aggregation20Option] = 0;
groupping[streamRegistry.Aggregation50Future] = 0;
groupping[streamRegistry.Aggregation50Option] = 0;
...
groupping[streamRegistry.TradeFuture] = 0;
groupping[streamRegistry.TradeOption] = 0;

Посмотреть сколько открывается соединений, и с какими названиями, можно в логе PlazaTrader-а в момент подключения:

Цитата:

PlazaTrader | 30.01.2013 15:10:21.761 | | Attempted to connect Webinar_0.
PlazaTrader | 30.01.2013 15:10:21.819 | | Attempted to connect Webinar_1.
PlazaTrader | 30.01.2013 15:10:21.820 | | Attempted to connect Webinar_2.

Управление ревизиями.

Каждая реплицируемая таблица имеет в своей структуре несколько служебных полей, предназначенных для обеспечения механизма репликации. Одним из полей является уникальный номер изменения в таблице. При любом изменении в таблице (вставке, редактировании, удалении записи) затронутая запись получает значение replRev, равное максимальному replRev в таблице до изменения +1. После согласования схем данных, клиент отсылает на сервер максимальные значения номера ревизии для каждой таблицы. Начальная синхронизация заключается в том, что сервер присылает клиенту все данные с номерами, большими, чем те, что указал клиент. Если клиент не указал номер ревизии для таблицы, то данные по этой таблице будут приходить в полном объеме.

Для того чтобы получение данных начиналось с последних сохраненных ревизий, необходимо добавить нужные таблицы в PlazaRevisionManager.Tables:

Код

var revisionManager = PlazaTrader.StreamManager.RevisionManager;

revisionManager.Tables.Add(Trader.TableRegistry.TradeFuture);
revisionManager.Tables.Add(Trader.TableRegistry.TradeOption);

При первом подключении, после добавления таблиц в RevisionManager, данные так же будут получены в полном объеме, т.к. информация о сохраненных номерах ревизий еще отсутствует. После переподключения, данные будут скачиваться с номера последней сохраненной ревизии.
Интервал, через который сохраняется номер последней ревизии, доступен через PlazaRevisionManager.Interval. По умолчанию файл с номером последней ревизии по выбранной таблице сохраняется в папку \StockSharp_Plaza\Revisions. Для того чтобы перезакачать все данные, достаточно удалить файлы из папки Revisions.

Полный ордерлог.

Полный журнал заявок – сервис Московской биржи, который позволяет получать список всех торговых транзакций, принятых торговой системой в текущую торговую сессию с указанием текущего статуса заявок (поставлена/удалена) и изменений параметров транзакции (частичных исполнений, передвижений заявки). Также в журнале отображается запись о сделке, с указанием номера сведенной в данную сделку заявки. Ордерлог - самый глубокий и детальный уровень биржевых данных, который доступен трейдеру. По данным ордерлога можно построить стаканы, получить тики и многое другое.

Для получения и обработки всех данных по ордерлогу необходимо добавить таблицу AnonymousOrdersLog:

Код

PlazaTrader.Tables.Add(PlazaTrader.TableRegistry. AnonymousOrdersLog);

и подписаться на обработку события NewOrderLogItems.
Ордерлог, в отличие от потока агрегированных заявок, содержит информацию по всем заявкам, таким образом, по ордерлогу может быть построен стакан полной глубины. Библиотека S# предоставляет функционал, позволяющий автоматически строить стаканы и тики по данным ордерлога.

Для построения стаканов по журналу заявок необходимо выставить соответствующий флаг
Код
```
PlazaTrader.CreateDepthFromOrdersLog = true;
```
при установке этого флага автоматически отключается обработка потоков агрегированных заявок и для получения данных добавляется таблица AnonymousOrdersLog.
Для построения тиков по журналу заявок необходимо выставить флаг
Код
```
PlazaTrader.CreateTradesFromOrdersLog = true;
```
при установке этого флага отключается обработка потоков журнала сделок по фьючерсам и опционам и для получения данных добавляется таблица AnonymousOrdersLog.

Сохранение и восстановление настроек.

S# Plaza2 коннектор предоставляет широкие возможности для управления настройками подключения, списком выбранных таблиц, группировкой потоков по соединениям и другими настройками. В одних случаях, эти настройки могут быть зашиты в торговом роботе, в других, может возникнуть необходимость предоставить возможность редактировать эти настройки конечному пользователю. Для удобства, все коннекторы S# содержат встроенные механизмы сохранения и загрузки настроек с помощью методов Save и Load.

Для сохранения и загрузки настроек из внешнего файла можно воспользоваться соответственно сериализацией и десериализацией, реализованной в S#:

Загрузка

Код

var trader = new PlazaTrader();
if (File.Exists("trader.xml"))
{
//Загрузка настроек из существующего конфигурационного файла
var settingsStorage = new XmlSerializer<SettingsStorage>().Deserialize("trader.xml");
trader.Load(settingsStorage);
}

Сохранение

Код

//Сохраняем настройки в файл
var settings = new SettingsStorage();
trader.Save(settings);
new XmlSerializer< SettingsStorage >().Serialize(settings, " trader.xml");

WL источник для Гидры

2013-10-09T18:52:31Z

Источник загружает данные оттуда же, откуда и pro версия wealth-lab.

Поддерживаются свечки всех мастей.

Вроде как, с фиделити можно много разной инфы утянуть в том числе и макро, но в источнике нельзя.

Поддерживается Гидра версии 4.1.19.1

Установка (все почти также, как и для яху-гугл)

И снова идем на ГИТХАБ

Обращаем внимание на то, что б была включена ветка "master" и жмем "download zip".

После того, как скачали, идем в архиве в папку bin\Release или bin\Debug и ищем там Файлы:

WealthLab.DataProviders.Common.dll
WealthLab.dll
Fidelity.Components.dll
StockSharp.Hydra.WLTask.dll

Копируем его в Hydra\Plugins

Также ищем папку в архиве log4net_1_2_10_0 или Log4Net_old
Копируем оттуда log4net.dll и кидаем ее в корень Гидры с заменой.

Дело в том, что компоненты велс лаба собраны с более старой версией log4net, чем гидра.
Выпилить оттуда эту библиотеку нельзя, равно как и из гидры. Но заменить в гидре можно, тем более что в они фактически и не используется.

Запускаем Гидру. В списке Источников должен был появиться WL-source.
Если не появился, жмем добавить источник.

Настройки.

Есть два режима: обычный и перезагрузка.

В режиме перезагрузка, будут качаться все отсутствующие данные, начиная с указанной начальной даты.

Временной отступ - для обычного режима. При отступе равном, например, 50, будут качаться все отсутствующие данные за последние 50 дней.

Полезно, например, если вы считаете какой-нибудь индикатор за последние 50 дней, а все что раньше, вас не интересует.

Инструменты

При первом запуске, в главной директории Hydra появится текстовый файл WLSourceTickers.txt

Записываем в него id необходимых инструментов через пробел, например:

AAPL@SMART SPY@SMART APOL@NASDAQ GOOG@SMART

SMART это умная система роутинга ордеров по ECN'ам. Типа как exchange board. Можно не обращать внимания.

Для импорта инструментов в гидре жмем добавить.

Инструменты спарсятся и добавятся в базу.

Перед началом закачки нужно не забыть добавить желаемые данные - свечки нужного ТФ.

S#. Автоматическая торговля (вебинар про все нюансы и настройки Quik)

2013-09-10T23:16:08Z

Расскажем про все нюансы и настройки Quik для работы с платформой StockSharp!

Кратко пробежимся по S#.Studio, S#.Data и S#.Api!

Записаться на вебинар можно здесь

S#. Автоматическая торговля (вебинар про анализ маркет-данных)

2013-09-10T23:26:22Z

Все про данные в платформе S#!

Сегодня вебинар в 19:00, записаться можно здесь.

Краткий план:

Различные источники данных (особенности)
Сохраняем и просматриваем данные
Анализируем, совмещаем инструменты

S#. Автоматическая торговля (вебинар, базовое про C#, спредовый робот)

2013-09-10T23:27:18Z

Достаточно интересные темы раскрываются:

Программирование на .Net (C#) в целом. Базовые понятие, которые могут помочь написать первое приложение на S#.
Создание спредового робота, создание интересных конструкций.

S#.Designer. Скачивание, установка, запуск. Видео 1.

2016-09-05T12:03:55Z

Валютный арбитраж на рынке FORTS

2012-06-07T21:18:40Z

Мечтой каждого трейдера является risk-free стратегия.

В этой статье поговорим о валютном арбитраже на срочном рынке ММВБ-РТС. Так как у нас нет возможности построить простую стратегию, мы создадим стратегию сложного арбитража с тремя инструментами. Данная тема много раз перетиралась на различных порталах, но я задался вопросом - имеет ли она еще место быть?

Для ответа на вопрос я создал приложение (через API), экспортирующее данные по стаканам из терминала Альфа-Директ в рабочую книгу Excel.

Используемые инструменты:

Eu-6.12
USD-6.12
EURUSD

В правой колонке - рассчитанное значение фьючерса на доллар-рубль, а в левой - реальное значение.
В качестве параметров для расчета я принял среднее значение внутри спреда.

Теперь нам остается только построить график этого спреда(всего лишь за период в 15 минут). Как видим, в течение 15 минут наш спред 4 раза переместился с точки 0 до 10(в рублях).

Наиболее благоприятное время для торговли данной стратегии - с 17:00 до 18:45 по Москве в период повышенной волатильности, когда спред в каждом стакане наиболее узкий, а спред между парами достигает 80 рублей.

Общее ГО по трем инструментам составит чуть более 4200, то есть стратегия имеет право занять место в вашем портфеле!

Зачем создавать торговых роботов своими руками, если можно купить, заказать или получить бесплатно?

2015-09-17T21:23:56Z

Пожалуй, это самый частый вопрос того, кто только-только начинает делать первые шаги в алгоритмическом трейдинге. Почему нужно учиться писать роботов самостоятельно, чем просто пойти по легкому пути с делегированием? Действительно, а почему нет?

Давайте попытаемся ответить по порядку на эти три разных вопроса.

1 - Купить торговый робот

Сейчас в интернете множества различных сайтов с десятками, а то и сотнями готовых роботов. Бери - не хочу. Но давайте на минутку зададимся вопросом - а нет ли здесь подвода? Ведь, если роботы действительно приносят прибыль (с другом стороны, зачем нам покупать робота, который теряет деньги?), то зачем создателям их продавать? Почему создатели, вместо торговли на бирже своими роботами, занимаются их продажами?

Ответ прост. Продающиеся торговые роботы, как правило, если и были зарабатывающими, то в прошлом. Или же они имеют вид некого комбайна из десятка различных параметров. И ваш депозит трейдера успеет быстрее подойти к нулю, чем вы успеете найти комбинацию, дающая профит вашей торговле.

2 - Заказать разработку

Как и в предыдущем вопросе здесь кроется одно очень большое НО. Программисты не придумывают прибыльный алгоритм. Если бы они это умели, он зарабатывали на бирже. Поэтому вам потребуется самостоятельно разработать стратегию торговли на бирже, протестировать ее на истории, и, будучи на 99% уверенным в ее робастости, отдать на разработку.

Но постойте! Как вы сможете проверить алгоритм, если вы не можете написать код самостоятельно? А если вы можете написать код стратегии, протестировать ее, то зачем же тогда делать заказ?

Ответ так же прост. Не делайте заказы на роботов, если вы сами можете их разрабатывать. И, аналогично, если вы не можете делать роботов - не делайте заказы на них. Вы не сможете придумать качественную торговую стратегию, и ваши деньги, заплаченные программисту, вылетят в трубу.

Мы в нашем сервисе предупреждает об рисках заказа роботов теми, кто ни разу не писал своего до этого.

3 - Получить торговый робот бесплатно

Сейчас бесплатно можно получить готового робота от брокера. Или же скачать откуда-то в интернете. В чем подвод тут?

Нужно всегда помнить - бесплатный сыр бывает только в мышеловке. Вариантов тут несколько. Или робот псевдо-бесплатен (переходим к пункту Купить торговый робот), или он бесполезен и написан начинающим алготрейдером, или он преследует цели набора комиссии для брокера (особенно, если робот высокочастотен), или он является частью учебного пособия.

Наиболее полезным для начинающих будет только последний вариант с учебным пособием. Потому что этот вариант не будет иметь скрытого мотива. И данный робот, хоть и будет иметь аналогичное качество всем остальным роботам (что можно купить или заказать), но будет иметь неоспоримый плюс - попытаться вас научить делать роботов самостоятельно.

Надеюсь, данная статья помогла систематизировать ваши представления о роботов. Успехов в алгоритмическом трейдинге!

Модернизация форума и сайта

2016-08-17T23:49:23Z

Пора выходить из летнего анабиоза, господа-товарищи.

Лето в России подходит к концу, Турцию еще не открыли, Крым недостроен, а деревня поднадоела. Самое время возвращаться к работе над ботам.

Как вы наверное уже успели заметить, наш форум переехал на основную часть сайта. Мы постарались устранить основные недостатки предыдущего движка форума (а их было не мало). Но перед тем, как я опишу основные изменения, минутка релакса - просто посмотрите на наш новенький, беленький, чистенький редактор сообщений:

и вот какой получился список изменений у нового форума.

1. Предпросмотр - он теперь не обновляет страницу, а делается прямо в закладке там же, где редактируется текст.

2. Добавление файлов и картинок. Оно стало до безобразия проще. Просто кидайте файл в область под текстом через drag-n-drop:

Доступен и превью картинок. Просто наведите на залитую картинку, и вы увидете ее в масштабе 100x100.

3. Черновики. Сайт отслеживает редактирование текста, и, если у вас вдруг отключился свет, вода, газ, интернет, то на сервере будет доступна последняя копия.

4. Нет разделов. Вместо этого есть тэги. Например, если у вас вопрос по Гидре + СмартКом, то раньше была дилемма, в какой из разделов написать. Сейчас - просто добавляйте оба два =)

5. Статьи, новости и форум сделаны на общем движке. А значит, теперь можно Лайкать статьи и комментировать их!

6. Оповещения на почту. Можно подписываться на разделы целиком (например, на новые сообщения Форума), можно подписываться на конкретного автора, по тэгу (вам будет приходить письмо каждый раз, как кто-то напишет сообщение с указанным тэгом). Ищите на страницах кнопку

Пишите свои замечания, предложения, найденные ошибки.

Новая фича на сайте - связь брокеров и трейдеров

2016-06-21T13:56:06Z

Мы связали через наши брокерские лицензии трейдеров с брокерами.

С помощью новой фичи теперь вы можете:

Понять, какие брокера более востребованы у алгоритмических трейдеров. Актуально при первоначальном выборе брокера.
Узнать у коллег по цеху об новых технологических фишках вашего брокера.

Напишите свое мнение о наших фичах на сайте, и что еще хотели видеть на сайте.