computer reliability
in [Design]
|
Prev: Dumbed down consumer electronics: Adding DTV channels
Next: Can I run a "brushless DC FAN" backwards?
From: miso on 2 Aug 2010 20:59 On Aug 2, 5:27 pm, "k...(a)att.bizzzzzzzzzzzz" <k...(a)att.bizzzzzzzzzzzz> wrote: > On Mon, 2 Aug 2010 16:47:25 -0700, "Joel Koltner" > > <zapwireDASHgro...(a)yahoo.com> wrote: > ><k...(a)att.bizzzzzzzzzzzz> wrote in message > >news:qgie565q4vlml8igptmv351sr7539qie36(a)4ax.com... > >> On Mon, 2 Aug 2010 11:12:26 -0700 (PDT), JeffM <jef...(a)email.com> wrote: > >> No. The OS must not be *able* to be crashed by an application. *WHATEVER* > >> mischief the application tries to get into. > > >BSODs are usually caused by a bug in the OS itself -- some user mode > >application makes a system call, and some driver or other part of the OS > >doesn't check parameters or whatever and -- poof! -- a bug causes a critical > >bit of memory to be overwritten or some important process table trashed. > > Ok, but that doesn't change the point; *nothing* in user-mode should *ever* > crash the OS. This failure was one caused by exactly this (invalid entry). > > >What people are really saying is that, "those writing device drivers and the > >OS itself need to be held to a higher standard than those just writing user > >mode apps," and I'd agree with that. > > Certainly. > > >Writing device drivers is also not the > >kind of thing you usually see beginning programmers do either (there is no, > >"Windows Device Drivers for Dummies" or "Windows Device Drivers in 24hrs" book > >out there -- yet). Nevertheless, over time there have been plenty of buggy > >drivers written by well-known companies that certainly had the resources to do > >better. > > Like M$. How many times have they done kernal mode things in user mode? > > >E.g., some Creative Labs Sound Blaster drivers would crash and burn > >on multi-processor PCs, because they didn't bother to appropriate lock and > >synchronize access to their various queues and other data structures. They > >had this problem for years, and chose to ignore it because, up until the point > >that Intel started putting multiple cores on a single IC (and true > >multi-processing became inexpensive), it was only high-end users and > >"enthusists" with dual- or quad-CPU motherboards and Creative felt that was a > >tiny enough market that they could ignore it. :-( > > Creative has always ignored reliability. Their products have *always* sucked > as badly as M$, or worse. I'm surprised they've survived. Creative survives because everyone else is just as bad. On desktop linux boxes, the only thing I run are C-media boards. At least the drivers work. Firewire devices seem to be very reliable. What did they get right that USB didn't?
From: Grant on 2 Aug 2010 21:52 On Mon, 2 Aug 2010 17:59:40 -0700 (PDT), "miso(a)sushi.com" <miso(a)sushi.com> wrote: >On Aug 2, 5:27 pm, "k...(a)att.bizzzzzzzzzzzz" <k...(a)att.bizzzzzzzzzzzz> >wrote: >> On Mon, 2 Aug 2010 16:47:25 -0700, "Joel Koltner" >> >> <zapwireDASHgro...(a)yahoo.com> wrote: >> ><k...(a)att.bizzzzzzzzzzzz> wrote in message >> >news:qgie565q4vlml8igptmv351sr7539qie36(a)4ax.com... >> >> On Mon, 2 Aug 2010 11:12:26 -0700 (PDT), JeffM <jef...(a)email.com> wrote: >> >> No. The OS must not be *able* to be crashed by an application. *WHATEVER* >> >> mischief the application tries to get into. >> >> >BSODs are usually caused by a bug in the OS itself -- some user mode >> >application makes a system call, and some driver or other part of the OS >> >doesn't check parameters or whatever and -- poof! -- a bug causes a critical >> >bit of memory to be overwritten or some important process table trashed. >> >> Ok, but that doesn't change the point; *nothing* in user-mode should *ever* >> crash the OS. This failure was one caused by exactly this (invalid entry). >> >> >What people are really saying is that, "those writing device drivers and the >> >OS itself need to be held to a higher standard than those just writing user >> >mode apps," and I'd agree with that. >> >> Certainly. >> >> >Writing device drivers is also not the >> >kind of thing you usually see beginning programmers do either (there is no, >> >"Windows Device Drivers for Dummies" or "Windows Device Drivers in 24hrs" book >> >out there -- yet). Nevertheless, over time there have been plenty of buggy >> >drivers written by well-known companies that certainly had the resources to do >> >better. >> >> Like M$. How many times have they done kernal mode things in user mode? >> >> >E.g., some Creative Labs Sound Blaster drivers would crash and burn >> >on multi-processor PCs, because they didn't bother to appropriate lock and >> >synchronize access to their various queues and other data structures. They >> >had this problem for years, and chose to ignore it because, up until the point >> >that Intel started putting multiple cores on a single IC (and true >> >multi-processing became inexpensive), it was only high-end users and >> >"enthusists" with dual- or quad-CPU motherboards and Creative felt that was a >> >tiny enough market that they could ignore it. :-( >> >> Creative has always ignored reliability. Their products have *always* sucked >> as badly as M$, or worse. I'm surprised they've survived. > >Creative survives because everyone else is just as bad. On desktop >linux boxes, the only thing I run are C-media boards. At least the >drivers work. > >Firewire devices seem to be very reliable. What did they get right >that USB didn't? USB is simply a souped up keyboard and mouse clocked serial data interface: 5V, clock, data, 0V down only just so far of shielded cable. I think USB3 introduces some LVDT lane tricks for the higher speed link options, like the SATA serial data connection. Grant.
From: Jim Thompson on 2 Aug 2010 22:00 On Tue, 03 Aug 2010 11:52:12 +1000, Grant <omg(a)grrr.id.au> wrote: >On Mon, 2 Aug 2010 17:59:40 -0700 (PDT), "miso(a)sushi.com" <miso(a)sushi.com> wrote: > >>On Aug 2, 5:27�pm, "k...(a)att.bizzzzzzzzzzzz" <k...(a)att.bizzzzzzzzzzzz> >>wrote: >>> On Mon, 2 Aug 2010 16:47:25 -0700, "Joel Koltner" >>> >>> <zapwireDASHgro...(a)yahoo.com> wrote: >>> ><k...(a)att.bizzzzzzzzzzzz> wrote in message >>> >news:qgie565q4vlml8igptmv351sr7539qie36(a)4ax.com... >>> >> On Mon, 2 Aug 2010 11:12:26 -0700 (PDT), JeffM <jef...(a)email.com> wrote: >>> >> No. �The OS must not be *able* to be crashed by an application. �*WHATEVER* >>> >> mischief the application tries to get into. >>> >>> >BSODs are usually caused by a bug in the OS itself -- some user mode >>> >application makes a system call, and some driver or other part of the OS >>> >doesn't check parameters or whatever and -- poof! -- a bug causes a critical >>> >bit of memory to be overwritten or some important process table trashed. >>> >>> Ok, but that doesn't change the point; *nothing* in user-mode should *ever* >>> crash the OS. �This failure was one caused by exactly this (invalid entry). >>> >>> >What people are really saying is that, "those writing device drivers and the >>> >OS itself need to be held to a higher standard than those just writing user >>> >mode apps," and I'd agree with that. >>> >>> Certainly. >>> >>> >Writing device drivers is also not the >>> >kind of thing you usually see beginning programmers do either (there is no, >>> >"Windows Device Drivers for Dummies" or "Windows Device Drivers in 24hrs" book >>> >out there -- yet). �Nevertheless, over time there have been plenty of buggy >>> >drivers written by well-known companies that certainly had the resources to do >>> >better. >>> >>> Like M$. �How many times have they done kernal mode things in user mode? >>> >>> >E.g., some Creative Labs Sound Blaster drivers would crash and burn >>> >on multi-processor PCs, because they didn't bother to appropriate lock and >>> >synchronize access to their various queues and other data structures. �They >>> >had this problem for years, and chose to ignore it because, up until the point >>> >that Intel started putting multiple cores on a single IC (and true >>> >multi-processing became inexpensive), it was only high-end users and >>> >"enthusists" with dual- or quad-CPU motherboards and Creative felt that was a >>> >tiny enough market that they could ignore it. :-( >>> >>> Creative has always ignored reliability. �Their products have *always* sucked >>> as badly as M$, or worse. �I'm surprised they've survived. >> >>Creative survives because everyone else is just as bad. On desktop >>linux boxes, the only thing I run are C-media boards. At least the >>drivers work. >> >>Firewire devices seem to be very reliable. What did they get right >>that USB didn't? > >USB is simply a souped up keyboard and mouse clocked serial data >interface: 5V, clock, data, 0V down only just so far of shielded >cable. I think USB3 introduces some LVDT lane tricks for the >higher speed link options, like the SATA serial data connection. > >Grant. And slew-rate controls to keep the EMI in check... what I have the patents for (Intel only knows fast, zippo on analog :-) ...Jim Thompson -- | James E.Thompson, CTO | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona 85048 Skype: Contacts Only | | | Voice:(480)460-2350 Fax: Available upon request | Brass Rat | | E-mail Icon at http://www.analog-innovations.com | 1962 | Spice is like a sports car... Performance only as good as the person behind the wheel.
From: Robert Baer on 3 Aug 2010 02:25 miso(a)sushi.com wrote: > On Aug 2, 11:12 am, JeffM <jef...(a)email.com> wrote: >>> Richard Henry wrote: >>>> [USS] Yorktown[...] >>>> http://gcn.com/articles/1998/07/13/software-glitches-leave-navy-smart... >> Robert Baer wrote: >>> Whoever wrote the data entry program >>> should be strung up buy the balls for NOT checking >>> the validity of EVERY parameter entered during entry! >>> There is absolutely NO excuse! >> The Rules of Operating System Design >> #1 Applications must never crash the OS. >> #2 APPLICATIONS MUST NEVER CRASH THE OS. > > It's really hard to arm chair analyze the BSOD. In an industrial > environment, you have sensors going to i/o boards, noise spikes, etc. > This can easily be a hardware problem. > > I've had usb soundcards lockup linux in the past. Current ALSA seems a > bit more robust. Well, concerning noise spikes, i connected a 2.5KV regulator tester to my PC via an A-D/DIO board and it was a simple matter to filter and isolate "bazz-fazz" from the tester - so that there would be no problems with the PC. Hardware problem? Yess.. Fixable? Yess..
From: Martin Brown on 3 Aug 2010 03:16
On 02/08/2010 00:23, JosephKK wrote: > > Found this recently: > > ++++++++++ > > Subject: Tech worker: 'Blue screen of death' on oil rig's computer > > Gregg Keizer, *Computerworld*, 26 Jul 2010 > > A computer that monitored drilling operations on the Deepwater Horizon > had been freezing with a [BSOD] prior to the explosion that sank the > oil rig last April, the chief electrician aboard testified Friday at a > federal hearing. > > In his testimony Friday, Michael Williams, the chief electronics > technician aboard the Transocean-owned Deepwater Horizon, said that > the rig's safety alarm had been habitually switched to a bypass mode > to avoid waking up the crew with middle-of-the-night warnings. > > Williams said that a computer control system in the drill shack would > still record high gas levels or a fire, but it would not trigger > warning sirens, He also said that five weeks before the April 20 > explosion, he had been called to check a computer system that > monitored and controlled drilling. The machine had been locking up > for months. You'd have no data coming through." With the computer > frozen, the driller would not have access to crucial data about what > was going on in the well. > > The April disaster left 11 dead and resulted in the largest oil spill > in U.S. history. > > ========== > > What can i say? MS Windows should not be used for safety critical > systems in any way. Neither should Transocean. Odd that BP should have to pay for their mistakes. I guess Transocean is too small to be worth suing. Regards, Martin Brown |