mark@drd.com (Mark Lawrence) (04/15/91)
ajayshah%alhena.usc.edu@usc.edu (Ajay Shah) wrote: > > You carefully avoided putting any spoilers in your preview... now > could you just do a short summary? "Conclusion As you can see from Figure 1 [:-)], our tuned run of UNIX Oracle for the batch transactions ran roughly twice as fast as it had under OS/2. While there was an anomaly during the run -- transaction 30 overflowed temp table space, which is why it does not appear in the graph -- we think this general range of performance improvement will hold up when we resolve that problem. Things are far muddier with the accounting mix performance (Figure 2). [...] So what's the cause of this muddiness and the partial reversal of the general trend of better performance under UNIX? In a phrase: We needed more time to tune, but we had to ship it. [...] Finally, we're quite sure that adding 16 more megabytes of memory, which UNIX could make good use of while OS/2 could not, would not only eliminate the anomaly but greatly widen the performance gap between UNIX and OS/2 versions of Oracle Server." (don't yell at me -- I'm just the messenger. DBMS plans an extensive survey/benchmarking of rdbms on several server kinds of platforms over the next few issues. DBMS is published by M & T Publishing, 501 Galveston Dr, Redwood City, CA 94063. subscription inquiries to (800)456-1859. I've no relationship to this periodical. I just read it) -- mark@drd.com mark@jnoc.go.jp -- mark@drd.com mark@jnoc.go.jp
gupta@cai.com (04/20/91)
In article <1991Apr15.135105.4759@drd.com>, mark@drd.com (Mark Lawrence) writes: > ajayshah%alhena.usc.edu@usc.edu (Ajay Shah) wrote: >> >> You carefully avoided putting any spoilers in your preview... now >> could you just do a short summary? > > "Conclusion > > As you can see from Figure 1 [:-)], our tuned run of UNIX Oracle for > the batch transactions ran roughly twice as fast as it had under OS/2. > [...] A point that some might find of significance in this "benchmark" is that the machine used was a dual CPU multiprocessor. The operating system OS/2 does not support symmetric multi-processing. The SCO UNIX does. Now the people at DBMS wonder why UNIX is faster...
mark@drd.com (Mark Lawrence) (04/22/91)
In article <378.280f6241@cai.com> gupta@cai.com writes: >A point that some might find of significance in this "benchmark" is that >the machine used was a dual CPU multiprocessor. The operating system >OS/2 does not support symmetric multi-processing. The SCO UNIX does. >Now the people at DBMS wonder why UNIX is faster... That's just the point, isn't it? UNIX _can_ make use of more than 16 MB of ram, OS/2 _can't_. UNIX _can_ make use of more than one processor, OS/2 _can't_ (ad nauseum). So why does any MIS shop worth it's salt even consider moving to a dead-end closed solution like OS/2? The only advantage I can see is cost: Microsoft is really pushing SQL Server on OS/2 at the moment. The same engine (essentially) on a SparcStation class machine will set you back roughly five times the cost as OS/2. Also, to set the record straight, they did get OS/2 to make some use of both processors: "SCO UNIX also has the advantage of symmetrical multiprocessing. LAN Mangers 2.0's multiprocessing option allowed the LAN I/O and file system code to be dedicated to one processor while the rest of OS/2 and the database server ran on the other. Santa Cruz Operation's MPX option for UNIX 3.2.2 was not nearly so lopsided. While all IRQ handling would sit on processor 1 because of a SystemPro quirk, all other processes would be assigned to the less busy of the SystemPro's two 33 MHz 486 processors." -- mark@drd.com mark@jnoc.go.jp $B!J%^!<%/!&%i%l%s%9!K(B Nihil novum sub solem