Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Networking Books Media The Internet Book Reviews

Expert Network Time Protocol 260

Posted by timothy from the this-will-make-you-smile dept.
Ben Rothke writes "If you review the thousands of Internet RFCs, you'd be hard pressed to find a protocol that lends itself to philosophical overtones, save for one -- the Network Time Protocol (NTP). The nature of time is abstract, difficult to measure and highly subjective. Yet time is a critical element in everyone's life, and in the effective operations of corporate networks." Read on for the rest of Rothke's review.
Expert Network Time Protocol: An Experience in Time with NTP
author Peter Rybaczyk
pages 176
publisher Apress
rating 9
reviewer Ben Rothke
ISBN 1590594843
summary Expert Network Time Protocol is a fascinating look into NTP, and the stories behind the science


NTP is built on top of the TCP/IP protocol suite and is used to ensure accurate time-keeping with a trusted time reference. These references can be radio signals, GPS satellites, atomic clocks, Internet-based time servers and more. NTP is powerful enough to synchronize network clocks with millisecond accuracy.

In Expert Network Time Protocol: An Experience in Time with NTP, Peter Rybaczyk merges the philosophical aspects of time with the nuts of bolts of the NTP protocol. The book is composed of two parts, the first concerned with the meta-philosophy of time, and the second detailing the inner workings of NTP. The attempt in part one to merge technology and science with philosophy is a daunting task, and most often does not succeed. The notable exception to this is Douglas Hofstadter's Gödel, Escher, Bach: An Eternal Golden Braid.

Rybaczyk creates Sam, a fictional character who walks through the history of time. It is unclear who this Sam is -- whether he is supernatural being, or someone who got root on a time server. The author writes that the transcendental nature of time and the nuts and bolts of NTP are inseparable, but I personally found it difficult to determine what message part one was meant to convey. Fortunately, part one takes up but the first 34 pages.

Where the book shines, and where most readers will find value, is in part two, which details how to effectively design, configure, deploy and operate NTP. Where part one is conceptual, part two is extremely practical. Chapter 3 opens up with a comprehensive overview of the what, how and why effective time-keeping via NTP is needed.

The book details from a business perspective why synchronized and accurate time is a universal need. From transactional integrity, airline departures, sporting events, job shift changes, to FedEx pickups and more, nearly every activity requires time synchronization to work at peak levels. Effective network administration also requires time synchronization for network login procedures, directory synchronization, backups, and routing stability to work accurately.

From an information security perspective, password and digital ID synchronization, log file accuracy and auditing, and access control security are just a few of the areas where correct time can mean the difference between success and failure.

Where time synchronization is crucial, though, is in the realm of digital forensics. An otherwise painstaking digital forensic process might be worthless if time-related evidence from network devices is not correctly synchronized. If network devices are not correctly synchronized, you can basically forget about using them in any type of legal case.

Attorney Ronald Coleman, partner and computer law litigator at the New Jersey-based Coleman Law firm explains that in a computer law case involving serious discrepancies in network log times, the prosecution would conceivably drop the case. Similarly, a civil case to recover damages from an attacker is seriously undercut by these seemingly innocuous timing mistakes. "The network managers' lack of diligence at ensuring that the time was synchronized on their systems," explains Coleman, "opens them up to serious questions in front of a jury as to whether the logs and the system data are reliable at all -- especially with a gap of more than a couple of minutes, which might be explained away by which clocks were being relied on." In fact, an error of this magnitude would make the entire network administration suspect. That could be a disaster, Coleman says, where the network tracing record plus the human beings who sloppily set the automation in motion are going to be the chief sources of evidence against the alleged computer criminal. "A snafu such as seriously unsynchronized logs is just the sort of opening that could raise the level of doubt needed to undermine the other side's case."

Chapter 3 concludes with an interesting look at the cutting edge of time protocols, specifically the Interplanetary Internet. The Interplanetary Internet project is an attempt to synchronize computer time within the realm of deep space. NASA will in due time establish a deep space infrastructure whose purpose is to support the communication needs of multiple missions. Such an infrastructure would require time synchronization, but within a radically different framework from what exists today. The Interplanetary Internet and its underlying time synchronization are intended to solve that.

Chapter 4 brings the reader back to earth and provides vital information about how to design an effective NTP architecture. The key to designing the most appropriate NTP architecture for a given infrastructure is to first understand the different modes that NTP devices can operate in. The chapter details the five different NTP modes, the mode categories, and gives configuration information about each mode.

The chapter also provides information about NTP security. While NTP versions 3 and 4 provide added security (including symmetric private key cryptography and support of the Autokey protocol), it is ultimately up to the organization to determine what level of NTP security they need. Those organizations that don't require accurate time won't need much NTP security. But for those organizations who business requires synchronized and accurate time, such issues will drive the implementation of how they deploy NTP and its security functionality.

Chapter 5 details how organizational motivations (again, from a business perspective) will affect how you design your NTP architecture, and then describes several use scenarios. The book notes that designing an effective NTP deployment is a process that embodies four key steps: choosing a time source, deciding upon the NTP topology, determining the NTP features to configure, and then monitoring and managing the NTP operations. The chapter then goes on to describe various ways these steps can be carried out. The chapter provides a comprehensive overview on how to deploy NTP, be it on a dedicated time server, via already deployed products such as Cisco or Juniper routers, or on Unix/Linux/Windows file servers.

It is important to note that NTP is just the protocol. The actual implementation of NTP requires separate software client and server applications. The book focuses on the protocol and does not get into any specific vendors, other than a few screen shots from the configuration menu of a Symmetricom time server.

The author notes that on the surface, NTP is simple and almost inconspicuous, and overshadowed by better-known protocols such as HTTP, FTP and DNS. But once you start digging into NTP, you are dealing with one of the most pervasive elements of existence, namely time. Within NTP's scope, one could be dealing with atomic clocks, GPS satellites, clock selection, encryption algorithms and much more. So while at its heart, NTP may be a simple protocol, there is a complex infrastructure beneath it.

NTP is one of the most fundamental, yet overlooked services in the TCP/IP suite, and time synchronization is one of the most overlooked areas in networking. Hopefully, a book such as this can spark a renaissance. For far too long, time synchronization has not been afforded due diligence, and the effects have at times been disastrous. A view of the archives of the Risk Forum digest attests to this fact.

After a somewhat murky start in part one, Expert Network Time Protocol: An Experience in Time with NTP provides the reader with a superb synopsis of nearly everything he needs to know about NTP and effective time synchronization on his network, from an experienced implementer in the field. It is a fascinating look at one of the most humble, yet fundamental protocols on the Internet. For those who care about the correct time on their network, this book is required reading.

Ben Rothke, CISSP is a New-York based security consultant with ThruPoint, Inc. and the author of Computer Security: 20 Things Every Employee Should Know. He can be reached at ben@rothke.com You can purchase Expert Network Time Protocol: An Experience in Time with NTP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Expert Network Time Protocol More

Expert Network Time Protocol

Comments Filter:

  • I thought I had time to read this (Score:4, Funny)

    by Anonymous Coward on Friday August 19, 2005 @02:09PM (#13356661)
    But I just synched my clock and it turns out I'm ten minutes behind.
  • It was far too long and I have far too little time to read it.

    • Cliff sez... (Score:5, Insightful)

      by fm6 ( 162816 ) on Friday August 19, 2005 @02:41PM (#13356932) Homepage Journal
      There's this protocal called NTP that's used to synchronize computer clocks. That's not enough to fill out a book, so the author padded it out with a lot of stuff from history and philosophy. At least, that's my summary of the review.

      Really, all most of us need to know about NTP can be found on Ntp.org. [ntp.org]. Particularly useful is their NTP Pool project [ntp.org], which uses DNS aliasing to allow you to sync from random servers, and avoid placing a burden on any one server.

      • Re:Cliff sez... (Score:4, Insightful)

        by EvilTwinSkippy ( 112490 ) <yoda AT etoyoc DOT com> on Friday August 19, 2005 @03:22PM (#13357330) Homepage Journal
        You know, people manage to fill books on just about anything. And the padding usually centers around the Philosophy behind it.

        (Glances at shelf... sees "Longitude", Talbot's "The Holographic Universe", Glieck's "Chaos"... Ok, I never did read Longitude. That was for a Engineering Humanities course.)

        • Re:Cliff sez... (Score:4, Informative)

          by hal9000(jr) ( 316943 ) on Friday August 19, 2005 @03:56PM (#13357661)
          Duuuude. Longitude is a brief history of the development of navigation and an interesting read. Whoda thunk that determining your longitude would be such a problem. Besides, it's short. But what I have found is that many, many technical books are either way to general about things you need to know and way to specific about stuff you do.
        • You should read "Longitude" [amazon.com]", it is really good
        • The books you cite are about the history and philosophy of navigation, chaos, etc. If this book pretended to be along those lines, you'd have a point. But it doesn't. It's an NTP handbook, supposedly written for people who want to use the NTP protocol.

          I read about the H&P of various obscure subjects myself. (And watch people's eyes glaze over when I talk about what I've read!) But I read about them in books that are about, not technical manuals that need filler. And yes, they're filler, because they'r

    • Chapter 1: Meet Sam

      Chapter 1: Sam sets up NTP on Linux
      Section1: Sam meets the man in the Red Hat: In this chapter Sam types rpm -i ntp.rpm && ntpd
      Section2: Sam meets Mandrake: In this chapter Sam types urpmi ntp && ntpd
      Section3: Sam meets Gentoo: In this chapter Sam types emerge ntp && ntpd
      Section 4: Sam meets Debian and battles the GNU: In this chapter Sam types apt-get install ntp && ntpd

      Chapter 2: Sam set up NTP on other Unixes
      Section 1: In this chapter Sam

  • Minor correction (Score:3, Informative)

    by Bandito ( 134369 ) on Friday August 19, 2005 @02:13PM (#13356698)
    NTP is built on top of the TCP/IP protocol suite and is used to ensure accurate time-keeping with a trusted time reference.

    Ummm, doesn't NTP run over UDP?

    • Re:Minor correction (Score:4, Informative)

      by EvilTwinSkippy ( 112490 ) <yoda AT etoyoc DOT com> on Friday August 19, 2005 @02:17PM (#13356721) Homepage Journal
      UDP and TCP are part of TCP/IP. (Just a question of whether we are working on level 3-4 or 4-5 on our OSI model.)
      • There is UDP/IP and TCP/IP.
        • There is UDP/IP and TCP/IP

          No, there isn't. In common parlance, TCP/IP means all kinds of network protocols running on top of IP, such as TCP, UDP, ICMP, and others. If you specifically mean only TCP, then you just say TCP, not TCP/IP.

          • Well, there is a UDP/IP [faqs.org] defined a little later in the RFC, but you're right there is also the TCP/IP Protocol Suite [faqs.org] which is the combination of them all. So, I guess technically UDP is part of TCP/IP. But even the RFC on TCP/IP says:

            A more accurate term is "internet technology".

            Which I would assume would imply that they thought that the clumping together of TCP/IP was kind of misleading.

        • Bugger. I guess I'm going to need a seperate ISP feed if I want to use both networks the same time.
          • The network is an IP network. TCP and UDP can run on top of IP networks. Although, as I digressed from my original oppinion above, I do realize that TCP/IP is an officially recognized term for the combination of all the recognized technologies. Originally, I was just under the misconception that TCP/IP was just a term that came out of common usage. But now I know there is even a whole RFC devoted to it. My bad. But UDP still has nothing to do with TCP in general.
      • I am sure I will be modded down, but what the heck....

        UDP and TCP are part of TCP/IP. (Just a question of whether we are working on level 3-4 or 4-5 on our OSI model.)

        Ummm.... TCP/IP and OSI were designed to be completely separate networking protocol suites. Ultimately, TCP/IP does not mesh well with the OSI model.

        After the failure of anyone to actually impliment OSI, it became a great tool to confuse wannabe network techs.

        For the record, TCP/IP was designed around (and runs on) a 4-layer model. This mod
    • That's what I thought. I use NTP deamons all the time, I always edit etc/ntp.conf to fetch the time from several time servers.
    • At least rdate uses TCP by default, and UDP is optional.

    • Re:Minor correction (Score:3, Informative)

      by fo0bar ( 261207 )
      > > NTP is built on top of the TCP/IP protocol suite and is used to ensure accurate time-keeping with a trusted time reference.
      > Ummm, doesn't NTP run over UDP?

      The term "TCP/IP protocol suite" is somewhat of a misnomer. It is a network model that is comprised of:
      * Application (OSI layers 5-7)
      * Transport layer (OSI layer 4)
      * Internetwork layer (OSI layer 3)
      * Network Interface layer (OSI layers 1 & 2)

      As such, UDP is a Transport layer protocol of the TCP/IP network model. Fun, ain't it?

      • Re:Minor correction (Score:5, Funny)

        by e2d2 ( 115622 ) on Friday August 19, 2005 @02:57PM (#13357036)
        Actually OSI layers 1 and 2 are the physical and data-link layers respectively. Not related to TCP/IP.

        But this is all academic. Let's talk about boobies, err, I mean NTP.

    • "TCP/IP" is a misleading term. UDP is based on IP and so is TCP. When someone refers to "TCP/IP" they really mean anything built on IP. A better name might be "TCP/UDP/IP".

  • meh (Score:4, Insightful)

    by ResQuad ( 243184 ) * <{slashdot} {at} {konsoletek.com}> on Friday August 19, 2005 @02:15PM (#13356710) Homepage
    Does this really matter? I mean NTP works, which is great, so do I really need to understand the "meta-philosophy" behind NTP? All I know is that I have the two Domain Controllers sync to 6 outside machines (reliable servers), and all the machines internally sync off thoes two.

    All the computers in the network are within a second of eachother - and thats good nuff for me.

    • Re:meh (Score:5, Informative)

      by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Friday August 19, 2005 @02:29PM (#13356836) Homepage Journal
      Does this really matter?

      Yes, if you're into the meta-philosophy of timekeeping. If not, then the first part of this book obviously isn't for you.

      All I know is that I have the two Domain Controllers sync to 6 outside machines (reliable servers)

      Do you know enough about NTP to be able to evaluate whether those are good sources? If not, then the second part of this book may be useful.

      All the computers in the network are within a second of eachother - and thats good nuff for me.

      ...you hope. As the reviewer said, precise synchronization is absolutely critical for forensic purposes. Can you conclusively demonstrate that Event A on machine Foo occurred before Event B on machine Bar? Would you be willing to testify to that fact if a conviction or monetary judgment were on the line?

      Even if you don't think you need it, it's so trivially easy to get millisecond accuracy on all but the most unstable tickers that I never have understood why people don't sync their computers. If nothing else, it's nice to be able to set your watch to a known-accurate time source, then use that to set the rest of the clocks in your house. Am I the only one that hates seeing different times on the combination oven and microwave that has two separate displays within two feet?

      • There is very little done that I know of that requires millisecond accuracy. I'd be willing to testify that the times were syncronized with in +/- 1 second on all the machines in the office.

        If you think your machines are synced closer than that... your probably lieing. Remember that the internal clocks run at slightly different rates between hardware vendors. While two nearly identicle machines will slow down at the same rate (which is fine), two machines from different companies will speed up/slow down
        • "Unless you have every single machine plugged into a GPS/radio time unit - or syncronizing every minute ... there is just no way to be sure that every machine in a mixed hardware enviroment is exactly the same time."

          Actually there is... a properly set up NTP infrastructure. The NTP server on each host not only periodically resynchronizes to known good time sources, but uses the results of those synchronizations to track the drift of it's own internal clock, which then allows it to compensate (generally quit
        • Remember that the internal clocks run at slightly different rates between hardware vendors.

          That's why we have a drift file [apac.edu.au]. As more and more NTP synchs happen the drift file becomes more and more precise. Maybe a couple days or so depending on update frequency (I usually update at 1024 seconds) the clock will eventually converge with the authoritative time server.

          I once had two machines that were only sync'd about once a day.

          You may want to increase that, if you are concerned about accuracy. IIRC
        • " There is very little done that I know of that requires millisecond accuracy"

          The review mentions forensics, but I would extend it to any time when you need to check log files with time stamps on two seperate machines. Having accurate clocks saves a lot of hassle.

      • Am I the only one that hates seeing different times on the combination oven and microwave that has two separate displays within two feet?

        I don't understand. My clocks always show the same number. On the other hand, I get really annoyed by the flashing being out of sync between all the kitchen applicances...

      • ...you hope. As the reviewer said, precise synchronization is absolutely critical for forensic purposes. Can you conclusively demonstrate that Event A on machine Foo occurred before Event B on machine Bar? Would you be willing to testify to that fact if a conviction or monetary judgment were on the line?

        Well, since different observers have different simultaneity space-times, in general two observers cannot be assumed to agree on whether event A preceded or followed event B. (if it event B does not reside

        • We'll assume that non-relativistic simultaneity is a reasonable model for the current Internet for the sake of conversation. It's more polite for the non-physicists among us.

    • Re:meh (Score:4, Insightful)

      by b0r1s ( 170449 ) on Friday August 19, 2005 @02:30PM (#13356845) Homepage
      Agreed. It should be sufficient to point out a few facts:

      1) It's important
      2) You want to sync at least 2 internal machines to more than one outside system
      3) You want to have internal machines sync against your two internal machines from (2)

      The philosophy of time doesn't need to be in a book about NTP. Waste of paper, waste of print, waste of ... time.

      • Agreed. It should be sufficient to point out a few facts:

        Maybe... but when you really care about millisecond or sub-millisecond timing, you wind up digging pretty deep. And you have to understand that two clocks will differ from each other; you can't have two separate clocks in exact lock-step. At some resolution of measure, they _are_ going to differ over time.

        To complicate matters: Oscillators speed up and slow down. Network traffic varies over time. Network delays are asymmetric. Server response del

  • Windows does not support NTP properly, and most of the earlier versions don't support it at all.

    It works fine in BSD, but you dont need a whole book, just tick the NTP box during the install process. (Linux is probably the same).

  • Subjective? (Score:5, Funny)

    by mybecq ( 131456 ) on Friday August 19, 2005 @02:20PM (#13356753)
    The nature of time is ... highly subjective
    But only when discussed by metaphysical artists approaching the speed of light...

  • A good description of NTP... (Score:4, Informative)

    by shadowmatter ( 734276 ) on Friday August 19, 2005 @02:20PM (#13356756)
    ... without any of that mumbo-jumbo from RFCs can be found here [wisc.edu] [warning: PostScript file]. It's well written, and the safeguards and filtering techniques are very interesting.

    - shadowmatter

  • If you enjoyed this book... (Score:5, Funny)

    by Momoru ( 837801 ) on Friday August 19, 2005 @02:21PM (#13356770) Homepage Journal
    Be sure to purchase these books on other such stimulating topics:

    Ping, For Dummies!
    Gopher: The Next Generation
    All you ever wanted to know about the "yes" command

  • I prefer clockspeed's taiclock (Score:4, Interesting)

    by Lost+Found ( 844289 ) on Friday August 19, 2005 @02:22PM (#13356778)
    DJB's clockspeed package:

    http://cr.yp.to/clockspeed.html [cr.yp.to]

    Includes an SNTP client, TAI client, TAI server, and clock correction program. It's very simple and it keeps my entire cluster to within a very small amount of drift of the atomic clock, with the sync interval doubling at every sync.

    I use SNTP to get Stratum-1 time from NIST, then TAI to serve Stratum-2 time to my cluster.
    • I use SNTP to get Stratum-1 time from NIST

      Don't be so needlessly antisocial. Pick a nice public stratum-2 server [isc.org] and leave the big guys alone. It reduces load (thus latency, thus inaccuracy) at the top and probably gives you better accuracy, assuming you're not in the same building as tycho.

      I'd much rather sync against my ISP's GPS-based NTP server than a better source far away. It's better in every way, and it won't make the stratum-1 guys want to punch you.

      By the way, clockspeed hasn't been updated since October 1998. OpenNTPD [openntpd.org] is a light, modern client that you might wish to consider.

    • It uses the RDTSC assembly command on the x86. While this is good and nice if you don't have a speedstep technology computer, if you do, then the clockspeed of the CPU actually varies, and the RDTSC is defined to increment every clock-edge of the CPU.

      This means that if you have the SpeedStep technology in your computer, then RDTSC is not a reliable time source.

      This should be noted as a particular caveat on anything relying on RDTSC as a reliable timer.
  • I would just like to say that seeing articles like this one... well, it doesn't help speed up the recovery process. It's like leading an alcoholic to the door of a bar.
  • Lunchtime, doubly so. ;P
    • I contend that time is truly an illusion based on our perception of the laws of physics. Consider this: According to our perception of time, events, changes in state, motion, etc., all of these things "take time" to occur. While sometimes we can't precisely know when an event will occur (the uncertainty principle in quantum mechanics, for example) we can say positively that we never perceive all events in the universe occurring simultaneously. Thus we "perceive" the passage of time. However, we also al

  • Damn! (Score:5, Funny)

    by dal20402 ( 895630 ) * <dal20402@ m a c . com> on Friday August 19, 2005 @02:26PM (#13356810) Journal
    the transcendental nature of time

    I tried to explain this to my boss when I showed up for work at 10:30 today. But he's such a moron, he didn't understand it. Instead of being impressed by my knowledge and intelligence, he fired me. Dammit!

  • Biggest complaint (Score:3, Funny)

    by markov_chain ( 202465 ) on Friday August 19, 2005 @02:31PM (#13356852)
    The most annoying thing about dealing with NTP for me was that nowhere in the documentation or on the 'net was there a clear, simple, one-command way to sync a machine's time to a given time server.
  • You need a book for this?

    C:\>net time /setsntp:ntp.yourisp.net
    C:\>w32tm /resync (windows 2k3)
    C:\>w32tm -once (win 2k)

  • He didn't create him (Score:3, Funny)

    by cryptochrome ( 303529 ) on Friday August 19, 2005 @02:43PM (#13356946) Journal
    Rybaczyk creates Sam, a fictional character who walks through the history of time. It is unclear who this Sam is -- whether he is supernatural being, or someone who got root on a time server.

    We do know, however, that he has a holographic partner named Al who talks to a computer named Ziggy a lot, and that he hopes that his next leap will be the leap home.

  • calendar puzzle (Score:5, Interesting)

    by ch-chuck ( 9622 ) on Friday August 19, 2005 @02:45PM (#13356971) Homepage
    At your command prompt type $ cal 9 1752
    explain.

  • Simultaneity (Score:3, Insightful)

    by hcg50a ( 690062 ) on Friday August 19, 2005 @02:46PM (#13356973) Journal
    Chapter 3 (a look at the cutting edge of time protocols, specifically the Interplanetary Internet) should be pretty short.

    In a relativistic universe, the concept of absolute simultaneity is gone. Given two events separated in space (like two nearby supernovae, or two alarm clocks going off), depending on their speeds and distances, two observers may disagree on which one occurred first, even after they make various relativistic corrections for their own speed.

    If two observers can't agree on simultaneity of two events, they will not be able to agree on the correct time.

    Of course, this won't matter practically within the solar system, but between solar systems, it could start to make a difference.
    • even for atomic clock on aircraft, flying from U.S. to London resulting in difference on the order of 53 ns, and 39 ns for return trip, so I'd say that with current computers and their GHz clocks we're slightly into the realm of relativistic effects being noticable on our planet.
    • Timekeeping in space takes relativity into account. They have to, or they would wind up in the wrong place. Interplanetary NTP, IIRC, has some fancy tricks to manage this. Interstellar distances and velocities should make no difference, but we're a long way from that.

  • The question I want answered is. (Score:4, Funny)

    by papasui ( 567265 ) on Friday August 19, 2005 @02:48PM (#13356991) Homepage
    Precisely how long has it been since this guy last got laid.... DON'T ANSWER IT'S AN INFINITE LOOP!

  • With apologies to Peter Lorre (Score:5, Interesting)

    by bobalu ( 1921 ) on Friday August 19, 2005 @02:59PM (#13357051)
    "Time, time, what is time? The Swiss manufacture it, Italians squander it, French hoard it, the Americans say it is money and the Hindus say it does not exist.

    I think time is a crook".

    From "Beat The Devil", 1953:
    http://www.imdb.com/title/tt0046414/ [imdb.com]
  • ...there's a human for every task. For every tedious nerdy task that needs doing you'll find some human who will not only work on it, but will enthuse over the subject matter and do their job well. Whether it's maggot farming or telling the time this is a wonderful thing. But there's no need to tell everyone else about your job.
  • I mean, if I was a protocol engineer making a protocol for synchronising the time between systems, there'd be two packets, one that says "tell me the time" and one that says "this is the time" with a space for the time, and that would be it.

    Maybe this is why I'm not a protocol engineer.

    • I don't really know the nitty gritty either... but I do know that one of the big pieces missing in the two packet system is the time delay. A round trip packet to a random server on the internet for me would be about 150ms, but it varies, a LOT. The time protocol needs to be a lot more accurate than that (well, for some tasks, not so much for others).
    • That's basically NTP. Congrats!

      Of course, the interesting part is that packets don't travel instantaneously. It's not enough to ask what the time is - you also need to know how long it takes the responder to answer. Furthermore, travel times aren't symmetric and you have to estimate how much of the total elapsed time between sending the request and receiving the answer occurs during each leg of the trip. Remember, the other guy faces the same constraints that you do - you can't just ask him for the an

    • Maybe this is why I'm not a protocol engineer.

      I used to be. And I knew Dave Mills, who designed NTP.

      There are quite a number of problems in time synchronization. Here are a few of them.

      • Authoritative source You have to get time from a better source than you have locally. So you need some scheme to identify time source quality. And it has to detect and prevent loops, so you don't get a group of machines all synchronizing to each other and behaving as if they're synchronized to a primary standar
  • Few people need sub milisecond accuracy of full NTP, and if they do there's a few nice servers available for that, for clients a simple client is all you need, and it's not that complex, you send a UDP datagram asking for the time, you get one back with the time in it, if your feeling fancy you can even improve SNTP by calculating network delay and factoring that into the time calculation.
    • The problem of naive SNTP implementations is that varying delays on your link can make the clock jump backward in time regularly.
      That is not a good thing.

  • Set your time wrong, lose your case? (Score:2, Interesting)

    by Anonymous Coward
    This sounds to me like the first thing a hacker should do is to screw up your clock upon getting root: voila, get out of jail free card.

  • I don't need no stinking time server! (Score:3, Funny)

    by phallstrom ( 69697 ) on Friday August 19, 2005 @04:45PM (#13358076)
    I just keep track of the dupes on slashdot. When I see this story again, I'll know it's four hours later... ... give or take a month or two... :)

Slashdot Top Deals

Never test for an error condition you don't know how to handle. -- Steinbach

Close