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."
SystemTime = CurrentDataBaseTime
TimeDifference = LocalTime - SystemTime
Now = LocalTime - TimeDifference
I think we are starting to see that perhaps defining sanity solely in societally-defined terms might not always be an appropriate methodology.
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.
Who gives a fuck
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...
The so called "Internet of Things" is totally irrelevant! Its ONLY purpose is to give corporations and governments (which are the same thing in most countries now) more ways to spy on people and take away their rights, especially the right to privacy!
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.
Since we're connected to the IOT already ..... just have a reasonably accurate local time source, and synchronize the time once a day.
Is NIST hoping for some extra funding?
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.
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.
Who cares? Consumers not totally nutz; they are not going to buy into the Internet of Things.
Since the "Internet of Things" is either Maker/Hipster fail, or Government surveillance, there's really no value lost if it can't happen. /also, I run my own time server, thank you, your piddly port 123 traffic won't escape.
Right ON !
Power to the people.
The IOT is a massive surveillance grid by Google, Facebook, NSA, and all their partners and shills.
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.
So my oven turns off a few seconds later, who care. Kidding
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?
At least, I am sure I read that somewhere.
And if not, it should be fairly trivial to do over existing infrastructure, especially now that spectrum has been freed up in most countries with the digital TV and radio push.
More to the point, if we are speaking mission-critical systems like car control, train control, plane control, people WILL create these systems for it. It is the easiest way to do it since all it needs is a software update. (of course, bureaucracy nonsense will obviously get in the way and make that price $100,000 for an upgrade to the software that would be rolled out, and it would be buggy, broken, and cause plains to crash unless the Scorpion team get on it)
At least as far as Android is concerned it is endangered by an incredibly buggy implementation of the Bluetooth LE stack.
Je me souviens.
Its hardly the only thing by which "Internet of Things" is endangered. Its far from the biggest threat I'd even say.
and as long as they rule us, we're not going to be allowed to have it. Their kind simply can't comprehend the concept so they hate us for being smarter than them. That is how they do.
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.
Isn't this exactly what real time os were developed for and used by millions of computers everywhere to do? Greater scheduler control and guaranteed execution. This article is stupid.
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...
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.
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.
It covers a wide berth of timing related topics and is information dense. I found no marketing BS in this paper at all.
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.
There has been done some good progress in deploying good clocks. The LTE network carry a IEEE1588 clock syncronzied, where it is synconized with a GPS clock at the base station.
./
You're in the wrong place.
" self-driving cars will need far higher standards in order not to put lives at risk."
Well, if you can't even build an ignition-lock that doesn't kill people, it can get hard.
SoulSkill, the article at TheStack is talking about RealTimeProcessing, which means the decision must be made in xx time or else.
HardRealTime systems are found in a car's anti-lock breaks. They MUST decide in a given time (e.g., 1/100th of a second) or the output is totally useless.
SoftRealTime systems are found in VOIP systems. The MST decide in a given time (e.g., 1/100th of a second) the the output is of greatly reduced quality.
This has nothing to do with NETWORK TIME or a RealTimeClock. They are not talking about 3pm. They are talking about always deciding something very fast for safety reasons.
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.
There is no dependency on Time (as in Friday at 3 pm). There is a requirement for accurate frequency, self-clocking, and frequency/phase locking. These problems were solved in decades ago. Nothing of any consequence whatsoever uses Time-of-Day for anything other than interacting with humans -- it is far to inefficient and a highly stupid way to sychronize events.
The only thing time (as in time of day) is useful for is display to humans since humans are (mostly) incapable of computing the correlation factors required to account for differences in local tick counts between disparate frequency/phase locked systems.
Because I'd like to know which products to run away from screaming if I ever see them.
"Things which are directly responsible for life safety" and "things which are write-accessible via the Internet" should be one hundred percent disjoint sets. Note that this does not imply that life-critical systems cannot have *components* which are IOT, only that life-critical parts absolutely may not be write-accessible via IOT components.
I don't care if a car has an IoT system, or a nuclear plant's status monitors get screen-scraped for some silly web app. But if you're a system designer and you would let an Internet-accessible device do anything but passively look at the engine controller, or the reactor's control rod drive system, you need to be locked up for being criminally insane.
"Hey APK.. you only get to say something when you actually write a piece of software that does not need a 3 year education for the operator to work with it" - by I4ko (695382) on Wednesday March 18, 2015 @04:22PM (#49286645)
See subject: It doesn't - just an IQ above 10 below plantlife (like yours isn't obviously). You only get to talk to ME that way when you can do better YOURSELF, blowhard.
---
"and... err... you know.. .actually works, instead of just taking 100% cpu for 4 hours." - by I4ko (695382) on Wednesday March 18, 2015 @04:22PM (#49286645)
My system does nearly 4 million record entries in well under 35 minutes (older Core I7 920)!
I'd think a "bigshot product manager" like YOU CLAIM TO BE could afford the same or better system as I possess - apparently not (you must be a shoe salesman @ best/most then).
---
"when the same can be achieved with curl/wget, bash, grep, sort and cat under Cygwin in less than 3 minutes.... Your software does not work" - by I4ko (695382) on Wednesday March 18, 2015 @04:22PM (#49286645)
Doubt it. You don't seem to UNDERSTAND how the data for hosts files works then (obviously) - it's NOT that simple since many providers of them use diff. formats + pack the files with a LOT of "b.s." comments etc. & junk - to get the BEST hosts file, my program shears ALL OF THAT, clean away (string processing's expensive on CPU, but then again, seeing you're a mere "mgt. STOOGE"? I can see your lack of education, experience, & understanding on that note... lol, what else can I say?).
Plus, that'd mean installing ALL KINDS OF "moving parts" bullshit with runtimes too (overheads galore) - I do it from 1 SINGLE PART I wrote myself... unlike YOUR LIMITED "skillset" making you USE the tools others wrote (but not you yourself).
APK
P.S.=> Above ALL else? Listen blowhard: Try doing what I did & get results like my ware being hosted & recommended by the folks @ MalwareBytes here http://hosts-file.net/?s=Downl...
... apk
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>