>Hi Gar,
>
>If I'm being a pain about this, feel free to ignore. . .
>
>So both were multiprocessors, with the second one being less "powerful" all around than the first.

Yes.
>
>What were the CPU mhz of each?
>


Can't access right now. But the big one was around 850, the smaller one around 750. You see we bought the line about putting money into Ram and Disk -- not processors. (The reason we had the multi-processor capablity is that most servers capable of handling really high quality disks and large amounts of RAM also have multi-processor capablity.
>With the 2 scenarios you have described it may even have been possible to get better than the industry average 1.7x difference in performance, and it looks like you did on the bigger box.
>
>The 1.7x comes from a mixed workload of several simultaneous jobs and the (approx.) .3 "loss" (people might have expected 2x) is the result, mostly, of contention for RAM and the overhead associated with giving each processor the latest content of the RAM whenever it asks for some.
>So in your case, running only one process (other than OS processes) that contention should be minimal, freeing up more processor cycles to do real user work.
>
>JimN

Last point -- the big machine usually had one major process running in server memory, plus some small processes where speed was not critical running on user workstations -- using the big server as a giant hard disk. VFP processes exclusively though. Small process did things like pull a few hundred records out of a 6 million record database using an optimizable query. Even with opening and closing the large table across the network this still was a matter of seconds. It was the really intensive processes (for example pulling 400,000 records into the 6 million record table that took time -- with extensive string manip and if-tests for for each record.).(BTW --SQL was much faster than a scan loop for us.)

On the workstation we were just running one process. It truly was used as a workstation.