Re: [time-nuts] time-nuts Digest, Vol 99, Issue 111
Hello Magnus,
I know what you're talking about, I'm working for a company specialized in
broadcasting (from studio's to stations to satellites...) and in this world correct
timing is paramount, we live by the 1/25 second rythm and even less if you
have to sync on a line in the image ;-).
Some time ago we were instaling a complete TV station and had huge problems
with image stability and also especially the correct starting time of a clip or transmission.
Nobody wants to start his newsreel at eg. 20:00:05;23... it must be 20:00:00;00
We were looking into this and noticed that the customers servers (Win!) where
synced by SNTP, this is plain c..p!
Have a look @ http://technet.microsoft.com/en-us/library/cc773013(WS.10).aspx
Especially where it says:
"Important
The W32Time service is not a full-featured NTP solution that meets time-sensitive
application needs and is NOT SUPPORTED by Microsoft as such. For more information,
see Microsoft Knowledge Base article 939322, Support boundary to configure the
Windows Time service for high-accuracy environments."
Also have a look @ http://support.microsoft.com/kb/939322
It says:
"We do not guarantee and we do not support the accuracy of the W32Time service
between nodes on a network. The W32Time service is not a full-featured NTP solution
that meets time-sensitive application needs. The W32Time service is primarily
designed to do the following:
Make the Kerberos version 5 authentication protocol work.
Provide loose sync time for client computers.
The W32Time service cannot reliably maintain sync time to the range of 1 to 2 seconds.
Such tolerances are outside the design specification of the W32Time service."
So it is... 1 to 2 seconds....!!!!!!!!
Our video playout servers are decent super stable units that use heaps of Xilinx FPGA's
for coding/decoding videostreams supervised by a mil-spec VXworks OS, it uses the
so-called LTC for synchronising the playout, implemented mostly in hardware so
I did not suspect our machines. I did install a new TCG (TimeCode Generator) where
I also had heaps of problems with, I did debug the stuff together with the manufacturer's
R&D and finally got a perfectly synced station AND a Stratum-1 NTP (everything in
double with automatic failover, a requirement for a TV-station). (Thanks to lurking for
years as a genetically predispositioned Time-Nut, my father was a watchmaker...So I
knew more or less what a was talking about and could prove things thanks to my TBolt etc.)
Then I did install Meinberg NTP-client on every Win machine and all was suddenly
perfectly running, everybody happy!
This also solved some frequent file versioning problems for storing different versions of
videoclips especially in a mixed Win/Lin environment where Linux proved to be the
more logical/strict way of implementation.
Another thing, being considered as the local video timenut a colleague called me from
Saudi Arabia where he was having timing problems on two locations spaced 700km. apart
where he had funny image jumps at the exact same time, both stations were synced by
each the same TCG with GPS option (same as above), could the americans jam the GPS
signals over there, somebody heard about this? It could be a real problem for us, we
may need to use another method for station timing (Rb maybe, with some regular syncing
etc.)
Sorry for my long message but I don't often send timenut mail and this is a good example
of some real-life timenutting ;-)
I also have here a nice BeagleBone mini Linux board resting, where I would want to install
a FreeBSD image on and implement a NTP with a promising GPS board from Adafruit,
something for the long and cosy winter evenings... :-)
Best regards,
Jacques Tiete
From: Magnus Danielson magnus@rubidium.dyndns.org
To: Time-Nuts time-nuts@febo.com
Subject: [time-nuts] Timing performance of servers
Message-ID: 50887008.3030609@rubidium.dyndns.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Fellow time-nuts,
When spending time on a conference last week, I heard one interesting
comment that they lost data due to bad timing on their Windows servers.
Now, I know that the standard Windows uses SNTP in order to achieve the
goal of having the timing of the machines sufficiently aligned to allow
Kerberos authentication. SNTP suffice for that, as it needs to be a
handful of minutes in line.
If you need better performance than that, you should use NTP (and then
download and install Meinbergs Windows-client for NTP).
Then again, I would point out that for this type of data, it would most
probably be better served on a Linux box.
What should be a nice wake-up call for them would be a summation of how
different strategies would give them clock precision of sufficient
grade. So, does anyone know of such measurements presented anywhere?
There are bits and pieces, but the ideal for this case would be if they
where collected in one page/paper.
This is an awareness thing, so that people can do a little more
well-informed choices.
Cheers,
Magnus
Message: 6
Date: Wed, 24 Oct 2012 19:04:50 -0500
From: Edgardo Molina xe1xus@amsat.org
To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Subject: Re: [time-nuts] Timing performance of servers
Message-ID: 9A578007-FAB2-420E-BE25-6453F72E164D@amsat.org
Content-Type: text/plain; charset=iso-8859-1
Dear Mangus,
I will allow myself to share a comment on your thread.
Timing on windows servers is not one of their plausible strengths. It was clearly pointed out during the SIM conference last week at CENAM. In fact there was an interesting discussion about the drawbacks when using NTP Windows based servers and all kind of NTP appliances compared to full size Linux based NTP servers. The example of what NIST is using nationwide for their servers set an example of good server hardware and linux to provide the nation's NTP pulse.
I haven't done any experiments with Windows for NTP services, still it could be interesting as to set a benchmark while comparing it to the Linux boxes.
I am currently trying out the Domain Time II NTP client from Symmetricom for the thesis. I have to come back to Symmetricom's Miguel Garc?a to decide on purchasing a Domain Time II NTP client kit. How is the Mainberg NTP client different from the Symmetricom version? Have you tried both? If not I will be more than glad to help comparing both if you can help me pointing out the source for a demo version of Mainberg's software. Maybe then an objective review of both clients will be in order, I will be more than glad to do it or to test them against Windows NTP services, appliances and/or Linux NTP boxes. I have at least an example of those at the office.
-13
Just my 2x10 cents.
Regards to you and the group,
Edgardo Molina
Direcci?n IPTEL
T : 55 55 55202444
M : 04455 20501854
Dear Jacques,
Very interesting your studio work and experiences. I bought a year ago a couple of second hand GPS receivers and Leitch clocks belonging to TV studios and radio stations so I can imagine a little bit of what you are talking about.
I am interested in sharing the experiences with Beagle Bone. I got one recently. I would like to use Linux instead of FreeBSD. If you wish we could correspond over the email to do some tests and try to get two versions of the micro NTP box.
What do you think about it?
Regards,
Edgardo Molina
Dirección IPTEL
T : 55 55 55202444
M : 04455 20501854
Piensa en Bits SA de CV
Información anexa:
CONFIDENCIALIDAD DE INFORMACION
Este mensaje tiene carácter confidencial. Si usted no es el destinarario de este mensaje, le suplicamos se lo notifique al remitente mediante un correo electrónico y que borre el presente mensaje y sus anexos de su computadora sin retener una copia de los mismos. Queda estrictamente prohibido copiar este mensaje o hacer usode el para cualquier propósito o divulgar su en forma parcial o total su contenido. Gracias.
NON-DISCLOSURE OF INFORMATION
This email is strictly confidential and may also be privileged. If you are not the intended recipient please immediately advise the sender by replying to this e-mail and then deleting the message and its attachments from your computer without keeping a copy. It is strictly forbidden to copy it or use it for any purpose or disclose its contents to any third party. Thank you.
On Oct 25, 2012, at 4:17 AM, Jacques Tiete jacques@tiete.org wrote:
Hello Magnus,
I know what you're talking about, I'm working for a company specialized in
broadcasting (from studio's to stations to satellites...) and in this world correct
timing is paramount, we live by the 1/25 second rythm and even less if you
have to sync on a line in the image ;-).
Some time ago we were instaling a complete TV station and had huge problems
with image stability and also especially the correct starting time of a clip or transmission.
Nobody wants to start his newsreel at eg. 20:00:05;23... it must be 20:00:00;00
We were looking into this and noticed that the customers servers (Win!) where
synced by SNTP, this is plain c..p!
Have a look @ http://technet.microsoft.com/en-us/library/cc773013(WS.10).aspx
Especially where it says:
"Important
The W32Time service is not a full-featured NTP solution that meets time-sensitive
application needs and is NOT SUPPORTED by Microsoft as such. For more information,
see Microsoft Knowledge Base article 939322, Support boundary to configure the
Windows Time service for high-accuracy environments."
Also have a look @ http://support.microsoft.com/kb/939322
It says:
"We do not guarantee and we do not support the accuracy of the W32Time service
between nodes on a network. The W32Time service is not a full-featured NTP solution
that meets time-sensitive application needs. The W32Time service is primarily
designed to do the following:
Make the Kerberos version 5 authentication protocol work.
Provide loose sync time for client computers.
The W32Time service cannot reliably maintain sync time to the range of 1 to 2 seconds.
Such tolerances are outside the design specification of the W32Time service."
So it is... 1 to 2 seconds....!!!!!!!!
Our video playout servers are decent super stable units that use heaps of Xilinx FPGA's
for coding/decoding videostreams supervised by a mil-spec VXworks OS, it uses the
so-called LTC for synchronising the playout, implemented mostly in hardware so
I did not suspect our machines. I did install a new TCG (TimeCode Generator) where
I also had heaps of problems with, I did debug the stuff together with the manufacturer's
R&D and finally got a perfectly synced station AND a Stratum-1 NTP (everything in
double with automatic failover, a requirement for a TV-station). (Thanks to lurking for
years as a genetically predispositioned Time-Nut, my father was a watchmaker...So I
knew more or less what a was talking about and could prove things thanks to my TBolt etc.)
Then I did install Meinberg NTP-client on every Win machine and all was suddenly
perfectly running, everybody happy!
This also solved some frequent file versioning problems for storing different versions of
videoclips especially in a mixed Win/Lin environment where Linux proved to be the
more logical/strict way of implementation.
Another thing, being considered as the local video timenut a colleague called me from
Saudi Arabia where he was having timing problems on two locations spaced 700km. apart
where he had funny image jumps at the exact same time, both stations were synced by
each the same TCG with GPS option (same as above), could the americans jam the GPS
signals over there, somebody heard about this? It could be a real problem for us, we
may need to use another method for station timing (Rb maybe, with some regular syncing
etc.)
Sorry for my long message but I don't often send timenut mail and this is a good example
of some real-life timenutting ;-)
I also have here a nice BeagleBone mini Linux board resting, where I would want to install
a FreeBSD image on and implement a NTP with a promising GPS board from Adafruit,
something for the long and cosy winter evenings... :-)
Best regards,
Jacques Tiete
From: Magnus Danielson magnus@rubidium.dyndns.org
To: Time-Nuts time-nuts@febo.com
Subject: [time-nuts] Timing performance of servers
Message-ID: 50887008.3030609@rubidium.dyndns.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Fellow time-nuts,
When spending time on a conference last week, I heard one interesting
comment that they lost data due to bad timing on their Windows servers.
Now, I know that the standard Windows uses SNTP in order to achieve the
goal of having the timing of the machines sufficiently aligned to allow
Kerberos authentication. SNTP suffice for that, as it needs to be a
handful of minutes in line.
If you need better performance than that, you should use NTP (and then
download and install Meinbergs Windows-client for NTP).
Then again, I would point out that for this type of data, it would most
probably be better served on a Linux box.
What should be a nice wake-up call for them would be a summation of how
different strategies would give them clock precision of sufficient
grade. So, does anyone know of such measurements presented anywhere?
There are bits and pieces, but the ideal for this case would be if they
where collected in one page/paper.
This is an awareness thing, so that people can do a little more
well-informed choices.
Cheers,
Magnus
Message: 6
Date: Wed, 24 Oct 2012 19:04:50 -0500
From: Edgardo Molina xe1xus@amsat.org
To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Subject: Re: [time-nuts] Timing performance of servers
Message-ID: 9A578007-FAB2-420E-BE25-6453F72E164D@amsat.org
Content-Type: text/plain; charset=iso-8859-1
Dear Mangus,
I will allow myself to share a comment on your thread.
Timing on windows servers is not one of their plausible strengths. It was clearly pointed out during the SIM conference last week at CENAM. In fact there was an interesting discussion about the drawbacks when using NTP Windows based servers and all kind of NTP appliances compared to full size Linux based NTP servers. The example of what NIST is using nationwide for their servers set an example of good server hardware and linux to provide the nation's NTP pulse.
I haven't done any experiments with Windows for NTP services, still it could be interesting as to set a benchmark while comparing it to the Linux boxes.
I am currently trying out the Domain Time II NTP client from Symmetricom for the thesis. I have to come back to Symmetricom's Miguel Garc?a to decide on purchasing a Domain Time II NTP client kit. How is the Mainberg NTP client different from the Symmetricom version? Have you tried both? If not I will be more than glad to help comparing both if you can help me pointing out the source for a demo version of Mainberg's software. Maybe then an objective review of both clients will be in order, I will be more than glad to do it or to test them against Windows NTP services, appliances and/or Linux NTP boxes. I have at least an example of those at the office.
-13
Just my 2x10 cents.
Regards to you and the group,
Edgardo Molina
Direcci?n IPTEL
T : 55 55 55202444
M : 04455 20501854
Dear Jacques,
On 10/25/2012 11:17 AM, Jacques Tiete wrote:
Hello Magnus,
I know what you're talking about, I'm working for a company specialized in
broadcasting (from studio's to stations to satellites...) and in this
world correct
timing is paramount, we live by the 1/25 second rythm and even less if you
have to sync on a line in the image ;-).
Some time ago we were instaling a complete TV station and had huge problems
with image stability and also especially the correct starting time of a
clip or transmission.
Nobody wants to start his newsreel at eg. 20:00:05;23... it must be
20:00:00;00
We were looking into this and noticed that the customers servers (Win!)
where
synced by SNTP, this is plain c..p!
Have a look @
http://technet.microsoft.com/en-us/library/cc773013(WS.10).aspx
Especially where it says:
/"Important
The W32Time service is not a full-featured NTP solution that meets
time-sensitive /
/application needs and is NOT SUPPORTED by Microsoft as such. For more
information, /
/see Microsoft Knowledge Base article 939322, Support boundary to
configure the /
/Windows Time service for high-accuracy environments."/
Also have a look @ http://support.microsoft.com/kb/939322
It says:
/"We do not guarantee and we do not support the accuracy of the W32Time
service /
/between nodes on a network. The W32Time service is not a full-featured
NTP solution/
/that meets time-sensitive application needs. The W32Time service is
primarily /
/designed to do the following:/
/Make the Kerberos version 5 authentication protocol work.
Provide loose sync time for client computers.
The W32Time service cannot reliably maintain sync time to the range of 1
to 2 seconds. /
/Such tolerances are outside the design specification of the W32Time
service."/
So it is... 1 to 2 seconds....!!!!!!!!
These are very valuable references, many thanks for bringing them to my
attention.
Our video playout servers are decent super stable units that use heaps
of Xilinx FPGA's
for coding/decoding videostreams supervised by a mil-spec VXworks OS, it
uses the
so-called LTC for synchronising the playout, implemented mostly in
hardware so
I did not suspect our machines. I did install a new TCG (TimeCode
Generator) where
I also had heaps of problems with, I did debug the stuff together with
the manufacturer's
R&D and finally got a perfectly synced station AND a Stratum-1 NTP
(everything in
double with automatic failover, a requirement for a TV-station). (Thanks
to lurking for
years as a genetically predispositioned Time-Nut, my father was a
watchmaker...So I
knew more or less what a was talking about and could prove things thanks
to my TBolt etc.)
Then I did install Meinberg NTP-client on every Win machine and all was
suddenly
perfectly running, everybody happy!
This also solved some frequent file versioning problems for storing
different versions of
videoclips especially in a mixed Win/Lin environment where Linux proved
to be the
more logical/strict way of implementation.
This is a valuable experience to share. Many thanks!
Another thing, being considered as the local video timenut a colleague
called me from
Saudi Arabia where he was having timing problems on two locations spaced
700km. apart
where he had funny image jumps at the exact same time, both stations
were synced by
each the same TCG with GPS option (same as above), could the americans
jam the GPS
signals over there, somebody heard about this? It could be a real
problem for us, we
may need to use another method for station timing (Rb maybe, with some
regular syncing
etc.)
There are geographical areas where you have higher risk of being the
indirect target, yes.
Sorry for my long message but I don't often send timenut mail and this
is a good example
of some real-life timenutting ;-)
Then you should share me of your experience. :) This was a very nice post.
I also have here a nice BeagleBone mini Linux board resting, where I
would want to install
a FreeBSD image on and implement a NTP with a promising GPS board from
Adafruit,
something for the long and cosy winter evenings... :-)
So many nice projects. :)
Have a BeagleBone lying around here somewhere. Putting a GPS onto it
would be a great project. :)
Cheers,
Magnus