Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Discuss Year 2000 Issues -- Ignore unavailable to you. Want to Upgrade?

To: Ken who wrote (5159)	3/30/1999 8:10:00 PM
From: Cheeky Kid	Respond to of 9818

Small towns on Y2K: What, me worry? flash.cleveland.com

To: Ken who wrote (5159)	3/31/1999 4:10:00 AM
From: Ken	Respond to of 9818

Emb. systems: to Dr. Frautschi/comment letter: any comments by engineers? " >Y2KWEEKX week 41 issue 28 March 29, 1999 >ON THE EMBEDDED FRONT: Mark (mailto:frautsch@tmn.com) >...With a follow-up, I was able to get satisfactory answers. Yost >allowed that when Northrup Grumman IV&V's 30 million lines of IRS >code, they found 1,500 errors. Question: Were these 1500 new errors introduced by the changes (i.e., was the baseline a set of IV&V'd code with no errors), or was this the total number of errors found in the code by this process? The answer is important: much code has never been through the kind of careful testing process being used for Y2k work. Thus, we see both the bad news (lots of latent errors uncovered) and the good news (lots of latent errors fixed). Note that 1 error per 20,000 lines of code (0.005%) isn't necessarily an alarming rate at all. I know lots of companies that happily ship million-line-of-code products with 50 known bugs! It's all a question of defect severity. > * * * > >For over a year I have struggled with one annoying piece of broken logic >around the embedded systems aspect of Y2k: "If it does not need a date, it >does not track a date and therefore it is Y2k immune."... Actually, it is a bit more subtle than this: If no date is ever downloaded to the RTC then it cannot track the date and the "epoch" date is set to 1/1/00 at every reset and therefore it is Y2k immune (unless left on for 100 years) If the system has no date input then it cannot track the date and the elapsed time since setting the epoch date determines rollover. (This is typically a large number of years between resets) > It's easy to invent counterexamples as I argue in my paper >http://www.tmn.com/~frautsch/y2k2.html What counterexamples? Or perhaps the power train or stove/microwave examples are considered such? These are weak examples, as the "epoch date" in a non-date-tracking system will be what the RTC resets to at system reset, which is 1/1/00 (and the system therefore will not fail unless elapsed time between resets exceeds 100 years.) >Thanks to a call from Gary Mailhiot, I formed a new question, not for the >system manufacturers, but for the suppliers of real time clocks (RTCs): "How >many of your RTCs are built w/o dates?" I am beginning to gather some >answers: This is question is not particularly helpful, as you discovered (perhaps without realizing the significance of the results gathered.) RTC's, as you have found, almost universally are designed to SUPPORT date tracking. That is not at all surprising. That answer barely scratches the surface. One must ask a deeper set of questions to really understand the issue. * How many RTC's ship with ANY date preset? (none that I've found) * How many RTC's can measure dates after being installed, without first being reset? (none that I've found) * How many RTC's can be reset to a date other than 1/1/00 without being externally programmed? (none that I've found) Bottom line from my investigations: 1) RTC's generally do support dates 2) RTC's are shipped in a completely non-functional state; they do not work at all until reset the first time in their installed system. (Why? They are "state machines," and until they are reset, the state values are completely meaningless. They can't even count correctly until reset.) 3) Upon reset, the date in an RTC is 1/1/00. Any other epoch must be externally configured, e.g. by a BIOS. A simple non-date tracking embedded system will not bother with such complexities, and may well not even have the circuitry (i.e. I/O port wiring) to accomplish such a relatively high end function. >Assume that this trend continues. It then becomes difficult to imagine that >embedded systems are made using real time clocks that do not keep dates, >regardless of need. There are few places to buy them. This is an incorrect conclusion. Real Time Clocks that _support_ dates do not _keep_ dates unless the date is somehow entered into the chip. If a system has no method for date entry, the date cannot get into the RTC, and the RTC can't "keep" the date. It's that simple. >I joined the "Citizen Needs" workshop. We were tasked with developing a >message for the general public. We chose a one week period for storing (not >'stockpiling' or 'hoarding') water, food, batteries, medicine, etc... This is quite reasonable, and also in line with the Red Cross' message. >...It is not a prediction. VERY good statement. We've got to start distinguishing between our expectations/predictions and our preparations (which normally should exceed any expected/predicted problem.) FWIW, Pete --- Pete Holzmann Pete@ICTA.net 12175 Howells Road President/CEO Colorado Springs, CO 80908 USA ICTA Tel/Fax: [1](719)495-8789 icta.net