Проблемы измерения времени в системах видеонаблюдения

Дмитр,

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

Отчего Вы использовали NTP сервер Widows PC? Вы не пробовали поднять такую службу на Linux машине, или на маршрутизаторах (Cisco, Nortel, Mikrotik, ...)?

TechSupport согласен с Вами. Рекомендация была бы полезна. Еще б конечные пользователи читали документацию к обрудованию ))

Я не программист. делаю как мне проще.

Глебу Анатольевичу

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

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

И если, при аварии любой распределенной системы - вы(м.ч.) теряете всего лишь часть, то при глобальной - вы(м.ч.) теряете ВСЁ!

Ну и что в данном случае считать меньшим злом?

Дмитрию

Нет клиентское место с Domination не ведущее.

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

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

Два года это не срок, вот поработаете лет этак 20, тогда на такие шишки и на такие грабли по-наступаете, что поймете - лучше, каждый день, объяснять заказчику - где зачем и почему, чем один раз попасть в положение и объяснять: - почему он(заказчик) вбухавший кучу деньжищ в ОПС СКД и ОВП - в один миг потерял всё, - причем всё, это в буквальном смысле: - и товар и деньги и все архивы в которых могли бы быть факты о совершенном преступлении. ;-)

Рекомендация была бы полезна.

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

И если бы, эти проблемы решалась, - то они были бы решили еще в прошлом веке и никаких проблем а-ля "Проблема 2000 года" - не было бы в помине ещё тогда.

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

В конце концов в?се зависит от конкретного объекта. Если служба организована правильно, то можно и ручками, но вероятность ошибки выше, чем при автоматической синхронизации???????.?

Рекомендация была бы полезна.

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

И если бы, эти проблемы решалась, - то они были бы решили еще в прошлом веке и никаких проблем а-ля "Проблема 2000 года" - не было бы в помине ещё тогда.

???

Как "принципы работы файловых систем PC" мешают обеспечить актуальные временные метки в записях?

Как эти "принципы..." приводят к потере записей при сезонном сдвиге времени?

Да и "Проблема 2000 года" имеет отношение к теме, как бузина к киевскому дядьке...

Вадим, мне трудно следить за Вашей мыслью! :)

Хочу оспорить фразу "Рекомендация будет абсолютно бесполезна"!

Моделируем ситуацию в которой нет автоматики и нет связи с Интернет:

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

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

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

У наших с Вами заказчиков всё "в шоколаде", а у заказчика нашего "ненавистного инженера" - через некоторое время "полная ...опа".

Куды "простому инженеру" податься, что ему делать? Предлагаете припасть к живительному источнику Вашего многолетнего опыта, который передаётся "изустными сказаниями"? Даже если у Вас останется свободная минутка после посещения всех Ваших заказчиков,- "простой инженер" повесится, узнав что причина в "принципах работы файловых систем PC" :)

Это хорошо? Это "пиративно"!

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

Надеюсь на Ваше понимание и участие.

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

А я извиняюсь, - "ху-из" он, этот загадочный "простой инженер широкого профиля" ?

Ваша постановка вопроса больше, напоминает анекдот про смежные специальности - "сантехник-гинеколог", "главный помощник младшего дворника", а вовсе не про специалиста ОПС и СВН.

Т.ч. если ЖАДИНА заказчик, нанял себе для монтажа ОПС, СКД или СВН "гастарбайтеров-сантехников", а затем еще на обслугу нанял "главного помощника МНС-а из теплотехнического ВУЗ-а" - то он сам себе "злостный Буратино" и ему ни какая охрана не нужна, ему нужна только видимость и в таком случае, - что он заказал, то он и имеет.

Другой вопрос что сегодня сплошь и рядом обратная ситуация, это ситуация когда - "нахватавшиеся верхушек" "МНС-ы теплотехники" начинают сплошь и рядом подряжаться и разводить заказчиков, которым действительно необходимы серьезные меры охраны!

- Вот тут, - полный "Алес Ахтунг Капут".

Да и "Проблема 2000 года" имеет отношение к теме, как бузина к киевскому дядьке...

Глеб Анатольевич - а Вы проведите небольшой эксперимент у себя на рабочем столе.

Возьмите и установите дату (дата - это же время) на вашем цифровом устройстве записи, на винчестер которого, ну скажем умещается - 1 сутки записи.

Так вот - возьмите и установите дату на пару суток вперед, сделайте запись в течении суток, а затем верните дату на "родину" - т.е. откатите на двое суток назад и посмотрите что у Вас произойдет с размером текущей записи и что будет Вам сообщать система о наличии свободного места на HDD.

Дай Бог если она (сегодняшняя запись) в течении двух суток будет минут 5-10, а то её (текущей записи) может и не быть в течении последующих двух суток.

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

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

Просто я одно время занимался системами GPS мониторинга за транспортом, там проблема со временем как бы "решена"и решена она именно путем местной локализации по отношению к всемирному Гринвичу, причем в каждом посылаемом пакете данных объектовый комплект (у которого время синхронизируется со спутниками GPS) всегда сообщает точное время отправки своих данных привязанных именно к Гринвичу, но и это никак не избавляет от проблем потери данных при неправильно идущих часах на сервере приема данных GPS мониторинга - потому как базу он ведет с индексацией по собственным локальным часам и винде глубоко насрать на то, что время приема указанное в пакете не совпадать с её собственным.

И вот когда у нас отменили переход на "зима-лето", то мы просто взвыли и не от того что перестали переводится часы, взвыли именно от того что просто поменялись часовые пояса и Челябинск вдруг стал в одном часовом поясе с Новосибирском и вся коррекция локального времени к глобальному Гринвичу накрылась медным тазом. И до тех пор пока Майкросов Виндовс не выпустила очередной "заплатки", - на всех PC работающих с системой мониторинга GPS в городах Челябинске, Екатеринбурге и т.д. приходилось выставлять часовой пояс города Новосибирска вместо Екатеринбурга.

PS

Вот такая вот бузина с эти "всемирно синхронизированным временем", только не у Вас там в Киеве, а у нас тут, причем не далеко - прямо за баней :-)

Вадим, Ваш опыт очень ценен. Отчего же Вы даже не пытаетесь обобщить его по конкретной проблеме и выработать советы и рекомендации?

А пока Вы думаете над этим философским вопросом, я попытаюсь снова очертить круг проблем с измерением и управлением временем в системах видеонаблюдения.

1) проблема сезонных сдвигов. При возврате на "стандартное" (зимнее) время стрелки часов переводятся на 1 час назад и после этого записи за последний перед переводом стрелок час становятся недоступными;

2) проблема интернет-синхронизации. В Windows системах по умолчанию период синхронизации составляет 7 суток, за этот период отличие локального времени системы может составить десятки секунд. Записи становятся неактуальными, а при синхронизации вероятна потеря информации (при опережении локального времени);

3) для систем наблюдения без доступа к Интернет вторая проблема может многократно усугубиться за счёт бОльшего периода коррекции локального времени;

4) системы наблюдения не защищены от намеренной фальсификации времени. Такая фальсификация может стать причиной выведения из строя архивов записей.

Рекомендации по снижению рисков, связанных с проблемами измерения времени:

1) Для территорий с обязательным переходом на "летнее время" - отключить сезонную автоматическую коррекцию времени. Включить в перечень регламентных работ коррекцию "летнего времени" вручную два раза в год в даты переходов. При переходе на стандартное время (сдвиг на один час назад) видео архив за последний час следует сохранить перед коррекцией времени.

2) Для систем видеонаблюдения на платформе Windows следует сократить период синхронизации до 1-2 часов. Такие настройки можно сделать с помощью редактирования реестра (http://itfound.ru/78-sinhron-time-windows.html).

3) Для систем видеонаблюдения без доступа в Интернет следует включить в перечень регламентных работ коррекцию времени всех элементов системы не реже одного раза в 7 календарных дней.

4) Потребовать от разработчиков системы видеонаблюдения детекции события изменения локального времени и включения этого события в перечень тревог.

Прошу сообщество критиковать, дополнять и напуствовать...

Уважаемы Глеб Анатольевич - не ужель Вы всё еще не поняли что обращаясь ко мне (вернее к моему опыту), Вы обращаетесь не по адресу! ;-) Хотя и даже обращение к неким "производителям": - это так же "мимо кассы"!

Прочтите хотя бы вот это:

Синхронизация времени в linux через windows с GPS-приемником

И тогда, надеюсь, поймете: - что даже, обращение с мольбой о помощи: - ни к Гейтс Биллу; - ни к Торвальдсу Линусу, Вам не помогут решить проблем потери данных при изминении системного времени, потому что эти проблемы есть у всех - начиная с сотовых операторов с их билингом, банков с их транзакциями и процентами начисляемыми за период времени, вообщем у всех.

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