PC clock generator without 14.318MHz
How about the Apollo launches ?
On Wed, Oct 19, 2016 at 12:40 AM, jimlux jimlux@earthlink.net wrote:
On 10/18/16 4:25 PM, Magnus Danielson wrote:
Jim,
On 10/19/2016 12:51 AM, jimlux wrote:
On 10/18/16 2:30 PM, Tom Van Baak wrote:
Hi Vladimir,
Some of these numbers survive to the present. I'm typing this post on
an XP laptop where QueryPerformanceCounter() has a Frequency.QuadPart
of, you guessed it, 3579545 Hz, which is why my Win32 laptop's
high-res clock has ~279 ns resolution.
For more fun with time, frequency, oscillators, and prime numbers,
see: http://www.poynton.com/PDFs/Magic_Numbers.pdf
and this is why clocks in film movies on TV run slightly slow<grin>..
because the film was shot at 24 fps, and it's converted to 29.97 frame
rate (in the US) by a 3:2 pulldown scheme.
I am sure that all the time nuts here notice that 0.1% rate difference.
Over a half hour TV program it adds up to almost 2 seconds of offset.
(that's just because we watch things like movies shot of counters
running).
Hmm.. there's probably film footage of things with a running counter in
the scene counting tenths or hundredths of a second (sporting events,
nuclear bomb tests, etc.) I wonder if you could see that difference by
single framing something like a filmed 100 meter race where they have an
onscreen timer.
The time-code of TV and film production runs with a frame-counter.
Now, since the 30/1.001 factor is uneven, to get things into shape the
factor is compensated using the drop-frame method.
SO that compensates in the "big sense" so that "timecode" and "wall clock"
line up..
But when they do the original telecine, they're basically running a 30fps
(interpolated from 24 fps) sequence of frames at 29.97. Over the air,
there will usually be a commercial break and they can add/drop any
arbitrary number of frames to get it to line up (should they even care
about whether the on-screen clock ticking the seconds actually lines up)
So I was thinking about something where you get a broadcast (or maybe a
video conversion on DVD/tape/online) that is a continuous piece of film.
Seems that something like 100 meter race, which lasts 10 seconds, and will
have an on screen timer to hundredths isn't quite long enough to see the
1.001 error (and would it be one continuous shot, or would they have edited
film together from different viewpoints).
What about a filmed rocket launch with a countdown timer or similar? they
might have one continuous piece of film long enough.
Partly, its going to be limited by the magazine size of the camera: a 400
ft magazine is a bit more than 6 minutes (1 ft = 1 second in rough terms),
so that's plenty long to see the difference.
What you really want is continuous footage lasting, say, a minute, of some
event (motivating the coverage) where there's an accurate clock visible in
the scene, where the film was originally shot at 24fps, and has been
converted to video.
An interesting quest....
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/m
ailman/listinfo/time-nuts
and follow the instructions there.
Hmm.. there's probably film footage of things with a running counter in
the scene counting tenths or hundredths of a second (sporting events,
nuclear bomb tests, etc.) I wonder if you could see that difference by
single framing something like a filmed 100 meter race where they have an
onscreen timer.
You don't have to go back very far and film cameras used mechanical
governors for speed control.. "quartz lock" is a relatively recent
addition, and as recently as 20 years ago, you had to pay extra for it
when renting camera gear.
Hi Jim,
I recently happened to view the Director's cut of Woodstock. On the bonus disc there's a piece called "Synchronization" with amazing information about the extreme effort it took to sync 3 days of footage of 12 cameras and 8-track audio tape in an era before quartz timing. 60 Hz hum played a role.
Since I know none of you are going to spend 9 hours watching the DVD, I found at least one page on the web with part of the story.
Go to https://www.editorsguild.com/V2/magazine/archives/0107/news_article04.htm and skip way down Chuck Levey's part, or just text search for the word "sync".
He mentions the wristwatch trick:
"In 1969, we shot the performance material using AC power in
order to stay in sync. It was clumsy. There were cables. The motors
were heavy and became very hot. In the rain we kept getting shocked.
And don't forget our primitive 'get a shot of your wristwatch'
attempts at time code.
The last sentence wins a prize:
"With a laugh, Levey compares the new syncing technologies to those
of the original film. "We were glad when it came to the footage
of The Who, because Pete Townshend's trademark windmill guitar
technique made syncing that passage a little easier," he recalls.
/tvb
Attila,
On 10/19/2016 01:25 AM, Attila Kinali wrote:
On Tue, 18 Oct 2016 23:36:55 +0200
Magnus Danielson magnus@rubidium.dyndns.org wrote:
To this day, the 1.001 factor haunts us in all modern hardware and
timing designs, including the latest synchronization standards.
It's fascinating that we have been simulating several centuries into the
future to ensure that the algorithms for the synchronization will make
the 1.001 factor keep working as intended. I wrote one such simulator
being used.
So, you are doing the inverse of a programmer archeologist[1]?
SCNR :-)
On a more more serious note: what exactly have you been simulating?
And how does this frequency make a difference?
When you use GPS/GNSS as source for your TV-signals, you define a
suitable epoch, such as the PTP Epoch. At the Epoch, all sample values
where in phase, and from then on they progress with SI-second, so with a
TAI-approximation you can calculate it. The time of day, date etc. you
derive from the UTC-approximation.
The 1.001 factor then requires a 1001 s long cycle before it aligns up.
Considering some other factors, this can be as long as 4004 s for
everything to aline up. So, TAI-time modulus 4004 s and from there it is
relatively simple for all the phases.
You would find the details in SMPTE 2059-1 and SMPTE 2059-2.
All the traditional formats can be expressed in this time. In order to
achieve it fully, the PTP server needs to extend with additional info,
which among other things tells us how the TV station is setup and when
the common daily jamming occurs.
Now, as we do full-HD signal, it is 2,97 Gb/s for European TV or
2,97/1,001 Gb/s for US TV. So we naturally need a way to get these
values in low-jitter form, which is a bit interesting. The older BT.656
SDI format, also known as SMPTE 259 had a nice and round common number
of 270 Mb/s for both formats, but somebody didn't think it through for
the HDTV variant and the number-magic broke up.
We keep inherit this into 4k video and 8k I guess.
Lovely, isn't it?
Cheers,
Magnus
On 10/18/16 4:50 PM, Adrian Godwin wrote:
How about the Apollo launches ?
On Wed, Oct 19, 2016 at 12:40 AM, jimlux jimlux@earthlink.net wrote:
What you really want is continuous footage lasting, say, a minute, of some
event (motivating the coverage) where there's an accurate clock visible in
the scene, where the film was originally shot at 24fps, and has been
converted to video.
An interesting quest....
But didn't you know, those were all faked in Hollywood<grin>
Yes.. the trick is finding a continuous shot.. I did some googling and
didn't turn up a continuous shot.. lots of "edited highlights" reels..
What I need is that really boring single camera watching from a single
viewpoint with a high resolution counter in the field of view. The "big
countdown clock" at KSC doesn't show fractions of a second.
I also found some stuff from the 1976 olympics (200m and 400m), but it's
multiple camera angles and obviously video recording.
It will likely be something that was shot for "scientific purposes" (so
the clock's in the scene) that someone has telecine'd for amusement -
I've got a DVD full of atomic bomb detonation clips at home.. maybe one
of those, because they just took the archival footage and put it on DVD,
no edits, no color correction, etc.
There might also be some sort of newsreel footage of some piece of
appropriate equipment (e.g. high speed counter) is featured for a few
seconds.. if someone had one of those older scalers with the 10 neon
bulbs for each digit arranged in columns, that might work.. if they're
counting milliseconds or microseconds, then a few second clip would be
long enough. Or a counter with a fast discrete display (like an older HP
with a non-multiplexed display)
On 10/18/16 5:06 PM, Tom Van Baak wrote:
Hmm.. there's probably film footage of things with a running counter in
the scene counting tenths or hundredths of a second (sporting events,
nuclear bomb tests, etc.) I wonder if you could see that difference by
single framing something like a filmed 100 meter race where they have an
onscreen timer.
You don't have to go back very far and film cameras used mechanical
governors for speed control.. "quartz lock" is a relatively recent
addition, and as recently as 20 years ago, you had to pay extra for it
when renting camera gear.
Hi Jim,
I recently happened to view the Director's cut of Woodstock. On the bonus disc there's a piece called "Synchronization" with amazing information about the extreme effort it took to sync 3 days of footage of 12 cameras and 8-track audio tape in an era before quartz timing. 60 Hz hum played a role.
Since I know none of you are going to spend 9 hours watching the DVD, I found at least one page on the web with part of the story.
Go to https://www.editorsguild.com/V2/magazine/archives/0107/news_article04.htm and skip way down Chuck Levey's part, or just text search for the word "sync".
He mentions the wristwatch trick:
"In 1969, we shot the performance material using AC power in
order to stay in sync. It was clumsy. There were cables. The motors
were heavy and became very hot. In the rain we kept getting shocked.
And don't forget our primitive 'get a shot of your wristwatch'
attempts at time code.
We've all done that... And an analog watch is easier to read in a fuzzy
out of focus (too close to the camera) shot than a digital watch.
The last sentence wins a prize:
"With a laugh, Levey compares the new syncing technologies to those
of the original film. "We were glad when it came to the footage
of The Who, because Pete Townshend's trademark windmill guitar
technique made syncing that passage a little easier," he recalls.
who knew that the who was thinking about time-nuts..
On 10/18/2016 11:23 PM, Mike Cook wrote:
Le 18 oct. 2016 à 16:53, Vladimir Smotlachavs@cesnet.cz a écrit :
Hello,
I have operated own NTP servers with stable system clock for many years. The principle is quite simple - I replaced 14.318 MHz quartz with OCXO based circuit. Now I have to build few more servers with modern mini-ITX motherboards, however on many of them (e.g. from ASUS) I can’t find any 14.317 MHz quartz. Such frequency is a relic of original PC design and I wonder if it is used any other basic frequency in recent clock generators?
The 14.317MHz xtal was connected to the south bridge controller chip, but for recent CPUs this has gone away as has northbridge and the system clock has been integrated into the PCH (Platform Controller Hub) chip according to Wikipedia, so I suspect that if you find the clock feeding that , then you could stabilize it in that same way.
Thank you Mike, PCH will be object of my experiments.
I wonder than probably nobody solved stable clock source in "post
14.318" mainboards.
Vladimir
thanks,
Vladimir
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
"The power of accurate observation is commonly called cynicism by those who have not got it. »
George Bernard Shaw
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
The last time I read about this it was on an ARM based board. They clocked
it with a GPSDO. I think the problem is MUCH easier if you can abandon
the PC platform.
The other story I read solved to problem by adding even more hardware and
some software changes. They moved the nanosecond counter out of the CPU
chip to a hardware counter and then the PPS signal connected to a latch.
This avoids the interrupt latency.
In most normal NTP servers the interrupt causes the CPU to snapshot its
internal nanosecond counter and store the snapshot in memory and set a flag
so the user space task can then read the value stated in RAM. This gets
you only microsecond resolution.
With special hardware the counter is latched with external hardware then
then on the interrupt handler only has read the latch and place that valuer
in RAM and set the same flag. The trouble is that EVERY routine that
reads the internal counters has to by modified to read the eternal counter.
As I remember these system ran BSD UNIX.
On Wed, Oct 19, 2016 at 9:02 AM, Vladimir Smotlacha vs@cesnet.cz wrote:
On 10/18/2016 11:23 PM, Mike Cook wrote:
Le 18 oct. 2016 à 16:53, Vladimir Smotlachavs@cesnet.cz a écrit :
Hello,
I have operated own NTP servers with stable system clock for many years.
The principle is quite simple - I replaced 14.318 MHz quartz with OCXO
based circuit. Now I have to build few more servers with modern mini-ITX
motherboards, however on many of them (e.g. from ASUS) I can’t find any
14.317 MHz quartz. Such frequency is a relic of original PC design and I
wonder if it is used any other basic frequency in recent clock generators?
The 14.317MHz xtal was connected to the south bridge controller chip, but
for recent CPUs this has gone away as has northbridge and the system clock
has been integrated into the PCH (Platform Controller Hub) chip according
to Wikipedia, so I suspect that if you find the clock feeding that , then
you could stabilize it in that same way.
Thank you Mike, PCH will be object of my experiments.
I wonder than probably nobody solved stable clock source in "post 14.318"
mainboards.
Vladimir
thanks,
Vladimir
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/m
ailman/listinfo/time-nuts
and follow the instructions there.
"The power of accurate observation is commonly called cynicism by those
who have not got it. »
George Bernard Shaw
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/m
ailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/m
ailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
Chris, I agree with you that additional HW to avoid interrupt latency is
necessary. My NTP servers with stable oscillator and HW card processing
PPS (still in use but some mainboards failed after 10 years of reliable
service) are described here:
http://archiv.cesnet.cz/doc/techzpravy/2007/ntp-server/
Vladimir
On 10/20/2016 04:38 AM, Chris Albertson wrote:
The last time I read about this it was on an ARM based board. They clocked
it with a GPSDO. I think the problem is MUCH easier if you can abandon
the PC platform.
The other story I read solved to problem by adding even more hardware and
some software changes. They moved the nanosecond counter out of the CPU
chip to a hardware counter and then the PPS signal connected to a latch.
This avoids the interrupt latency.
In most normal NTP servers the interrupt causes the CPU to snapshot its
internal nanosecond counter and store the snapshot in memory and set a flag
so the user space task can then read the value stated in RAM. This gets
you only microsecond resolution.
With special hardware the counter is latched with external hardware then
then on the interrupt handler only has read the latch and place that valuer
in RAM and set the same flag. The trouble is that EVERY routine that
reads the internal counters has to by modified to read the eternal counter.
As I remember these system ran BSD UNIX.