In message ECC7F999-673E-4F70-95EF-1D888761A991@rtty.us, Bob Camp writes:

Actually that is not true anymore.  Modern CPU's are very finicky about
clock jitter because the PLL the frequency up to GHz range.  Some of the
clock-chips used now discipline a low-UHF range oscillator to the XTAL
to cope with this, but most just PLL the frequency up there.

It's pretty much still 14.318 Mhz pretty universally.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

You need to replace the clock that drives the CPU; in some designs this was
the 14.318 MHz oscillator that would be multiplied up to the required
frequency.  You could also replace the 14.318 MHz oscillator with a TCXO or
better; make your own simple OCXO around a 14.318 MHz oscillator or lock a
14.318 MHz oscillator to a high stability reference oscillator (Rb, GPSDO
etc.).  You would need to do some circuit surgery on the PC motherboard for
this type of stuff.

Some links:

http://www.moshier.net/#Rubid_pc Lock 14.318 MHz to Rb
http://www.wraith.sf.ca.us/ntp/#ocxo-osc Simple oven
http://www.techlib.com/electronics/ovenckts.htm More simple oven circuits
http://www.febo.com/pages/soekris/index.html John's note for the Soekris
and clock hacking

Regards.

Mark.

--

Mark Allwright, VE6NTP

-----Original Message-----
From: Sarah White
Sent: Friday, November 30, 2012 5:10 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Using a frequency synthesizer replacement for
motherboard oscillator

On 11/30/2012 6:30 PM, Eric Garner wrote:

Yeah, the one on the (Soekis) example was pretty small. So far none of
of the replies have indicated that anyone on here has experience beyond
an embedded system.

Mostly I started this thread because there have been a few with people
discussing implementing NTP on embedded microcontrollers, arduino, etc.
and I was thinking of doing it from the other side (turning a nice-ish
server into a rock-solid timekeeper)

Thanks so far everyone. Really impressed that I already managed to get
4x replies so quickly :)

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.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric, your experiences here is of great interest to me too, I've been
exploring external clocking of Ethernet controllers as of late but
have not dived into it yet.

I'm more interested in your how, but of course also in your why.

// jwalck

PS. Hey everyone, new to this list since two days joining after
attending my first PTTI. Working with time and frequency distribution
in Sweden and with time getting deeper into the field both on and off
work.

On 12/01/2012 01:15 AM, Eric Garner wrote:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQumoZAAoJEFwg9i9GDX+nF10P/jRTK9oCZrPz9e4++FoO9NvN
+THbxwsGpGq8c1OdDDo+1ewbzmRi9SehVPngzq0Lc6rfpEwYCIqnfiM9kWokhJDW
vgRwc4Re/ensYLDpGG+fMxqkKucpNS2UfsqND0xyCK4BGxDMqWbfwyukKGlKAGn+
oFoPX0+QGkgTq8tLs6HxhuSyi1Y1vc3reuZZpFDLqI+7OwwGlTFsTlSzcz2sF9/A
6TV1hcYLOnxwfNPKbSURqz5s2/3rCZf3KnlcTzxr3LLWNKJYcrW795WHpvMIYbC9
me+Oq+24EyJ69Io1ruClxMdi6vU9UC8bU8wy2J27ume4oD2E5JWPr4uY6xXlvYx6
ddkRb+p8K+NwyswNXNa3q+XFwAgsCImOusq9eOL7jc0J7M/NIrJj9GpCgn91/VGd
/ZUpH7nZA7I7Um3uMgXe6zsoKHToyzYu5CtfRkS8INPS/vWfo0X+Ysos1FlfFhQS
kFq306FgBpX5DRhD1e0uKSqMPuGM+Pv5uqB7DeuuY0qJS1H1RvCBatnvt1KAiVSA
vh0z2s3I3Z1FnZE0/LeDSXZS3lDPfT39CdDpKqiEN4P2ifBzJI78v/3IUSykSKor
aC6XHVI2eRbXjop59wcWT2gGt3a1u1uRCSv2MaQ0To8kb/+QMlxUqupqNToYHMFt
UsPHLL5m4bg5+l6669VR
=gybO
-----END PGP SIGNATURE-----

Originally the IBM PC design used an 8253 or 8254 PIT, programmable
interval timer, located at ports 40h to 43h with Timer 0 clocked at
1.193182 MHz (1/3rd of 3.579545 MHz or 1/12th of 14.318 MHz) and set
to divide by 65536 which generated about an 18.2 Hz interrupt rate on
IRQ 0.  Timer 1 generated the since deprecated DRAM refresh clock and
Timer 2 goes to the PC speaker.

Some of the early IBM PC non-compatible hardware implemented a fixed
divisor for Timer 0 which caused problems for software expecting to be
able to reprogram the divider.

I do not know how they generate the 1.193182 MHz PIT clock now.  Early
on they just used an additional oscillator, usually 14.318 MHz, which
was separate from the CPU clock.  I lost interest and started doing
all of my precision timer functions in external hardware when Intel's
SMM, system management mode, started adding unacceptable jitter to
interrupt service routines.

Now of course a variety of higher precision timers are included.
Either the 1.193182 MHz based PIT via interrupt 0 or the 32.768 kHz
based RTC via interrupt 8 can be used to calibrate the CPU timers when
the CPU clock is unknown.

There was a hoax at about the time that the 12 MHz 286 microprocessors
became available where a couple of guys were wiring a small capacitor
across the 32.768 kHz clock crystal causing the RTC to run slow which
caused the CPU clock speed measured via software to appear many times
higher.  Conveniently the wall clock time as measured by the now
slowed RTC showed the same thing.  I remember an interview the guys
gave where they declined to describe their improvements to the 286 but
said the process amounted to collecting groups of instructions and
ramming them through as fast as possible and that it might be feasible
with a 386 as well.

On Sat, 1 Dec 2012 12:34:43 -0700, "Mark Allwright"
mark.allwright@shaw.ca wrote:

On 12/02/2012 01:29 AM, David wrote:

In a modern world, look for things like HPET and TSC:

http://en.wikipedia.org/wiki/High_Precision_Event_Timer
http://en.wikipedia.org/wiki/Time_Stamp_Counter

You want to get a better reference clock to these timers.

Cheers,
Magnus

On Sun, 02 Dec 2012 01:53:07 +0100, Magnus Danielson
magnus@rubidium.dyndns.org wrote:

I only mention and do not go into detail about the higher precision
timers later in my post because by the time they were available,
Intel's system management mode was adding so much jitter than I lost
interest in using PC hardware in applications where they otherwise
might have been useful.  To be fair, not all motherboards and BIOSes
had this problem but it was not worth weeding out the poorly
performing ones.

One of my favorite tricks back when the ISA bus was still available
was to use a custom expansion board I built and an oscilloscope to
measure the interrupt latency.

Jonathan,

My research group has had some good experiences using products from Endace (
http://www.endace.com/) for network timing measurement at the ethernet
level. I don't have a pointer immediately to the work, but if there is
interest can ask tomorrow at work. The gist of it though was to understand
precise timing characteristics of network switches for better simulation.
Examining the time "in switch" for various packets at the microsecond level
was needed to understand various delay curves for different network loads,
with an ultimate goal of proper statistical modeling reflecting reality as
close as possible.

I personally have also used endace products to measure packet timings for
research, but I didn't need so much precision for that work - however I can
say they have a good API and decent tech support for interacting with their
cards and products.

HTH.

Regards,
Erich

On Sat, Dec 1, 2012 at 2:35 PM, Jonatan Walck jwalck@netnod.se wrote:

Erich,

On 12/02/2012 08:54 PM, Erich Heine wrote:

This is a bold challenge, it's a difficult task (clear speak: there is a
reason for this to be a research field, industry never really got it
under control).

Is there native support with Linux kernels?
It would be very nice to have the support using SO_TIMESTAMP and friends.

Cheers,
Magnus

On Sun, Dec 2, 2012 at 3:16 PM, Magnus Danielson <magnus@rubidium.dyndns.org

It is a challenge. I'll have to re evaluate my understanding of the timing
characteristics of the card in light of my new and growing knowledge on
timing. However, this is what I understand now:

I'm sure the timing isn't perfect, but we mitigated some of the potential
clock issues by doing many runs of tests. Further a single endace DAG card
has 2 or 4 network ports on it, so timing can be measured across a network
to the same card with the same reference clock which helps simplify error
source.  (The card has a feature which allows time stamping packets on the
card from that reference clock). Also there is a mechanism by which the
endace cards can be connected directly to each other to synchronize their
clocks to each other, so packet timings across cards can well measured.

I wasn't very involved in the details of the project I'm describing, so I
can't speak to how well any one of those functionalities of the cards
performed, nor how much error we saw or tolerated, I'll ask those folks
later today (as I happen to have a meeting with them about other stuff
anyway :))

One thing I can speak to though, is that in simulation of the type they are
doing - the general granularity of the simulation results are on the order
of 10^-3, so understanding the switches at 10^-6 isn't used directly in the
simulation, but rather to build probability distribution functions that
capture the behavior of the switches well enough to see cumulative results
comparable to observed networking conditions (e.g. the result of N switches
handling serializing events under certain loads will get packet trains like
$X and other loads like $Y and so on). One thing the PI on that project
mentioned was the shape of those functions being correct is the highest
priority. I understand this to mean that the errors "average out" (not an
actual mean, but through some statistics I don't understand all the way yet
they stop being significant compared to other issues).

Perhaps I'll need to point those researchers at this list to find out ways
to better get the timings they want :)

It's been a couple of years since I got deep on this, so I don't remember
details. I do know all the work we've done with the cards was on Linux, and
it worked nicely - I had no issues that were OS related. One thing about
the paradigm for the DAG cards is they are not in the standard networking
stack. They expose themselves from the kernel in a different way via an API
(which Endace provides the source for). To do IP networking with them, you
need to provided your own network stack in userland - however this is out
of the scope of the companies goal. They are really about providing high
speed layer2 access. I believe their primary use cases are research like we
did, and extremely low-latency communications between machines in clusters
(targeting high frequency traders and the like).

I'm an applications engineer for a company that makes Ethernet controllers
and PHYs. Some of our customers use crystals (more often oscillators) that
they selected based on price rather than performance. when i'm debugging a
customer issue replacing the clock source with a synthesizer is a good
troubleshooting aid. I's also useful when trying to prove that a low
quality clock source (or clock distribution network) in a link partner is
producing a poor (usually jittery) output that makes it hard for our parts
to achieve link.

On Fri, Nov 30, 2012 at 5:06 PM, Jim Welch welch20@comcast.net wrote:

--
--Eric

Eric Garner