Slashdot Mirror
Internet of Things Endangered By Inaccurate Network Time, Says NIST
An anonymous reader writes: Current standards of network timekeeping are inadequate to some of the critical systems that are being envisaged for the Internet of Things, according to a report (PDF) by the National Institute of Standards and Technology (NIST). The report says, "A new economy built on the massive growth of endpoints on the internet will require precise and verifiable timing in ways that current systems do not support. Applications, computers, and communications systems have been developed with modules and layers that optimize data processing but degrade accurate timing." NIST's Chad Boutin likens current network accuracy to an attempt to synchronize watches via the postal system, and suggests that remote medicine and self-driving cars will need far higher standards in order not to put lives at risk. He says, "modern computer programs only have probabilities on execution times, rather than the strong certainties that safety-critical systems require."
That's assuming self-driving cars and medicine have any place at all on the internet.. Which they don't, if you ask me.
The network is not necessarily involved. The example given of a self-driving car talks about the amount of time taken to distinguish between a plastic bag blowing in the wind and a child running in front of the car. This is not "network" timekeeping, just regular real-time processing.
There is no "now" [1]. If you're relying on accurate timing from a network, you're already broken. If you require accurate local times, then you know that and know the error terms on your clocks. Standard OS clocks only tick at about 100hz, so you're always out by an average of 5ms anyways.
[1] https://queue.acm.org/detail.c...
Nobody has ever depended on accurate time synch delivered over a network system with zero guarantee of packet delivery, let alone guarantee of delivery time. NTP has always just been "Good enough" to make sure your systems to be on the same date/time so things can synchronize in a somewhat organized fashion.
Anything requiring honestly accurate time synch has always relied on external synchronization schemes. Ultra-accurate clocks, sometimes synched with outside networks that /do/ have guarantee mechanisms.
But that was in the past. Long gone are the days of special 1000 dollar add on-cards for scientific and specialized computing applications.
Now you can get a GPS chip for 25 cents and draw a half-inch antenna on the outer edge of your PCB.. And guess what? High quality, accurate time sync that rivals the most expensive solutions from yesteryear. Fuck. The SoC that your IoT device is running on probably has half of that circuitry already built in (Along with Wifi, bluetooth, etc) so your GPS transceiver chip probably only costs half that.
I am a professional real-time embedded software engineer working with mission-critical networking devices. I don't buy the claims in the article because I don't understand _why_ internet-of-things devices need to have tight time sync or be real-time deterministic.
Accurate time sync is challenging - especially if you have wireless asymmetric links with non-deterministic latency.
Rather than trying to fix time sync, we should be questioning the reasons why we require tight sync to begin with. It is definitely necessary in certain situations, but those are far from the norm. In most cases where lives are not at stake, it's way easier and more sane to implement your system such that it does not need super accurate time sync.
Dice.com.
The clocks are hyper-accurate, world accessible and the technology is sufficiently robust and mature to be considered essentially bulletproof. It relies on a broadcast technology that scales to any number of receivers you care to connect and doesn't get bogged down by additional loading. Best of all it's managed and maintained by the US Government - but it works correctly anyway.
Anyone who is designing such systems around "accurate time" hasn't got a freaking clue how to build such systems.
For example, when dealing with spacing on self-driving vehicles, you rely on radar or laser tracking to maintain the separation between vehicles, not some wildly inaccurate network message about the velocity and position sent by other vehicles.
Medical in particular baffles me. Who in their right mind would design a medical system that synchronizes with anything other than the patient's own body rhythms?
But hey, that's what happens when you get some simulation designers trying to apply their single-clock logic to complex systems. They don't think about how real systems work -- the problem isn't an inaccurate time value -- it's an inaccurate understanding of the problem itself.
I do not fail; I succeed at finding out what does not work.
There's also GPS, for which receivers are very cheap and which provides very accurate time.
This article is nonsense. Assuming IoT ever becomes an actual thing, the vast majority of devices won't need any better than the "good enough" that NTP provides. Those that do will probably manage their own time using accurate clocks and GPS.
Time patronization rarely matters. Usually you need an accurate clock (i.e. exactly 100hz) way more than you need your time to be within 0.100ms of someone elses time.
The article talks about synchronization of time between systems and processes, not accurate time, as in my watch is 5 minutes fast.
If a self driving car is seeing something in front of it and launches an app to determine what that object is, then that app needs to return an answer before the car hits the object and in time to brake to a stop, if necessary. It needs a time signal to understand how much time it has left. The problem, in this situation, is that without some sort of accurate time signal and time synchronization, the object recognition app could take more than the remaining time to develop an answer. Of course, you could launch a second app that acts as an emergency braking program that will hit the brakes in time, even if the object recognition app hasn't returned a result. The problem here is that you still don't know within a rigid level of certainty that the emergency baking app will complete in time.
In many ways you can see this exact same problem with inexperienced drivers. It takes them longer to process what's in front of them and decide to hit the brakes or not. An experienced driver almost has an automatic awareness ("muscle memory") that gives them an advantage when reacting to situations that they have encountered before.
My thought is that as these scenarios become "learned", they can be moved to "muscle memory". For example, most firewall devices rely on application-specific integrated circuit (ASIC) for real-time firewall rule evaluation. It seems to me that self-driving cars will require their own version of ASICs that contain "rules of the road" and evaluation shortcuts to handle real-time events without having to rely on time signaling.
SystemTime = CurrentDataBaseTime
Delay = LocalTime - SystemTime - TimeDifference
TimeDifference = LocalTime - SystemTime - Delay
Now = LocalTime - TimeDifference
There, corrected it for you. Now you try to figure this problem out.
It covers a wide berth of timing related topics and is information dense. I found no marketing BS in this paper at all.
It's when LocalTime appears in the future that the fun begins. Snap LocalTime back a few seconds to sync with CurrentbaseTime, feh, probably livable. But make it more than an hour, and do you risk having all of those log entries either being reset to some arbitrary time, or do they have to disappear?
I once worked on the kernel of a system that had to deal with time updates very carefully to avoid screwing up various user land apps whose programmers never considered that a time delta could be negative. Rather than snap the current reported system time to the correct time I would slow down or speed up the progress of time until reported and actual got sufficiently close.
The Time Rift of 2100: How We lost the Future --- and Gained the Past.
WE CAN ONLY BLAME OURSELVES for the Time Rift. From discrete logic to main boards to chipsets to picoboards to nanite molecular clusters, we had machines re-drawing the same machines on smaller scale until they were like dust and pebbles, and yet, everything worked pretty well most of the time.
THE DISTINCTION between software and hardware had merged, workable modules open sourced and refined with a really clever interconnection scheme. Somewhere along the line we left hardware design from 'scratch' --- and software design to the 'code' level --- behind. Things were no longer constructed for purpose. Software was no longer compiled. We began to plug and play and clone and shim.
IT WAS HUMANS, amateur enthusiasts even, that first cloned and shimmed small machines into other machines of similar more refined purpose, and they did it with the same techniques we had used to construct analog circuits: locking together this way, and securing with that, test and done. There was an art to it. Where one had once meshed APIs together in the synchronous communications realm, now it was a matter of finding the proper angle and orientation of these smart pebbles, based on their markings and unique shapes. There was a flair to it, and some of this art was as much judged by its appearance as by function.
BUT SOON WE GREW WEARY of that, and trained our machines to clone, shim and assemble these smaller machines. It was like some cyborg Tetris game where your challenge was to fit the pieces together as they fell from the sky. And the sky was full of pieces. Anything was possible if your reach was long and you gazed far enough, to grasp the perfect puzzle-piece.
A FEW RESPONSIBLE ENGINEERS of the era took the time to publish diagnostic procedures with which one could fix these amalgamations, should one have the patience to pull them apart to do so, like the SAMS Photofacts of old. Every piece had its own direct interface for configuration and in theory at least, one could fix problems or reconfigure the pieces by simply talking to them directly. They documented these diagnostic and configuration interfaces, often cribbed from the documents of other engineers, which were scarcely ever used now, probing them to discover the more primal pieces within to gather documentation on those too.
BUT IT WAS THANKLESS to do so, and these engineers found themselves out of work or forcefully retired. Their productivity paled besides younger geniuses who were simple hunter-gatherers, whose cleverness in assembling working prototypes was deft and swift. From concept to bubble-wrap technology companies had little interest in deep documentation. It was seen as a fetish. The thing works! Clone it and done. These hastily made things flooded the market and soon replaced other well-documented things. At times something failed and its inventors could not say why, they just assembled a new one or went bankrupt.
IN A SAD IRONY as to the supposed superiority of digital over analog --- that this whole professionon of digitally-stored 'source' documentation began to fade and was finally lost. It had became dusty, and the unlooked-for documents of previous eras were first flagged and moved to lukewarm storage. It was a circular process, where the world's centralized search indices would be culled to remove pointers to things that were seldom accessed. Then a separate clean-up where the fact that something was not in the index alone determined that it was purgeable. The process was completely automated of course, so no human was on hand to mourn the passing of material that had been the proud product of entire careers. It simply faded.
THEN SOMETHING TOOK THE INTERNET BY STORM, it was some silly but popular Game with a perversely intricate (and ultimately useless) information store. Within the space of six months index culling and auto-purge had assigned more than a third of all storage to the Game. Only as the Game itself faded
<blink>down the rabbit hole</blink>