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, [email protected] wrote: > Send time-nuts mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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? ([email protected]) > 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 <[email protected]> > To: Discussion of precise time and frequency measurement > <[email protected]> > Subject: Re: [time-nuts] TEC party file format? > Message-ID: > <[email protected]> > 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 <[email protected]> > To: Discussion of precise time and frequency measurement > <[email protected]> > Subject: Re: [time-nuts] TEC party file format? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Jun 29, 2011 at 10:54 AM, Hal Murray <[email protected]> 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: [email protected] > To: "Discussion of precise time and frequency measurement" > <[email protected]> > Subject: Re: [time-nuts] TEC party file format? > Message-ID: > <[email protected]> > 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" <[email protected]> > To: "'Discussion of precise time and frequency measurement'" > <[email protected]> > 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: [email protected] [mailto:[email protected]] On > Behalf Of John Pease > Sent: Tuesday, June 28, 2011 11:07 AM > To: [email protected] > 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 -- [email protected] > 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" <[email protected]> > To: "Discussion of precise time and frequency measurement" > <[email protected]> > Subject: Re: [time-nuts] TEC party file format? > Message-ID: <C5CBBD72B83D4DD6B190DBFF2946DB55@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 <[email protected]> > To: Tom Van Baak <[email protected]>, Discussion of precise time and > frequency measurement <[email protected]> > Subject: [time-nuts] Precision PC timing [was TEC party file format?] > Message-ID: > <[email protected]> > 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" <[email protected]> > To: "Discussion of precise time and frequency measurement" > <[email protected]> > Subject: Re: [time-nuts] TEC party file format? > Message-ID: <8AACB1C8350E411A87D74550D3CA338E@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" <[email protected]> > To: "Discussion of precise time and frequency measurement" > <[email protected]> > 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 <[email protected]> > To: Discussion of precise time and frequency measurement <[email protected]> > 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" > <[email protected]> > To: "Discussion of precise time and frequency measurement" > <[email protected]> > 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 -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > > > -------------------------------------------------------------------------------- > > >> _______________________________________________ >> time-nuts mailing list -- [email protected] >> 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 <[email protected]> > To: Discussion of precise time and frequency measurement > <[email protected]> > Subject: Re: [time-nuts] Precision PC timing [was TEC party file > format?] > Message-ID: <[email protected]> > 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 <[email protected]> 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 -- [email protected] >> 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 > [email protected] > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > End of time-nuts Digest, Vol 83, Issue 113 > ****************************************** _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
