Having read the Bruce Beach article and several rebuttals, the basic argument seems to come down an old 70's song lyric. Does any embedded chip really know what time it is? Do any of them really care?

According to BB there are lots of hard-to-find buggy RTCs ("Secondary clocks" ala BB) out there which know what time it is and will fry their little circuits on the roll-over. Thereby precipitating system failures of unknown severity.

According to rebuttals RTCs either don't know or care what time it really is because:

1. RTCs are reset whenever their external power source is cut. 2. RTCs may be set at any point in between manufacture and implementation 3. Most systems use what Beach called the primary clock which seems to work like a metronone and is blissfully unaware of what a "year" is.

If anyone can add to or clarify the above I will be most appreciative.

-- Anonymous, April 13, 1999

Answers

> 1. RTCs are reset whenever their external power source is cut.

Most are. Some have built-in lithium batteries, which can have up to ten year lifespan.

> 2. RTCs may be set at any point in between manufacture and implementation

That is true. They may be set to an arbitrary value, or to the correct date/time.

> 3. Most systems use what Beach called the primary clock which seems to work like a metronone and is blissfully unaware of what a "year" is.

For some timing chores, this is true. I use the ocsillator tick often when doing simple timing stuff. But if the system needs to do anything complicated, especially on long-interval delays, it is often easier to use a RTC.

Jon

-- Anonymous, April 13, 1999

Jon, Thanks for the simple answer. Like everything else about Y2k the more you know - the more unsure you are.

So the answer is - everyone is right.

Embedded chips act in all the ways described by all members of the debate. There are chips which have their own power and know what time it is. There are chips which run for years thinking it is the wrong time. There are chips which can be reset externally and chips which can't. Some chips will fail on 1/1/2000 and there are lots more that could fail anytime after.

We don't know. May as well roll dice or cast the I-ching. Hail Eris Hail Discordia

-- Anonymous, April 13, 1999

Well, we do know somethings.

We know that more than 90% of all Wintel/IBM PC based embedded systems have RTCs that don't handle the century role over and have the potential for Y2K failures.

We know that more than 100 million Wintel/IBM PC based embedded systems ship each year.

We know that Y2K failure rates in Wintel/IBM PC based systems is significantly higher than the average for all embedded systems (I put it at a very conservative 1%).

We know that at least 10% of all companies aren't going to get all their products compliant in time. And even if they did they're not going to get all the systems sold prior to 1997 upgraded.

Therefore, this coming December 1999 over 8 million Intel x86 based embedded systems will ship, 800 thousand of them will have potential Y2K problems, 8 thousand of them will fail with potentially deadly side-effects. Not to mention the more than 300 million x86 based embedded systems already out there, somewhere.

For lots more discussion and gory detail on embedded systems and RTCs do a search of this forum for "ajedgar".

--aj

-- Anonymous, April 14, 1999

My understanding is that most of those IBM PC's that won't handle the date roll over, simply need to be turned of during the roll over time, restarted after the new year is in all is well. That is my understanding for most cases, sorry to all those 'interesting people' that planned on seeing in the new year working on your PC. Graham.

-- Anonymous, April 14, 1999

Graham, your assumption is wrong.

First of all I'm not talking about desktop PC's I'm talking about embedded IBM PC compatible controllers, like this one from Ampro: http://www.ampro.com/products/coremod/cm3sxi.htm

Secondly powering down and back up again does NOT magically fix the problem.

Here is a little thought experiment for you. You are the Y2K Program Director for an off-shore drilling rig in the Gulf of Mexico. The rig is 100% automated using hundreds of IBM PC compatible systems all networked together all communicating with thousands of other sensors, relays and PLCs.

What is your plan to remedy the situation?

--aj

-- Anonymous, April 15, 1999

Not to muddy the waters on this highly technical discussion, but if IBM compatible PC/BIOS/RTCs were the only y2k issue we had, all of us working in y2k could have all wrapped this thing up in January and all gone home. This problem is the EASIEST to fix, it takes me about 2 minutes to upgrade a BIOS that takes care of the problem on most machines, on the rest a patch file can be installed in five. It doesn't matter whether the PC is a desktop or used as a MMI/controller - I've done both. And for most desktops that are 486's through the Pentiums, the BIOS will take a manual entry (via either the Windows or DOS date function) of the date in the year 2000 and from thence forth be compliant, even after shutdown.

The Ampro example is not much differen't, in fact the website describes the boards as basically IBM compatible scaled down for embedded systems. The fix is very similar, a patch file for the 486's and faster.

And to the best of my knowledge, all of the PC's by the major vendors currently being shipped are Y2K compliant (many certified by NSTL Ymark2000 testing). Lets move on to real threats in embedded systems like custom programming of non-PC devices using date functions, or to PC based software applications with important date functions that have significant effects.

The PC/BIOS/RTC issue is a no-brainer. Regards,

-- Anonymous, April 16, 1999

PS, One last tidbit. If the aforementioned PC's are using DOS5.0 or above or one of the Windows Operating systems, then as long as they are running, the PC/BIOS/RTC y2k compliance is almost certainly to be a moot point - Almost all applications get their dates from the "system" clock (the operating system software has it's own "clock" that uses the microprocessor pulses). The operating systems listed above have minor y2k issues, but all will roll over the dates properly through and after the year 2000 and applications accessing the dates will get a good date (of course the application must be y2k compliant as well). The BIOS/Real Time Clock is never an issue until you shut the PC down and start it back up, at that time the operating system gets the date from the RTC. There is the rare instance that an application could get the date directly from the RTC CMOS, but Dell found no apps that did that in thousands and thousands they evaluated (it has been done though).

Soooooo....all PCS running DOS5.0+/WIN will roll over like a fat cat if its running during the 2000 transition. Its the restart thats iffy, as well as the software application compliance...

Regards,

-- Anonymous, April 16, 1999

FactFinder,

Yes if all we had to worry about was PC/RTC problem we might very well be done by now. But's it's not the only problem is it? It is just one small dimension of a very simple, but extremely large problem.

Yes if all we had to worry about was DOS 5.0 and Windows 95/98/NT life would be simpler wouldn't it? But that is not the way things are. There are at least 6 other versions of embedded DOS, plus literally hundreds of other niche and proprietary embedded OSes: pSOS, QNX, VRTX, VxWorks, Theos, uCOS, SPOX, ... to name just a few. And then each one of those have all their respective versions and patches.

You state: "The BIOS/Real Time Clock is never an issue until you shut the PC down and start it back up, at that time the operating system gets the date from the RTC." I'm glad you are so sure of yourself. Did you know it is a pretty common trick to reinvoke the "date" command periodically to force a reload of the RTC? It is a well known problem with PC hardware that the software clock drifts over time, so a cheap and dirty trick is to reload the time and date from the RTC every 15 minutes or so.

You state: "There is the rare instance that an application could get the date directly from the RTC CMOS, but Dell found no apps that did that in thousands and thousands they evaluated (it has been done though)." Here you are confusing desktop apps with embedded systems applications. I don't think Dell tested thousands of proprietary embedded systems running on a couple of hundred different OSes.

You state: " Soooooo....all PCS running DOS5.0+/WIN will roll over like a fat cat if its running during the 2000 transition. Its the restart thats iffy, as well as the software application compliance..." And your point is???

As I have said before, I am glad your particular testing is going so swimmingly well. And I'm happy for you that from where you're standing the PC/BIOS/RTC issue is a "no-brainer". Unfortunately from a more global standpoint your statement is simply wrong.

There are over 300 million PC based embedded systems installed and operational in the world. Are you trying to tell me that 100% will be remediated? That all Y2K problems will be found? That all Y2K problems will be thoroughly tested? That all the Y2K fixes will introduce no new bugs?

Here is my position. A minimum of 10% of all PC based embedded systems will not by remediated in any way (30 million units). 10% of those will have Y2K issues (3 million units). 10% of those will have Y2K bugs that cause serious faults, shutdowns and damage (300 thousand units).

I think these numbers are _conservative_. The number of embedded PCs that get no attention at all might be as high as 30%.

And, maybe, just maybe, the place where FactFinder works won't have any problems at all. Good for you!

--aj

-- Anonymous, April 20, 1999

P.S., one last tidbit,

There are over 4 billion embedded MCUs/MPUs shipped each and every year, of which embedded PCs accounts for less than 2.5%.

However, some significant percentage of the remaining 3.9 billion MCUs/MPUs use these non-compliant RTCs: http://mot-sps.com/y2k/mailing.html#rtclist

You see? I'm not only concerned with the PC/BIOS/RTC problem it just happens to be the area in which I have the most experience.

--aj

-- Anonymous, April 20, 1999

Just a "ping" to keep the thread fresh.

Where has "Fact"Finder gone?

-- Anonymous, April 27, 1999