Time mismatch issue

[gauravrana]

Is there an permanent solution of below attached screenshot?

[Philip D'Ath]

I'm not familiar with that product - but what a pain!  7 seconds!!!

The only thing I can think of is to choose one NTP time source in your organisation, and sync everything against that.

[Scott Olsen]

You absolutely need to have all the resources synchronized via NTP for things to be reliable (not to mention make sense).

Check your NTP config.  VSM servers, video endpoints, switches, workstations.  The whole thing.

[Nicholas Hood]

In our setup we have 1 VSM server, 1 maps server and 6 media servers. In the servers network settings we use the default gateway (the router) as the NTP server. For the cameras, we use the specific media server the camera is attached to as it's NTP server. It's critical that the times be synced for accurate archiving as well as being able to sync multiple video sources at the same time. It is also critical because if a video is ever used in court, (assuming this is being used as a security system) it might not hold up, with even small differences like that.

[Scott Olsen]

I concur Nicholas.  Personally, I was almost called up for expert testimony to provide a technical explanation for the smallest of time discrepancies between a camera's OSD timestamp and the additional archive timestamp also displayed on playback.  While it was only ~1 second, I needed to explain to council that all the following was occurring during these two timestamps:

• Firmware overlays OSD information (timestamp) prior to codec compression, so there is some time spent actually computing and compressing the video stream.
• Packetization of the actual data to be placed on the network.
• Transport of said data to VSMS instance responsible.
• Possible internal processing by the VSMS archiver daemon itself just prior to being officially timestamped on the VSMS server while being committed to disk.

So, even if your NTP protocol is properly configured and doing its job, someone may still find temporal quirks to nit-pick!

Cheers!

[StephanMC]

While on the topic of NTP and times.

Anyone ever run into the issue when watching multiple cameras and synching them all together and watching footage at 16x that after some minutes in real time (maybe several hours on recordings) that the recording drift apart by 10 or more seconds?

[Scott Olsen]

I've recently been picking apart some of the underlying processes that store media files on disk, and, while I obviously can't confirm (as I'm ultimately just an end user), I'm speculating that it may be an 'inter-file gap' accumulating over time.  What I mean by that is that down at the filesystem / database level in the VSMS daemon, there is a finite temporal resolution that can be obtained ("timestamp accuracy") when indicating the ending, and beginning, of each actual SMD file stored in the media repositories, and their related SQL database entries.

.... If I had to come up with an analogy, think of massive financial systems that deal with fractions of a cent internally... if most outward facing accounts have a finite (or more coarse) resolution of a full cent, there is going to be a bit of 'play' or 'slop' inherent internally.

Further to this... I believe the initial timestamp synchronization (when you first instruct the panes to sync) is as accurate as possible and based off of UTC timestamps and SMD inter-file index seeking to set the initial playback start point.  It then proceeds to play archive file streams back in the most efficient way possible... which is straight sequential access across the disk, across multiple archive (SMD) files.  I suspect that over time, these extremely minute inter-file gaps accumulate and I'm very confident that once this sequential playback of multiple streams is started, it never actually performs periodic consistency checks against the UTC timestamp in the archive (i.e. - It's not cognizant of its own drift).  The reason I believe this to be true is that if you manually intervene and pick a new playback start point... it will realign with the UTC timestamps for the archive again.

Again, I can't absolutely confirm anything I've stated above is actually what's occurring (you'd need to speak to Cisco directly about that), but it is what I have to offer you for a possible explanation based on my own observations.

Cheers!

[StephanMC]

neat explanation. could well be something along those lines.

[mcwalter]

Is the HWclock synchronized? You can verify on the CLI for each server by running these 2 commands

date

hwclock

If they don't match then you need to synchronize them.

hwclock --systohc

You can also check the NTP on each server by running this

ntpdate -q x.x.x.x (the IP of your NTP server)

Before running that command I recommend shutting down the cisco services. As Scott says NTP is critical. Mess around with time while the archives are running at your own risk. 

service cisco stop

service cisco start are the 2 commands you may need. 

Good luck!