On 2009-01-01, Laws, Peter C. wrote:
> I enjoyed my extra second, how about you?
All my Linux systems had a fine time. None of them locked up / crashed /
rebooted / etc.
The kernels involved included:
2.6.24-etchnhalf.1-amd64
2.6.18-5-486
2.6.16-2-486
2.6.18-5-k7
2.6.18-4-powerpc
2.4.16-k7
-
David Woolley writes:
>Russell, David wrote:
>>
>> I am suspicious of a particular implementation, especially since one problem
>The point of having a reference implementation for an RFC is that the
>reference implementation is the definitive definition of the algorithm,
>i.e. the reference
Adam Myrow writes:
>FWIW, my computer running Slackware Linux 12.2 had no trouble with the
>leap second. I have ntpd using us.pool.ntp.org. Slackware 12.2 runs
>Linux 2.6.27.7, which seems to be a lot better in terms of the drift
>rate than older kernels in the 2.6 series. When the leap second
> Chris:
>
> Does indeed sound familiar to me here.
>
> I'm working also but with a slightly different fix.
>
> Not using PPS kernel patch as its difficult to add in to the RPM based
> kernels here on Fedora Core 9 so I'm just using the shm driver and
> plain old ntpd. My solution was to fudge the
On Jan 1, 12:38 pm, Evandro Menezes wrote:
> On Dec 31 2008, 8:49 pm, givemeafckingacctyoudou...@gmail.com wrote:
>
>
>
> > So, basically I'm manually adjusting the nmea second reading forward
> > by 1.
>
> > The SHM(0) gps is still fudged to account for normal lag w/ the time
> > given on qnan. H
On Jan 1, 12:38 pm, Evandro Menezes wrote:
> On Dec 31 2008, 8:49 pm, givemeafckingacctyoudou...@gmail.com wrote:
>
>
>
> > So, basically I'm manually adjusting the nmea second reading forward
> > by 1.
>
> > The SHM(0) gps is still fudged to account for normal lag w/ the time
> > given on qnan. H
Unruh wrote:
> "David J Taylor"
>
> writes:
>
>> Unruh wrote:
>> []
>>> Apparently a number of Linux machines completely locked up at the
>>> leap second. Problems in the kernel ntp.c code apparently.
>
>> Oh, that's interesting. Do you have any specific references? I
>> haven't looked at th
Russell, David wrote:
>
> I am suspicious of a particular implementation, especially since one problem
The point of having a reference implementation for an RFC is that the
reference implementation is the definitive definition of the algorithm,
i.e. the reference implementation is correct, by
Dave,
I am sure that the algorithm is great, really. It is just that I can't figure
out from RFC 1305 how it gets calculated: "which can be calculated in a manner
similar to the filter dispersion described previously".
My first attempt was too similar and I ran the same data points th
Sam Nelson writes:
>In article , unruh-s...@physics.ubc.ca
>says...
>> Hans =?iso-8859-1?Q?J=F8rgen?= Jakobsen writes:
>>
>> >On Thu, 1 Jan 2009 12:15:22 -, Sam Nelson wrote:
>> >> In article , h...@wheel.dk says...
>> >>> On Tue, 30 Dec 2008 19:13:51 GMT, lguzm...@mercurio.cl wrote:
>> >>
"David J Taylor"
writes:
>Unruh wrote:
>[]
>> Apparently a number of Linux machines completely locked up at the leap
>> second. Problems in the kernel ntp.c code apparently.
>Oh, that's interesting. Do you have any specific references? I haven't
>looked at the source code, but I would have t
FWIW, my computer running Slackware Linux 12.2 had no trouble with the
leap second. I have ntpd using us.pool.ntp.org. Slackware 12.2 runs
Linux 2.6.27.7, which seems to be a lot better in terms of the drift
rate than older kernels in the 2.6 series. When the leap second
happened, the following
Once upon a time, Unruh said:
>Apparently a number of Linux machines completely locked up at the leap
>second. Problems in the kernel ntp.c code apparently.
I had one Red Hat Enterprise Linux 4 box lock up. However, I have a
half dozen other boxes running the exact same software set (kernel and
Here's the culprit: http://www.pool.ntp.org/scores/209.132.176.4
I'm happy that the pool can weed these guys out.
Now, if only NTP would query the IP periodically at certain events,
such as when coming back from stand by, when a server is a frequent
false ticker or unreachable...
___
>Apparently a number of Linux machines completely locked up at the leap
>second. Problems in the kernel ntp.c code apparently.
2 of mine locked up. They were running 2.6.25 and 2.6.26
1 worked. It was running 2.6.23.
Does anybody have any details on the bug or it's fix?
--
These are my opini
Russel,
he detailed calculations are in the refeence implementation document on
the NTP project page and in the NTPv4 Internet Draft. However, if the
select dispersion is excessive, it isn't because the algorithm is in
error; it's because you really do have large differences in the server
popu
After 30min from the leap second, I checked my NTP client box and
found something interesting. It had 5 pool servers configured, but
one of them was unreachable, so it effectively had only four to work
with. Two of these ran old versions of NTP (4.1.1) and probably were
not aware of the leap seco
On 2009-01-01, George R Kasica wrote:
> WE run over 150 VMs under unix/linux where I work and about 20 ESX
> servers (its actually my day job) so I might be able to help you.
[snip: ESX configuration example]
I've added this to http://support.ntp.org/bin/view/Support/VMWareNTP
--
Steve Koste
On Dec 31 2008, 8:49 pm, givemeafckingacctyoudou...@gmail.com wrote:
>
> So, basically I'm manually adjusting the nmea second reading forward
> by 1.
>
> The SHM(0) gps is still fudged to account for normal lag w/ the time
> given on qnan. Here's my conf with the modified gpsd:
> #Garmin GPS 18x LV
Hi there
Unruh wrote:
> Apparently a number of Linux machines completely locked up at the leap
> second. Problems in the kernel ntp.c code apparently.
One of mine did;
I have two Debian Lenny boxes. Kernel 2.6.26-1-486 on a AMD Athlon, and
2.6.26-1-686 on Core 2 Quad. Both are based on Linux 2
In article , unruh-s...@physics.ubc.ca
says...
> Hans =?iso-8859-1?Q?J=F8rgen?= Jakobsen writes:
>
> >On Thu, 1 Jan 2009 12:15:22 -, Sam Nelson wrote:
> >> In article , h...@wheel.dk says...
> >>> On Tue, 30 Dec 2008 19:13:51 GMT, lguzm...@mercurio.cl wrote:
> >>> http://www.theregister.co.u
George R. Kasica writes:
>On Wed, 31 Dec 2008 17:57:25 GMT, Unruh
>wrote:
>>George R. Kasica writes:
>>
>>>On Wed, 31 Dec 2008 00:20:45 GMT, "David J Taylor"
>>> wrote:
>>
Unruh wrote:
> "David J Taylor"
[]
>> With just the reference clock type 20, I get the accuracy needed.
>>
"David J Taylor"
writes:
>Unruh wrote:
>[]
>> OK, the leap second passed. My one ntp machine handled it fine.
>Same here - a non-event so my thanks to all those who designed and coded
>correctly.
>> Here is the output from my GPS 18LVC.
>[]
>That's most interesting, Bill. I've added it to m
Unruh wrote:
[]
> Apparently a number of Linux machines completely locked up at the leap
> second. Problems in the kernel ntp.c code apparently.
Oh, that's interesting. Do you have any specific references? I haven't
looked at the source code, but I would have thought that ntp.c sounded
like a
"David J Taylor"
writes:
>Laws, Peter C. wrote:
>> I enjoyed my extra second, how about you?
>>
>> I was amused that WWV announced that it was *going to* happen in the
>> 4th minute ... after the insertion. :-)
>Well, thankfully it was a complete non-event here:
> http://www.satsignal.eu/ntp
Hans =?iso-8859-1?Q?J=F8rgen?= Jakobsen writes:
>On Thu, 1 Jan 2009 12:15:22 -, Sam Nelson wrote:
>> In article , h...@wheel.dk says...
>>> On Tue, 30 Dec 2008 19:13:51 GMT, lguzm...@mercurio.cl wrote:
>>> http://www.theregister.co.uk/2008/12/31/zune_death/
>>> claims that zune are locking up
On Wed, 31 Dec 2008 21:21:33 +, David Woolley
wrote:
>TopCut GmbH / Ludwig Öfele wrote:
>> Hello everybody!
>>
>> I am using a debian (testing) linux on a virtual machine of VMWare (in a
>> linux host).
>> I found, that the time in the VM was awfully wrong and hoped to fix this
>> with ntp.
George R. Kasica wrote:
[]
> What sort of weather info do you process? Here is map and forecast
> generation and storage, serving out over web, data collection locally,
> EMWIN data collection and retransmission, and a couple bigger web
> sites.
Essentially - anything which is sent out over the EU
On Thu, 01 Jan 2009 07:43:13 GMT, "David J Taylor"
wrote:
>Laws, Peter C. wrote:
>> I enjoyed my extra second, how about you?
>>
>> I was amused that WWV announced that it was *going to* happen in the
>> 4th minute ... after the insertion. :-)
>
>Well, thankfully it was a complete non-event here
On Wed, 31 Dec 2008 17:57:25 GMT, Unruh
wrote:
>George R. Kasica writes:
>
>>On Wed, 31 Dec 2008 00:20:45 GMT, "David J Taylor"
>> wrote:
>
>>>Unruh wrote:
"David J Taylor"
>>>[]
> With just the reference clock type 20, I get the accuracy needed.
> The PPS line from the GBS-18 LVC i
On Wed, 31 Dec 2008 12:42:18 GMT, "David J Taylor"
wrote:
>George R. Kasica wrote:
>[]
>> I'd be happy to put it in here, but doing so with the Fedora Core 9
>> RPM based code is not something I'm familiar with.
>
>I understand that perfectly.
>
>> I'm used to working
>> with straight source code
On Wed, 31 Dec 2008 18:49:22 -0800 (PST),
givemeafckingacctyoudou...@gmail.com wrote:
>George, You're experiencing the exact same problem as I am. I'll
>probably make a more detailed thread in this group describing it
>later, but basically the programs trying to match the NMEA data with
>the PPS p
On Thu, 1 Jan 2009 00:06:04 GMT, Laws, Peter C. wrote:
> I enjoyed my extra second, how about you?
>
> I was amused that WWV announced that it was *going to* happen in the 4th
> minute ... after the insertion. :-)
>
Here are clockstats log around the (non-)event.
54831 86388.033 127.127.26.0 scpi
On Thu, 1 Jan 2009 12:15:22 -, Sam Nelson wrote:
> In article , h...@wheel.dk says...
>> On Tue, 30 Dec 2008 19:13:51 GMT, lguzm...@mercurio.cl wrote:
>> http://www.theregister.co.uk/2008/12/31/zune_death/
>> claims that zune are locking up due to leap second.
>
> No such claim appears to be ma
"Unruh" wrote in message
news:dcd6l.455$db2@edtnps83...
[...]
> Well, the ntp survey is a "port scan " (one port, but getting no trivial
> information from it). Any law would have a hard time differentiating
> between the "port scanning that is not yours" and the ntp survey.
I disagree. It's
In article , h...@wheel.dk says...
> On Tue, 30 Dec 2008 19:13:51 GMT, lguzm...@mercurio.cl wrote:
> http://www.theregister.co.uk/2008/12/31/zune_death/
> claims that zune are locking up due to leap second.
No such claim appears to be made there. The problem appears to be
something to do with th
On Tue, 30 Dec 2008 19:13:51 GMT, lguzm...@mercurio.cl wrote:
> Dear all
>
>
>
> I am writing an article about the "leap second" of this year. Do you know how
> companies or people can synchronized their time with the "new" one?
>
http://www.theregister.co.uk/2008/12/31/zune_death/
claims that zun
Unruh wrote:
[]
> OK, the leap second passed. My one ntp machine handled it fine.
Same here - a non-event so my thanks to all those who designed and coded
correctly.
> Here is the output from my GPS 18LVC.
[]
That's most interesting, Bill. I've added it to my Web page:
http://www.satsignal.
Laws, Peter C. wrote:
> I enjoyed my extra second, how about you?
>
> I was amused that WWV announced that it was *going to* happen in the
> 4th minute ... after the insertion. :-)
Well, thankfully it was a complete non-event here:
http://www.satsignal.eu/ntp/ntp-events.htm#2008-12-31
My than
39 matches
Mail list logo
