Date: Sun, 2 Jan 2000 17:11:40 -0600 From: Karl Denninger <karl@Denninger.Net> To: Warner Losh <imp@village.org> Cc: current@FreeBSD.ORG Subject: Re: xntpd - VERY old folks, how about updating? :-) Message-ID: <20000102171140.B26048@Denninger.Net> In-Reply-To: <200001022250.PAA31962@harmony.village.org>; from Warner Losh on Sun, Jan 02, 2000 at 03:50:35PM -0700 References: <20000102094459.B22738@Denninger.Net> <8426.946828544@critter.freebsd.dk> <20000102103732.A23004@Denninger.Net> <200001022133.OAA31402@harmony.village.org> <20000102161029.A25883@Denninger.Net> <200001022232.PAA31807@harmony.village.org> <20000102163802.A25936@Denninger.Net> <200001022242.PAA31877@harmony.village.org> <20000102164519.A25992@Denninger.Net> <200001022250.PAA31962@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 02, 2000 at 03:50:35PM -0700, Warner Losh wrote: > In message <20000102164519.A25992@Denninger.Net> Karl Denninger writes: > : Yes, you have HARDWARE timers that do that. > : > : So what? > : > : I'm talking about TIME SERVERS on UNIX machines. > > So am I. > > : You know, ntpd and friends? Yes, that. > > That's one of the things in our application. So what? > : Now explain to me how stability of your timing source ON THOSE MACHINES > : is MATERIALLY different to any process WHICH THAT DEVICE MAY INTERACT WITH > : between 10ns and 1us, AS SEEN FROM THE UNIX MACHINE. > > It is better because the variance in the measurements that we make is > much smaller than 1uS would give. Not possible without custom hardware. The inherent uncertainty in a PPS interface delivered through a parallel port in the interrupt context of a common grade-processor is greater than picosecond claims. Now the *integration* of many of these signals may not be, but the point still holds. That you FLUNKED your first science course where the uncertainty of measurements was discussed, and the boundaries on certainty were laid out, does not change those FACTS. You CANNOT declare a measurement (no matter what it is) to be more precise than the sum of ALL uncertainties in the measurement domain. This is a material FACT, and no amount of posturing changes it. PAYING for precision in a measurement source that is a few orders of magnitude beyond the response windows of what it is connected to is *STUPID*. This includes your claim of anything approaching 10ns resolution on consumer-grade computer hardware. > : I'm simply not interested in NON-GERMANE devices to the discussion; we were > : talking about FreeBSD on REAL computers, not specialty hardware for process > : control or nuclear physics experiments. > > Get a life Karl. I was telling you about my experiences and if you > don't like it, take a chill pill or go play in traffic. > > Warner Go stick your finger in a 220V socket, or sit on whatever Poul uses to do what I asked HIM to do just a few minutes ago. Perhaps that would reduce the population of this group by two people who don't deserve the term "scientist" applied to them. Scientists. BAH! You'd have to flunk first-semester physical science courses to not understand how the boundaries of uncertainty in measurements work, and why buying a reference source that is more precise than the LEAST PRECISE element in your entire measurement chain is almost always a COMPLETE waste of money. If you have two elements in a measurement chain, and one has 10ns repeatability and the other has 10us repeatability, the measurement you obtain is FOR ALL INTENTS AND PURPOSES equivalent to the 10us one. Even if the OTHER timebase is only accurate to 10us, the TOTAL inaccuracy is 20us MAXIMUM. What, Warner, is the INTERRUPT LATENCY (including processing time) specification on a Pentium? You know, the amount of time the chip requires to (1) recognize the INTERRUPT being dragged, (2) save the current context, (3) switch to the interrupt context, and (4) execute the FIRST instructions in that context. Now add to that the ACTUAL gate delays for ALL the gates between your piece of wire and the processor. Then tell me that this sums to ~10ns. You're smoking hard drugs - the processor cannot respond to the interrupt until (potentially) a multi-cycle instruction has been COMPLETED. Further, the act of responding itself requires several MORE cycles, as does the physical act (in the interrupt context) of reading the input latch. In fact, for an ISA parallel port, the speed involved in reading that latch is limited by ISA bus speed! Be careful with the pontification here Warner - some of us actually HAVE done hard real-time work and some of us also know a bit about how MPUs REALLY work in the REAL world. Posturing does NOT work with me on topics like this. You ain't getting no 10ns resolution off any production FreeBSD box without specialized timekeeping hardware that READS the pps output and has its OWN high-precision clock so it can tell the processor how many ticks elapsed from the time IT saw the PPS output until the processor got around to reading the latch. No way in hell. You want to claim otherwise? Fine - show me a gate analysis on the port you connect that clock to (from the wire to the processor's INTERRUPT pin), along with a gate propagation analysis on the processor and the execution path it must take, both worst and best case, from receipt of a signal on the interrupt pin until the FIRST instruction in the handler is executed. Have fun. -- -- Karl Denninger (karl@denninger.net) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000102171140.B26048>