[ntp:questions] Re: Clock accuracy & auto setting : digital television does a crap job of providing time services...
larson at w6yx.stanford.edu
Sun May 7 08:18:32 UTC 2006
Since the application for ATSC broadcasting seems to be mostly setting
the clocks in the receiver's equipment, the 232 picoseconds of NTP seems to
rather far beyond what is needed. After all, 232 picoseconds is just under
7 centimeters at light speed. Thus, broadcasting the time of day (to set
the clock in your TV recorder) to that resolution seems a bit excessive.
0.01 second seems adequate to me to not miss the program.
The problem as I see it is that the sources are way bad (as you note).
Clearly, NTP would be a useful and available way of keeping a machine
transmitting time on a broadcast signal in good sync.
With ATSC, there seems to be some difficulty with daylight saving time --
when the time advanced this spring, I noticed that the electronic program
guides apparently did not advance. Attempts to set the clock on my ATSC
receiver from over the air signals got various times which did not match
local time. I eventually gave up and went back to the recommendation in
the addendum to the manual to manually set it to local non-DST time, with
the timezone set. That gets the program guide to match, but the clock of
course reads an hour slow.
It is unclear whether the Asians who programmed the thing didn't
understand time, or whether the standard is that completely flawed that it
doesn't account for properly dealing with transferred times in UTC and
converting for display. (Though, transmitting daylight saving time info in
the WWVB style seems a good idea, given the government's willingness to
fiddle with it and almost certainly break lots of things with built in
Precision is not a solution for lack of accuracy.
Neither precision nor accuracy will make up for implementation errors.
p.s. Doesn't CBS news still do the ping at the top of the hour? I think
they are still coming out from KCBS here. (I don't know what they do about
satellite delay of the feed (signal travel time, and any digital coding/decode
times). I have no idea how they will deal with the variable time delays of
IBOC digital processing.
In article <e3jgrk$8bm$1 at dewey.udel.edu> "David L. Mills" <mills at udel.edu> writes:
>The 128-bit NTP date spans 584 billion years with a resolution of .05
>attosecond. The 64-bit NTP timestamp spans 136 years with a resolution
>of 232 picoseconds. Is there something that needs better than 232
>picoseconds? A 4-GHz CPU comes close.
>As for broadcasters chiming good time, I do know that PBS/NPR
>distributes progams via digital satellite and IP network with NTP.
>However, I am told the gadgetry that actually brands the signal doesn't
>use NTP, is often banished to the bottom of the rack and nobody knows
>how to adjust it. As for the broadcast program start time, so far as I
>can tell it's withing 30 ms of UTC. That's the best I can do with
>eyeball and ear.
>When I worked for an NBC affiliate in Detroit we had two clocks, one
>synchronized to the power grid and the other a Western Union gadget that
>synchronized via wire. The WU clock was purposely set to run slow by a
>second or two per hour. Once per hour WU sent a pulse over the wire
>causing the clock to do a hands-up jerk. I quickly learned to use that
>clock only to calibrate the few seconds offset of the grid at the
>hands-up signal. Broadcast networks once sent an audible ping at
>hands-up to do the same tning, but that was (ahem) 50 yuears ago..
>Alan Larson wrote:
>> In article <e2p993$qim$2 at gnus01.u.washington.edu> "Max Power" <mikehack at u.washington.edu> writes:
>>>In North America, the FM RDS time service is of very low quality.
>>>In Europe (I understand) this is not the case with RDS.
>>>Stations running RDS should be mandated by law to provide a quality
>>>service -- based on transmitter power and coverage area.
>>>Over time RDS's time service should be uniform.
>>>DRM (on MW and SW) time service is of a lower quality than RDS -- but could
>>>be upgraded with a specialized "80 bit" NTP-UNIX time packet.
>>>ATSC and DVB-T (& DVB-H/M) need a uniform ~"80 bit"...~"128 bit" time packet
>>>service that is well thought out.
>>>Futureproofing is important, so probably 128 bits or more is preferable.
>> 128 bits? What do you want - to specify the time of the heat death of the
>> universe (long after our sun dies) to nanosecond resolution, then be able to
>> tell the time of the death of the next universe (if there is one)?
>> 64 bit NTP is probably quite adequate, and definitely enough bits if
>> one doesn't insist on the NTP nanosecond precision.
>> However, the time information doesn't need to be NTP, or IP based.
>> By the way, NTP is not a part of unix.
>> Presently, the analog TV stations transmitting time don't even seem
>> to consider it worth keeping the clocks set accurately -- some use a
>> PC's clock, with no external source to deal with its drift.
>> The time sent with ATSC seems to be random as well. Some stations
>> seem to have gone ahead with DST, but the only way to get the program
>> data to be correct is to manually force (and set) the receiver to use
>> local standard time.
>> Of course, not using UTC is astoundingly stupid -- folks who live next
>> to a time zone boundary are out of luck if some stations are on each side.
>> However, counting on broadcasters to get the time right is a fantasy.
>> They cannot even get their program guide information correct in the data
More information about the questions