I realize this is long, but I tried to include the whole story. I did
work earnestly to solve this on my own, but unfortunately I've been
spinning my wheels the last few days. Thanks for any help.
I am having a problem with drift values approaching and, on occasion,
reaching +/-500ppm. My time
Rob Neal wrote:
> On Mon, 3 Mar 2008, Andy Helten wrote:
> -snippage-
>
>> I am having a problem with drift values approaching and, on occasion,
>> reaching +/-500ppm.
>>
>>
> -snippage-
>
Harlan Stenn wrote:
> iburst is good. burst, very likely not.
>
Actually, I just ran a test and, at least for refclock_bancomm, burst is
the only one that matters. However, even with 'burst', it would still
take 64 seconds for ntp to declare a peer if minpoll is not also
decreased. I attribu
;burst' command back into ntp.conf, removed the drift file, and
restarted ntp.
Andy
Andy wrote:
> Rob Neal wrote:
>
>> On Mon, 3 Mar 2008, Andy Helten wrote:
>>
>> -- snippage --
>>
>> Lose the 'iburst burst' on 16.
>>
>&
Andy wrote:
> The good news is that "new ntp.conf" appears to work! This is the first
> configuration that has produced reasonable results, granted it could
> still be a fluke since the drift was rather unpredictable (but _always_
> settled near +/-500ppm). The bad news is that we _require_ some
Rob Neal wrote:
> On Wed, 5 Mar 2008, Andy Helten wrote:
>
>
>> I think I have been giving it enough time to stabilize -- any test I
>> consider legitimate was allowed to run for at least 8 hours. Most tests
>> ran overnight for 18-24 hours and some tests ran ove
Fran Horan wrote:
>
>
>
>> So, the summary is that drift goes to 500ppm when stepping is disabled
>> but runs normally when stepping is enabled and both situations never
>> require a time step. This makes no sense to me. By the way, as
>> mentioned previously, we require that time does not s
Miroslav Lichvar wrote:
> On Fri, Mar 07, 2008 at 09:13:14AM -0600, Andy Helten wrote:
>
>> As I mentioned in a previous email, I was going to run ntp while adding
>> back in some of the features I removed. After doing this, at least
>> superficially, I've isol
Richard Gilbert wrote:
>
>
> A comment in ntp.conf and/or the startup file, explaining WHY stepping
> is enabled should go a long way toward solving the "dumbass" problem.
>
>
Yes, I know, but that requires someone to actually read the comments in
the conf files and there is always the '-x' a
agallo wrote:
> I have a bc635 gps card that I would like to use to donate NTP
> services to pool.ntp.org.
>
> I have downloaded the freeBSD driver and attempted to compile with the
> driver with the following results:
> btfp.h:424:5: warning: "OPSYS" is not defined
> btfp.h:424:12: warning: "Fre
trying to
> compile without success. As far as writing a driver, that's a bit
> beyond my skill level :)
>
> Thanks.
>
> On Mon, Mar 10, 2008 at 11:51 AM, Andy Helten
> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>
>
>
> agallo wrote:
Vifkov wrote:
> May sound like a newbe question, but am I wrong or earlier Windows
> clients were syncing with NTP ?
>
> The problem is simple: A big building, about 350-400 Windows XP PCs,
> and 2 Linux servers not only for NTP, but for it too... Now today, on
> my laptop I had to edit the regist
Unruh wrote:
> Time should never move backward. "Steps" should be fast drifts. (1PPM
> if necessary but not 100PPM.
>
>
I don't know that this is unconditionally true. From
https://lists.ntp.org/pipermail/questions/2006-September/011548.html,
quoting Dr. Mills:
> 4. In the design of th
I use PoE every day -- it powers the outdoor antennae that connects to
my wireless ISP (distance of about 5 miles). I have gotten up to
3000kb/s over this link (which is slightly higher than what I'm paying
for). So, whatever you are debating here, PoE is almost certainly *not*
the problem.
Dav
Hal Murray wrote:
>> The ntp log file shows when NTP steps the time. But then the potential harm
>> is already done. Especially if the time moves backward, our server might
>> have serious trouble. Is there a log event which indicates that the time is
>> going to be reset in order to enable us to
Unruh wrote:
> [EMAIL PROTECTED] (Andy Helten) writes:
>
>> Another disadvantage with preventing steps is that it isn't really a
>> supported mode (because it's a "tinker") and, as I've found, it doesn't
>> always work. When I disable t
Hal Murray wrote:
>>> That certainly sounds like a bug to me.
>>>
>
>
>> Me too, but disabling time step is a tinker and tinkers are generally
>> use at your own risk. Besides, after much testing, I'm fairly certain
>> the problem is indeed with the kernel -- especially considering I d
David Woolley wrote:
> Andy Helten wrote:
>
>>>> offset never went >128ms). With time steps enabled the drift value
>>>> settles <90ppm (and again, no step actually occurs).
>>>>
>
> 90ms is a relatively bad static frequency err
Unruh wrote:
> [EMAIL PROTECTED] (Andy Helten) writes:
>
>> My current problem is that drift settles at 82ppm (what I called <90 in
>> previous email) in one run and then 32ppm in another run (with a reboot
>> between). This is similar to the problem I had with
Hal wrote:
>> My current problem is that drift settles at 82ppm (what I called <90 in
>> previous email) in one run and then 32ppm in another run (with a reboot
>> between). This is similar to the problem I had with stepping disabled
>> where drift would go from +500ppm in one run and then swing
Richard B. Gilbert wrote:
> David Woolley wrote:
>
>>> It looks like the crystal oscillator inside the system has been
>>> suddenly and permanently altered. Is that even possible?
>>>
>> I believe that is quite possible as a result of aging.
>>
>
> I believe that changes in crystal
Richard B. Gilbert wrote:
> Andy Helten wrote:
>
>> Richard B. Gilbert wrote:
>>
>>> David Woolley wrote:
>>>
>>>
>>>>> It looks like the crystal oscillator inside the system has been
&
king for fun or one-off projects, I try to
> help them out with source code or advice.
>
>
> Greg Dowd
> gdowd at symmetricom dot com (antispam format)
> Symmetricom, Inc.
> www.symmetricom.com
> "Everything should be made as simple as possible, but no simpler"
Unruh <[EMAIL PROTECTED]> wrote:
> Actually it is much worse than that. On my system, on bootup the clock
> frequency can very by up to about 50PPM due to a Linux bug. In general it
> takes ntp about 10 hours to regain tight synchronisation. (In that case it
> is microsecond since it is synching
[EMAIL PROTECTED] (Hal Murray) wrote:
>> Which linux bug causes your frequency to vary? The only frequency issue
>> I've encountered is a slight variation in the dynamic boot time
>> measurement of the TSC (time stamp counter) frequency. This problem is
>> not so much a bug in my opinion and
jimp wrote:
> Andy Helten wrote:
>
>> Heiko Gerstung wrote:
>>
>>> Juergen Perlinger schrieb:
>>>
>>>
>>>> Hi everybody,
>>>>
>>>> One of the things that can be annoying is that NTPD cannot do
Unruh wrote:
> j...@specsol.spam.sux.com writes:
>
>
>> Andy Helten wrote:
>>
>>> Heiko Gerstung wrote:
>>>
>>>> Juergen Perlinger schrieb:
>>>>
>>>>
>>>>> Hi every
Heiko Gerstung wrote:
> Juergen Perlinger schrieb:
>
>> Hi everybody,
>>
>> One of the things that can be annoying is that NTPD cannot do an initial
>> synchronization from (most) reference clocks over a difference of more than
>> 4 hours.
>>
>> The reason is that 'refclock_process()' calls 'cl
Terje Mathisen wrote:
> Andy Helten wrote:
>
>> Unruh wrote:
>>
>>> uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be
>>> used. If ntpd -g fails it is a bug.
>>>
>>>
>> Then it is a bug becau
martin.l.l...@gmail.com wrote:
> I have a network isolated the internet but I need a time server to run
> on this private network. Are there any standalone time server
> packages out there? Is there a way to force ntpd to sync with my
> computer clock and then run sending out the time data? Nt
max.birraman wrote:
> On 9 Giu, 19:49, E-Mail Sent to this address will be added to the
> BlackLists wrote:
>
>> max.birra...@gmail.com wrote:
>>
>>> i'going to write down a guide for this kind of porting
>>> with the info that i will collect, in order to have a
>>> reference point for
David Woolley wrote:
> So, basically, as long as you act irresponsibly with respect to use of
> energy and other resources, you will have no problem.
>
> Powering down is often the optimum way of minimising energy usage and
> maximising the time till land fill.
>
> To avoid temperature transient
Unruh wrote:
> So I have 9 clocks.
> The rates are
> -190, 19 , -106, -67,-200 -219, -115 -140 221
>
> On reboot, the latter changed from 221 to 215 (Which took ntp about 6
> hours to recover from)
>
> The clock scaling in linux seems to suffered a real problem in the past
> year or two, so that th
Kalle Pokki wrote:
On Tue, May 4, 2010 at 16:03, Rini van Zetten wrote:
I'm trying to setup an embedded system with ntpd and a gps device as reference
clock.
Everyhing went fine when the clock is not too far away when i start ntpd.
But when the clock offset is big (1-1-1970 for example),
Rob wrote:
Kalle Pokki wrote:
Yes, but reference clock drivers don't use the ntp timestamp. Take a
look at e.g. the SHM driver. There
Is this piece of code something that our friend does not want to change
because he believes it is doing the right thing? Or is it merely badly
writte
35 matches
Mail list logo
