GPS rollover: introduction of instability is systems?greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
I've been thinking recently about the 22 August GPS roll over and wondering about the chances of this injecting alot of instability into telecom and other time/timing sentive systems (world wide).
As telecom systems have advanced in the use of higher frerquencies to transimit digital information through the telecommunications structures of the world there is a coresponding increase in the vulnerability of these 'gigabit' systems to develop timing incompatabilities, particularly between systems.
Here's what I mean
Let's say that you were in charge of a very primative system that operated on the standard of 1 cycle per second. Since it is a world wide system you must assure that the system remains in synchonization everywhere on the planet so that when the equipment interpretted a certain value on the signal as a one or a zero it understood that this was the fifth bit in a stream and not the fourth or sixth. In order to do this you would have set up a synchronization signal in the system and this synch signal would be propogated all over the world so that the whole world could be in synch. The signal would have to be much more stable than the communication channel it was supporting.
So let's say it had to be accurate to within one tenth (1/10) of a second everywhere on the planet at once. All the equipment would poll this signal periodicly in order to remain synchronized, say every 3 seconds or so.
This system of synchonization also is worked up at high levels of the communications protocol to include a date because we would all like our computer data interfaces to stamp the correct (universal) date and time on transactions regardless of where they were coming from or going to, right? Just as the timing signal must 'tick' so the date must 'tock'.
OK. The present system is operating at 1 cycle per second. But you and your competitors develop newer equipment which operates at 10 cycles per second and the timing signal protocol is upgraded to accomodate the newer more accurate timing needs. The throughput requires the synch signal to be accurate to 100th of a second now but the date and time portion stays almost the same, except it must also now roll over with increased percision.
Well, that was many years ago. Now the communications environment operates at 10 billion bits per second with a next phase planning for 100 billion bits per second. As these speeds have increased so has trafic and the economy of using this medium increased. In fact, now virtually the entire economy of the world is enmeshed in the telecommunication system and 99.99% of all finacial transactions on the planet occure electronicly and are bound to the electronic system.
The system has grown so intensely fussy that there are 100's of satellites and over 200 cesium clocks stationed around the world to keep things in synchonization. Tick tock tick tock, civilization runs on a clock.
The satellites are enmeshed in a complex system with the cesium clocks and ground stations all over the planet. The GPS system is but a part of this.
What happens when the GPS system rolls from epic 1023 to epic week 0?
I suppose we will see.
But I would not want to be dependant (such as a bank account) upon the world telecommunications system between August 21 1999 and March 1st 2000.
I am not claiming that 'satellites will fall from the sky'. But if we lose synchonization in this system then the entire system will have to be shut down world wide in order to restart it. Why? Because you must start from a universally known good point. 1 cycle per second or something like that. Is it possible?
Honest discussion appreciated.
All trolls will be ignored.
-- ..- (firstname.lastname@example.org), July 01, 1999
My wife work for a telephone company (no kidding). Here's what her boss has to say, and she is in charge of the telephone network:
The switches do rely on GPS clocks for synchronization. But they do have backups. There are protocols built in that allow the switches to stay synched up with their internal clocks.
However, this is not a long term solution. They would need to find another synchonization point (the assumption is that they could eventually use the atomic clocks in Colorado).
But the satellites should keep functioning and broadcasting a signal. It's the recievers that are recognized to have a clock turnover vulnerability. And the older ones to boot.
If anyone can correct me, please offer a real technical explanation. I don't want to mislead anyone here, but this is my non-telephone answer from a tele-techie.
-- JAW (email@example.com), July 01, 1999.
JAW that is what concerns me. As the systems become fsater they become more vulnerable to synchronization issues in shorter time frames. I do not know about this business but it seems to me to be part of the 'pot' of this lottery we call Y2K. Little things can become big things (chaos theory) particularly in complex systems.
I am not claiming a big bad wolf here just saying that this is another 'we don't know' and therefore to assess how to offset that risk, which is what we should all be thinking - risk reduction - before everyone else starts thinking the same thing (a seperate kind of risk in and of itself).
-- ..- (firstname.lastname@example.org), July 01, 1999.
Actually, either it will work or not. There shouldn't be a degradation of service.
But you are right about telecommunications failure. There isn't much of a decent work around. Either it works or it doesn't.
But I have a pretty good feeling that the GPS thing will not have a big impact. We'll see.
-- JAW (email@example.com), July 01, 1999.
Darn few of the professional receivers still in service will be noncompliant to the week 1024 rollover. JPO refused to authorize the purchase of any that were not, and that pretty well forced the mfrs to comply. Now that doesn't say anything about cheap receivers that were meant for sale to the public only. But I find it hard to believe that they would do a complete chip redesign to ADD a problem back in that they had already eliminated.
-- Paul Davis (firstname.lastname@example.org), July 02, 1999.