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.
Sounds like another real job for a "quantum computer"...
So, we're going back to coding in assembly and calculating the execution time of opcodes, right?
Get free satoshi (Bitcoin) and Dogecoins
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.
so Now == CurrentDataBaseTime?
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.
A regular hissy fit over something they don't yet control.
Why does my toaster need to know the time more accurately than, say, a five minute window? For that matter, why does my toaster need internet access?
For that matter, why the hell do I want my two-ton thin-metal-shelled death trap visible on the internet while flinging its contents (me) down the highway at 80MPH?
Isn't there a radio signal transmitted in most modern countries specifically FOR synchronising times without a hardline or remote purposes?
There is WWV in United States and DCF77 in Europe.
At least as far as Android is concerned it is endangered by an incredibly buggy implementation of the Bluetooth LE stack.
Je me souviens.
Don't forget forcing mandatory upgrades, removing features and charging you to add them back. then announcing that they're moving to a subscription model, and if you don't pay them $500 a month, your house will no longer work.
I remember reading an SF story once where everything was 'smart' and people even had to put a quarter in the lock to get in and out of their house; that's the future the rentier corporations want to see.
Its hardly the only thing by which "Internet of Things" is endangered. Its far from the biggest threat I'd even say.
And, if you don't buy them, the government will mandate them. Smart TVs will allow them to immediately send police or ambulance to your house when something bad happens, and smart themostats will allow them to control power demand for the most efficient energy usage.
DOCSIS cable modems use a Time Division Multiple Access (TDMA) techniques to allow multiple subscribers share their valuable upstream bandwidth. When a cable modem wants to transmit data up to the internet, the data packet must arrive at the cable provider's equipment with a precision around 6.25 microseconds. With this amount of precision, the transit time has to be factored in. Yet this is done all the time with cable modems that cost less than $100 a pop.
There already exists all the technology required to be very, very accurate and precise.
I couldn't figure out, I can't figure out what they are talking about.
I've only seen IoT things that either don't care, at all, about time: all the datakeeping is local, and you can ask them or not ask them about the state and the logs (a fridge or a kettle doesn't care what your clock is),
or IoT things that are real time. that doesn't care what your clock is because they will just want to contact you as fast as possible, like a fire alarm. It really doesn't care what your clock is, it just wants to get the message through as fast as possible - which is a problem, but not this problem.
Locally IoT things are usually also real-time, and then they only care about highest possible bus delays. Like a car. A car doesn't try to talk to itself like it was several IoT devices. A thermostat reads temperature and adjust the power output accordingly in a timely fashion, knowing that the delay between the reading of the temperature and the switching of the relay isn't too delayed (seconds or minutes is also real-time), if the sensor-relay delay is too long it goes into limp-home mode and probably turns off the relay to be safe.
I tried to think of cryptological solutions that required to systems on either side to keep an accurate time, but I couldn't. I know some keycode boxes use time as a factor when they generate the login key, but they really don't keep accurate time and that doesn't seem to be a problem...?
Anyone that come up with a good example?
I think that systemd offers a solution to this problem. It probably includes timekeeping functionality. It also powers all Linux distros, and all IoT devices run Linux. So I don't see why there is even a problem here. All IoT devices could use systemd, systemd will keep the time consistent on all IoT devices, and nobody needs to worry about any of this.
And this works fine even if the time differences are 'positive' or 'negative'?
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? And my password change? And the front door alarm entry? Did that get re-timed, or deleted, or marked as suspicious?
We are going to use the concept of synthetic time to resolve these issues.
I know this is nontrivial. So will the IoT deal with this sufficiently? Do many systems deal with this well?
deleting the extra space after periods so i can stay relevant, yeah.
The log problem you're talking about isn't an issue if you use a robust logging system like systemd's journal. Binary logs are more resilient to time changes than text logs are.
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.
1. Don't let safety-critical decisions be based on unreliable time sources.
2. Let each device tag incoming messages with its own timestamps, which never leave the device. Due to the laws of nature messages can safely be assumed to have been transmitted no later than the time of reception.
I wonder if I should patent this...
These radio beacons aren't very reliable though. A little bit of interference from some nearby electronics can be enough to lose connection.
Article TLDR version: a cluster of microcontrollers (raspberry pis) does not a real-time operating system (RTOS) make.
The article has to do with deadline-based process timing in a dispersed computing cluster. It has nothing at all do with "network time" which means keeping clocks in sync.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Perhaps GP should read up on IEEE 1588-2008 which is also known as the "Precision Time Protocol".
Of not living up to it's marketing. Despite what those idiot investors and marketing folks who over-invested in the buzzword would like us to believe, there will be no internet of things. While one can think of plenty of reasons why any particular object in the house might be slightly improved by being able to share some random status or change to the internet at large; one can barely think of anything that that would greatly improve this behavior. Yes I can get a push notification when the toaster pops... but if I was far enough away not to hear it pop, the toast will be cold by the time I get there anyway. Yes occasionally an internet connected thermostat has allowed me to turn off the heat when I'm away, but mostly it just allows me to tweak it from the comfort of my bed 10 feet away.
Technology, as it becomes cheaper and the the relative usefulness / to expense ratio goes down will slowly creep into every day crevices of our lives, it doesn't change the fact that this is not because the usefulness of having these things done has gone up, but merely the price of the technology to do so has gone down.
It's 3D all over again (and again, and again)... There are a lot of folks that REALLY want IoT to be the next huge money maker, and have invested a lot of their gambling money (That's what modern investing on futures is for the most part anyway) on it being HUGE. I think the only thing huge about IoT will be the disappointment.
- Holy crap, I've got MOD points! Who thought that was a good idea.
There are many broadcasts with time embedded into them. They are not exactly secure as authenticating the time is far harder than receiving it.
For IoT really you have two times the local time that needs to be taken of faith to be right (served from a local trusted source) this is your clock display etc etc etc, it keeps the complexity and recently ever changing timezone bits out of IoT devices. You then have a unix clock few IoT devices should need this level of accuracy or complexity, when they do they should always use a local reference as IoT devices should not expect nor require they have any internet access to function NTP seems to fit this role well. I'm not sure NTP levels of time accuracy and complexity will be needed for many IoT objects alarm systems about all that comes to mind.
No sir I dont like it.
They are the official time keepers, so of course they want the world to rely on their services for better time keeping!
I have seen this with radar processing chains where different component slew the time at different rates, mostly because of differences in the OS and the time synchronisation software. If one part of the chain suddenly steps its time by a second, downstream components reject its messages.
http://michaelsmith.id.au
First only one system on the network needs to actually check with the internet time servers. Everything else can just check that local system. The most damaging thing is not having the time be wrong but the times be out of sync with each other. I'd much rather have all the systems be 4 hours off in the same direction than have them be every which way with some of them using the right time and some of them not.
Second, there are a lot of ways to check the time and the NIST is not the only way to do it. A lot of companies maintain time servers that I've found to be more error free. I sync to them more often than not simply because it works more often.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
You appear to be confusing Republicans with Democrats. Though, to be fair, it's pretty easy to do these days.
The easiest time source nowadays is the almost ubiquitous cell phone system. You don't even need a paid data service to get the time from the local cellsite.
Are there really situations where every frame has to be received? I believe that for most use cases it is fine if you successfully just get one update every now and then.
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.
If you don't want your utilities to spy on how much of their resources you are using, then disconnect from the grid and the pipes.
One way to "fix" that issue is to not have time go backwards, but make time tick more slowly until real time catches up. Servers should be closer to seconds out of sync. Several of my home systems are less than 1ms out of sync with remote servers 80+ ms away from me.
Time is a big issue here with RTOS, not just scheduling but the synchronization with other devices. The devices don't have the same clocks so there often needs to be some synchronization when they talk to each other, especially on networks. All of the wireless protocols we have depend upon accurate timing so that each node knows which channels to be on at which time. The tighter and more accurate you can get this time then the better your network performance is, and as a side effect the more power you save (very important if you're on a battery that needs to last for years without recharging).
The internet of things, which is I agree a vague term, will have categories of things which can not use a global beacon sent by an AP and so much synchronize their time in a distributed manner. This is the sort of thing I see the NIST being very interested in.
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.
They won't be mandatory at first. But insurance will be more expensive for 'the disconnected' because their risks are greater. 'Don't you want to be safe?'
Typical NTP from the public pool seems to be anywhere from 0.5ms to 2.5ms. Which is good enough for practical purposes for most things.
With luck, good components, and good climate control, you can usually manage to keep an internal LAN within about 1/5th of a millisecond. Maybe 1/10th if everything is well behaved.
Wolde you bothe eate your cake, and have your cake?
I am sorry to inform you that there is an old Turkish proverb that states "If my aunt had moustache, then she would be my uncle". This was the first thing came to my mind while reading TFA....
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>
In my experience, the public NTP pool is up to 30ms off. I have NEVER had all of my public pool server agree at the same time, there has always been at least one that is way off.