нельзя было сделать как следует в принципе из за недостатков самого тслаба.
Думаю проблема не с ТСЛабом, он, что ему прислали, то скриптам и отдает.
В то время когда был сделан сей кубик не то что БД нельзя было заюзать, вообще сами скрипты через АПИ еще глюкали постоянно. Так что в то время все было круто. сейчас уже нет.
С этом я не могу согласиться.
К тому же если взять пересчет по интервалу при котором пишутся данные то легко заметить что ФинИнфо приходит уже из будущегоа не на момент закрытия свечки, а на момент когда было запрошено. Отсюда вы оперируете будущим
. Это до пол секунды может быть. Не очень верно это.
Это и так и не так, подробности ниже.
Написал небольшой тестовый скрипт, логирующий время пересчета скрипта и время из FinInfo.LastUpdate. Запустил его на 1 секундном интревале для RIZ3 и вот что он выдал:
N Локальное время FinInfo.LastUpdate Разница Время начала посл. бара Время окончания (расчетное)
1 2013-12-12_22:39:22.542; 2013-12-11_22:39:21.000; 00:00:01.5429670; 2013-12-12_22:39:21.000; 2013-12-12_22:39:22.000
2 2013-12-12_22:39:22.544; 2013-12-11_22:39:21.000; 00:00:01.5449672; 2013-12-12_22:39:21.000; 2013-12-12_22:39:22.000
3 2013-12-12_22:39:22.764; 2013-12-11_22:39:22.000; 00:00:00.7649892; 2013-12-12_22:39:21.000; 2013-12-12_22:39:22.000
4 2013-12-12_22:39:22.768; 2013-12-11_22:39:22.000; 00:00:00.7689896; 2013-12-12_22:39:22.000; 2013-12-12_22:39:23.000
5 2013-12-12_22:39:22.957; 2013-12-11_22:39:22.000; 00:00:00.9570084; 2013-12-12_22:39:22.000; 2013-12-12_22:39:23.000
6 2013-12-12_22:39:23.345; 2013-12-11_22:39:22.000; 00:00:01.3450472; 2013-12-12_22:39:22.000; 2013-12-12_22:39:23.000
7 2013-12-12_22:39:23.347; 2013-12-11_22:39:22.000; 00:00:01.3470474; 2013-12-12_22:39:22.000; 2013-12-12_22:39:23.000
8 2013-12-12_22:39:23.562; 2013-12-11_22:39:22.000; 00:00:01.5620689; 2013-12-12_22:39:22.000; 2013-12-12_22:39:23.000
9 2013-12-12_22:39:23.755; 2013-12-11_22:39:22.000; 00:00:01.7550882; 2013-12-12_22:39:22.000; 2013-12-12_22:39:23.000
10 2013-12-12_22:39:23.945; 2013-12-11_22:39:22.000; 00:00:01.9451072; 2013-12-12_22:39:22.000; 2013-12-12_22:39:23.000
11 2013-12-12_22:39:24.153; 2013-12-11_22:39:23.000; 00:00:01.1531280; 2013-12-12_22:39:22.000; 2013-12-12_22:39:23.000
12 2013-12-12_22:39:24.154; 2013-12-11_22:39:23.000; 00:00:01.1541281; 2013-12-12_22:39:23.000; 2013-12-12_22:39:24.000
13 2013-12-12_22:39:24.551; 2013-12-11_22:39:23.000; 00:00:01.5511678; 2013-12-12_22:39:23.000; 2013-12-12_22:39:24.000
14 2013-12-12_22:39:24.742; 2013-12-11_22:39:23.000; 00:00:01.7421869; 2013-12-12_22:39:23.000; 2013-12-12_22:39:24.000
15 2013-12-12_22:39:25.171; 2013-12-11_22:39:23.000; 00:00:02.1712298; 2013-12-12_22:39:23.000; 2013-12-12_22:39:24.000
16 2013-12-12_22:39:25.361; 2013-12-11_22:39:23.000; 00:00:02.3612488; 2013-12-12_22:39:23.000; 2013-12-12_22:39:24.000
17 2013-12-12_22:39:25.552; 2013-12-11_22:39:23.000; 00:00:02.5522679; 2013-12-12_22:39:23.000; 2013-12-12_22:39:24.000
18 2013-12-12_22:39:25.968; 2013-12-11_22:39:23.000; 00:00:02.9683095; 2013-12-12_22:39:23.000; 2013-12-12_22:39:24.000
19 2013-12-12_22:39:26.159; 2013-12-11_22:39:23.000; 00:00:03.1593286; 2013-12-12_22:39:23.000; 2013-12-12_22:39:24.000
20 2013-12-12_22:39:26.460; 2013-12-11_22:39:25.000; 00:00:01.4603587; 2013-12-12_22:39:23.000; 2013-12-12_22:39:24.000
21 2013-12-12_22:39:26.462; 2013-12-11_22:39:25.000; 00:00:01.4623589; 2013-12-12_22:39:25.000; 2013-12-12_22:39:26.000
22 2013-12-12_22:39:26.571; 2013-12-11_22:39:25.000; 00:00:01.5713698; 2013-12-12_22:39:25.000; 2013-12-12_22:39:26.000
23 2013-12-12_22:39:27.049; 2013-12-11_22:39:25.000; 00:00:02.0494176; 2013-12-12_22:39:25.000; 2013-12-12_22:39:26.000
это при подключении к обычному финамовскому серверу, правда на вечерке.
На текущий момент на моем компе следующая разница по времени с сервером точного времени:
>w32tm /monitor /computers:ntp.psn.ru
ntp.psn.ru[194.149.67.129:123]:
ICMP: 7ms задержка
NTP: -0.3411538s смещение относительно локального времени
RefID: gps-time.prao.psn.ru [194.149.67.32]
Страта: 2
Т.е. токальное время ушло вперед на 341 миллисекунду.
Пойдем с конца, почти.
В строке 21 пришлел бар со временем начала и окончания 22:39:25-22:39:26.
При этом LastUpdate все еще 22:39:25, т.е. по факту отстает на секунду от времени окончания бара, хотя точно неизвестно насколько, поскольку LastUpdate округлено до секунд.
С 12 по 20 строки (т.е. скрипт пересчитывался 9 раз в течении почти 2 с половиной секунд), идут значения, появившиеся непосредственно перед тем как появился этот бар (сделки соответствующие прошли, бар появился). Каждая строка - это пересчет скрипта и свое, возможно уникальное, состояние данных FinInfo. Какое из этих значений 9 значений FinInfo сопоставить этому бару, оканчивающемуся в 22:39:26? Последнее? Т.е. то, которое в строке 20 и со временем LastUpdate 22:39:25?
Хорошо, берем из строки 20, но далее с таким же временем есть еще 3 строки. Блок (мой и Ваш тоже) их сохранит, а при следующем чтении сопоставит с нашим баром уже не значения из строки 20, а значение из строки 23, потому что именно оно будет последним со временеим меньшим 22:39:26.
Это означает, что в первый раз к бару в 22:39:26 будут сопоставлены одни значения FinInfo, а в последующие разы уже другие. Т.е. данные будут перерисовываться. А при этом все ведь, вроде, правильно! Где "обман"?
Кстати если Вы не позаботитесь о записи и чтении данных из БД в порядке их поступления, то результат, вообще, может быть каждый раз разный.
Теперь если использовать не LastUpdate, а локальное время. Последним со временеим меньшим 22:39:26 будет строка 18 (если сделать поправку на сдвиг локального времени, то 19). Будет небольшое отставание данных, но этот вариант будет стабильно повторяться.
Кстати в строке 20 последний бар оканчивается еще в 22:39:24, но LastUpdate уже 22:39:25. Т.е. типа из будущего. На самом деле, видимо, сделок со временем 22:39:25 еще не было, но вот так вот. И это штатная ситуация. Особенно сильно это будет заметно на малоликвидных инструментах.
Данные по FinInfo и по сделкам приходят в разных "потоках", и любой из них по пути может "задержаться" чуть ли не как угодно. Никто ничего не гарантирует.
К чему я это все привел: что локальное время использовать, что LastUpdate, все равно будут неточности в сопоставлении FinInfo и баров. Надеюсь, мой пост окажется Вам полезным. При записи, точнее при чтении, Вам точно так же придется расставлять стаканы по барам
Предыдущий топик
К началу
