There’s never enough time. Frances Buontempo wonders what this really means.
Time has flown by and I still haven’t got around to writing an editorial. Given that time passes at a rate of 1 Hertz, or one second per second, claiming that time has flown faster than usual as an excuse is unconvincing. Can one second ever appear faster or slower than usual? Can an effect be observed before a cause? When I look back through text messages on my phone I often see a response to a question before I asked it, since its clock slips, making the timestamp on my message later than that of the reply. I can rearrange the conversion in my head, so it’s not a problem. Does it matter when things happened? Or in the case of an editorial, if it happens at all?
Time can be a real issue in distributed computing. The machines can synchronise their clocks, so that at the same moment they each reset the current time to a chosen time. How do you define a moment anyway? We could become very philosophical very quickly but the requirement ‘Synchronise watches at 06:00 hours’ certainly begs a couple of questions: how can I tell it is 06:00 and where, since local time-zones vary? If you have managed to get all your machines to report the same time at the same moment, using radio signals, or a Network Time Protocol [ NTP ], being careful to avoid doing it too frequently thereby adding network load, you cannot ensure each clock will continue ticking at the same rate. Clocks are said to be ‘syntonised’ if they have the same frequency, even if they aren’t running at 1 Hertz. Often crystals that vibrate at a known frequency are used for time keeping in a computer, however they are affected by various fluctuations in the environment, such as heat, and they age. You can buy a high quality more stable crystal on a PCI but that costs. The IEEE 1588 defines a precision time protocol [ PTP ] for synchronising multiple clocks over a network. While a group of people stood beside each other could get their watches to display 06:00 simultaneously if they turned up on time at the same place to synchronise their watches, the further the message about the current time has to travel the more significant the time taken for the message to arrive becomes. The PTP uses a ‘sync’ and ‘follow-up’ message to overcome this. This still does not deal with frequencies differing between machines, so will have to happen periodically. As noted, more expensive crystal oscillators are less prone to environmental changes, however the topology of a network of machines will still affect time signals. Jitter, or variation in latency, increases with more devices. Network traffic fluctuates. Using software, even following a well-defined protocol can make jitter worse. IEEE 1588 also can be used for hardware time stamping. Rather than stray well beyond my knowledge I will leave an interested reader to, well, read. See [ Dopplinger and Innes ] for example.
If we don’t need sub-millisecond accuracy we do have one oscillator we can currently rely on. The earth rotates at a rate of one revolution per day. How much can you achieve in a day? If I have a day off I tend to make a to-do list, motivated by all the things I feel I need to do. I frequently fail to get more than half way through this. For a while I have started with ‘Item 1. Make a to-do list’. This ensures I at least complete one task. I need to learn to be more realistic in my expectations. I am gradually learning to say “No” or at least “Not yet”. It is ok to have a backlog and just concentrate on one thing at a time. I am noticing how easily distracted I become by emails or following the references in articles and academic papers I read as I try to find out about something. Minimising my web-browser, closing my email client and putting my phone on silent help me to concentrate. Going for a long walk armed only with pen and a notepad, and my door keys, can also help. Once I am ‘in the zone’ I find it easier to be more brutal with potential distractions and time wasting temptations. If a book is only vaguely relevant I can put it aside. The same might happen as I code. If I am concentrating, I can see I’ve gone off in a terrible direction and delete everything and start again much more readily than if it only has part of my attention. Then I am much more likely to slap in a few Boolean flags and experiment until it appears to work. I also tend to under-estimate how long something will take me. If I have a free hour this evening, I tend to think, “I have an ACCU conference talk to write. I have an hour. Therefore I will write a conference talk in an hour.” This is clearly ridiculous. Based on previous experience, I will spend about 50 hours in total, coding up something I’ve never done before and doing a lot of background reading. Sometimes our estimates at work are formed, or even forced upon us, by sales people who have promised a client something will be ready next month, therefore we must ensure it is ready. This combination of backwards thinking and lack of experience inevitably leads to broken promises. The work we are asked to do is often something we have never done before and requires background reading. The sales people have often never written an application before. If they have and claim they could do it themselves in a week, it’s good to avoid the temptation to tell them to get on with it themselves. In one of my first programming jobs, I saw this happen frequently. After many demands to work over the weekend I asked to go with the salesman and be involved in the up-front promise. We made a couple of moves towards a more iterative approach, delivering one small functional requirement that could form a basis of discussion about future work, rather than promising an entire system in three months and failing to get any one part of it working properly. For a small business this means the potential for more regular cash flows, which is a good thing. Again, though, I am straying from my main point.
Is time always important? Why does it always seem to slip by quicker when you need it the most? Does it matter what order things happen in? Lessons from relativity will tell us that the order in which things appear to happen will depend on your standpoint. Sometimes a strictly linear order of events is not required. With my text messages, even without a sequence number, I can reassemble the conversation. With some messaging protocols a sequence number is provided so communications can be reassembled in order if required. This also draws attention to missing packets of data. We can launch things asynchronously and respond when they are done. This can speed things up – true multitasking, rather than constant context switching, is a beautiful thing. It can seem unnatural if you are used to thinking things through in a step-by-step known order. Messages can be time-stamped, though as discussed this will cause confusion if local machines each have their own idea of ‘now’. Things get worse if they don’t all use universal time coordinates, UTC, or GMT if you will. Imagine a log-file, with local-time timestamps and day-light saving kicking in midway through. All your log-files use UTC, right? When your customer says this happen at 6 a.m., do check where they were at the time, as well as what they were doing. One person’s 6 a.m. is another’s lunch-break. If you just have one application you probably just have one log file to search through on one machine. A multithreaded application should obviously have the manners to log the thread id as well as the time stamp. If you have a larger distributed system, with many moving parts including services, middleware, engines, databases and who knows what else, you may have many log files to look through if you want to find out what just happened and why. Chris Oldwood has rant^H^H^H^H written extensively on sensible logging. Through limiting my RIPs (reads in progress) I rediscovered his Overload article on distributed ‘diagnostic contexts’ [ Causality ] and forced myself to avoid re-reading all his blogs and articles. Without going into too many details, just thinking about what you need to see in a log file is important. Next time I write a new program I am tempted to start with the logging, and avoid a big mess that screams “ERROR” at me every few lines, only to be told, “Those errors are normal.” In an ideal world, I would be able to hunt for a specific pattern and unique number in a log file, with a script, and extract the details I need to re-run the scenario to troubleshoot. Be nice to yourself and write better logging.
I am on the verge of running out of space, and time. Log files can leave a trace of what happened when, and are therefore akin to diary keeping. How many of us keep a diary? One of the reasons I am over-optimistic about how much I can achieve is because I do not have an accurate record of how long things usually take me. I have decided to start tracking my time spent on my to-do lists so I can come out with more sensible estimates next time. I might timetable slots for certain things – like reading emails – and only do this in batches to avoid interruptions. I know I waste ages reading things that turn out to be no help, arguing with people about things that don’t really matter, debugging the wrong bits of code because log files lead me astray. Time is precious and easily wasted. Perhaps you can try turning down meeting invites for a month and see if you manage to be more productive. If you track how you spend a day, you might be surprised by the amount of time you spend doing admin tasks. Measuring what’s actually going on often leads to surprising results. In order to learn new things, or tackle ‘chewy’ problems, you need long unbroken periods of concentration. We all recognise the clarity that comes with several hours of focus on one thing. Focus is not an ‘F’ word! If, like me, you feel time slipping away from you, take a leaf out of Richard Feynman’s book, or rather lecture [ Feynman ]:
To do real good physics work, you do need absolute solid lengths of time … it needs a lot of concentration … if you have a job administrating anything, you don’t have the time. So I have invented another myth for myself: that I’m irresponsible. I’m actively irresponsible. I tell everyone I don’t anything. If anyone asks me to be on a committee for admissions, ‘no’, I tell them: I’m irresponsible.
We can choose how we spend our time. It’s ok, and in fact, important to spend time relaxing and having fun. You need to spend time with your family and friends. If you want to achieve great things, or even one specific thing, like writing an email or fixing a bug, you need to make space and time for it. Timetable in a weekend off, or a holiday and timetable in some space to keep learning and achieving great things. Being busy isn’t the same as being productive.
It always takes longer than you expect, even when you take into account Hofstadter’s Law.
~ Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid
References
[Causality] ‘Causality – Relating Distributed Diagnostic Contexts’ Chris Oldwood, Overload 114, April 2013 http://accu.org/index.php/journals/1870
[Dopplinger and Innes] ‘Using IEEE 1588 for synchronisation of network connected devices’ 2007 http://www.embedded.com/design/connectivity/4007059/Using-IEEE-1588-for-synchronization-of-network-connected-devices
[Feynman] in various places, including in Study Hacks Blog: ‘Feynman didn’t win a Nobel by promptly responding to email’ http://calnewport.com/blog/2014/04/20/richard-feynman-didnt-win-a-nobel-by-responding-promptly-to-e-mails/
[NTP] http://www.ntp.org/
[Neville-Neil] ‘Time is an Illusion Lunchtime Doubly So’ George V. Neville-Neil Communications of the ACM , Vol. 59 No. 1, pages 50–55 http://cacm.acm.org/magazines/2016/1/195723-time-is-an-illusion-lunchtime-doubly-so/fulltext
[PTP] ‘Introduction to Distributed Clock Synchronization and the IEEE 1588 Precision Time Protocol’ http://www.ni.com/tutorial/2822/en/
