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: jim kelley who wrote (24936)	12/16/1999 8:31:00 PM
From: Thomas Mercer-Hursh	Read Replies (1) \| Respond to of 64865

All I can say is that this suggests you don't know a lot about system internals. In the PC world, things are pretty generic within tiers, tiers being things like a particular generation box such as the new 100Mb/s bus systems. But, in the RISC world, there may be some common components coming from supplier sources, but what one does with them is all over the map and a night and day difference in performance. I remember benching a series of system a few years back for an application which was particularly intense in terms of loading masses of data into a database. There was some expected scaling between boxes we expected to be different, but then there were a couple of RISC boxes from different manufacturers that we expected to be mostly the same because standard benchmarks, price, etc. were all about the same. One of these, though, absolutely blew the socks off the rest of them. Turned out that it had a significantly higher speed main bus, something largely overlooked in the specs. But, that difference in moving data from point A to point B within the system was obviously a key bottleneck in overall performance at that time. Note that one shouldn't focus only on the disk subsystem. It is one piece which shows up as particularly crucial in this type of application, but other pieces, like the number and speed of internal buses, is also important to this particular class of application and other types of application have their own key ingredients. It is obvious you are mostly just goading, but you might as well at least say something useful while you are at it...

To: jim kelley who wrote (24936)	12/17/1999 1:54:00 PM
From: rudedog	Read Replies (1) \| Respond to of 64865

Jim - You are on very weak technical ground. The SCSI drives, bus control chips and so on are about as much connected to performance as the gasoline is to performance in a car. Still a Ferrari is faster than a Ford LTD even though both use premium unleaded - As a rather basic example, many UNIX systems use a CAM-based async driver - this allows a single driver to handle pretty much the whole range of possible SCSI devices, but has several disadvantages, among them twice as many interrupts (and context switches) as a driver designed to enhance transaction performance. A driver specifically tailored to optimize transaction performance, with a sufficiently strong subsystem, can execute a transfer with NO interrupts or context switches. The differences in code path are stunning. A scatter-gather transfer of a megabyte of data from application space to disk using a CAM driver executes more than a MILLION instructions and performs 80 context switches, each of which flushes the I and D cache and causes a processor stall. The same operation on an enhanced driver requires 150,000 instructions and 40 context switches. An optimized driver can execute in less than 30,000 instructions with No context switches. These translate to aggregate system I/O levels of 2000, 8000 and 40,000 I/O per second... clearly, CPU speed will not overcome a 20X architectural advantage. BTW, the NT drivers in current use with the standard release are equivalent in performance to the CAM model...