The Linux Intergration Services don't work for Virtual Server; they are only
for Hyper-V and Hyper-V is only for 64-bit and I have 32-bit hardware so
Hyper-V isn't an option for me. Therefore the Intergration Services aren't a
viable option.
___
ques
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
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
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 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 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
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
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
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
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
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 reading the NTP spec it sounded to me like the formu
Once upon a time, Chris Albertson said:
>On Fri, Mar 11, 2011 at 10:12 AM, Ryan Malayter wrote:
>. have you ever audited the code of your BIOS? Or the firmware
>> on your chipsets, NICs, RAID cards, or disk drives? Your "control" of
>> a physical server is just as illusory as that of a Virtual M
On Sat, Mar 12, 2011 at 11:14 AM, Ralph wrote:
> Right. So what would be good is a solution along the lines of those methods
> that simply use the time off the time servers without worrying about the local
> clock, but that 'fix' the local clock in a more friendly way like ntpd does.
You may be
On Sat, Mar 12, 2011 at 1:24 AM, David Woolley
wrote:
> Chris Albertson wrote:
>>
>
> My understanding is that system management mode code is still executed.
It does not runif it is disabled of not present. and of course this
only applies to PC hardware. Linux runs on many platforms from offic
As I outline in my other post, this method wouldn't care about offset. It
isn't
about precision accuracy, it's about relative consistency.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Ralph writes:
> So what would be good is a solution along the lines of those methods
> that simply use the time off the time servers without worrying about
> the local clock...
How are you going to measure the offset?
--
John Hasler
jhas...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA
___
Appartently timesharing is for educational environments now; and not just for
'big iron'...
http://www.microsoft.com/windows/multipoint/
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Right. So what would be good is a solution along the lines of those methods
that simply use the time off the time servers without worrying about the local
clock, but that 'fix' the local clock in a more friendly way like ntpd does.
(See my other reply for a few other ideas).
__
On Friday, March 11, 2011 11:49:39 PM UTC-8, unruh wrote:
>
> No, that is not the problem. The problem is that the computer has an
> internal clock that depends on things like counting processor cycles. If
> suddenly the processor disappears for a while with no processor cycles,
> the timing wil
unruh wrote:
> On 2011-03-08, Ralph wrote:
>>
>>
>>> When are you going to start working on it?
>>> ... or are you asking others to do free programming
>>> for you, to work around your unique problem?
>>
>> Maybe I deserve that flame for having ranted a bit, but
>> I hardly think the probl
unruh wrote:
> The problem on a VM system is that the frequency jumps around. Ie, when
> the VM is running, its frequency should be very close to the fundamental
> clock frequency, and when it is not running, its freq is 0.
What do you know about that?
Did you ever do a small test to see if it is
"Uwe Klein" wrote in message
news:h01s48-89b@klein-habertwedt.de...
David J Taylor wrote:
Is that NT3.5 fact still valid ?
Never understood why anyone would use Windows for real work anyway.
The thing that it does best is waiting ever faster for the next
keypress from the user.
uwe
Pe
David J Taylor wrote:
Is that NT3.5 fact still valid ?
Never understood why anyone would use Windows for real work anyway.
The thing that it does best is waiting ever faster for the next
keypress from the user.
uwe
Perhaps people use Windows because the software they wish to run is only
av
Is that NT3.5 fact still valid ?
Never understood why anyone would use Windows for real work anyway.
The thing that it does best is waiting ever faster for the next
keypress from the user.
uwe
Perhaps people use Windows because the software they wish to run is only
available for Windows? I
David Woolley wrote:
Chris Albertson wrote:
Yes, Linux, after the first boot block is loaded does not use any of
that code, no BIOS calls are made from the OS, none of other ROMs
either. It's open Source so people read the code.
My understanding is that system management mode code is still
Chris Albertson wrote:
On Fri, Mar 11, 2011 at 10:12 AM, Ryan Malayter wrote:
. have you ever audited the code of your BIOS? Or the firmware
on your chipsets, NICs, RAID cards, or disk drives? Your "control" of
a physical server is just as illusory as that of a Virtual Machine.
Yes, Linux, a
Chris Albertson wrote:
On Fri, Mar 11, 2011 at 10:47 AM, John Hasler wrote:
RPM writes:
What's baffling, though, is why you need to add an entire virtual
machine and operating system just to run another process.
The problem is Windows does not multitask well. I've been told you
can't e
On 2011-03-12, Ralph wrote:
> @Chris
>
> I appreciate the offer to help.
>
> I've been thinking about this problem a while and here are my thoughts... It
> seems to me that ntpd has the goal of keeping extremely accurate time - which
> is important for many obvious reasons. However there are th
On Fri, Mar 11, 2011 at 9:24 PM, Ralph wrote:
> @Chris
>
> I appreciate the offer to help.
>
> I've been thinking about this problem a while and here are my thoughts... It
> seems to me that ntpd has the goal of keeping extremely accurate time - which
> is important for many obvious reasons. How
There are certainly plenty of arguments for how VMs can help companies reduce
costs.
However, personally in cases like mine, I'm using a VM because I want to be
able
to work with more than one operating system without having to own 4 different
PCs. And frankly, even for me it provides a great
@Chris
I appreciate the offer to help.
I've been thinking about this problem a while and here are my thoughts... It
seems to me that ntpd has the goal of keeping extremely accurate time - which
is important for many obvious reasons. However there are those of us that
don't need time accurate t
On Fri, Mar 11, 2011 at 10:47 AM, John Hasler wrote:
> RPM writes:
> What's baffling, though, is why you need to add an entire virtual
> machine and operating system just to run another process.
The problem is Windows does not multitask well. I've been told you
can't expect to run multiple serv
On Fri, Mar 11, 2011 at 10:12 AM, Ryan Malayter wrote:
. have you ever audited the code of your BIOS? Or the firmware
> on your chipsets, NICs, RAID cards, or disk drives? Your "control" of
> a physical server is just as illusory as that of a Virtual Machine.
Yes, Linux, after the first boot blo
Parvin, Richard wrote:
> I run Symmetricom S300.
> I would like to use Sysplex to manage the time on my mainframes.
> Could someone point me to some documentation?
How much are you paying researchers?
--
E-Mail Sent to this address
will be added to the BlackLists.
___
RPM writes:
> As for your notion of "safety" when running on a real physical
> server... have you ever audited the code of your BIOS? Or the firmware
> on your chipsets, NICs, RAID cards, or disk drives? Your "control" of
> a physical server is just as illusory as that of a Virtual Machine.
The ha
On Thu, Mar 10, 2011 at 4:33 PM, Uwe Klein
wrote:
> IMHO most "leveragers" of VMs don't understand what happens in
> their loved sandbox which completely destroys the
> notion of a "controlled and escape proof environment"
>
No, we do, it's just that 20:1 server consolidation ratios and the
atte
Rick Jones wrote:
Uwe Klein wrote:
What actually happened to the idea of different users ;-)
Silly Uwe - timesharing is for old, slightly bulging guys with
beards. :)
Have we met before in person ;-? ( How did you know )
It requires too much thought to make sure that User A can't
ever se
Uwe Klein wrote:
> What actually happened to the idea of different users ;-)
Silly Uwe - timesharing is for old, slightly bulging guys with
beards. :) It requires too much thought to make sure that User A can't
ever see anything of User B's and that Instance 1 of COTSware won't
step on the toes o
@lists.ntp.org] On Behalf Of
E-Mail Sent to this address will be added to the BlackLists
Sent: Thursday, March 10, 2011 2:51 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Ralph wrote:
> The VM technology being used in the this
Ralph wrote:
> The VM technology being used in the this case is
> Microsoft's Virtual Server (which is the server version
> of Virtual PC) and the predecessor to Hyper-V.
So, you are trying to run
ntp-4.2.2pl-9
on CentOS (v ?)
in a Microsoft's Virtual Server (2005 ?)
on windows 2008?
Dave Hart wrote:
On Wed, Mar 9, 2011 at 20:24 UTC, Chuck Swiger wrote:
I'm sure programs can detect virtualization, but the point is
VoIP softswitches do care about latency and probably about system
clock jitter, another example alongside the lvm approach demonstrating
VM timekeeping can be re
Chuck,
Thanks for all the insights and information here... I'm sure it got lost in the
myriad of message here.
The VM technology being used in the this case is Microsoft's Virtual Server
(which is the server version of Virtual PC) and the predecessor to Hyper-V.
___
Ralph wrote:
> Maybe I deserve that flame for having ranted a bit, but
> I hardly think the problem of clock time that won't behave
> within a linux guest VM is 'unique'. Do a google search
> on it, I'm clearly not the only one with this problem.
> And if they gave a flying flip about the many di
On Wed, Mar 9, 2011 at 20:24 UTC, Chuck Swiger wrote:
> Because of the above, I've drawn the conclusion that "running ntpd's in the
> other DomUs/guest VMs is almost entirely pointless".
One oft-quoted reason I hear is "we don't control the Dom0" whether
it's corporate orgchart separation, or lea
On Mar 9, 2011, at 3:36 AM, Miroslav Lichvar wrote:
> On Tue, Mar 08, 2011 at 03:26:34PM -0800, Chuck Swiger wrote:
You are better off running ntpdate (or sntp) periodically via cron in
the DomUs.
>>>
>>> Perhaps in certain cases, but not across the board.
>>
>> I'd be happy to review c
On Mar 8, 2011, at 5:56 PM, Steve Kostecke wrote:
> On 2011-03-08, Chuck Swiger wrote:
[ ... ]
>>> NTP disciplines the system (i.e. kernel) clock, not the hardware
>>> clock on the mother board.
>>
>> That's right, although in reasonably common for platforms to
>> periodically write the system cl
On Tue, Mar 08, 2011 at 03:26:34PM -0800, Chuck Swiger wrote:
> >> You are better off running ntpdate (or sntp) periodically via cron in
> >> the DomUs.
> >
> > Perhaps in certain cases, but not across the board.
>
> I'd be happy to review counterexamples to my generalization
I'd say it depe
On 2011-03-08, Chuck Swiger wrote:
> On Mar 8, 2011, at 1:18 PM, Steve Kostecke wrote:
>
>> On 2011-03-08, Chuck Swiger wrote:
>>
>>> Seriously, each physical machine only has one RTC and crystal
>>> oscillator. It's useful to run one instance of ntpd in the Dom0 (or
>>> host ESX) context where
On Mar 8, 2011, at 1:18 PM, Steve Kostecke wrote:
On 2011-03-08, Chuck Swiger wrote:
>> Seriously, each physical machine only has one RTC and crystal
>> oscillator. It's useful to run one instance of ntpd in the Dom0 (or
>> host ESX) context where it can actually work and keep this real
>> hardwar
On 2011-03-08, Chuck Swiger wrote:
> Seriously, each physical machine only has one RTC and crystal
> oscillator. It's useful to run one instance of ntpd in the Dom0 (or
> host ESX) context where it can actually work and keep this real
> hardware clock in sync.
NTP disciplines the system (i.e. ke
On 2011-03-08, Miroslav Lichvar wrote:
> On Tue, Mar 08, 2011 at 05:00:44PM +, unruh wrote:
>> filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4
>> 58156.6,
>
>> Not at all sure how Mills comes into the picture. On a system where the
>> frequency fluctuates wildly,
On Mar 8, 2011, at 9:13 AM, Ralph wrote:
> Well along those lines, what about creating a driver or deamon (for
> lack of something better to call it) that provides time to ntpd that
> gets that time from the host machine?
I still haven't been able to figure out which virtualization system you are
On Tue, Mar 8, 2011 at 9:04 AM, Ralph wrote:
> I'm going to end this particular line of discussion because
> it is clear that this is a fruitless conversation and arguing
> back and forth about my personal ability to code a solution for
> VM time syncronization doesn't do anything for the problem
On 2011-03-08, Ralph wrote:
> Well along those lines, what about creating a driver or deamon (for
> lack of something better to call it) that provides time to ntpd that
> gets that time from the host machine? Similar to the local clock
> setting but somehow trusting the host. Or would that still
On Tue, Mar 08, 2011 at 05:00:44PM +, unruh wrote:
> filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4
> 58156.6,
> Not at all sure how Mills comes into the picture. On a system where the
> frequency fluctuates wildly, ntpd is not the right answer, nor is any
> sys
Well along those lines, what about creating a driver or deamon (for
lack of something better to call it) that provides time to ntpd that
gets that time from the host machine? Similar to the local clock
setting but somehow trusting the host. Or would that still have the
problems with high jitter w
On 2011-03-08, Richard B. Gilbert wrote:
> On 3/8/2011 4:16 AM, Miroslav Lichvar wrote:
>> On Sun, Mar 06, 2011 at 11:22:34AM +, David Woolley wrote:
>>> Ralph wrote:
>>>
filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4
58156.6,
>>>
>>> Your frequency error is way
I'm going to end this particular line of discussion because
it is clear that this is a fruitless conversation and arguing
back and forth about my personal ability to code a solution for
VM time syncronization doesn't do anything for the problem at
hand.
On 2011-03-08, Ralph wrote:
> Host OS is windows (2008 if we want to get specific)
>
> nose and corkskrew is nessecary because frankly I'm not
> accustomed to there being any difference between a guest
> OS and a physical OS in most cases and even when there is
> it hasn't been relevant what the h
On 2011-03-08, Ralph wrote:
>
>
>> When are you going to start working on it?
>> ... or are you asking others to do free programming
>> for you, to work around your unique problem?
>
> Maybe I deserve that flame for having ranted a bit, but
> I hardly think the problem of clock time that wo
On Tue, Mar 8, 2011 at 1:16 AM, Miroslav Lichvar wrote:
> On Sun, Mar 06, 2011 at 11:22:34AM +, David Woolley wrote:
> This seems to be a common problem and with virtual machines getting
> everywhere it will probably only get worse. I'm wondering how hard it
> would be for ntpd to detect that
On 3/8/2011 4:16 AM, Miroslav Lichvar wrote:
On Sun, Mar 06, 2011 at 11:22:34AM +, David Woolley wrote:
Ralph wrote:
filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 58156.6,
Your frequency error is way outside any reasonable bounds, which is
reflecting in a very high
"Rob" wrote in message []
VMware advises to run ntpd in the guest.
Thanks, Rob. I wonder whether this is a change from their earlier
suggestions? I see that they now do suggest this as one route (as well as
providing their own time synchronisation program as another option). Are
the reco
Ralph wrote:
Host OS is windows (2008 if we want to get specific)
nose and corkskrew is nessecary because frankly I'm not
accustomed to there being any difference between a guest
OS and a physical OS in most cases and even when there is
it hasn't been relevant what the host OS is.
Hi Ralph,
Y
"Ralph" wrote in message
news:d695207e-04ec-4664-8580-35bc25806...@glegroupsg2000goo.googlegroups.com...
Well it started out as NTP's problem because apparently the
clock instability makes it so NTP can't run right on the guest.
I understand this isn't so much an NTP problem if the expectation
i
David J Taylor wrote:
> "Ralph" wrote in message
> news:d695207e-04ec-4664-8580-35bc25806...@glegroupsg2000goo.googlegroups.com...
>> Well it started out as NTP's problem because apparently the
>> clock instability makes it so NTP can't run right on the guest.
>> I understand this isn't so much
Sorry if the formatting is bad.
I don't have a local newsfeed (ISPs seems to have abonded providing
that)
so I have to post via google. I wraps fine on their editor but I can
see
where it might not format well in the newsfeed.
Ralph,
You may be able to use one of the free news services inst
Host OS is windows (2008 if we want to get specific)
nose and corkskrew is nessecary because frankly I'm not
accustomed to there being any difference between a guest
OS and a physical OS in most cases and even when there is
it hasn't been relevant what the host OS is.
"Ralph" wrote in message
news:c5b90638-395f-4e77-8761-f99c25343...@glegroupsg2000goo.googlegroups.com...
Ok. The host OS time is fine so I'd have no problem using that
as the source for my linux guest.
What no one has provided yet is an answer to 'how' to get the
linux guest VM to get the prope
Well it started out as NTP's problem because apparently the
clock instability makes it so NTP can't run right on the guest.
I understand this isn't so much an NTP problem if the expectation
is that NTP can't run on a guest OS, but since everyone seemed to
state so matter of factly that the guest sh
> When are you going to start working on it?
> ... or are you asking others to do free programming
> for you, to work around your unique problem?
Maybe I deserve that flame for having ranted a bit, but
I hardly think the problem of clock time that won't behave
within a linux guest VM is 'un
Sorry if the formatting is bad.
I don't have a local newsfeed (ISPs seems to have abonded providing that)
so I have to post via google. I wraps fine on their editor but I can see
where it might not format well in the newsfeed.
___
questions mailing lis
Ok. The host OS time is fine so I'd have no problem using that
as the source for my linux guest.
What no one has provided yet is an answer to 'how' to get the
linux guest VM to get the proper time from the host?
___
questions mailing list
questions@list
On Sun, Mar 06, 2011 at 11:22:34AM +, David Woolley wrote:
> Ralph wrote:
>
> >filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 58156.6,
>
> Your frequency error is way outside any reasonable bounds, which is
> reflecting in a very high jitter, which is probably the ultimat
Ralph wrote:
Can it even be fixed?
Well I hope so. Not to bash on the linux world, but I don't get why this
timing thing is so
hard... I mean I understand it from a techinical perspective because I've read
all about how the
hardware and timers and stuff work, but practically speaking, some
Ralph wrote:
> Not to bash on the linux world, but I don't get why this
> timing thing is so hard...
> I mean I understand it from a techinical perspective
> because I've read all about how the hardware and timers
> and stuff work, but practically speaking,
> somebody needs to get with the prog
On 2011-03-07, Ralph wrote:
>>
>> Can it even be fixed?
>
> Well I hope so. Not to bash on the linux world, but I don't get why this
> timing thing is so hard... I mean I understand it from a techinical
> perspective because I've read all about how the hardware and timers and stuff
> work,
On 2011-03-06, Ralph wrote:
> It is a VM, which I'm sure is why the clock isn't playing nice but I haven't
> found the right solution to fix it... The clock was running fast until I
> added the divider=10 option and now it runs slow - but I rather have ntp have
> to move the clock forward than
On 3/7/2011 3:00 AM, Ralph wrote:
Yes this is a VM (see other ealier posts about that). I've been
trying to get the clock to behave but haven't found the solution.
Some people seem to think there isn't an answer. I'm not after super
accurate time here, I just want my clock to stay within a minu
On 3/6/2011 4:48 PM, Chris Albertson wrote:
On Sun, Mar 6, 2011 at 12:18 PM, Ralph wrote:
It is a VM, which I'm sure is why the clock isn't playing nice but I haven't
found the right solution to fix it..
Can it even be fixed? I'd guess maybe not. Has anyone here run ntpd
on a virtual mach
Ralph wrote:
Can it even be fixed?
Well I hope so. Not to bash on the linux world, but I don't get why this
timing thing is so hard... I mean I understand it from a techinical
perspective because I've read all about how the hardware and timers and stuff
work, but practically speaking, som
Any idea how to get a clock correction on a MS Virtual PC / Virtual Server?
Last time I tried to install the MS VPC tools for linux on a machine it
thoroughly hosed things up; so unless there is a new an improved version I'm a
little hesitant to go there agian.
Yes this is a VM (see other ealier posts about that). I've been trying to get
the clock to behave but haven't found the solution. Some people seem to think
there isn't an answer. I'm not after super accurate time here, I just want my
clock to stay within a minute or two of what actual time is
>
> Can it even be fixed?
Well I hope so. Not to bash on the linux world, but I don't get why this
timing thing is so hard... I mean I understand it from a techinical
perspective because I've read all about how the hardware and timers and stuff
work, but practically speaking, somebody need
@Richard
I know that one shapshot is very early on but if you look at the start of the
thread you can see information on what things look like after it has been
running a while and in that second output of the two in that last post you can
see that it is quickly headed in that direction after a
On 3/6/2011 3:14 PM, Ralph wrote:
Did another complete shutdown of ntpd, made suere there were no ntpd processes
running, set the time with ntpd -q -g, and then started it back up. Here is
what things look like shortly after startup...
ntpq -c peer -c as -c rl
remote refid
On 3/6/2011 3:18 PM, Ralph wrote:
It is a VM, which I'm sure is why the clock isn't playing nice but I haven't
found the right solution to fix it... The clock was running fast until I added
the divider=10 option and now it runs slow - but I rather have ntp have to move
the clock forward than h
On 2011-03-06, Ralph wrote:
> It is a VM, which I'm sure is why the clock isn't playing nice but I
> haven't found the right solution to fix it...
[snip]
> Are there other tweaks I can do to try to get the clock running
> properly on a VM?
For Xen:
Run 'echo 1 > /proc/sys/xen/independent_wall
On Sun, Mar 6, 2011 at 12:18 PM, Ralph wrote:
> It is a VM, which I'm sure is why the clock isn't playing nice but I haven't
> found the right solution to fix it..
Can it even be fixed? I'd guess maybe not. Has anyone here run ntpd
on a virtual machine?
=
Chris Albertson
Redondo Beach, Ca
Davd write:
> You have a very high initial offset so first I'd shutdown
> ntpd then use ntpdate to set the time to a reasonable value
> or use 'ntpd -g -q'. With such a large offset you might need
> a few tries at setting the clock to within a few milliseconds.
That might be an issue for ancient n
Did another complete shutdown of ntpd, made suere there were no ntpd processes
running, set the time with ntpd -q -g, and then started it back up. Here is
what things look like shortly after startup...
ntpq -c peer -c as -c rl
remote refid st t when poll reach delay offs
I have done what you suggested in terms of setting the clock with services
shutdown and then starting ntpd back up and I still end up in this state.
Every time ntpd adjusts the clock it has to add around 190s; looks like it's
doing it every hour or so...
The driftfile has 8.747 in it. I have
It is a VM, which I'm sure is why the clock isn't playing nice but I haven't
found the right solution to fix it... The clock was running fast until I added
the divider=10 option and now it runs slow - but I rather have ntp have to move
the clock forward than have it moving backwards. When it wa
If that is the case, is there anything that can be done to the system to make
it 'behave'?
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Ralph wrote:
If that is the case, is there anything that can be done to the system to make
it 'behave'?
Assuming that was in response to mine. Find out what is wrong with the
system and repair or replace it, up to and including the mother board,
if that is where the problem lies.
Somethin
Ralph wrote:
I'm trying to get my ntpd configuration to work and no matter what I try
nothing seems to work.
I have numerous servers configured (and have tried various ones) in addition to
pool servers and still can't get a configuration that works cleanly. When I
run the peer command, all t
Ralph wrote:
filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 58156.6,
Your frequency error is way outside any reasonable bounds, which is
reflecting in a very high jitter, which is probably the ultimate cause
of rejection.
This system is not savable by NTP.
___
On 2011-03-06, Ralph wrote:
> I'm trying to get my ntpd configuration to work and no matter what I
> try nothing seems to work.
Is this in a VM?
> I have numerous servers configured (and have tried various ones) in
> addition to pool servers and still can't get a configuration that
> works clea
I'm trying to get my ntpd configuration to work and no matter what I try
nothing seems to work.
I have numerous servers configured (and have tried various ones) in addition to
pool servers and still can't get a configuration that works cleanly. When I
run the peer command, all the servers disp
99 matches
Mail list logo
