On Mar 30, 5:32 am, Spoon <[EMAIL PROTECTED]> wrote:
> In other words, assume my clock says it is some time last year, and
> gains 1 second every day (11.6 ppm). I don't want NTP to either slew or
> step my clock to the correct time, but I still would want it to fix this
> 1 s per day (11.6 ppm) fr
Redwood City, CA - 2007/04/14 - The NTP Public Services Project
(http://ntp.isc.org/) is pleased to announce that NTP 4.2.4p2-RC1,
a Release Candidate of the NTP Reference Implementation from the
NTP Project, is now available at http://ntp.isc.org/download.
Bug Fixes:
* [Bug 811] ntpd should not
David Woolley wrote:
> ntpd also has a trap reporting mechanism, but I don't know of any
> standard trap receiver for ntpd and you will still have the problem
> of inferring the failure as the local clock will prevent ntpd detecting
> it as a failure.
I don't know anything about this. Care to exp
[EMAIL PROTECTED] wrote:
> Michael L. Semon wrote:
>> 1) Use my current Linux 2.6.18.1 + LinuxPPS and sit and watch as ntpd
>> darts +/- 120 us over the course of a few hours, even when idle.
>>
>> 2) Reboot to FreeBSD and let the kernel, hardpps, and the NTP kernel
>> code make more radical short-
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Hal Murray) wrote:
> Then your goal is not to synchronize B's clock to A's clock, you need
> to synchronize B's clock to the source of your CBR data. How good is
No. He wants to synchronize B's clock to the that of the machine that
is adding ti
>A has no control over the rate of the data stream: A receives a CBR data
>stream from a local device, stuffs the data into packets, and sends them
>over the network. B is not allowed to discard any packet.
Then your goal is not to synchronize B's clock to A's clock, you need
to synchronize B's cl
Perhaps I am revisiting a known topic, and it sounds like you may have 2
problems, one is keeping the time on several machines in sync to a known
degree of precision and accuracy, and the second problem may be strobing all
of these machines to the same master clock frequency.
H
__
The Garmin GPS 18 LVC (or whatever) is under US$80. You'd have to check
with other folks about the prices of different units.
Then it's a function of local reality.
Is it practical to run an antenna wire from your NTP machine to a GPS unit?
Is it practical to put a (possibly very small) machine
>>> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Riccardo Castellani)
>>> writes:
Riccardo> 1. I thought with "restrict default ignore" settings it was more
Riccardo> secure for client, which will reject all packets except for server
Riccardo> A/B. At this time I suppose that "restrict de
1.
I thought with "restrict default ignore" settings it was more secure for
client, which will reject all packets except for server A/B.
At this time I suppose that "restrict default nomodify nopeer notrap noquery"
setting can permitting to client to synchronize itself to server A/B but will
not
Spoon wrote:
> Steve Kostecke wrote:
>
>> If you can receive CDMA cellphone signals in the bunker you could use a
>> product such as the Endrun Technologies PraecisCT:
>>
>> http://www.endruntechnologies.com/network-time-source.htm
>
> Do you know the price of this solution? Is the signal sent i
Steve Kostecke wrote:
> If you can receive CDMA cellphone signals in the bunker you could use a
> product such as the Endrun Technologies PraecisCT:
http://www.endruntechnologies.com/gps-cdma3.htm states:
CDMA is virtually absent in Europe.
Is that statement true today?
Is there another tec
Hans Jørgen Jakobsen wrote:
> Spoon wrote:
>
>> Hans Jørgen Jakobsen wrote:
>>
>>> The master(A) send packets out at its rate.
>>> B answers trying to have N in the buffer.
>>
>> This was my original implementation. It did not work well.
>
> Did you have a buffer large enough to take care of jitt
Hello,
I've found the following articles rather interesting:
http://www.wraith.sf.ca.us/ntp/#bios-issues
http://www.ijs.si/time/temp-compensation/
http://en.wikipedia.org/wiki/Voltage-controlled_oscillator
Regards.
___
questions mailing list
[EMAIL PR
Steve Kostecke wrote:
> Spoon wrote:
>
>> In my situation, I don't care what time it is, but my clock needs
>> to tick at the correct rate.
>
> The least expensive means of getting your clock to tick at the correct
> rate is to synchronize it to the ubiquitous time-base known as UTC.
>
>> I thin
Hal Murray wrote:
> Spoon wrote:
>
>> I'll try to explain my situation in detail.
>>
>> Consider two systems, A and B.
>>
>> A sends ~1000 UDP packets per second to B.
>>
>> A timestamps each packet.
>>
>> These packets travel over an IP network, and suffer delay and jitter.
>>
>> B is supposed t
Maarten Wiltink wrote:
> Spoon wrote:
>
>> Maarten Wiltink wrote:
>>
>>> [...] could you monitor the buffer length and adjust frequency
>>> on system B from that? If it's slowly draining, slow down B a little;
>>> if it's growing, speed it up ever so slightly. Just like NTP does,
>>> really.
>>
>
Richard B. gilbert wrote:
> Spoon wrote:
>
>> Hans Jørgen Jakobsen wrote:
>>
>>> Spoon wrote:
>>>
Consider two systems, A and B.
A sends ~1000 UDP packets per second to B.
A timestamps each packet.
These packets travel over an IP network, and suffer delay and jit
On Sat, 14 Apr 2007 10:43:57 +0200, Spoon wrote:
>
> Here are some links for my own reference:
>
>
> http://www.trimble.com/timing.shtml
> http://www.trimble.com/tmg_acutime2k.shtml -> EOL
Its only RS232 version thats EOL. Differential (~RS485 like) still available.
(Part of Acutime 2000
Harlan Stenn wrote:
> Are you running the kernel time discipline stuff?
> If so, please see http://bugs.ntp.isc.org/740
I'm not sure exactly what "kernel time discipline stuff" means.
(I'm running Linux 2.6.20.5-rt8 and glibc 2.3.6)
My observations do not correspond to the problem described in bu
Brian Debelius wrote:
> Spoon wrote:
>
>> The very hard part (for me) is seeing that B's buffer is in fact slowly
>> draining when there is a lot of jitter on the link between A and B.
>>
>> I've tried using an exponentially-weighted moving average to filter the
>> jitter out, but it didn't work
21 matches
Mail list logo