Dave Hart wrote:
> offset. The Vista machine, however, has spasmed with spikes of plus
> or minus 30-90ms in the offset with a wandering frequency drift
> estimate.
The offset doesn't mean the clock is wrong by this amount, although it
does indicate that application programmes may not be able t
The approach I'm using for now to decide whether to use the
interpolation thread is to repeatedly call GetSystemTimeAsFileTime
until the sytem time ticks, and take the difference between the two
subsequent readings. If this is greater than 4ms, the interpolation
thread is started, otherwise, strai
Dave Hart wrote:
> I have a couple of machines on the same LAN behind consumer broadband
> NAT running ntp 4.2.4p6.
>
> One is running Windows XP, the other Windows Vista, both 32-bit OSes.
> The Windows XP machine has done well with NTP, usually below 10ms
> offset. The Vista machine, however, h
ryad@gmail.com wrote:
> On Jan 19, 10:26 pm, Terje Mathisen
> wrote:
>> ryad@gmail.com wrote:
>>> Hello everybody,
>>> I'm trying to track (offline) the drift of my gps clock relative to my
>>> hw clock (the clock that I would have obtained without GPS).
>>> My final goal is to convert a s
I have a couple of machines on the same LAN behind consumer broadband
NAT running ntp 4.2.4p6.
One is running Windows XP, the other Windows Vista, both 32-bit OSes.
The Windows XP machine has done well with NTP, usually below 10ms
offset. The Vista machine, however, has spasmed with spikes of plu
ryad@gmail.com writes:
>On Jan 19, 6:54=A0pm, Unruh wrote:
>> "your" gps clock does not drift. Your HW clock may drift.
>> The time sent out by GPS is accurate to a few nanoseconds. Your hardware
>> clock is not.
>Of course. I agree.
>> >hw clock (the clock that I would have obtained witho
kiran shirol wrote:
> Danny,
>
> NTP sends the response with same address as it came in. So are you
> suspecting that the VLAN is causing this issue. What could possibly be going
> wrong ?
>
Then you need to show the exact send line and response line which is not
what you showed me. Run ntpd -
On Jan 19, 10:26 pm, Terje Mathisen
wrote:
> ryad@gmail.com wrote:
> > Hello everybody,
>
> > I'm trying to track (offline) the drift of my gps clock relative to my
> > hw clock (the clock that I would have obtained without GPS).
> > My final goal is to convert a series of gps timestamps to th
ryad@gmail.com wrote:
> Hello everybody,
>
> I'm trying to track (offline) the drift of my gps clock relative to my
> hw clock (the clock that I would have obtained without GPS).
> My final goal is to convert a series of gps timestamps to the
> equivalent hw timestamps (with microsec precision
On Jan 19, 12:28 am, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
>
> The problem is the TSC calibration routine in recent kernels.
But this is only a problem when the kernel uses the default boot
option "clocksource=tsc". The article at
http://support.ntp.org/bin/view/Support/K
> However, it is not as simple as one can think,
> because it seems that ntp sync the hardware clock each 11 minutes:(
> This sync must be disabled.
>
> Is there a way to do that?
I've a linux 2.6.25,
the
CONFIG_GENERIC_CMOS_UPDATE
flag could help me
(see: dicussion "Linux 11-minute mode (RTC u
On Jan 19, 6:54 pm, Unruh wrote:
> "your" gps clock does not drift. Your HW clock may drift.
> The time sent out by GPS is accurate to a few nanoseconds. Your hardware
> clock is not.
Of course. I agree.
> >hw clock (the clock that I would have obtained without GPS).
> >My final goal is to conv
ryad@gmail.com writes:
>Hello everybody,
>I'm trying to track (offline) the drift of my gps clock relative to my
"your" gps clock does not drift. Your HW clock may drift.
The time sent out by GPS is accurate to a few nanoseconds. Your hardware
clock is not.
>hw clock (the clock that I wou
"kiran shirol" writes:
>This is a multi-part message in MIME format.
>--=_NextPart_000_0023_01C97A7A.22418D90
>Content-Type: text/plain;
> charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>My switch has configured for peering with the following switches
>ntp peer 101
Danny,
NTP sends the response with same address as it came in. So are you
suspecting that the VLAN is causing this issue. What could possibly be going
wrong ?
Just for my understanding, how does the peer association work in general ?
Any references would do.
Thanks
Kiran Shirol
"Danny Mayer"
Phil,
Can you provide me the link to the discussion you had on the same topic ? I
am interested in knowing more details.
Regards,
Kiran Shirol
wrote in message
news:of934f3a67.43d91a3c-on85257543.00586c3a-85257543.0058b...@wendys.com...
> Danny -
>
> It sounds like this is the same behavior t
Danny -
It sounds like this is the same behavior that I asked about a few weeks
ago, I think.
I have a Windows machine with two IP addresses, acting as an NTP time
source for devices on one of the two networks. Time synch requests come in
from the clients on network A, and the response from the
kiran shirol wrote:
> My switch has configured for peering with the following switches
>
> ntp peer 101.1.1.2
> ntp peer 101.2.2.2
> ntp peer 102.1.1.2
>
> Vlan has the following configuration:
> ip address 10.1.1.1/24
> ip address 20.1.1.1/24 secondary
>
> Peer sends the NTP message 20.1.1.2(Ou
Hello everybody,
I'm trying to track (offline) the drift of my gps clock relative to my
hw clock (the clock that I would have obtained without GPS).
My final goal is to convert a series of gps timestamps to the
equivalent hw timestamps (with microsec precision).
My GPS clock is built from the shm
Hi there
Adam Myrow wrote:
> It would be interesting to know what kernel version those who are having
> trouble with unstable drift in Linux are using. I am using kernel
> 2.6.27.7,
2.6.26
> and it is very stable, varying no more than 5 PPM, even across
> reboots. It should be noted that I r
Adam Myrow wrote:
> It would be interesting to know what kernel version those who are having
> trouble with unstable drift in Linux are using. I am using kernel
> 2.6.27.7, and it is very stable, varying no more than 5 PPM, even across
> reboots. It should be noted that I rebuilt my kernel with t
My switch has configured for peering with the following switches
ntp peer 101.1.1.2
ntp peer 101.2.2.2
ntp peer 102.1.1.2
Vlan has the following configuration:
ip address 10.1.1.1/24
ip address 20.1.1.1/24 secondary
Peer sends the NTP message 20.1.1.2(Out-Interface) -> 20.1.1.1(VLANs secondary
It would be interesting to know what kernel version those who are having
trouble with unstable drift in Linux are using. I am using kernel
2.6.27.7, and it is very stable, varying no more than 5 PPM, even across
reboots. It should be noted that I rebuilt my kernel with the timer
frequency set to
kiran shirol wrote:
> Hi NTP experts,
>
> I am not able to establish ntp peer adjaceny with secondary ip address on
> vlan interface.
>
> I noticed that when peer sends a NTP message to Device Under Test's(DUT)
> vlan interface secondary address, DUT would respond the message with source
> add
Hi there
Brian Inglis wrote:
> Is spread specturm clock signal generation (EMI reduction) disabled for
> the CPU and buses in the firmware?
These are the BIOS options;
CPU Spread Spectrum [Auto]
Allows you to enable or disable the CPU spread spectrum.
Configuration options: [Auto] [Disabled]
On Mon, 19 Jan 2009 02:25:33 -0700, Brian Inglis wrote:
> On Fri, 16 Jan 2009 00:50:02 GMT in comp.protocols.time.ntp, Unruh
> wrote:
>
>>"David J Taylor"
>> writes:
>>
>>>Unruh wrote:
>>>[]
Yes, but that same manual says that the voltage for the 18PC version
is 8-30V. It says nothing
In article <49745d61$0$185$e4fe5...@news.xs4all.nl>,
Nero Imhard writes:
> David J Taylor schreef:
> > Are current versions of FreeBSD much better for timekeeping than
> > Linux?
>
> In my rather subjective raw user (or rather: administrator) experience
> there are just too many little problems
David J Taylor schreef:
> Are current versions of FreeBSD much better for timekeeping than
> Linux?
In my rather subjective raw user (or rather: administrator) experience
there are just too many little problems getting ntp to work decently
starting from a stock Linux, and the result never instill
On Mon, 19 Jan 2009 00:28:22 -0600 in comp.protocols.time.ntp,
hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote:
>>> Linux seme to be having a real real problem with its time calibration
>>> routines. It's drift rate jumps on reboot by up to 50PPM from one
>>> reboot to the next.
>
>>
On Fri, 16 Jan 2009 00:50:02 GMT in comp.protocols.time.ntp, Unruh
wrote:
>"David J Taylor"
>writes:
>
>>Unruh wrote:
>>[]
>>> Yes, but that same manual says that the voltage for the 18PC version
>>> is 8-30V. It says nothing about the internal voltage being the 4.5 to
>>> 5.5 V.
Not quite - t
Hi NTP experts,
I am not able to establish ntp peer adjaceny with secondary ip address on
vlan interface.
I noticed that when peer sends a NTP message to Device Under Test's(DUT)
vlan interface secondary address, DUT would respond the message with source
address set to vlan interface's primary
David Woolley wrote:
> David J Taylor wrote:
>
>>
>> Would it be any better for the routine to lie, and just give to the
>> nearest MHz, rounded down?
>
> That would result in an excessive error for those not using time
> synchronisation software,
I might say /tough/!
> and would produce extreme
32 matches
Mail list logo
