Crouch Echlin Effect?

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

I checked this out from the Vanity Fair article. I haven't seen any discussion of this - did I miss it, or is it fairly new? Anyone have any additional info? *****************************

 

Time Dilation or the Crouch Echlin Effect


In 1997 a Year 2000 problem was discovered that recently has been dubbed "Time Dilation" or the "Crouch Echlin effect", named after the people who uncovered this potentially serious problem. The desktop PCs and computer systems that show the Crouch Echlin effect have one thing in common: a real time clock (RTC)/CMOS that, if accessed during the once-a-second-update cycle, gives bad data to the BIOS POST date/time routine. This effect has the potential of causing such problems as the random crashing of your accounting system; file date errors; wrong dates being inserted in data; historical data being lost, misdated, or scrambled; and in the extreme case, system failures.

It is commonly believed that computers will behave the same after the millennium as prior to it, but this will not necessarily be the case. On boot up, after year 2000, the computer may occasionally make a jump in date and time. When this happens, you will have just experienced Time Dilation or the Crouch Echlin effect.

Per Mike Echiln, "The effect will affect devices in all classes of computers. It has been demonstrated on Intel and clone CPU based PCs and PC compatibles. It has also been demonstrated on other desktop platforms as well as on workstation platforms. … We are afraid it will show up in most computing platforms, on a significant percentage of individual devices of each platform."

This effect was initially reported by Jace Crouch when he was doing a routine year 2000 rollover test on his computer. After the test, he left his computer set for past the year 2000 to see what would happen. His results:

The system clock "ran" extremely rapidly. After two weeks, the system date was mid-December 2000. The date reported in CMOS and reported various WP and Microsoft applications was identical. Whatever date the RTC reported, the applications displayed. Files were saved with a 00 year date, but win 3.1 file manager displayed a :0 date. These files were readable, writable, and seemed otherwise normal.

After about ten days, the system would not recognise that I had two serial ports. For whatever reason, every system test that I ran reported only one serial port. This was the case with Norton Utilities 7, MSD, and an old WP utility. Nothing else started shutting down, but I figured that if a serial port went down, anything could happen next, maybe trash the hard drive in some strange time-warp way.

Once I set the system clock back to the correct 1997 date, both serial ports were recognised, and they worked fine. I have no idea why the clock "ran" so fast in Y2K, nor why the system stopped recognising the second serial port. This was enough to convince me that even on a simple PC, the Y2K problem can cause hardware failures."

Development of discussions and tests:

As discussions took place and new tests were performed, the testing showed four things.

The effect only happens post rollover to Y2K. This was shown by the repeated pre/post 2 week cycles of testing.

The effect is characterised by random time/date jumps occurring only at start up of the computer.

The one thing in common with these computers is a non-buffered Real Time Clock. (By observation, and correlation of those observations.)

When the time/date jumps and is wrong at the OS clock level, the RTC still has the correct time. (By analysis of machines when they were affected by the effect.)

 

The 244 grace period:

The 244 grace period is described by Mike Echlin as follows: "The designers of the original 146818 RTC/CMOS chip realised that you can not read the RTC while it is updating. And they also realised that people would not check the status after every read, so that set the status a little early, while the data is still good, and guaranteed that it would still be good for 244 microseconds (a grace period I call it) so that you could read the status, and then still have enough time to get the data even if the status changed right after you checked it.

The problem here is that the BIOS before year 2000 takes less than 244 microseconds to read the RTC, but after year 2000, because of the different logic path it takes due to the century change, it takes longer than 244 microseconds to read the RTC.

If you read the RTC at the beginning of a second you have all the time in the world to do it, (almost a whole second, minus the time needed for the RTC to update at the end of the second). But if you start your read at the beginning of this 244 grace period, you only have the 244 to do it in.


The reason that there is a different logic path after year 2000 is because of the way the PC keeps the date, and the way it reads the date from the RTC. The RTC has second, minute, hour, day, month, year, but the PC keeps it as clock ticks since midnight, and days since 01.01.1980. So, before year 2000, you just subtract 80 from the current year, and adjust for leap years, and count days in the current year. After year 2000, you have to adjust for the new century, and count the years since rollover, and the days in the current year, and the extra days in leap years, and calculate whether or not year 2000 is a leap year. And on top of all this, you have to convert from BCD".

 

Studies / Tests

The studies showed that the BIOS code that reads the RTC chip has three paths to follow depending on the value of the Century Bytes stored at register 0X32 of the CMOS memory. If the value is anything but BCD19 or BCD20, then an error value shows up and the BIOS date is set incorrectly. It is the theory of Mike Echlin that the difference in logic path changes the amount of time used to read the RTC and if the RTC is not buffered, then the value being read from the RTC is not reliable, and can cause the Time Dilation effect.

The only way to detect this problem is to test for it. This can be done by checking to see if your devices have an RTC that is not buffered, or using the NSM Diagnostic Fix software to check it for you.





-- Online2Much (can't_think_of_one@the.moment), February 13, 1999

Answers

Nope, not new.

Not really confirmed, not shown not to happen.

Compaq/DEC played with it for a while and gave a lukewarm endorsement to an Echlin fix, but haven't pushed it.

-- please (dont@bother.com), February 13, 1999.


I assumed this old issue was real. I read that the problem was confirmed in some systems, but there has been little info on it recently.

I plan on setting my PC back to the 1980s later this year. My old Pentium 166 and Micro$oft software probably won't do so good in the new century. 1999 becomes 1989 for my PC this year.

-- Anonymous99 (Anonymous99@Anonymous.com), February 14, 1999.


Crouch/Echlin effect de-bunked by Intel

"Compaq has been unable to re-create the effect"

"Compaq has not seen evidence of the Crouch-Echlin effect during testing of its own systems or in discussions with other system manufacturers"

"Since Compaq is unable to recreate the TD effect, we are not offering any TD related tools"

and from http://support.intel.com/support/year2000/c-e-wp.htm

"Intel has been unable to re-create the issue. We have worked with some of our customers and have spoken to end users in our attempt to find the root cause of these anomalies. There have been five hypotheses asserted and all have been disproved."

"All systems tested, including Echlin's, handled interrupts properly, handled the UIP properly and did not have different logic paths based on the century..."

"We have tested all hypotheses asserted by Echlin, our customers and Intel experts and are confident that we have disproved all as root causes "

Karl

Karl W. Feilder, President & CEO, Greenwich Mean Time http://www.gmt-2000.com

Compaq Computer Corporation has conducted a thorough investigation of the issue commonly known as Time Dilation (TD) or the Crouch-Echlin effect. Compaq has been unable to re-create the effect and, while we cannot explicitly confirm or deny its existence, based on our investigation we are confident that no Compaq- or Digital-branded personal computer systems are subject to this effect. Please see the below Q&A's for further information.

In addition, Compaq worked closely with Intel Corporation during Intel's examination of the effect. Compaq accepts Intel's findings, which are outlined in a white paper available through the following link http://www.Intel.com/Support/Year2000/ .

Q1: What is the Crouch-Echlin effect?

A1: The Crouch-Echlin effect is a reported time-keeping anomaly when a system clock is set after the Year 2000. It was reportedly discovered by computer user Jace Crouch and described by programmer Michael Echlin. Echlin hypothesized that the Crouch-Echlin effect was caused by a BIOS choosing a new execution path after the Year 2000 and incorrectly programming the system's Real Time Clock (RTC).

Q2: Are Compaq PCs affected by the Crouch-Echlin effect?

A2: No. Compaq has not seen evidence of the Crouch-Echlin effect during testing of its own systems or in discussions with other system manufacturers. As a result of its testing, Compaq has confirmed that its PCs are not affected by time dilation (TD).

Q3: What is Compaq doing about the Crouch-Echlin effect?

A3: Compaq attempted to duplicate the Crouch-Echlin effect on Compaq systems and conducted a thorough engineering review. However, Compaq has not seen evidence of the Crouch-Echlin effect during testing or in discussions with other system manufacturers. In addition, Compaq worked closely with Intel Corporation during Intel's investigation of this effect.

Compaq is in agreement with Intel's findings. For further information on Intel's findings, please refer to Intel's position paper on the analysis of the Crouch-Echlin effect at: http://www.intel.com/support/year2000/ . Compaq will continue to work with others in the industry to address Year 2000 related issues.

Q4: I heard that the reported problem can occur only in systems with a non-buffered RTC. Is this true?

A4: According to Crouch and Echlin, the TD anomaly or effect has been observed in computers with "non-buffered" RTCs. However, Compaq's research indicates that this problem could only occur on a system whose BIOS does not meet the RTC's specification. This would make it a BIOS issue, not an RTC issue. If end users are concerned about the quality of their system BIOS, Compaq recommends contacting the system manufacturer or BIOS manufacturer to obtain the latest BIOS upgrade available.

Q5: How can end-users tell if their system is affected?

A5: Compaq recommends that end users check the Year 2000 capabilities of their PCs by using one of the industry-accepted utilities currently available, such as the YMARK2000 test available from National Software Testing Laboratories (NSTL). If end users are concerned about the quality of their system BIOS, Compaq recommends contacting the system manufacturer or BIOS manufacturer to obtain the latest BIOS upgrade available.

Q6: I have heard that Echlin has a software fix. Didn't Compaq previously confirm the existence of TD and offer a software fix for sale?

A6: Consultants at the Compaq Services Year 2000 Expertise Center in Albany, NY, observed what initially appeared to be the TD phenomenon on a PC that was not made by Compaq or Digital. At that time, the Albany Center acquired the rights to resell the TD tools created by Mike Echlin in an effort to service customers whose PCs came from a variety of manufacturers.

Since Compaq is unable to recreate the TD effect, we are not offering any TD related tools. Compaq will continue to evaluate this issue and will take appropriate steps, if needed, to ensure our customers continue to have the best possible computing experience. Together with its partners, Compaq offers a comprehensive portfolio of Year 2000 solutions that span all phases of the Year 2000 Readiness cycle.

Compaq Computer Corporation 1/12/99 2

Compaq Computer Corporation 20555 SH 249 PO Box 69200 Houston, TX 77070-2698 Houston, TX 77269-2000 Tel 281-370-0670

Compaq Computer Corporation 1/12/99 1



-- Mutha Nachu (---@oiltankerburning.com), February 14, 1999.


YOUR NAME

IS LIKE A GAME

WHERE WE ALL BLAME

THE PERSON SAME

-- Mutha Fucka (dooby@dooby.com), February 14, 1999.


Ah, yes...Another insiteful, informed, enlightened Yourdnite!

You might better have said, "Please...don't bother me with the facts!"

Or better yet, "only fear-mongers allowed to answer questions on this forum...wouldn't want anyone getting a different opinion than TEOTWAWKI!"

your intelligence is a shining beacon to all...



-- Mutha Nachu (---@kissmebigboy.com), February 14, 1999.



As I understand it, this effect is only applicable to 286 systems.

-- dave (wootendave@hotmail.com), February 14, 1999.

Some earlier threads on this topic:

Time Dilation at http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=0008AH

Time Dilation -TD - The other Y2K problem at http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=000AIv

More on Time Dilation at http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=000CaE

TD - Looks like the jury's still out at http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=000Er8

TD update at http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=000FVE

The following thread has lots of links to other articles on time dilation:

pc bios clock. at http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=000Fwp

-- No Spam Please (anon@ymous.com), February 14, 1999.


This has been discussed in depth here and on csy2k. My own take is that its a real, but quite rare, effect. There may be another reason than C-E thats not been appreciated. Remember, we are talking about the behavior of sets of electronic subsystems manufactured by dozens (hundreds?) of firms over 12-15 years. You could literally have 10 semmingly identical Compaq computers that are in fact 10 similiar (but not identical) systems. Lastly, no computer company in its right mind would want to confirm a problem like this in its products!

-- RD. ->H (drherr@erols.com), February 14, 1999.

Online - Thankx for the post. It reminded me that I still have a personal computer that is not compiant. We have been so wrapped up in the effects of Y2K on society (the forest) that I have ignored the immediate PC concern (individual tree:) As the other posts have shown, the idea of the C-E effect is not new, I ran accross it initally in December, but further study got put on the "back burner" as they say.

Anonymous - Thankx for the great idea about setting the date back 10 years. That just might be the answer for me. Seems simple, cheap, and works for our personal use of this computer.

Mutha and No Spam. Thanks for the article and links. Info gather is much easier with help from others on the forum.

Merlin, wishing he hadn't misplaced his "magic wand" in our "interesting times" :-)

-- Merlin Emery (MerlinEmery@yahoo.com), February 14, 1999.


I just recently finished disassembling all RTC-access code in the most notorious PC Crouch and Echlin have yet identified (this was the original PC where the effect was noticed). Many thanks to Mike Echlin for sending me the binary dump of the BIOS for this.

I found two significant bugs in this code, and one potential bug. Neither bug is related to 2000, since this BIOS contains no century- aware code whatever. However, these bugs can indeed allow the BIOS to pass garbage to the OS in two different ways. Sudden jumps in time/date depend entirely on how the OS interprets and uses this garbage when it happens. But it can happen at any time, not just after 2000.

If anyone wants real nitty gritty technical detail about this, just send me an e-mail and I'll explain as clearly as I can.

-- Flint (flintc@mindspring.com), February 14, 1999.



Flint-

so what you're saying is that Crouch - Echlin exists, but is simply not y2k specific? If so have you had the chance to fiddle with it at all and find out exactly what sorts of things, external to the EPROM, can cause it to flip out?

just wonderin' Arlin

-- Arlin H. Adams (ahadams@ix.netcom.com), February 14, 1999.


Moderation questions? read the FAQ