Timekeeping broken on Windows XP with multimedia timer enabled (-M option)
Alan
installed on XP Service Pack 3. NTPD was not only completely unable to
keep the clock in synch but actually made things far worse with time
drifiting backwards by up to a second every few minutes and NTPD
continually stepping the clock forward with the "exceeds 500ppm message".
I then downloaded the pre-built 4.2.6 from Dave Harrt's site and it did
exactly the same. Then I tried turning off the "-M" option and
restarting (both versions). The clock quickly achieved synch to within a
few milliseconds. The drift frequency was calculated at 4.764 (rather
than above 500) and the jitter reduced to a few milliseconds. Now when I
run certain applications the clock jumps by a few millseconds (which the
-M option is supposed to cure but I can live with this under windows)
but my question is why is NTPD broken in my environment when installed
withe the default Meinberg installation option of setting the timer to
highest resolution? Anyone else seen this?
This on a dual core AMD-64 with WIndows XP Professional fully patched.
Alan
> I downloaded the latest prebuilt binary from Meinberg (4.2.4p4)and
Martin Burnicki
By default Windows has a time resolution of 1 timer tick interval only, i.e
about 16 ms with Win XP.
The reference implementation of NTP uses the Windows QueryPerformanceCounter
(QPC) API call to interpolate the time between 2 timer ticks.
The QPC API is implemented in the Windows Hardware Abstraction Layer (HAL)
and uses one of the timers provided by the mainboard and/or the CPU.
If the QPC call works based on the CPU's timestamp counter (TSC) registers
then the value of the current timestamp taken depends on the CPU core on
which the code is executed.
On many types of AMD dual core CPUs the timestamp counters in the individual
cores are not synchronized, so if a piece of code runs alternating on
either CPU core the resulting timestamps may not be consistent, and
computations based on those time stamps yield faulty results.
Also, changes in the CPU clock frequency by AMD's Cool'n'Quiet or Intel's
Speedstep can mess up the QPC results.
A workaround can be to add the USEPMTIMER switch in the boot.ini file. See:
Explanation for the USEPMTIMER switch in the boot.ini
http://blogs.technet.com/perfguru/archive/2008/02/18/explanation-for-the-usepmtimer-switch-in-the-boot-ini.aspx
This forces the QPC API to work using the power management (PM) timer
provided by the mainboard's chipset instead of the CPU's TSC registers.
AFAIK this boot switch should have been set by some XP service pack, but you
may want to check whether this is really the case.
I've written a little tool which can reports clock frequency for the QPC
API:
http://www.meinberg.de/download/utils/windows/wclkres-1.2.zip
Unpack the ZIP archive and run the command
wclkres -p
in a command line window. Please let us know which Performance Counter
Frequency is reported by the command. If the PM timer is used then the
frequency should be about 3.58 MHz. If the frequency matches the CPU's
clock frequency then the CPU's TSCs are used which may cause such bad
behaviour.
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
Alan
I've checked and I have /usepmtimer in boot.ini and wclkres -p reports
Performance Counter Frequency: 3.580
I also have Cool N Quiet turned off in BIOS.
As an experiment I tried seeting affinity to processor 0 and retrying
with the -M switch. No improvement - Jitter is at 100+ millseconds
within a minute and the clock starts being regulaly stepped forward a
few minutes later. With affinity set and without the -M switch I synch
to within a few milliseconds with jitter of a few millseconds almost
immediately. ALthough both offset and jitter jump up by about 20 msec
depending on what I run but then settle down again as I expect under
Windows without -M switch
Overnight (without the -M option) with the system idle and only running
NTPD, both offset and jitter on all configured server clocks dropped to
about 1 msec or less. Again even if the system is "idle" the time drift
rate rockets as soon as -M is turned on.
Anything else I might look at?
Evandro Menezes
wrote:
>
> Also, changes in the CPU clock frequency by AMD's Cool'n'Quiet or Intel's
> Speedstep can mess up the QPC results.
Actually, on systems running Windows XP or later if the HAL deternines
that this is the case, then RDTSC is not used for this function.
HTH
Evandro Menezes
> API:http://www.meinberg.de/download/utils/windows/wclkres-1.2.zip
Or just run this Microsoft tool from the command-line:
\\live.sysinternals.com\tools\clockres
It's also available from http://live.sysinternals.com/Tools/Clockres.exe
HTH
Alan
Max 15.625 ms
Minimum 1.000 ms
Current 15.625 ms
However when I turn -M on the bottom line changes to Current 0.977 ms
Is that really correct as even I can tell 0.977 is less than the
"minimun" 1.000 ms" in the previous line?
David J Taylor
I hope you get this fixed. Here's what you can get with XP with the MM
timer enabled:
Windows XP LAN-synched to a stratum-1 server, 32s poll for local servers,
1024s poll for Internet backup servers:
http://www.satsignal.eu/mrtg/narvik_ntp-b.html
Windows XP acting as a stratum-1 server:
http://www.satsignal.eu/mrtg/feenix_ntp_2.html
Both PCs running "ntpd 4.2.6-o Dec 09 11:48:30.27 (UTC-00:00) 2009 (1)"
from Dave Hart's site. Both PCs have Intel, not AMD processors. Note the
reduced offset on the monthly graphs in week 1 and week 2 - it was so cold
here we kept the heating on 24 hours a day. PC Narvik has been rebooted
about three times since the middle of week 2, hence the three positive
transients.
On PC Narvik, Services Manager, Path to executable is:
C:\Program Files\NTP\bin\ntpd.exe -M -g -c "C:\Program
Files\NTP\etc\ntp.conf"
Now you happen to mention processors, I realise that the PC where the
timekeeping is poor with the more recent versions of NTP (i.e. 4.2.5 and
later) both have AMD processors. Maybe a coincidence?
Cheers,
David
Alan
I get "Frequency error 3030 PPM exceeds tolerance 500 PPM". Considering
that without =M the frequency modification is only about 5 PPM then
obvioulsy something very strange is going on. It seems that even if the
timer precision is increased by another program then time immediately
starts to drift rapidly by hundreds of milliseconds.
David J Taylor
news:Z9I5n.58805$Q36....@newsfe19.ams2...
> Would like to get to the bottom of this as well. Using 4.4.6-o with -M ,
> I get "Frequency error 3030 PPM exceeds tolerance 500 PPM". Considering
> that without =M the frequency modification is only about 5 PPM then
> obvioulsy something very strange is going on. It seems that even if the
> timer precision is increased by another program then time immediately
> starts to drift rapidly by hundreds of milliseconds.
Alan,
Our experience was that the switching between normal and high-resolution
timers caused steps of many milliseconds (I don't recall the exact figure)
which really messed up NTP. So either run with no MM timers at all, or
run with the MM timers permanently enabled, and NTP recognises that
change, and adjusts accordingly. Have NTP start the MM timers was one
solution, and hence the -M option.
It might be helpful to know what the event log says with both sets of
startup parameters, as there may be a clue there which Dave Hart, the
person closest to this code, can interpret.
I must confess to having nagging doubts about AMD (but with no good
reason), about whether you have another program setting the time (check
that w32time.exe is not running - Show Processes from all users), and
perhaps something in the BIOS. One final idea (which there was no option
on my test system) might be to start with just one CPU active in the BIOS.
Cheers,
David
Martin Burnicki
> Thanks for the reply,
>
> I've checked and I have /usepmtimer in boot.ini and wclkres -p reports
> Performance Counter Frequency: 3.580
So your system does indeed use the PM timer to implement the QPC function.
> I also have Cool N Quiet turned off in BIOS.
AFAIK this should only affect the TSCs, so the setting should not matter at
all if the PM timer is used.
> As an experiment I tried seeting affinity to processor 0 and retrying
> with the -M switch. No improvement
That's what I had expected. The affinity should also show an effect if the
TSCs are used for QPC, which is not the case.
> - Jitter is at 100+ millseconds
> within a minute and the clock starts being regulaly stepped forward a
> few minutes later. With affinity set and without the -M switch I synch
> to within a few milliseconds with jitter of a few millseconds almost
> immediately. ALthough both offset and jitter jump up by about 20 msec
> depending on what I run but then settle down again as I expect under
> Windows without -M switch
>
> Overnight (without the -M option) with the system idle and only running
> NTPD, both offset and jitter on all configured server clocks dropped to
> about 1 msec or less. Again even if the system is "idle" the time drift
> rate rockets as soon as -M is turned on.
>
> Anything else I might look at?
We are also using QPC in the driver software for our PCI cards. Quite some
time ago we had a customer who also had timing problems with our driver. it
turned out that the problem was the chipset on the mainboard which returned
inconsistent timestamps.
As you have observed, if you don't use the -M flag system time seems to jump
(20 ms in your case) if some other application sets the multimedia timer to
highest resolution. However, this is just what ntpd does on startup if the
-M switch has been specified. So I'd expect that in your case ntpd runs
stable without -M, but I'm afraid if another app changes the MM timer then
time disciplination will be as poor as with the -M flag specified.
Anyway, I'm actually, out of ideas what you could try to improve the
situation.
Martin Burnicki
> Here's what I see from clockres without the -M option on
>
> Max 15.625 ms
> Minimum 1.000 ms
> Current 15.625 ms
This seems to indicate the internal timer ticks at 15.625 ms interval by
default, but if the MM timer is set to highest resolution the timer tick
changes to 1 ms.
However, under Windows up to XP/Server 2003 the system time returned by the
GetSystemTimeAsFileTime call still increments in 15.625 ms steps even if
the MM timer has been set to 1 ms and thus the internal tick rate has been
increased. You can check this with my wclkres tool.
> However when I turn -M on the bottom line changes to Current 0.977 ms
>
> Is that really correct as even I can tell 0.977 is less than the
> "minimun" 1.000 ms" in the previous line?
I think 1 ms is just the nominal value and 0.977 is due to rounding errors
or an inexact measurement interval.
Martin Burnicki
> "Alan" <grei...@netscape.net> wrote in message
> news:Z9I5n.58805$Q36....@newsfe19.ams2...
>> Would like to get to the bottom of this as well. Using 4.4.6-o with -M ,
>> I get "Frequency error 3030 PPM exceeds tolerance 500 PPM". Considering
>> that without =M the frequency modification is only about 5 PPM then
>> obvioulsy something very strange is going on. It seems that even if the
>> timer precision is increased by another program then time immediately
>> starts to drift rapidly by hundreds of milliseconds.
Yes, looks like timing is seriously broken on your hardware.
Dave Hart, isn't there a way to force disabling time interpolation with your
binaries even if the system time increments in 15.625 ms steps?
Maybe this could be wort a try in this special case.
> Alan,
>
> Our experience was that the switching between normal and high-resolution
> timers caused steps of many milliseconds (I don't recall the exact figure)
> which really messed up NTP. So either run with no MM timers at all, or
> run with the MM timers permanently enabled, and NTP recognises that
> change, and adjusts accordingly. Have NTP start the MM timers was one
> solution, and hence the -M option.
>
> It might be helpful to know what the event log says with both sets of
> startup parameters, as there may be a clue there which Dave Hart, the
> person closest to this code, can interpret.
>
> I must confess to having nagging doubts about AMD (but with no good
> reason),
AFAIK the CPU type (Intel or AMD, CPU family ...) should not matter if the
PM timer is used for QPC instead of the TSCs.
However, as I've mentioned in a different reply, the problem may be due to a
fault chipset.
The Linux kernel identifies quite a number of problematic hardware and
displays appropriate warnings at startup, so booting a current Linux system
(maybe from a Live CD) on that machine and watching the startup messages
*may* give some hints.
> about whether you have another program setting the time (check
> that w32time.exe is not running - Show Processes from all users), and
> perhaps something in the BIOS. One final idea (which there was no option
> on my test system) might be to start with just one CPU active in the BIOS.
I doubt the problem may be due to a different time sync program running
since the problem occurs if and only if the MM timer tick rate is changed.
David J Taylor
> since the problem occurs if and only if the MM timer tick rate is
> changed.
>
> Martin
Agreed, Martin. Just clutching at straws with all the things I have seen
which can cause problems on Windows. Thanks also for your notes on the
different processors and timers. Is:
Performance Counter Frequency: 3.580
a guarantee that the TSC isn't being used?
Cheers,
David
Alan
fairly mainstream manufacturer board with NVIDIA Chipset and onboard
graphics. That or very similar architecture boards are quite widely in use.
I do have a copy of OpenSolaris I stuck on another partition to play
with some time ago so I can install NTPD on it and watch what happens
when I get a chance. Might also try a fresh install of Windows on
another parition to see if I still see the problem.
In the meantime what I've noticed is that if I fire up most multimedia
apps (web browser plugins for example) then the timer resolution gets
set to 1.953 ms or 3.906 ms and in this case NTPD DOES MANAGE TO SYNCH
THE TIME!! (although it drifts a bit before resynching) It seems that it
is only when the timer interval drops to 0.977 ms either set by NTPD or
something else (Windows Media player sets it to this for example) that
we enter a time-warp.
So in summary
Current timer interval: 15.625 ms - No problem
Current timer interval 3.906 ms - No problem
Current timer interval 1.953 ms - No problem
Current timer interval 0.977 ms - Wild time drift
More digging when I get a chance.
Martin Burnicki
> Is:
>
> Performance Counter Frequency: 3.580
>
> a guarantee that the TSC isn't being used?
AFAIK if the TSC is used then the clock frequency reported for QPC matches
the CPU's clock full clock frequency, and IIRC then according to some MS
docs the reported frequency does not even change when the CPU's clock is
decreased for power saving. IMO that also wouldn't make much sense.
From what I've seen the reported QPC clock frequency depends on which timer
circuit is being used. Some months ago I've already posted what I had
found:
http://lists.ntp.org/pipermail/questions/2009-March/022159.html
But of course I can not *guarantee* this is always correct ;-)
In that article there are also some hints which Windows versions / service
packs use which timer to implement QPC. I've just reread that article and
found this perfectly matches what Alan has observed, i.e. Windows XP SP3
should use the PM timer even if no /usepmtimer flag has been added in
Windows' boot.ini.
Of course it does not explain the problems Alan is observing.
Regards,
Dave Hart
> Dave Hart, isn't there a way to force disabling time interpolation with your
> binaries even if the system time increments in 15.625 ms steps?
No, the opposite is available (forcing its use on), but the only way
to disable interpolation is to use ntpd -M on Windows Vista or newer,
where after cranking the multimedia timer to highest resolution, ntpd
will notice the system clock is stepping in less than 4ms increments
and disable interpolation:
if (os_clock_precision < 4 * 10000 && !getenv("NTPD_USE_INTERP_DANGEROUS")) {
msyslog(LOG_INFO, "using Windows clock directly");
} else {
winnt_use_interpolation = TRUE;
It is interesting to me that the brokenness is the same on 4.2.4p8
(which has the old Windows interpolation code) and 4.2.6 (which has
the new interpolation introduced around 4.2.5p162). Both codebases
are trying to do the same thing, maintain a mapping between the
performance counter timeline and the system clock timeline. Since
both are equally hosed, I am relieved to believe it's not indicating a
problem with the new interpolation code.
Although it's a longshot, you can try forcing ntpd to use the
processor TSC instead of QueryPerformanceCounter. To do this, you
need to determine your processor frequency very accurately (and I
can't point to a good tool for that offhand). Then add --pccfreq=X
where X is your processor frequency in Hz. For a nominally 400MHz
space heater of mine, the magic value is --pccfreq=398125000. If you
don't get this within a few PPM of the correct figure, expect ntpd to
go wild immediately. If your TSC rate (CPU frequency essentially)
varies over time, it will break this config. When using the TSC (PCC)
instead of QueryPerformanceCounter, ntpd 4.2.6 will automatically lock
thread affinity to a single processor for threads which use the
counter.
Cheers,
Dave Hart
Martin Burnicki
> I'll try a few experiments. Motherboard is ASRock ALiveNF6p-VSTA, a
> fairly mainstream manufacturer board with NVIDIA Chipset and onboard
> graphics. That or very similar architecture boards are quite widely in
> use.
>
> I do have a copy of OpenSolaris I stuck on another partition to play
> with some time ago so I can install NTPD on it and watch what happens
> when I get a chance.
Remember whether timekeeping works correctly depends at least on:
- which timer circuit is being used
- whether that timer hardware works correctly or not
- whether that timer is handled correctly by the OS, or not
so it's possible OpenSolaris is a perfect timekeeper on that board.
> Might also try a fresh install of Windows on
> another parition to see if I still see the problem.
>
> In the meantime what I've noticed is that if I fire up most multimedia
> apps (web browser plugins for example) then the timer resolution gets
> set to 1.953 ms or 3.906 ms and in this case NTPD DOES MANAGE TO SYNCH
> THE TIME!! (although it drifts a bit before resynching) It seems that it
> is only when the timer interval drops to 0.977 ms either set by NTPD or
> something else (Windows Media player sets it to this for example) that
> we enter a time-warp.
>
> So in summary
>
> Current timer interval: 15.625 ms - No problem
> Current timer interval 3.906 ms - No problem
> Current timer interval 1.953 ms - No problem
> Current timer interval 0.977 ms - Wild time drift
AFAIK the MM timer resolution can be set in 1 ms steps, so the nominal
values for what you've observed should be 4 ms, 2 ms, and 1 ms.
I have not yet had a closer look at the clockres tool from sysinternals
mentioned by Evandro Menezes, but that program just seems to count the MM
timer callbacks during a 15.625 ms system time interval, or vice-versa. See
this computation:
15.625 ms / 16 = 0.97656 ms
clockres shows the same 0.977 ms interval on a Win XP SP3 system here when
ntpd is running with -M. This system has a AMD Athlon 64 X2 4400+ CPU and
ntpd is working fine.
Here are a few thoughts I've also already posted some time ago, see:
http://lists.ntp.org/pipermail/questions/2009-December/025210.html
> Even if under Vista/Windows 7 the system time increments in 1 ms steps,
> the nominal standard tick count is still ~15600 (15601 on a Vista machine
> here), i.e ~15.6 ms. Since this is not an integral multiple of 1 ms there
> must be some math which converts from 1 ms steps to 15.6 ms steps, and
> that math may suffer from rounding errors.
>
> AFAICS this is still the basic problem as under XP or earlier, when the MM
> timer has been set: The MM timer ticks at 1 ms, but the system time ticks
> at 15.625 ms, and there also needs to be a conversion from one tick rate
> to the other.
>
> The difference in Vista/7 vs. 2000/XP seems to be that
> GetSystemTimeAsFiletime returns values from the 1 ms "tick domain" for the
> newer systems whereas it returns values from the 15 ms "tick domain" on
> older systems.
David J Taylor
news:mp2m27-...@gateway.py.meinberg.de...
[]
> AFAIK if the TSC is used then the clock frequency reported for QPC
> matches
> the CPU's clock full clock frequency, and IIRC then according to some MS
> docs the reported frequency does not even change when the CPU's clock is
> decreased for power saving. IMO that also wouldn't make much sense.
>
> From what I've seen the reported QPC clock frequency depends on which
> timer
> circuit is being used. Some months ago I've already posted what I had
> found:
> http://lists.ntp.org/pipermail/questions/2009-March/022159.html
>
> But of course I can not *guarantee* this is always correct ;-)
>
> In that article there are also some hints which Windows versions /
> service
> packs use which timer to implement QPC. I've just reread that article
> and
> found this perfectly matches what Alan has observed, i.e. Windows XP SP3
> should use the PM timer even if no /usepmtimer flag has been added in
> Windows' boot.ini.
>
> Of course it does not explain the problems Alan is observing.
>
>
> Regards,
>
> Martin
Thanks, Martin. I'm beginning to wish I'd never asked, as I have Windows
XP SP3 here and yet the performance counter is running at 2.4GHz (Intel
E6600 dual-core). Or does the PM_Timer only apply to AMD systems?
The AMD Vista and Windows-7 desktop systems show 3.579...MHz, an Intel
Windows-7 portable 1.757MHz (PIT?), an Intel Vista portable 14.3MHz
(HPET), and an Intel Windows Vista Desktop 14.3MHz.
All frequencies you listed, and nothing which helps Alan. Seemed to have
a peculiar timer resolutions though - I never seen 3.906 ms or 1.953 ms.
What software is setting those?
Cheers,
David
Evandro Menezes
wrote:
> AFAIK this should only affect the TSCs, so the setting should not matter at
> all if the PM timer is used.
Another detail on RDTSC: newer cores, such as Intel's Core2 and AMD's
Phenom, return a constant-rate readout by RDTSC. In actuality, the
counter that RDTSC is driven by the FSB clock instead of by the CPU
clock and, even if the later changes due to power management, it's
adjusted accordingly.
But it all boils down to the HAL, which will use whatever's necessary
to make sure that what QueryPerformanceCounter returns is independent
of the CPU clock.
HTH
Evandro Menezes
this-bit.and-this-part.co.uk.invalid> wrote:
>
> Thanks, Martin. I'm beginning to wish I'd never asked, as I have Windows
> XP SP3 here and yet the performance counter is running at 2.4GHz (Intel
> E6600 dual-core). Or does the PM_Timer only apply to AMD systems?
Windows chooses the most precise, invariant frequency source available
in the system. As I said before, Intel's Core2 processors have a TSC
that doesn't vary with the CPU clock (though its precision is not as
good as it seems). Only newer AMD processors sport the same feature
and even then it must be enabled by a BIOS option that's not always
available. Therefore, the likelihood of an AMD system using the PM
timer is greater than new Intel systems.
In these days, it's moot to worry about the precision of the
QueryPerformanceCounter function. Windows will use the most precise
time source in the system and only very old systems would not have at
least the PM timer.
HTH
Martin Burnicki
> On Jan 21, 4:43ï¿œam, Martin Burnicki <martin.burni...@meinberg.de>
> wrote:
>> AFAIK this should only affect the TSCs, so the setting should not matter
>> at all if the PM timer is used.
>
> Another detail on RDTSC: newer cores, such as Intel's Core2 and AMD's
> Phenom, return a constant-rate readout by RDTSC. In actuality, the
> counter that RDTSC is driven by the FSB clock instead of by the CPU
> clock and, even if the later changes due to power management, it's
> adjusted accordingly.
Ah, that's interesting. I did know that new CPU cores may not suffer from
switched CPU clocks anymore, but I didn't know this is because they are
driven by the FSB clock. So I assume the QPC clock frequency reported by
Windows can also correspond to the FSB clock.
> But it all boils down to the HAL, which will use whatever's necessary
> to make sure that what QueryPerformanceCounter returns is independent
> of the CPU clock.
There may still be limitations depending on the age of specific items, e.g.
the HAL can only decide which timer to use if the pros and cons of the
timers have been known to the programmers, and appropriate code has been
integrated into the HAL, when the specific HAL version was released.
Anyway, thanks for the hints.
Rob
>> Is that really correct as even I can tell 0.977 is less than the
>> "minimun" 1.000 ms" in the previous line?
>
> I think 1 ms is just the nominal value and 0.977 is due to rounding errors
> or an inexact measurement interval.
I thought the timer interval was 1/1024 Hz?
Rob
David J Taylor
> in the system. As I said before, Intel's Core2 processors have a TSC
> that doesn't vary with the CPU clock (though its precision is not as
> good as it seems). Only newer AMD processors sport the same feature
> and even then it must be enabled by a BIOS option that's not always
> available. Therefore, the likelihood of an AMD system using the PM
> timer is greater than new Intel systems.
>
> In these days, it's moot to worry about the precision of the
> QueryPerformanceCounter function. Windows will use the most precise
> time source in the system and only very old systems would not have at
> least the PM timer.
>
> HTH
Evandro, thanks for the details. I've never worried about the precision
of the QueryPerformanceCounter function in my own software, I'm just
reporting the values as a clue to why we see NTP behaving as it does.
BTW: I still have systems running which are older than Core2, on still has
an Intel PIII 550MHz (and keeps good time as a stratum-1 server with
Windows 2000).
Cheers,
David
Terje Mathisen
> Alan wrote:
>>
>> Is that really correct as even I can tell 0.977 is less than the
>> "minimun" 1.000 ms" in the previous line?
>
> I think 1 ms is just the nominal value and 0.977 is due to rounding errors
> or an inexact measurement interval.
Timer ticks on most versions of Win* are derived from the CMOS clock
chip which can generate interrupts at any power of two rate, from 1 Hz
to 32 KHz.
1024 Hz corresponds to ~977 us.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
Martin Burnicki
> Martin Burnicki wrote:
>> Alan wrote:
>>> However when I turn -M on the bottom line changes to Current 0.977 ms
>>>
>>> Is that really correct as even I can tell 0.977 is less than the
>>> "minimun" 1.000 ms" in the previous line?
>>
>> I think 1 ms is just the nominal value and 0.977 is due to rounding
>> errors or an inexact measurement interval.
>
> Timer ticks on most versions of Win* are derived from the CMOS clock
> chip which can generate interrupts at any power of two rate, from 1 Hz
> to 32 KHz.
Ah, I know the features of the CMOS clock chip but I haven't been aware this
chip is used to generate the timer tick IRQs.
> 1024 Hz corresponds to ~977 us.
Yep, and 64 Hz corresponds to 15.625 ms, the default system time increment
up to Windows XP.
Under Vista the clockres tool from sysinternals shows:
Maximum timer interval: 15.600 ms
Minimum timer interval: 0.500 ms
Current timer interval: 1.000 ms
So Vista seems to use a different timer for the timer tick, maybe the HPET
which is also used for QPC under Vista?
Evandro Menezes
wrote:
> Ah, that's interesting. I did know that new CPU cores may not suffer from
> switched CPU clocks anymore, but I didn't know this is because they are
> driven by the FSB clock. So I assume the QPC clock frequency reported by
> Windows can also correspond to the FSB clock.
Only indirectly. You certainly know that the CPU clock is a multiple
of the FSB clock. The unit of the result returned by RDTSC is still
CPU clock ticks, always. So, when the CPU clock multiplier is changed
from, say, 3.5 to 1.0, due to a power management decision, the TSC
circuitry is changed accordingly, so that its unit is the same as the
CPU's. The result is that when measuring the CPU clock, one will
still get it right.
However, the precision of the TSC is not 1 CPU clock tick anymore, but
the FSB multiplier. So it cannot be used so easily to measure how
many CPU clock cycles a sequence of instructions takes anymore.
AFAIK, on AMD processors it's still possible to chose between variant
and invariant TSC. But I think that the tendency is for BIOS makers
to not offer this option and just enable the invariant TSC, since only
developers care about its precision (and they can use a performance
counter for the same purpose).
HTH
Evandro Menezes
this-bit.and-this-part.co.uk.invalid> wrote:
>
> BTW: I still have systems running which are older than Core2, on still has
> an Intel PIII 550MHz (and keeps good time as a stratum-1 server with
> Windows 2000).
I guess that it would qualify for a low-power processor these days, so
who cares about managing its power and messing with its TSC?
;-)
David J Taylor
news:b3618b89-24cd-44a9...@f12g2000yqn.googlegroups.com...
> On Jan 21, 2:52 pm, "David J Taylor" <david-tay...@blueyonder.delete-
> this-bit.and-this-part.co.uk.invalid> wrote:
>>
>> an Intel PIII 550MHz (and keeps good time as a stratum-1 server with
>> Windows 2000).
>
> I guess that it would qualify for a low-power processor these days, so
> who cares about managing its power and messing with its TSC?
>
> ;-)
Low-power in what sense? Work done, or watts consumed? <G>
I would still very much like to have a low-powered (watts) system running
NTP perhaps with a good (for timekeeping) FreeBSD version. Something the
size of a home router, with a serial port for the GPS. Looking for better
than (say) ten microsecond accuracy. About US $100-150.
Cheers,
David
Uwe Klein
For Fiddle a Bit:
There is a wide spectrum of hardware available.
Take any of the Low Cost Thin clients ( Linux on ARM )
Take any of the "InternetRadio" sets ( same, Linux on ARM )
Take any of the Low Cost Router/WlanAccessPoint Hardware that
can have OpenWRT or similar installed. ( Linux on usually ARM )
http://en.wikipedia.org/wiki/List_of_router_or_firewall_distributions
Some even have ntpd in their package repository ;-)
uwe
David J Taylor
"Uwe Klein" <uwe_klein_...@t-online.de> wrote in message
news:r91037-...@klein-habertwedt.de...
> David J Taylor wrote:
[]
>> I would still very much like to have a low-powered (watts) system
>> running NTP perhaps with a good (for timekeeping) FreeBSD version.
>> Something the size of a home router, with a serial port for the GPS.
>> Looking for better than (say) ten microsecond accuracy. About US
>> $100-150.
>>
> Unpack and Work or Fiddle a Bit ?
>
> For Fiddle a Bit:
> There is a wide spectrum of hardware available.
> Take any of the Low Cost Thin clients ( Linux on ARM )
> Take any of the "InternetRadio" sets ( same, Linux on ARM )
>
> Take any of the Low Cost Router/WlanAccessPoint Hardware that
> can have OpenWRT or similar installed. ( Linux on usually ARM )
> http://en.wikipedia.org/wiki/List_of_router_or_firewall_distributions
> Some even have ntpd in their package repository ;-)
>
> uwe
Thanks for that, Uwe. Ideally, unpack and work!
A lot of hardware either doesn't have the serial port, or is grossly
over-priced (as it may be intended for "industrial" applications).
I think I would want a ready-to-run NTP, as I don't "do" Linux. Something
configurable via a Web interface.
Routers would indeed be a good choice, but there are hundreds! Someone
must have already researched the possibilities and be able to advise
models with a serial port and quality NTP?
Cheers,
David
Martin Burnicki
> On Jan 21, 10:42ï¿œam, Martin Burnicki <martin.burni...@meinberg.de>
Yes, it helps indeed ;-)
Interesting details I didn't know, yet.
Thanks,
David Lord
Not yet using this but have a 20 quid+vat router type board here
from Omnima.co.uk that has ADM5120P chip, wan + 4xlan ethernet,
2xusb but serial need some wiring. Will run Linux and can be
supplied with Squidge on CD, also for me will run NetBSD. Bit on
top end for power
There's also an ARM based device for under 30quid that will run
from power via USB connection, but wouldn't be as easy to get
going for what I need although with more onboard flash and ram.
Google for "bifferboard"
! Bifferboard. 150MHz CPU, Intel 486SX instruction set,
! MMU. 1 watt power consumption (200mA @5v);
! 68mm x 28mm x 21mm (weight 28g); 32MB SDRAM/8MB Flash
I was worried that SX might be npu deficient and may cause
problems. Both my 486sx have addon 486dx for npu.
David
Richard B. Gilbert
I think that that the closest you can come "off the shelf" would be a
Laptop. You are not likely to find one in that price range.
PHK has created GPS clocks using a "single board computer" and a GPS
receiver. I don't know what it cost him. See:
http://phk.freebsd.dk/soekris/pps/
Richard B. Gilbert
Routers usually do not make good GPS clocks! If they are functioning as
routers they have work to do and time keeping is not a priority.
Used computers (X86) are available for free if you don't mind "dumpster
diving" for them. You can run Solaris on one. Solaris, is not Linux
but it looks like Linux and uses something close to the Linux command
line interface. You may find that it's better documented than Linux.
It's a commercial O/S and supported by the vendor. Support, if you need
it, will cost you money.
If your objection to Linux is based on the user interface and/or the
libraries and tools you are probably "SOL"; the only viable alternative
is some flavor of Windows!
NTP is pretty much the same no matter what platform you run it on. The
O/S vendor may add a coat of paint or some bells and whistles but that's
probably the ONLY difference.
David J Taylor
news:YeedncqVudBjKcDW...@giganews.com...
[]
> I think that that the closest you can come "off the shelf" would be a
> Laptop. You are not likely to find one in that price range.
I'm not happy about leaving a laptop on 24 hours a day, in any case.
> PHK has created GPS clocks using a "single board computer" and a GPS
> receiver. I don't know what it cost him. See:
> http://phk.freebsd.dk/soekris/pps/
Thanks for your pointer, Richard. He mentions US $220. I don't suppose
he'd want to ship a pre-configured unit, though. It's certainly close.
Cheers,
David
John Hasler
> Routers usually do not make good GPS clocks! If they are functioning
> as routers they have work to do and time keeping is not a priority.
I think the idea is to buy a router because it is cheap hardware but to
use it only to run NTP.
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA
David J Taylor
[]
> Routers usually do not make good GPS clocks! If they are functioning as
> routers they have work to do and time keeping is not a priority.
Indeed! I was thinking of the router just as a source of low-cost, ready
to run hardware, with a completely different OS.
> Used computers (X86) are available for free if you don't mind "dumpster
> diving" for them. You can run Solaris on one. Solaris, is not Linux
> but it looks like Linux and uses something close to the Linux command
> line interface. You may find that it's better documented than Linux.
>
> It's a commercial O/S and supported by the vendor. Support, if you need
> it, will cost you money.
I already have a FreeBSD PC which I would run, but I wanted a much lower
power, and small form factor device.
> If your objection to Linux is based on the user interface and/or the
> libraries and tools you are probably "SOL"; the only viable alternative
> is some flavor of Windows!
I have no objection to Linux as such (although I read that FreeBSD may be
better), just that I am very unfamiliar with it, hence would most likely
need a pre-built OS. If loading the OS is a matter of FTP from Windows,
or were configuring the OS a matter of using a Web-style interface to the
box, I could comfortably manage that. I /did/ use the command-line when
setting up the FreeBSD box, and I could certainly follow instructions for
that.
> NTP is pretty much the same no matter what platform you run it on. The
> O/S vendor may add a coat of paint or some bells and whistles but that's
> probably the ONLY difference.
Fair enough, Richard. Interesting to have your thoughts.
Cheers,
David
David J Taylor
news:7s5qdo...@mid.individual.net...
[]
> Not yet using this but have a 20 quid+vat router type board here
> from Omnima.co.uk that has ADM5120P chip, wan + 4xlan ethernet,
> 2xusb but serial need some wiring. Will run Linux and can be
> supplied with Squidge on CD, also for me will run NetBSD. Bit on
> top end for power
That looks very neat - you could get the enclosure from them, and perhaps
the power adaptor as well. I do wonder, though, whether by the time
you've bought that, you might have paid as much as for a low-end router?
> There's also an ARM based device for under 30quid that will run
> from power via USB connection, but wouldn't be as easy to get
> going for what I need although with more onboard flash and ram.
> Google for "bifferboard"
>
> ! Bifferboard. 150MHz CPU, Intel 486SX instruction set,
> ! MMU. 1 watt power consumption (200mA @5v);
> ! 68mm x 28mm x 21mm (weight 28g); 32MB SDRAM/8MB Flash
>
> I was worried that SX might be npu deficient and may cause
> problems. Both my 486sx have addon 486dx for npu.
>
>
> David
Now the "bifferboard" is exceptionally neat! Would hang off the back of a
PC or could be powered from my existing power box for the GPS 18 LVC. You
get something like that working with the GPS 18 and you could sell me one!
(Or one of the Omnima boxed and ready to go). Noted about the lack of
numeric co-processor, though.
Cheers,
David
Uwe Klein
> Routers usually do not make good GPS clocks! If they are functioning as
> routers they have work to do and time keeping is not a priority.
You don't have to use the hardware for routing.
But is is the cheapest solution imho for
a system complete with wallwart and enclosure.
For OpenWRT which seems to be rather versatile
you get a wide range of supported hardware:
http://oldwiki.openwrt.org/TableOfHardware.html
Or some "Internet Radio" platform:
http://internetradiohack.blogspot.com/
uwe
Evandro Menezes
wrote:
>
> Yes, it helps indeed ;-)
I'm glad it does.
And just for completion, the current generation of AMD processors
derive the CPU clock from the memory controller clock instead of the
FSB. Moreover, the memory controller clock may also be changed on the
fly and is thus subject to power management policies too, effectively
making its TSC not invariant if the memory controller power is
managed. However, I don't know of any OS that does this yet.
Terje Mathisen
> Richard B. Gilbert wrote:
>> Routers usually do not make good GPS clocks! If they are functioning
>> as routers they have work to do and time keeping is not a priority.
>
> You don't have to use the hardware for routing.
> But is is the cheapest solution imho for
> a system complete with wallwart and enclosure.
The canonical DIY ntp server would be to base them on phk's choice, the
Soekris single-board computer:
http://phk.freebsd.dk/soekris/pps/
Since this board has a hw counter capable of accurately timing the PPS
signals,Poul-Henning got it to run at sub-us accuracy, using a cheap
timing GPS.
Jan Ceuleers
> The canonical DIY ntp server would be to base them on phk's choice, the
> Soekris single-board computer:
>
> http://phk.freebsd.dk/soekris/pps/
>
> Since this board has a hw counter capable of accurately timing the PPS
> signals,Poul-Henning got it to run at sub-us accuracy, using a cheap
> timing GPS.
A few more points:
- It does not explicitly say so at the page above, but the Soekris model that Poul-Henning used was the 4501. I've only got 4801s and they're not as good for timing.
- The results shown on the above page are of a 4501 that has been significantly hacked by adding a Rubidium oscillator to the mix. Not for the faint hearted and not cheap either.
- The net4501 costs �136 for the board and case. Add �15 for the power supply. Then add around �100 for a GPS riming receiver and another $1700 for the Rubidium standard. Admittedly the latter is optional if your needs are modest.
Cheers, Jan
John Ackermann N8UR
> Terje Mathisen wrote:
>> The canonical DIY ntp server would be to base them on phk's choice, the
>> Soekris single-board computer:
>>
>> http://phk.freebsd.dk/soekris/pps/
>>
>> Since this board has a hw counter capable of accurately timing the PPS
>> signals,Poul-Henning got it to run at sub-us accuracy, using a cheap
>> timing GPS.
>
> A few more points:
>
> - It does not explicitly say so at the page above, but the Soekris model that Poul-Henning used was the 4501. I've only got 4801s and they're not as good for timing.
>
> - The results shown on the above page are of a 4501 that has been significantly hacked by adding a Rubidium oscillator to the mix. Not for the faint hearted and not cheap either.
>
You're right that the hardware hacks (documented on my web site at
http://www.febo.com/pages/soekris) aren't for the faint-hearted. I'd
like to stress, though, that you don't need an expensive Rubidium or
Cesium standard to make a noticeable improvement in timekeeping,
particularly short-term response to things like ambient temperature
changes. An inexpensive (<$20) temperature compensated crystal
oscillator (TCXO) will be significantly better than the stock crystal on
the Soekris (or any other PC).
The quality of the oscillator will impact stability over time periods
shorter than NTP's loop time constant, but will have no effect over
longer time intervals where NTP steers the clock. The basic idea is
that *anything* will be more stable than the crystal on the motherboard.
BTW -- if you get a TXCO operating directly at 33.333 MHz, you don't
need the "ClockBlock" board either, which saves $70 over the
configuration shown in my article.
And if you can live with a surplus solution, there are tons of LPRO-101
Rubidium oscillators available on eBay for less than $100. They require
soldering to interface, but if you're already hacking a Soekris board,
the wiring is trivial.
John
Maarten Wiltink
news:4b5dda15$0$2866$ba62...@news.skynet.be...
[...]
> - It does not explicitly say so at the page above, but the Soekris model
> that Poul-Henning used was the 4501. I've only got 4801s and they're not
> as good for timing.
Why did you get 4801s? I recall reading here that the 4501 was no longer
for sale, but Soekris' own website offers them.
Groetjes,
Maarten Wiltink
Richard B. Gilbert
The only way to be sure he will or will not sell a pre-configured unit
is to ask him.
Richard B. Gilbert
> Richard B. Gilbert writes:
>> Routers usually do not make good GPS clocks! If they are functioning
>> as routers they have work to do and time keeping is not a priority.
>
> I think the idea is to buy a router because it is cheap hardware but to
> use it only to run NTP.
If you are talking about REAL routers, they are not cheap. If you are
talking about SOHO routers such as sold by LinkSys they are cheap enough
but building NTPD to run on one might be fairly difficult.
Just about any PC built in the last ten years should be able to run
Solaris or Linux and serve time using a GPS reference clock.
E-Mail Sent to this address will be added to the BlackLists
> I would still very much like to have a low-powered (watts)
> system running NTP perhaps with a good (for timekeeping)
> FreeBSD version. Something the size of a home router,
> with a serial port for the GPS. Looking for better
> than (say) ten microsecond accuracy. About US $100-150.
<http://www.veracityuk.com/products/timenet/timenet.php>
<http://www.veracityusa.com/products/timenet/timenet.php>
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
E-Mail Sent to this address will be added to the BlackLists
> David J Taylor wrote:
>> I would still very much like to have a low-powered (watts)
>> system running NTP perhaps with a good (for timekeeping)
>> FreeBSD version. Something the size of a home router,
>> with a serial port for the GPS. Looking for better
>> than (say) ten microsecond accuracy. About US $100-150.
>
> <http://www.veracityuk.com/products/timenet/timenet.php>
> <http://www.veracityusa.com/products/timenet/timenet.php>
<http://www.gpsntp.com/economic-ntpserver/>
John Hasler
> If you are talking about REAL routers, they are not cheap. If you are
> talking about SOHO routers such as sold by LinkSys they are cheap
> enough but building NTPD to run on one might be fairly difficult.
Should be quite straightforward to get Chrony or Ntpd running on one the
SOHO routers on which Linux can be installed.
Hal Murray
"David J Taylor" <david-...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid> writes:
>I have no objection to Linux as such (although I read that FreeBSD may be
>better), just that I am very unfamiliar with it, hence would most likely
>need a pre-built OS. If loading the OS is a matter of FTP from Windows,
>or were configuring the OS a matter of using a Web-style interface to the
>box, I could comfortably manage that. I /did/ use the command-line when
>setting up the FreeBSD box, and I could certainly follow instructions for
>that.
At that level, FreeBSD, Linux, and NetBSD are all close enough that
if you can install and run one of them, you can also handle the others.
I think there are two steps. One is to find the web page with step-by-step
directions with enough details. (and not so many deails that you get
lost in the fine print) I expect somebody here will answer questions
(off line?) if you need clarification.
The other is to learn enough about the system so you can keep
it running happily. I think that's easy enough, but it isn't well
defined. Again, people here will probably help if/when you need it.
There are probably other newsgroups/forums/mailing-lists/whatevers.
--
These are my opinions, not necessarily my employer's. I hate spam.
E-Mail Sent to this address will be added to the BlackLists
> Richard B. Gilbert writes:
>> If you are talking about REAL routers, they are not cheap.
>> If you are talking about SOHO routers such as sold by
>> LinkSys they are cheap enough but building NTPD to run
>> on one might be fairly difficult.
>
> Should be quite straightforward to get Chrony or Ntpd
> running on one the SOHO routers on which Linux can be
> installed.
Seems active
<http://www.google.com/search?q=Chrony+2010+site:openwrt.org>
<http://www.google.com/search?q=NTPd+2010+site:openwrt.org>
unruh
> John Hasler wrote:
>> Richard B. Gilbert writes:
>>> If you are talking about REAL routers, they are not cheap.
>>> If you are talking about SOHO routers such as sold by
>>> LinkSys they are cheap enough but building NTPD to run
>>> on one might be fairly difficult.
>>
>> Should be quite straightforward to get Chrony or Ntpd
>> running on one the SOHO routers on which Linux can be
>> installed.
>
> Seems active
><http://www.google.com/search?q=Chrony+2010+site:openwrt.org>
><http://www.google.com/search?q=NTPd+2010+site:openwrt.org>
>
David J Taylor
>> <http://www.veracityusa.com/products/timenet/timenet.php>
>
> <http://www.gpsntp.com/economic-ntpserver/>
Thanks, most interesting - I knew about neither of those products.
http://www.veracityuk.com/products/timenet/timenet.php
"Accuracy: Ethernet NTP �100ms overall" is not what I call "good
timekeeping".
http://www.gpsntp.com/economic-ntpserver/
"NTP time stamp resolution: +/- 15 usec" - nice that it has SNMP, but no
specification of accuracy!
You can't buy directly from either site, which discourages an impulse
purchase.
I already have the GPS, and was looking for a simple computer (small and
low-powered) where I could run a FreeBSD or similar system. Will see what
emerges from the router or David Lord's approaches.
Cheers,
David
Martin Burnicki
> On Jan 25, 8:15ï¿œam, Martin Burnicki <martin.burni...@meinberg.de>
Argh, I just began to hope things could become easier in the future. I'm
sure the OS maintainers will find a way to fiddle with this to degrade
timekeeping ;-)
Uwe Klein
> If you are talking about REAL routers, they are not cheap. If you are
> talking about SOHO routers such as sold by LinkSys they are cheap enough
> but building NTPD to run on one might be fairly difficult.
OpenWRT and similar Linux Distributions have binary packages for ntpd.
( And it is not much hassle to set up a crossbuild environment.
Well if you are on windows : SOL )
>
> Just about any PC built in the last ten years should be able to run
> Solaris or Linux and serve time using a GPS reference clock.
Those small ARM platforms take about 10W,
$ANY x86 PC takes about 100++W.
Occupied "real estate" is quite different too.
uwe
Uwe Klein
OpenMoko's FreeRunner Hardware could be interesting.
GPS, WLAN, USB-Net on Board ( Arm platform, ntpd works out of the box ).
http://wiki.openmoko.org/wiki/Neo_FreeRunner_GTA02_Hardware
uwe
David Lord
I've moved away from using ntp over ethernet as main method
for keeping systems in sync. Network and system load along
with temperature variations cause relative havoc which I'll
see if I can cure using pps from the radioclock. It could
be possible to stabilise system clock oscillators but I'm
not sure if that is effective or practical on modern pcs and
it really involves too much work vs pps via parallel port
(last system I purchased has neither serial nor parallel).
The ADM5120P may become base for generating a pps signal to be
distributed around network via rs422 and possibly 433MHz tx/rx
if that doesn't add too much variation. I'm not sure my
programming skills are up to this though.
I also have a 486dx with a very stable (at least long term)
crystal but lacking ram (I still have another 3x 486 but only
40MB ram total to split between four pcs).
My order for some D25 connectors from CPC turned up on Friday,
D25 hoods + all the extra items I'd added to take value up to
give free delivery, but stock discrepancy and no D25 bodies.
Anyway I had a search through my rubbish last night and found
a couple of connectors.
Meanwhile due to cold weather I've had heating turned up and
server using Conrad MSF receiver has had periods of much
reduced offsets (< 300us), so suspicion that the ttl out from
Conrad is on borderline for the rs232 on that server seems
confirmed and I'll give parallel port method a try on a
different system later this week.
David
Jan Ceuleers
> Why did you get 4801s? I recall reading here that the 4501 was no longer
> for sale, but Soekris' own website offers them.
I didn't get them specifically for timing purposes, but rather to act as a platform on which to build my own access routers (with added DSL and wifi peripherals). Not the cheapest way of doing that (which would be to get a Linksys box and run openwrt), but fun nonetheless.
Jan
E-Mail Sent to this address will be added to the BlackLists
David J Taylor
<Nu...@BlackList.Anitech-Systems.invalid> wrote in message
news:hjnmt9$q95$1...@news.eternal-september.org...
[]
> <http://www.marvell.com/platforms/plug_computer/>
Thanks for that. Interesting, as it seems that you /may/ be able to get
access to a serial I/O (needed for the GPS) according to the diagram here:
http://www.marvell.com/platforms/Marvell_PlugComputer_DevKit.pdf
I wonder whether anyone has ported NTP to this platform, and what accuracy
they have seen?
David
David Malone
>Thanks for that. Interesting, as it seems that you /may/ be able to get
>access to a serial I/O (needed for the GPS) according to the diagram here:
> http://www.marvell.com/platforms/Marvell_PlugComputer_DevKit.pdf
>I wonder whether anyone has ported NTP to this platform, and what accuracy
>they have seen?
I believe FreeBSD has been ported to that platform:
http://wiki.freebsd.org/FreeBSD/arm
Though I'm not sure of the exact status of the port. Warner would
probably know.
David.
E-Mail Sent to this address will be added to the BlackLists
> BlackLists wrote:
>> <http://www.marvell.com/platforms/plug_computer/>
>
> Thanks for that. Interesting, as it seems that you /may/
> be able to get access to a serial I/O (needed for the GPS)
> according to the diagram here:
>
> <http://www.marvell.com/platforms/Marvell_PlugComputer_DevKit.pdf>
>
> I wonder whether anyone has ported NTP to this platform,
> and what accuracy they have seen?
Seems implied by this:
<http://www.plugcomputer.org/plugwiki/index.php/Frequently_Asked_Questions#The_time_is_wrong.2C_and_when_I_tried_using_ntpdate_it_could_not_find_the_ntp_servers_on_the_web.>
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
E-Mail Sent to this address will be added to the BlackLists
> BlackList wrote in message
>> <http://www.marvell.com/platforms/plug_computer/>
>
> Thanks for that. Interesting, as it seems that you /may/
> be able to get access to a serial I/O (needed for the GPS)
> according to the diagram here:
> <http://www.marvell.com/platforms/Marvell_PlugComputer_DevKit.pdf>
>
> I wonder whether anyone has ported NTP to this platform,
> and what accuracy they have seen?
<http://plugcomputer.org/plugforum/index.php?PHPSESSID=52733b6b94aef4c469fccaabb98b52e4&topic=912.msg6855#msg6855>
notjeff: "I just recently setup my sheevaplug as a stratum-1 NTP server."
<http://tinyurl.com/yf7684o>
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
David J Taylor
> notjeff: "I just recently setup my sheevaplug as a stratum-1 NTP
> server."
> <http://tinyurl.com/yf7684o>
Thanks, again. However: "The jitter was usually between 1 and 3 ms" is
about a thousand times worse than I was hoping to achieve. Something to
keep an eye on, though.
Cheers,
David
Terje Mathisen
You need a real hw PPS signal to get down to single-digit us jitter, the
only alternative is to have an expensive timing source which you can
query and which includes the hardware to timestamp each request.
From reading the ntpd driver sources I think the Palisade has such a mode?
George White
> "Richard B. Gilbert" <rgilb...@comcast.net> wrote in message
> news:YeedncqVudBjKcDW...@giganews.com...
> []
>> I think that that the closest you can come "off the shelf" would be a
>> Laptop. You are not likely to find one in that price range.
>
> I'm not happy about leaving a laptop on 24 hours a day, in any case.
We do it routinely. Laptops are very commonly used to control
instruments and log data on oceanographic vessels. One benefit
is that they are immume to the usual power glitches.
There is already an ample supply of netbooks with broken screens.
<http://wiki.freebsd.org/AsusEee> gives the status of freeBSD on the
EeePC. What I'm not sure about is the long-term supply of replacement
batteries.
>> PHK has created GPS clocks using a "single board computer" and a GPS
>> receiver. I don't know what it cost him. See:
>> http://phk.freebsd.dk/soekris/pps/
>
> Thanks for your pointer, Richard. He mentions US $220. I don't suppose he'd
> want to ship a pre-configured unit, though. It's certainly close.
>
> Cheers,
> David
>
--
George White <aa...@chebucto.ns.ca> <gn...@acm.org>
189 Parklea Dr., Head of St. Margarets Bay, Nova Scotia B3Z 2G6
David J Taylor
news:Pine.GSO.4.64.10...@halifax.chebucto.ns.ca...
[]
>> I'm not happy about leaving a laptop on 24 hours a day, in any case.
>
> We do it routinely. Laptops are very commonly used to control
> instruments and log data on oceanographic vessels. One benefit
> is that they are immume to the usual power glitches.
Thanks for that, George. The one time I left a laptop on doing something
the HD didn't work the next day. Ever since then I have equated laptop
and fragile. Of course, in this case you might not even need an HD.
> There is already an ample supply of netbooks with broken screens.
>
> <http://wiki.freebsd.org/AsusEee> gives the status of freeBSD on the
> EeePC. What I'm not sure about is the long-term supply of replacement
> batteries.
Again, batteries wouldn't matter here. But I think it's the router-like
form factor I would prefer, and a serial port is essential.
Thanks for the information, though.
Cheers,
David
Terje Mathisen
>> EeePC. What I'm not sure about is the long-term supply of replacement
>> batteries.
>
> Again, batteries wouldn't matter here. But I think it's the router-like
> form factor I would prefer, and a serial port is essential.
My tmsw.dyndns.org S1 server (FreeBSD 8, Garmin 18LVC on the roof) is a
very old Dell Latitude laptop sitting in my (cold) attic.
The hard drive doesn't need to run very often at all, except for
flushing updates to the stats files, and the ntp server part has behaved
quite nicely, including riding out any brownouts we might have had.
David J Taylor
news:j2sg37-...@ntp.tmsw.no...
[]
> My tmsw.dyndns.org S1 server (FreeBSD 8, Garmin 18LVC on the roof) is a
> very old Dell Latitude laptop sitting in my (cold) attic.
>
> The hard drive doesn't need to run very often at all, except for
> flushing updates to the stats files, and the ntp server part has behaved
> quite nicely, including riding out any brownouts we might have had.
>
> Terje
You're lucky to have a very old laptop - none of mine have a serial port.
But, yes, I can see and agree that it's a low-usage application.
Cheers,
David