In article <slrnj9ph83.sve.un...@wormhole.physics.ubc.ca>, unruh <un...@physics.ubc.ca> writes: >On 2011-10-17, Hal Murray <hal-use...@ip-64-139-1-69.sjc.megapath.net> wrote: >> In article <slrnj9oqdj.3i3.un...@wormhole.physics.ubc.ca>, >> unruh <un...@physics.ubc.ca> writes: >> >>>In fact it is really hard for a computer to keep to 1us accuracy because >>>of the delays in interrupt processing. >> >> It's not the delay that is the problem. It's simple to correct for a >> fixed delay. (at least in theory) The problem is variations in the delay. > >Agreed, if only you had some way of knowing what the delay was. But as >you point out, if you did, it would not really be a problem (just as the >light travel down the cable from the GPS to the computer is not really a >problem since it can be calculated easily and thus fixed. Also, it is >usually much much smaller than the other delays.)
You could patch the interrupt code to flap some bits on the printer port and put a scope on them. You could probably write a hack that ran in user mode and flapped a printer port bit at a specified time. I'm thinking of something like wait until x, spin until x+y, read clock, flap bit, read clock. Then print the two clock times. You know the bit flapped somewhere in between them. With a bit of trial and error you could probably capture a good sample on a digital scope and read off the difference between the PPS and the flap. That would let you compute the clock offset. -- These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
