Сообщество. StockSharp

Ошибка при коннекте quik

2016-11-14T18:23:33Z

Приветствую,

при попытке установить соединение через lua-скрипт с квиком посредством утилиты Verifier возникает ошибка как на скрине 3. Скрипт в квике запущен без ошибок(скрин 2). В параметрах скрипта указан корректный адрес сервера на котором торгую - скрин 4.
Если закомментить в скрипте MarketDataAddress или TransactionAddress, то возникает ошибка как на скрине 1(т.е. параметры скрипта учитываются и передаются для обработки).
Также в квик были экспортированы настройки таблиц из файла info.wnd.
При настройке квика руководствовался мануалом по ссылке http://stocksharp.ru/for...ka-konnektora-quiklua/.

Подскажите пожалуйста, как можно разрешить эту ситуацию?

версия s# 4.3.18
винда 7
студия 2015
пробовал на двух брокерах: открытие и втб24, ситуация аналогичная.

Жуткие тормоза при подключении дизайнера к альфе-директ

2016-11-14T12:22:58Z

Доброго времени суток.
Был создан "супер робот": константа(инструмент)-свечи(5сек)-график. При подключении к альфе дизайнер умирает, кнопки нажимаются с откликом 5 сек, график показывает 4фпс, но обновляется в разброс партиями....
Подскажите в какую сторону копать?

Дизайнер в4.3.17.0. Альфы установлено две - конектится к 3.5. Настройки подключения по умолчанию. Комп средний - ноут на ай5.

Спасибо.

Конвертер - тип Стакан - Свойство - ошибка

2016-11-13T01:42:03Z

Доброго времени суток.
Дизайнер в4.3.17.0
При типе конвертера Стакана при выборе Свойств выпадает ошибка.

Фрагмент:
Название Время Тип Сообщение
S#.Designer 13.11.2016 0:49:04 Error "System.Reflection.TargetInvocationException: Адресат вызова создал исключение. ---> System.Exception: Duplicated primary key.
в DevExpress.Xpf.Grid.TreeList.TreeListSelfReferenceDataHelper.GetNodeDictionaryFromListSource()
в DevExpress.Xpf.Grid.TreeList.TreeListSelfReferenceDataHelper.LoadDataCore()
в DevExpress.Xpf.Grid.TreeList.TreeListSelfReferenceDataHelper.LoadData()
в DevExpress.Xpf.Grid.TreeList.TreeListDataProvider.DoRefresh(Boolean keepNodesState)
в DevExpress.Xpf.Grid.TreeList.TreeListDataProvider.OnDataSourceChanged()
в DevExpress.Xpf.Data.DataProviderBase.set_DataSource(Object value)
в DevExpress.Xpf.Grid.DataControlBase.SetDataSource()
в DevExpress.Xpf.Grid.DataControlBase.<OnItemsSourceChanged>b__60()
в DevExpress.Xpf.Core.Locker.DoLockedAction(Action action)
в DevExpress.Xpf.Core.Native.LockedPostponedAction.PerformLockedAction(Action primaryAction)
в DevExpress.Xpf.Grid.DataControlBase.<OnItemsSourceChanged>b__5f()
в DevExpress.Xpf.Core.Locker.DoLockedAction(Action action)
в DevExpress.Xpf.Grid.DataControlBase.OnItemsSourceChanged(Object oldValue, Object newValue)
в DevExpress.Xpf.Grid.GridControl.OnItemsSourceChanged(Object oldValue, Object newValue)
в DevExpress.Xpf.Grid.DataControlBase.OnDataSourceChanged(DependencyObject dObject, DependencyPropertyChangedEventArgs e)
в System.Windows.DependencyObject.OnPropertyChanged(DependencyPropertyChangedEventArgs e)
в System.Windows.FrameworkElement.OnPropertyChanged(DependencyPropertyChangedEventArgs e)
в DevExpress.Xpf.Grid.DataControlBase.OnPropertyChanged(DependencyPropertyChangedEventArgs e)
в System.Windows.DependencyObject.NotifyPropertyChange(DependencyPropertyChangedEventArgs args)
в System.Windows.DependencyObject.UpdateEffectiveValue(EntryIndex entryIndex, DependencyProperty dp, PropertyMetadata metadata, EffectiveValueEntry oldEntry, EffectiveValueEntry& newEntry, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType)

Plaza. Нововведения и отведения

2016-10-21T14:11:01Z

1) За ошибку Сейчас эта сессия не идет будет штраф. О штрафах у HFT можно почитать здесь http://moex.com/a3792

2) С 5 декабря 2016 прекращается поддержка API P2ClientGate (это НЕ CGate, а то, что было до него) и версий библиотек младше или равных 198.

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

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

Не работает пример SampleQuikCandles

2016-10-21T10:52:48Z

Добрый день
Запускаю SampleQuikCandles из пакета примеров к 4.3.14. Подключаюсь а Quik. Загружаю приложенные к примерам настройки Квика. В списке инструментов выбираю SIZ6 (кстати почему-то выбирается только из того, что есть в портфеле, ну да это ладно). Дальше нажимаю "График" и наслаждаюсь пустой формой:(, где свечки?. Что не так? Подскажите плз. Картинку приложил

Мы переехали в соц сеть Вконтакте

2014-02-07T10:28:42Z

Здравствуйте, друзья!

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

Наши видео-ролики вы можете просматривать их на любом устройстве: будь то Ipad или же мобильный телефон. Плюс у вас всегда будет доступ к нашей закрытой тусовке, в которой мы будем обсуждать все самые актуальные веяния в алготрейдинге, а также делиться торговыми идеями!

Для того что бы присоединиться к нам, нажмите кнопку Вступить в группу в Вконтакте. Затем пришлите на почту lesson@ данные вашей учётной записи (имя и фамилия указанные при создании аккаунта Вконтакте).

Наши группы:
CSharp. Edu
StockSharp. Edu
WealthLab. Edu (только для тех, кто проходит обучение по WealthLab)

Как описать канал на языке программирования?

2016-10-14T15:30:23Z

Ценовой канал довольно легко идентифицируется на глаз. Но как описать его в торговом алгоритме?

Прошу подсказать, если у кого то есть идеи.
Канал как минимум по трём точкам на нижней линии, и по трём точкам на верхней линии. Верхняя и нижняя линии параллельны

Запуск примеров

2016-09-29T19:20:07Z

Добрый день!
Первое знакомство с продуктом. Пробую открыть решение с примерами в VSC2015.Версия продукта 4.3.16.1. Некоторые проекты запускаются, но интересующий - SampleHistoryTesting - нет. Много ошибок в разметке MainWindow.xaml. Например "Имя StatisticParameterGrid не существует в пространстве имён "clr-namespace:StockSharp.Xaml;assembly=StockSharp.Xaml". Видимо что-то с этой сборкой не так?

Как получить данные по свечкам из Quik

2016-10-13T11:21:57Z

Добрый день
Аналогично примеру создаю правила обработки свечек в стратегии

_candleManager
.WhenCandlesChanged(_series)
.Do(ProcessCandle)
.Apply(this);

_candleManager
.WhenCandlesFinished(_series)
.Do(ProcessCloseCandle)
.Apply(this);

перед этим подписываюсь на портфель, инструмент, создаю менеджер свечек, и, казалось бы инициирую их передачу из терминала[blush]

var timeFrame = TimeSpan.FromMinutes(1);
candleManager = new CandleManager(qTrader);
series = new CandleSeries(typeof(TimeFrameCandle), security, timeFrame);
candleManager.Start(series);
qTrader.SubscribeMarketData(security,MarketDataTypes.CandleTimeFrame);

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

S#.Data и запрос к базе данных извне

2016-10-06T19:18:45Z

День добрый. Встала задача получения данных из S#.Data во внешний источник (реализовать аналог getSymbols из quantmod package). Подскажите, возможно ли это? Если "да", то какая из таблиц содержит данные по тикерам/сделкам/свечам?

Спасибо.

туплю на ровном месте

2010-03-12T13:15:00Z

делаю так
protected override bool OnProcess()
{
// если наша стратегия в процессе остановки
if (base.ProcessState == StrategyProcessStates.Stopping)
{
// отменяем стратегию
base.Orders.Where(o => o.State ==
OrderStates.Active).ForEach(base.Trader.GuarantyCancelOrder);
return false;
}
var direction = OrderDirections.Buy;
base.Volume = 1;
var order = base.CreateOrder(direction,
base.Security.GetMarketPrice(direction, MarketPriceTypes.Following),
base.Volume);
// регистрируем на котирование
var strategy = new MarketQuotingStrategy(base.Trader,
order, base.Interval, false, MarketPriceTypes.Following, new Unit());
strategy.Start();
base.ChildStrategies.Add(strategy);

return true;
//end
}
собирается без ошибок, но при нажатии на кнопку "старт" выскакивает

https://docs.google.com/leaf?id=0Bw2gQDvf41vtMzM3ZTAxMTktZjc5NC00NDY2LWI2NTktYTA5YzEyZDQ1MGRm&sort=name&layout=list&num=50

Finam. Смена адреса у HFT сервера

2016-09-20T18:43:51Z

Теперь он задается через DNS адрес ввиде hft.finam.ru

Собственно, вот для инициализации TransaqTrader ничего не меняется http://doc.stocksharp.ru...06-a542-206fa99f83c0.htm

Торговла на NYSE и NASDAQ

2016-09-27T13:57:24Z

Добрый день. Торгую много лет роботом на ММВБ и ФОРТС. С торговлей на западных рынках знаком лишь поверхностно, но теперь хочу узнать об этом больше. Рассматриваю возможность пройти обучение в Сток Шарпе за 32 тыр. Прошу ответить на такие вопросы.
1. Подскажите пару топ-брокеров в России, которые дают выход на NYSE/NASDAQ. Их торговый терминал должен подходить под СтокШарп.
2. Какие обычные комиссионные при торговле акциями?
3. Какова ежемесячная плата за терминал?
4. Какая минималка?
5. Наказывает ли биржа за чрезмерное выставление заявок? На ММВБ я ежедневно отсылают до 15 000 заявок.
6. Я немного знаком с терминалом ROX. Работает ли СтокШарп с этой платформой?
Спасибо за ответы.

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

2016-09-26T12:30:27Z

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

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

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

Внимание!

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

Тестирование на истории

2016-09-22T16:22:28Z

Возможно ли в stocksharp тестирование только на свечах (без тиков и стаканов) как в WLD?
Если нет, то насколько сложно реализовать?

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

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