[time-nuts] time-nuts Digest, Vol 83, Issue 113
Bill Dailey
docdailey at gmail.com
Wed Jun 29 20:26:09 UTC 2011
I would like a pci card that could be hooked up to an external reference for sound card stability
Sent from my iPhone
On Jun 29, 2011, at 3:02 PM, time-nuts-request at febo.com wrote:
> Send time-nuts mailing list submissions to
> time-nuts at febo.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> or, via email, send a message with subject or body 'help' to
> time-nuts-request at febo.com
>
> You can reach the person managing the list at
> time-nuts-owner at febo.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of time-nuts digest..."
>
>
> Today's Topics:
>
> 1. Re: TEC party file format? (Hal Murray)
> 2. Re: TEC party file format? (Chris Albertson)
> 3. Re: TEC party file format? (bg at lysator.liu.se)
> 4. Re: 53132A counter slow frequency update (Jose Camara)
> 5. Re: TEC party file format? (Tom Van Baak)
> 6. Precision PC timing [was TEC party file format?] (Scott Newell)
> 7. Re: TEC party file format? (Tom Van Baak)
> 8. Re: Precision PC timing [was TEC party file format?]
> (Chris Albertson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 29 Jun 2011 10:54:26 -0700
> From: Hal Murray <hmurray at megapathdsl.net>
> To: Discussion of precise time and frequency measurement
> <time-nuts at febo.com>
> Subject: Re: [time-nuts] TEC party file format?
> Message-ID:
> <20110629175426.B08B2800037 at ip-64-139-1-69.sjc.megapath.net>
> Content-Type: text/plain; charset=us-ascii
>
>
>> How does the pulse trigger the capture ? If some hardware line is polled,
>> how frequent is that polling ? The counter units may well be nanoseconds,
>> but the inherent uncertainty of the polling instant must be taken into
>> account.
>
>> If instead there is no polling, but it is a hardware triggering, then could
>> you please give more details ? Thanks.
>
> The code we are talking about was originally intended to let NTP support PPS
> signals.
>
> The idea is that the kernel grabs a time stamp in the interrupt routine. The
> user can poll or wait for the next event.
>
> The details are in
> RFC 2783 - Pulse-Per-Second API for UNIX-like Operating Systems
> March 2000
> http://www.faqs.org/rfcs/rfc2783.html
>
> Linux and *BSD generally support it. (For Linux, you need a recent kernel.)
> Details may vary. Check the source etc. It's probably an option when
> building the kernel and may not be turned on with the default distribution.
>
> I don't know about Windows.
>
>
>
> --
> These are my opinions, not necessarily my employer's. I hate spam.
>
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 29 Jun 2011 11:28:23 -0700
> From: Chris Albertson <albertson.chris at gmail.com>
> To: Discussion of precise time and frequency measurement
> <time-nuts at febo.com>
> Subject: Re: [time-nuts] TEC party file format?
> Message-ID: <BANLkTin9HTCU3DUB7Z3hjHZzekOOLT5PxA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, Jun 29, 2011 at 10:54 AM, Hal Murray <hmurray at megapathdsl.net> wrote:
>>
>>> How does the pulse trigger the capture ? If some hardware line is polled,
>>> how frequent is that polling ? The counter units may well be nanoseconds,
>>> but the inherent uncertainty of the polling instant must be taken into
>>> account.
>>
>>> If instead there is no polling, but it is a hardware triggering, then could
>>> you please give more details ? Thanks.
>
> The hardware design dates from the old IBM PC in the 1980's The pin
> on the serial port (and one on the old Parallel printer port) is tied
> to a CPU interrupt line. The micro-code inside the Intel chip polls
> this is very high rate, roughly a few GHz. (Actually we don't know if
> it is microcode or clocked logic and it may depend on the exact CPU
> model.)
>
> The interrupt jumps to a small bit of code inside the Kernel. This
> code reads a hardware counter. The count is saved and the units are
> ns. But acuracy is not at the ns level. But is certainly at the sub
> us level.
>
> I suspect all of this happens MUCH faster then you could implement
> using 7400 series TTL logic. The 5ns gate delay of a TTL chip is an
> "eternity" for a modern CPU. Even for me who works with computers
> all the time it's hard to imagine a CPU that can issue multiple
> instructions per cycle with a cycle rate over 3GHz. and I've got
> eight of those processors inside this computer.
>
> The user level program does not need to run in "hard" real time, it
> only has the read each time tag before the next tag is saved. The
> tags are sequence numbered so the user program can see if it missed a
> tag so missing one is not a serious error.
>
> I don't know the final level of accuracy but NTP uses the same system
> for the pulse per second ref. clock and if you take care it can run at
> about the 1uS level with respect to UTC.
>
> Top do better I think you'd need to use one of the HP Universal
> Counters and a GPIB interface or maybe the "Pic Tic II" to measure
> zero crossings. Or maybe some one can build a counter that runs off a
> 10MHz lab standard. But Pic Tic seems to have already do this. So I'd
> say if 1uS is not acceptable then use the external counter
>
> Again, what are the requirements? Can't evaluate a proposed design
> with out knowing what we are looking for.
>
>
> Chris Albertson
> Redondo Beach, California
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 29 Jun 2011 20:50:56 +0200
> From: bg at lysator.liu.se
> To: "Discussion of precise time and frequency measurement"
> <time-nuts at febo.com>
> Subject: Re: [time-nuts] TEC party file format?
> Message-ID:
> <e1655a87ccc012a93638c70a441419c0.squirrel at webmail.lysator.liu.se>
> Content-Type: text/plain;charset=iso-8859-1
>
>>
>>> How does the pulse trigger the capture ? If some hardware line is
>>> polled,
>>> how frequent is that polling ? The counter units may well be
>>> nanoseconds,
>>> but the inherent uncertainty of the polling instant must be taken into
>>> account.
>>
>>> If instead there is no polling, but it is a hardware triggering, then
>>> could
>>> you please give more details ? Thanks.
>>
>> The code we are talking about was originally intended to let NTP support
>> PPS
>> signals.
>>
>> The idea is that the kernel grabs a time stamp in the interrupt routine.
>> The
>> user can poll or wait for the next event.
>>
>> The details are in
>> RFC 2783 - Pulse-Per-Second API for UNIX-like Operating Systems
>> March 2000
>> http://www.faqs.org/rfcs/rfc2783.html
>>
>> Linux and *BSD generally support it. (For Linux, you need a recent
>> kernel.)
>> Details may vary. Check the source etc. It's probably an option when
>> building the kernel and may not be turned on with the default
>> distribution.
>
> It can be done entirely from user space as well. Some years ago I modified
> Jonathan Buzzards radioclkd-shm NTP interface.
>
> http://www.buzzard.me.uk/jonathan/radioclock.html
>
> ***********************
> /* wait till a serial port status change interrupt is generated */
> if (ioctl(fd, TIOCMIWAIT, TIOCM_CD | TIOCM_CTS | TIOCM_DSR)!=0)
> return -1;
> gettimeofday(tv, NULL);
> if (ioctl(fd, TIOCMGET, &arg)!=0)
> return -1;
> ************************
>
> The TIOCMIWAIT ioctl gives the core functionality. As seen above you can
> get (and separate) interrupts from DCD, CTS and DSR-pins on a real serial
> port. All three phases can be timetagged on one serial port. Have not
> tested USB2serials.
>
> Run the test mode - 'radioclkd --test' - and modify the code for your setup.
>
> I tested repetition rates up to 10kHz on an embedded P3 600MHz ULV SBC.
> Timestamps from a GPS locked 100Hz had most better than 10us and >>90%
> better than 100us. Very few outliers up to a few ms error. Kernel was a
> 2.4.30-ish with nano-patches. The SBC was running NTP with kernel mode
> PPS.
>
> --
>
> Bj?rn
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 29 Jun 2011 11:52:09 -0700
> From: "Jose Camara" <camaraq1 at quantacorp.com>
> To: "'Discussion of precise time and frequency measurement'"
> <time-nuts at febo.com>
> Subject: Re: [time-nuts] 53132A counter slow frequency update
> Message-ID: <00ea01cc368d$a6a8f100$f3fad300$@com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Check your cable, or better yet, look at the input signal with a
> oscilloscope. Something is fishy (missing return plus AC couple, too low
> amplitude, etc.).
>
> I used a 33250 generator at 50mVrms and tried going from 80MHz down to 1MHz,
> even 100Hz and it changed the very next gate period every time (one period
> had partial counts, of course).
>
> The 53132A doesn't have the 'green button' that presets it to a known state,
> but it always powers up in the default state.
>
> Your signal might need some special handling - sensitivity, coupling,
> termination?
>
> Finally, if the counter is an 'eBay special', it might be bad. Run self-test
> and follow confidence tests from service manual.
>
> Jose
>
>
> -----Original Message-----
> From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On
> Behalf Of John Pease
> Sent: Tuesday, June 28, 2011 11:07 AM
> To: time-nuts at febo.com
> Subject: [time-nuts] 53132A counter slow frequency update
>
>
>
>
>
>
> Hello,
> ?
> My new to me counter has a strange response when I change the input
> frequency. With the gate set to 1s, I can measure 100 MHz with plenty of
> digits. Then I change the frequency to 1 MHz and it takes several seconds to
> almost a minute for the display to change from 100 MHz to 1 MHz. The delay
> only occurs when I lower the input frequency quite a bit; 100?MHz to 10 MHz
> changes are displayed within 2 gate times.?When I increase the frequency
> form 1 MHz to 100 MHz I always get the correct display after two gate times.
> This delay is proportional to the gate time; the updating is 10 times faster
> with 0.1 s gate time.
> ?
> Is this behavior typical for this counter?
> ?
> Thank you
> ?
> John Pease
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 29 Jun 2011 12:14:48 -0700
> From: "Tom Van Baak" <tvb at LeapSecond.com>
> To: "Discussion of precise time and frequency measurement"
> <time-nuts at febo.com>
> Subject: Re: [time-nuts] TEC party file format?
> Message-ID: <C5CBBD72B83D4DD6B190DBFF2946DB55 at pc52>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> reply-type=original
>
>> I suspect all of this happens MUCH faster then you could implement
>> using 7400 series TTL logic. The 5ns gate delay of a TTL chip is an
>> "eternity" for a modern CPU. Even for me who works with computers
>
> We may be getting OT, but this assertion can't be true. If you
> factor in all the things that affect latency in an intel cpu and
> modern operating system, you'll appreciate why.
>
> Instructions have to be fetched. You may or may not get cache
> hits. There are multiple levels of cache. Multiple cores vying for
> locks at multiple levels of cache and memory. Virtual addresses
> need to be translated. Page tables. TLB misses. Data cache hits
> and misses. DRAM refresh. Instructions executed out of order.
> spin locks. cpu interrupts. bios interrupts. os interrupts. paging.
> swapping. The list goes on.
>
> True, things may happen at the sub-nanosecond inside a GHz
> intel cpu, but the one thing 7400 chips (and microcontrollers)
> have going for them is determinism (low jitter).
>
> If you need both sub-ns and low jitter, then use a TIC (hp 5370,
> SR 620, hp 53132, PICTIC, etc.).
>
> Out of curiosity, if anyone on the list has pointer to papers that
> show actual measurements of desktop systems used as precise
> timing devices let me know. Not external boxes or PCI cards, but
> using the OS itself as a timer. I'm sure with care 1 us or even
> 100 ns is possible. For example, how accurate is the best NTP
> system? But this is still a thousand times more jitter than plain
> logic circuits and a million times worse than specialized TIC's.
>
> Reply off-line, I know this is getting very off-topic.
>
> /tvb
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 29 Jun 2011 14:19:20 -0500
> From: Scott Newell <newell at cei.net>
> To: Tom Van Baak <tvb at LeapSecond.com>, Discussion of precise time and
> frequency measurement <time-nuts at febo.com>
> Subject: [time-nuts] Precision PC timing [was TEC party file format?]
> Message-ID:
> <201106291919.p5TJJMqg029026 at mail959c35.nsolutionszone.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> At 02:14 PM 6/29/2011, Tom Van Baak wrote:
>
>> Out of curiosity, if anyone on the list has pointer to papers that
>> show actual measurements of desktop systems used as precise
>> timing devices let me know. Not external boxes or PCI cards, but
>> using the OS itself as a timer. I'm sure with care 1 us or even
>> 100 ns is possible. For example, how accurate is the best NTP
>> system? But this is still a thousand times more jitter than plain
>> logic circuits and a million times worse than specialized TIC's.
>>
>> Reply off-line, I know this is getting very off-topic.
>
> Please don't take that off-line! I'd say this is pretty on-topic for
> time-nuts. Maybe it just needs a different subject line.
>
> --
> newell N5TNL
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 29 Jun 2011 12:28:46 -0700
> From: "Tom Van Baak" <tvb at LeapSecond.com>
> To: "Discussion of precise time and frequency measurement"
> <time-nuts at febo.com>
> Subject: Re: [time-nuts] TEC party file format?
> Message-ID: <8AACB1C8350E411A87D74550D3CA338E at pc52>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> reply-type=original
>
> Mark,
>
> That will work fine. In your data I see 124 measurements taken
> over half a minute and you're getting about 14 or 15 counts per
> measurement, each one is about 1/4 second. Your PC-based
> time-stamps allow you to mark the time of each measurement
> (or compute interval between N measurements).
>
> There's a hiccup at line 82 and 84 that you might want to debug.
>
> If you subtract the first from the last point you get a nice result:
> delta counts: 1781 - 8 = 1773
> delta time: 29.578 seconds
> which gives 59.94 Hz average frequency during that half minute.
>
> If you write a couple lines of code you can take the data as it's
> being collected, break it into, say, 1 minute or 10 minute chunks
> and plot how frequency varies minute to minute.
>
> To calculate time error, take the (presumably NTP sync'd) PC time
> delta, multiply it by 60 to give the number of cycles you *ideally*
> expect during that interval. Subtract that from the number of cycles
> you *actually* count during the same interval and that's how many
> cycles were gained or lost.
>
> If you then plot that over time (especially over several days) you
> will be impressed at how well the power company does keeping
> TE within a few seconds of zero.
>
> /tvb
>
> ----- Original Message -----
> From: "Mark Spencer" <mspencer12345 at yahoo.ca>
> To: "Discussion of precise time and frequency measurement" <time-nuts at febo.com>
> Sent: Wednesday, June 29, 2011 9:55 AM
> Subject: Re: [time-nuts] TEC party file format?
>
>
> I thought I would try simply feeding a 60 Hz signal from the AC line into a
> counter in totalize mode and logging the output several times a second with time
> stamps. I'll be curious to see how accurate this is.
>
> I've attached a small sample of the data.
>
>
>
> ----- Original Message ----
> From: Tom Van Baak <tvb at LeapSecond.com>
> To: Discussion of precise time and frequency measurement <time-nuts at febo.com>
> Sent: Wed, June 29, 2011 7:53:43 AM
> Subject: Re: [time-nuts] TEC party file format?
>
> Chris,
>
> Sounds good. Somebody that's interested or knows NTP (not me)
> can be the first to set up a mains frequency timed PC, publish
> fancy MRTG plots on the web, and watch the TEC test in July.
>
> Realize this is all just for fun. TEC should have zero impact on
> modern computer networks. The last system I worked with that
> relied on 60 Hz power for timekeeping was a 70's PDP 11/34.
>
> /tvb
>
> ----- Original Message ----- From: "Chris Albertson" <albertson.chris at gmail.com>
> To: "Discussion of precise time and frequency measurement" <time-nuts at febo.com>
> Sent: Tuesday, June 28, 2011 4:06 PM
> Subject: Re: [time-nuts] TEC party file format?
>
>
> The Linux or BSD pulse per second interface is general enough to work for this.
> It does not care if the pulses are one per second or 100 per second, or 60.
>
> Al it does it capture a timmer/counter when a pulse comes in. Then
> fets a flag a user program can read that says "data available". The
> user level programs reads the device ad gets the captured counter
> value, the flag is reset. Very simple and very low overhead.
>
> I think the counter units are nanoseconds
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
>
> --------------------------------------------------------------------------------
>
>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 29 Jun 2011 13:02:13 -0700
> From: Chris Albertson <albertson.chris at gmail.com>
> To: Discussion of precise time and frequency measurement
> <time-nuts at febo.com>
> Subject: Re: [time-nuts] Precision PC timing [was TEC party file
> format?]
> Message-ID: <BANLkTik1-QOp8fC+bhOxsaLCAJ6XZC3+Bg at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> It would be a simple experiment. All you need is a known good square
> wave oscillator that can produce a stable signal at RS232 voltage
> levels.
>
> Linus PPS comes with a test tool that will print the events like this
>
>
> found PPS source "/dev/pps0"
> ok, found 1 source(s), now start fetching data...
> source 0 - assert 1186592699.388832443, sequence: 364 - clear
> 0.000000000, sequence: 0
> source 0 - assert 1186592700.388931295, sequence: 365 - clear
> 0.000000000, sequence: 0
> source 0 - assert 1186592701.389032765, sequence: 366 - clear
> 0.000000000, sequence: 0
>
> The above test shows time of each event and the sequence number.
>
> One would have to import this to a spread sheet or write software but
> not hard core programming required
>
> On Wed, Jun 29, 2011 at 12:19 PM, Scott Newell <newell at cei.net> wrote:
>> At 02:14 PM 6/29/2011, Tom Van Baak wrote:
>>
>>> Out of curiosity, if anyone on the list has pointer to papers that
>>> show actual measurements of desktop systems used as precise
>>> timing devices let me know. Not external boxes or PCI cards, but
>>> using the OS itself as a timer. I'm sure with care 1 us or even
>>> 100 ns is possible. For example, how accurate is the best NTP
>>> system? But this is still a thousand times more jitter than plain
>>> logic circuits and a million times worse than specialized TIC's.
>>>
>>> Reply off-line, I know this is getting very off-topic.
>>
>> Please don't take that off-line! ?I'd say this is pretty on-topic for
>> time-nuts. ?Maybe it just needs a different subject line.
>>
>> --
>> newell ?N5TNL
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
>
>
>
> ------------------------------
>
> _______________________________________________
> time-nuts mailing list
> time-nuts at febo.com
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>
> End of time-nuts Digest, Vol 83, Issue 113
> ******************************************
More information about the time-nuts
mailing list