Измерение интервалов между тиками с точностью до 1 ms - страница 2

Спасибо, Better, этот источник мне известен. Дело именно в точности до миллисекунд, чтобы надежно установить функцию плотности распределения лагов тиков. Сама эта функция имеет максимум где-то в области одной секунды. А хочется, чтобы было достаточное количество данных с лагами в интервале до одной секунды...

Анализ тиков это конечно здорово, но при 100% бесперебойной связи с сервером. По моему опыту реальность далека от идеала и по этому уход в тики зачастую ошибочен. Либо приходитс оперировать с фреймами из очень большого количества тиков, чтобы минимизировать погрешность. Но тогда все теряет смысл-лучше уж использовать минутки.

Нет смысла анализировать тики с такой точностью.Мое мнение.

Ну смотря для чего. Для торговли - да, ценность крайне сомнительна. Моя цель - выяснение хотя бы некоторых характеристик случайного процесса генерации тиков, которые я считаю нужными. Например, p.d.f. лагов тиков. Mak в теме 'Тики: распределения амплитуд и задержек' высказал гипотезу, что распределение логарифмов лагов, возможно, нормально. Но для проверки этого нужно иметь статистику для лагов менее 1, так как максимум - как раз в области 1.

Известно, что волатильность является антиперсистентным процессом. И что это нам дает?

Что это такое?

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

2 Rosh: да ничего, собственно. Но есть вроде как попытки построения стратегий на этом свойстве волатильности. Хотя сильно сомневаюсь, что эти стратегии устойчивы. Зато у нас больше понимания того, какие риски можно ожидать, - особенно в свете концепции Питерса о бесконечности дисперсии доходов, хе-хе.

Согласно тому источнику средний лаг между тиками по евре в 2006 году был около 11 секунд. Точнее - 5.5 тиков в минуту.
Не думаю, что максимум этой функции может быть в области 1-й секунды, если ее мат.ожидание почти 11 сек.

Как известно, время прохождения пакетов даже при очень хорошем канале составляет десятки милисек. Поэтому очень
сомнительно чтобы кто-то мог писать тики с такой плотностью. Кроме, может быть, того, кто сам их генерит. Но даже и
Reuters вряд ли такую плотностью имеет, ведь тики возникают из реальных сделок, а посчитайте сколько сделок должно
совершаться в мире в сутки, чтобы тики следовали с лагом в 1 милисек. Это ведь сделки не на тисячи баксов, а на миллионы
и выше.

И последнее. Я писал тики почти весь 1-й квартал прошлого года. Минимальное значение лага составляло величину порядка
100 милисек. Лаги менее 1-й сек. довольно редки и случаются как правило в районе острых пиков. Поэтому, ИМХО, поиск данных
с лагами 1-10 милисек. - гиблое дело. А данные 100 милисек. - 1 сек. погоды в распределении не делают.

Не думаю, что максимум этой функции может быть в области 1-й секунды, если ее мат.ожидание почти 11 сек.

Yurixx, ты почти все верно говоришь, но тут есть важнейшее обстоятельство: это распределение с сильнейшей асимметрией (скосом). Глянь 'Тики: распределения амплитуд и задержек' , мой пост с картинками, картинка первая. Очевидно, матожидание для этой кривой гораздо больше, чем абсцисса пика. Не помню точно, но тут и так все видно. И максимум кривой действительно близок к 1 с. А мне интересно именно поведение ее вблизи максимума и левее его, а там, увы, совсем мало точек при такой дискретизации измерений лагов.

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

Такой лаг бывает не круглые сутки, а крайне редок. И вообще - правильно, что

поиск данных с лагами 1-10 милисек. - гиблое дело

Конечно. Я и не собираюсь ловить такие микролаги, их действительно и должно быть очень мало. Да еще и учитывая время прохождения информации по каналам. Но, как ни странно, количество лагов в диапазоне 0.5-1.5 секунд значительно больше аналогичного количества, чем в диапазоне 3-4 секунд, 6-7 или тем более 10-11.

Я писал тики почти весь 1-й квартал прошлого года. Минимальное значение лага составляло величину порядка 100 милисек.

Я писал данные (Alpari IDC) с 17:51 market watch 6 июня по 10:49 7 июня 2007 (этот промежуток времени трудно назвать трендовым); минимальный лаг был 0.125. Есть основания считать, что на большем диапазоне он может быть значительно меньше.

Да и невозможно физически!!! Системное время обновляется раз в 54.926 миллисекунды. http://www.intel.com/support/motherboards/desktop/sb/cs-002888.htm
Т.е. примерно 18 раз в секунду. Так что максимальная точность 0. 05 сек