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 thanks
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:
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 zune are
In article slrnglpbkr.11et@freesbee.wheel.dk, 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
On Thu, 1 Jan 2009 12:15:22 -, Sam Nelson wrote:
In article slrnglpbkr.11et@freesbee.wheel.dk, 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.
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 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 pin
On Wed, 31 Dec 2008 12:42:18 GMT, David J Taylor
david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk 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.
On Thu, 01 Jan 2009 07:43:13 GMT, David J Taylor
david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk 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. :-)
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
On Wed, 31 Dec 2008 21:21:33 +, David Woolley
da...@ex.djwhome.demon.co.uk.invalid 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
David J Taylor david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk
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
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 david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk
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.
[]
George R. Kasica geor...@netwrx1.com writes:
On Wed, 31 Dec 2008 17:57:25 GMT, Unruh unruh-s...@physics.ubc.ca
wrote:
George R. Kasica geor...@netwrx1.com writes:
On Wed, 31 Dec 2008 00:20:45 GMT, David J Taylor
david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk wrote:
Unruh wrote:
In article mg67l.646$db2@edtnps83, unruh-s...@physics.ubc.ca
says...
Hans =?iso-8859-1?Q?J=F8rgen?= Jakobsen h...@wheel.dk writes:
On Thu, 1 Jan 2009 12:15:22 -, Sam Nelson wrote:
In article slrnglpbkr.11et@freesbee.wheel.dk, h...@wheel.dk says...
On Tue, 30 Dec 2008 19:13:51
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
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 LVC 0
On 2009-01-01, George R Kasica geor...@netwrx1.com 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
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
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
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...
Once upon a time, Unruh unruh-s...@physics.ubc.ca 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
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
David J Taylor david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk
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
Sam Nelson s...@ssrl.org.uk writes:
In article mg67l.646$db2@edtnps83, unruh-s...@physics.ubc.ca
says...
Hans =?iso-8859-1?Q?J=F8rgen?= Jakobsen h...@wheel.dk writes:
On Thu, 1 Jan 2009 12:15:22 -, Sam Nelson wrote:
In article slrnglpbkr.11et@freesbee.wheel.dk, h...@wheel.dk
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
Unruh wrote:
David J Taylor
david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk
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
On Jan 1, 12:38 pm, Evandro Menezes evan...@mailinator.com 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 Jan 1, 12:38 pm, Evandro Menezes evan...@mailinator.com 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
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 NMEA
David Woolley da...@ex.djwhome.demon.co.uk.invalid 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
On 2009-01-01, Laws, Peter C. pl...@ou.edu 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
33 matches
Mail list logo
