[ntp:questions] Re: Clock accuracy & auto setting : digital television does a crap job of providing time services...

Max Power mikehack at u.washington.edu
Sat Apr 29 02:14:13 UTC 2006


>>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.

No I am not suggesting this.
64 extra bits can help futureproof a signal however...
================
>  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)?

Turing NTP into a very high precision signal is possible -- but I advocate 
split versions of the signal.
Otherwise, for consumers the extra 64 bits could be used for other time 
related services and futureproofing.
================
>  64 bit NTP is probably quite adequate, and definitely enough bits if
> one doesn't insist on the NTP nanosecond precision.

NTP does have its origins with Unix Time, and Unix / Linix / Minix ... need 
to be upgraded to account for 64 bit time [to help avert the 2038 crisis] --  
but not NTP time. However, Unix Time and NTP have always had near perfect 
interoperability for at least 2 decades...
================
>  However, the time information doesn't need to be NTP, or IP based.
> By the way, NTP is not a part of unix.

This 'time ignorance' socally acceptable now, but bad public policy.
Lack of use of UTC is a bad policy, but this is an ATSC problem -- not a 
DVB-T problem.
HDTV is very late Beta -- but when HDTV is omnipresent the lack of accurate 
time avalability should not be the case.
Your HDTV set should be able to sync its own clock after being turned on for 
5 minutes.
HDTV sets shoul be able to set the clocks of other devices [VCR's, DVD's, 
set top boxes] using whatever [TV] connection technology that will exist in 
future.
Commerical stations not providing an accurate time signal [to within 1.0s] 
should be punished (based on transmitter power) -- the ethics of this being 
that that keeping broacast clock accuracy requires virturally no cost 
overehead and provides a public service function. A lot of ATSC transmission 
energy goes into sending 'empty packets' or 'nulls' -- replacing 1% {per 
hour} of nulls with time signal packets would yield instant time sync.
I am considering the UK, Erie, Australia, NZ and Canada in my point -- not 
just the US.
================
> 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 
> stream.





More information about the questions mailing list