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 : All About Sun Microsystems -- Ignore unavailable to you. Want to Upgrade?

To: JC Jaros who wrote (27698)	2/14/2000 10:38:00 AM
From: rudedog	Respond to of 64865

JC - re: drivers and IHV code could be written by monkeys (and are) and it wouldn't break the nix OS, right? Not true in my experience - I have seen the Solaris kernel routinely panicked by poorly written system components during development... whammo, you're looking at a core dump... the difference is that in Sun's world, that stuff rarely is seen by the customer, since Sun controls the final configuration more tightly. Neither the Linux crowd not MSFT has that ability, since user configurations contain lots and lots of stuff which comes directly from IHVs and other developers not obligated to adhere to any standards. In order to achieve good performance and minimize code paths, drivers have to minimize interrupt overhead and move data from the I/O bus into program or system space with minimum disruption of the processor pipeline - that means the OS is not involved once the transfer is set up, and although modern architectures provide some protection against blatant abuse, there are still many, many ways to make a minor error which will demolish the OS... any OS. The only way around this is to have the OS supervise every aspect of the transfer, which imposes a huge penalty in performance. At a minimum, the "context" needs to switch every time the OS gets involved, which "flushes" the processor instruction and data cache... that means the next few instructions are executed by L2 cache, which is 4 to 8 times slower... if the next bit of stuff is not in L2, then there is an additional 4X to 8X performance hit. The result would be I/O routines which were maybe 1/10th the speed of a well designed driver. Early in driver development the drivers are often "instrumented" for debug purposes, which again gets the OS involved - no one would want to actually use a system with that kind of performance, it is "slow motion" big time.