Вопрос по LatencyRegistration

Добрый вечер!

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

Поэтому остаётся вариант только сравнивать два локальных времени, то есть считать Latency = Тполучения_ответа - Тотправки_транзакции. То есть как Хоббит, Туда и обратно =)

Аналогично и для отмены.

В S# Latency реализовано с помощью Stopwatch, насколько я понимаю.

Я, кстати, сама считаю аналогичным образом, потому что в нескольких версиях S# расчет Latency не работал.

Про отрицательное время это понятно, имел ввиду наоборот...суть вопроса была именно в аргументах...Если в стоке реализованно так как вы сказали, то у меня следующий вопрос...Подскажите, пожалуйста, как мне замерить время уходящее на обработки пачки ответов, отправленных транзакций, так как технически там тоже может быть задержка(уже на стороне компьютера)...
То есть дал команду на регистрацию...(Сколько времении тратится на отправку транзакции в ройутер)...далее она летит по шнурку на биржу(тут время понятно)...далее прилетает на ядро(тут биржа тратит какое то время на ее обработку-вычислить можно только зная все остальные аргументы)...далее летит ответ по ней по шнурку(тут тоже все понятно)...далее прилетает на роутер и с него обрабатывается библиотекой, ей фиксируют время и вычетают разницу - получаем общую латенси(вот как замерить последний этап обработки ответа библиотекой)...
Буду признателен очень за развернутой ответ...очень надо!

Вы спрашиваете про то, как замерить задержку библиотеки S#?

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

Как вариант, можно скачать пример биржи для роутера и посылать заявки напрямую без S#, засекая их Latency. Аналогичный тест произвести через пример S#, максимально очищенный от лишних получений потоков. Затем сравнить результат. Но опять же, Вы не поймете для каждой конкретной транзакции, сколько для неё задержка S#, только в среднем на транзакцию, при этом получите среднюю суммарную задержку посылания и обработки ответа.

Как замерить именно задержку обработки S# ответа для транзакции - не знаю. Почему Вы хотите измерять именно это время? Если придумаете, как это сделать - расскажите. =)

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

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

Если Вы на колокации, то, мне кажется, стоит смотреть в сторону C++ и Linux, но опять же, всё зависит от потребностей Вашего приложения.

Насколько я знаю, на колокации Latency в среднем около 1 миллисекунды. А у Вас сколько, если не секрет? Мне кажется, что S# на колокации будет вносить ощутимую задержку, там каждые 100мкс на счету. А вы пользуетесь CGate или P2ClientGate? Если CGate, то лучше обсудить с техподдержкой S# такие вещи, а если ClientGate, то точно от него надо избавляться.

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

Так и есть...около 1 мс...спайки бывают и под 20 мс...но природа их возникновния для меня до конца не понятна, впонлне может и на стороне биржи быть, поэтому и хочу замерить время обработки пачки между ройтером и стоком...
По поводу линукса и C++ - это стереотипы, вы замерьте за сколько например тактов или даже милисекунд[blink] обрабатывает данные ваша прога со стоком, и сопоставьте с максимально возможной частотой получения рыночных данных с биржи...Для справки самый быстрый стакан транслируется 1 раз в 3 мс на фаст реплике..Успеете вы обработать его?[drool] ...я думаю да...Вообщем пока не увидел я потребности в линуксе и с++, ради выйгрыша каких то наносекунд...может потому что алгоритмов настолько чувствительных к скорости не писал...ну и опять таки вернемся к частоте расдачи...[biggrin]
Вообще программно сток вполне подходит для решения скоростных задач...остальное дело рук и техники...

CGate уж конечно...

Если ваши алгоритмы не очень чувствительны к скорости, тогда, конечно, можно и на S# оставаться, особенно если у вас CGate. Но важно понимать, что если два участника одновременно получили стакан, но один обрабатывает его и посылает заявку через, скажем, 500мкс, а другой через 300мкс, то заявка второго окажется в ядре биржи быстрее и будет первой в очереди.

У меня вообще бесплатный конектор S# ClientGate, торгую через интернет [biggrin] , пока этого хватает, но на колокацию с таким комплектом смысла не вижу идти.

Еще надежность маркет даты возьмите на рассмотрения в качестве плюса колакации...