Re: [LUG] leap second

Thanks Gordon, a well written and useful reply.Â

I have a friend who specialises in trading hardware and has told me some stories of the frankly ridiculous methods they do to to gain insignificant amounts of time, not only in bandwidth as you mention, but also overclocking with super-cooling peltier rigs for desktop computers. Overclocking the fastest processers by over a factor of two.Â

But most people won't care if a process runs a second late, systems are congested, computer loads add latency, and when you consider the state of the copper hung through devon's hedges then well, it's a miracle anything works at all. Ever.

>ÂOr, you write a program to run once a day - there are 86,400 seconds in a day, right? What happens the day after when 86,401 seconds have elapsed...

I wouldn't have a program counting seconds indefinitely without some outside check. I appreciate the OS and the system clock need to be smart enough, but I think regular checking via ntp (whichever method) to reputable outside sources (and I do enjoy using time.windows.com for some servers as a source sometimes, although only from a twisted sense of irony) is the way to go.Â

I'll keep using ntpdate for as long as it's in debian's repos though. NTP is quite large enough already, although you're right about pool.ntp - I do actually use that for most systems as recommended.

But you make some excellent points and although I maintain that an extra second is unlikely to break most systems, it is something that sysadmins and programmers ought to be aware of.

On 10 January 2015 at 14:45, Gordon Henderson <gordon+lug@xxxxxxxxxx> wrote:

On Sat, 10 Jan 2015, Simon Avery wrote:

ÂI think you missed my point. I think Torvalds agrees - this time around,

the leap second isn't going to be an issue for us (as per Daniel's)
question. So b***cks to the scare-mongerers telling us all our website are
going to crash.

Why would they? Can't think why web servers would fall over due to poor
dates - although of course I can't predict what crufty cgi has been written
on every one.

Leap seconds are not new. Neither is British summer time or "Daylight savings" as it's sometimes called elsewhere...

Read comp.risks for the past few decades to see issues virtually every time time changes from winter to summer and back again )-: And that's (usually) one hour - what difference can one second make? Well, lots - and there is lots and lots of poorly written software out there (including one of mine which made it to comp.risks if you can find it :-)

Transactions are now happening with sub-millisecond accuracy - particularly in the financial sectors - a whole second there will make a huge difference - could be the difference between gaining or losing a few million pounds for example...

Dedicated fibre circuits are being installed just to save a millisecond on data going over London - it's that crazy in the fast trading financial markets )-:

Heres a trivial/silly example: You schedule a program to run at midnight. This program pays someone some money. Mignight comes, the program runs, the money moves. One second later at leap second time, it's still midnight, so the program runs again ...

Or, you write a program to run once a day - there are 86,400 seconds in a day, right? What happens the day after when 86,401 seconds have elapsed...

PC clocks are notoriously poor, which is why most folk have ntpdate cronned
once a day, or a full ntp server running to keep things in check.

0 0 * * * /usr/sbin/ntpdate time.nist.gov &>/dev/null

If you have Internet access please use ntp and not ntpdate.

Also the days of time.nist.gov are over. Always better to use the pool servers now if possible, and local ones.

If you have a relatively recent ntp installation, then your /etc/ntp.conf could be as simple as:

# by default act only as a basic NTP client
restrict -4 default nomodify nopeer noquery notrap
restrict -6 default nomodify nopeer noquery notrap
# allow NTP messages from the loopback address, useful for debugging
restrict 127.0.0.1
restrict ::1

pool debian.pool.ntp.org iburst
pool uk.pool.ntp.orgÂ Â Âiburst

The pool command will pick a set of servers from the given pool, or you can pick then directly via e.g. 0.uk.pool.ntp.org etc. They use round-robbin DNS to make them select different servers and balance the load.

NTP and NTPDATE don't touch the hardware clock. NTP will actually work out how much the Linux clock drifts (that's the software one that Linux maintains, not the hardware one), so that if you're off the Internet for a period of time it will correct drift.

Typically with Linux (And other *nix in general), the hardware clock is only read once at boot time and used to set Linuxes software clock - and it's written to at shutdown time - the hwclock program which manages it can also calculate and correct for drift of the hardware clock - assuming you have corrected the time read from it via NTP.

So at boot:
Â hwclock: hardware clock +/- /etc/adjtime -> software clock
Â ntp initialised to jump-start the software clock
Â (This used to be ntpdate)

Running:
Â ntp updates the system clock and calculates drift.

Shutdown:
Â hwclock calculates drift from kernel clock vs. hardware clock, writes
Â this to /etc/adjtime and updates /etc/adjtime

If there is no hardware clock, you'd typically install the fake-hwclock program and this sets the Linux time (at boot) to the time of the last shutdown. (and writes the time to a file at shutdown) then hopefully ntp will correct it later... This is how its done on the Raspberry Pi for example.

Also, ntpdate is being deprecated - as NTP can now do the functions of ntpdate - more bloat to NTP rather than a separate dedicated program, but that's progress for you.

FWIW: I have designed a software implemented hardware clock for Linux and once managed to get "timelord" as part of my (sadly unofficial) job title.

Time is an illusion ...

Gordon

--
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq