On 2011-03-14, Ralph wrote:
> Maybe what I'm misunderstanding is the 'how' of that measurement? And I
> correct
> that the assumption in all this is that the system clock ticks are
> consistent?
> And that is the root of the problem in getting things to work properly on a
> VM?
>
> In readin
unruh wrote:
On 2011-03-14, Ralph wrote:
Nope. The HW clock is a clock which is completely separate from the
operating system.
So maybe if we could have a mode where ntpd uses the hardware clock to measure the round trip and instead of the system clock? Or just uses the hardare clock
Imp
unruh wrote:
> The problem is not the round trip measurement ( although that can be a
> minor problem). The problem is that the rate of the vm clock is not
> consistant, and thus ntp, which adjusts the clock by adjusting the rate
> ( and strongly assumes that that rate changes slowly if it changes
Terje Mathisen wrote:
b) Since both the PPS and NMEA drivers have fudge flags to use a falling
instead of the default rising edge of the DCD signal, I can use the
first version of David's hack, i.e. from the official PPS header via the
free RS232 level driver (U6 - pin 11->14). This should avoid
Rob wrote:
unruh wrote:
The problem is not the round trip measurement ( although that can be a
minor problem). The problem is that the rate of the vm clock is not
consistant, and thus ntp, which adjusts the clock by adjusting the rate
( and strongly assumes that that rate changes slowly if it c
Maarten Deen wrote in
news:Xns9E95E2074B3415r68mtnbtdvsdr@194.109.133.242:
> hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote in
> news:k4odnvhgatyt6_jqnz2dnuvz_jydn...@megapath.net:
>
>> In article ,
>> Maarten Deen writes:
>> ...
>>>23 Feb 20:42:53 ntpd[27664]: time reset +2.4
On Sunday, March 13, 2011 11:41:59 PM UTC-7, unruh wrote:
>
> Sure. Teh Hw clock ( rtc) is on its own timer which does not depend on
> any of the system timers. However it typically has a rate that is many
> PPM out and that rate cannot be adjusted. This makes it completely
> unsuitable for the cl
On Mar 14, 2011, at 4:45 AM, Terje Mathisen wrote:
> It is in fact so wrong that a recent VMware report quoted here stated that
> with current VMware products you would get _better_ time sync on a client OS
> by running ntpd on the client, than by running ntpd on the host and using
> VMware's op
On 2011-03-14, Ralph wrote:
> On Sunday, March 13, 2011 11:41:59 PM UTC-7, unruh wrote:
>>
>> Sure. Teh Hw clock ( rtc) is on its own timer which does not depend on
>> any of the system timers. However it typically has a rate that is many
>> PPM out and that rate cannot be adjusted. This makes it
On Fri, Mar 11, 2011 at 12:47 PM, John Hasler wrote:
> The hardware doesn't go away when you add another layer or two of
> complexity by adding VMWare.
>
> What's baffling, though, is why you need to add an entire virtual
> machine and operating system just to run another process.
If only it were
Chris Albertson wrote:
> Use either "ntpdate" or "ntpd -q".
> They both work the same way. They go to an NTP server
> and then jump the local system time to match the server.
> Run this every hour as a cron job.
I think he will likely need to use ntpd -g -q
and much more often than once a hou
11 matches
Mail list logo
