I may have the spelling wrong-but I know it is close enough for those that know. This was somewhat of a big thing on north's site and a few others at one time. I also read on one site that it was a hoax. Any ideas out there?? I certainly haven't heard anything anywhere about its consequences. Thanks.

-- futureshock (gray@matter.com), January 28, 2000

Answers

Never saw it, but if it was on Mr North's site, odds are overwhelming it was scaremongering nonsense perpetrated by the ignorant on the naive.

There goes one guy who ought to be seriously ashamed of himself.

-- I'mSo (lame@prepped.com), January 28, 2000.

I am not a north fan-I think he is a lunatic-BUT I did get a lot of useful links and info, and this was the main reason I prepped for a month. I never believed in his apocolyptic vision-I avoid fundamentalists of all types-christian, buddhist, political, etc- Anyway, the supposed effect I am speaking of had to do with PCs losing time after the rollover.

-- futureshock (gray@matter.com), January 28, 2000.

The Crouch Echlin Effect bit two Nuclear Generating Stations immediately after the Roll and were reported as such by Kosky's group.

Additionally, it has struck several posters on this Forum, mostly in the form of "Jumping Clocks" but at least one poster here found his "firmware expired" about a week after CDC.

The C-E effect is a real, if relatively trivial, Y2K Effect.

-- K. Stevens (kstevens@ It ALL went away 28days ago .com), January 28, 2000.

Don't think it was a hoax -- meaning something perpetuated by people in order to hoodwink others -- but I do think it was something no one could really understand. Seemed to effect older computers (286, 386) more often than pentiums.

The effect seemed to be that once the clock was reset to 2000 it would lose time, with eventual loss of some functions. As I recall, the (first) reported incident concerned a computer in which an output port shut down. I know DEC and Compaq looked into it, but don't know what they decided.

There didn't seem to be a large enough data base established to determine one way or the other if it could be a problem. In order to investigate, each computer had to be rolled forward to 2000 and then turned off and on repeatedly (simulating nite-time turn off, morning turn-on).

Some people declared hoax, others claimed to have seen it occur.

Discussions centered around clock timing using 2000 as a date, and they never seemed to reach conclusion. If you're really interested, go to c.s.y2k (deja news) and search on it. Mike Echelin and ? Crouch were the initial reporters of the effect.

-- rocky (rknolls@no.spam), January 28, 2000.

Thanks to those who answered. It is just part of the overall process of assessment to follow up on all possible problems that were reported, pre- and post-rollover.

-- futureshock (gray@matter.com), January 28, 2000.

OK, I'll try to handle this one. I'll skip the gory technical details unless someone is very very curious, and give a summary.

Reading the time and date from the RTC chip is easy. However, the timing constraints are very tricky, so writing a routine that guarantees that the time and date are read correctly under *all* possible circumstances is not trivial at all. I have yet to see a BIOS that does it right.

(Indeed, there is some debate as to whether it *can* be done right without introducing an unacceptable amount of overhead. That's another story)

As a result, every now and then the code will return incorrect values from some (the most common) types of RTC chips. The result is a "jump" in the time or date, either forwards or backwards. The worst code I've seen will get it wrong (at random) every 500 reads or so, while the best code will get it wrong only about one time in a million.

To my knowledge, nobody has yet found any RTC read routine whose characteristics change in any way based on the century. In other words, seeing the rare time jump has nothing to do with year 2000, and could happen (and did happen) during any year.

By convention (and in most RTC chips by necessity), the century is maintained by software rather than by hardware. It is conceivable that the extra logic in a "century aware" BIOS could require enough time to execute to violate timing constraints by enough to make a read error more likely after the century change. However, nobody has ever found any real-world coding errors that might cause this to happen. And not for lack of searching, believe me.

Field observations, in fact, have found the most common "time jumps" to occur in older and much slower units, none of which paid the century any attention at all. However, the slower the computer, the more difficult to meet the timing constraints, and therefore the more likely the timing errors.

(As a footnote, the probability of getting it wrong are functions not only of the quality of the code, but also of the CPU speed and the location (and hence the response time) of the RTC chip. Code that gets it wrong one time in 500 on a 20MHz processor will get it wrong only one time in 5000 on a 200MHz processor, all else being equal.)

In general, the Crouch-Echlin effect is a fancy name to describe poor code used to access the Real Time Clock hardware only. But poor code is everywhere, to the point where it can be considered standard practice! (And yes, I cringe reading my old code too). When code screws up doing anything else, it's simply called "poor code". The Crouch-Echlin flavor of poor code is nothing special or unusual.

Considering that poor RTC access code and the occasional time jumps have nothing to do with the century, is this a hoax? You decide. The errors are real, but in practice have nothing to do with y2k.

(Finally, if anyone is really curious about UIP timings, "atomic" reads, error handling and other technical details, just send me an email. That stuff is interesting only to those who find device drivers more fun than sex).

-- Flint (flintc@mindspring.com), January 28, 2000.

From: Y2K, ` la Carte by Dancr (pic), near Monterey, California

So what do we do if it seems to be affecting us? I just checked my clock again for the first time since that last post, linked above, and it was off by a minute and a quarter already. So, I rebooted my computer and it went back to being on time, without my having to adjust the clock. Having to reboot on a daily basis is not acceptable to me.

-- Dancr (addy.available@my.webpage), February 01, 2000.

Dancr:

The RTC chip is not used by the OS to maintain the time and date -- that chore is handled by an entirely different oscillator. The OS calls the BIOS one time, during the OS boot process, to get the initial time and date from the RTC. After that, the OS maintains the time and date internally from a timer chip (and not from a clock/calendar chip). These two chips, running on different oscillators, can vary quite a bit. The timer chip isn't usually all that accurate, so it's not unusual for your time to get off quickly -- mine gains about 10-12 minutes per week.

But this has nothing to do with Crouch-Echlin or poor RTC coding. It has everything to do with keeping price down -- those inaccurate crystals are dirt cheap.

-- Flint (flintc@mindspring.com), February 01, 2000.