Feedback

A forum for readers to speak their minds on issues that are important to the design community

Rancher's reprise

To the Editor:

I'd like to raise a few issues concerning your recent article on the Sun server ranches ("The Compute Ranch Takes Over EDA," August, p. 55). Ranches (or farms) are nothing new. When I worked for Intel a number of years ago (the early '90s--the Pentium era) they created what they termed a "RISC farm" made up of racks of IBM RS-6000s.

I noticed an omission of any reference to multi-threaded applications running on SMP engines. Isn't Sun exploiting this technology?

Is there a typo in the table for average queue time? Shouldn't that unit of measure be minutes, not hours?

Stephen Lear
Engineering services manager
Texas Instruments Storage Product Group
San Jose

Author Dwayne Lee replies:

Yes, I agree that ranches and farms aren't new; we at Sun put together our first farm back in 1991-92 during the development of the Ultrasparc-I processor. We are focusing on trying to get the message out that the ranch/farm computing methodology is a great way to leverage computing resources and to bring efficiency to compute-intensive tasks. This style of computing should be more commonplace than it has been.

We do run multi-threaded applications and our load-balancing/sharing software manages these applications appropriately. For example, a user can send a job into the system and ask for six CPUs; the system then reserves six CPUs for this particular job to run on. The EDA market, however, has yet to promote many multi-threaded applications. Sun has been working with our ISVs to develop more multi-threaded applications. Generally the EDA vendors need to develop this capability in new applications, as trying to add this to existing applications is very difficult. MP/MT applications are continuing to grow in number and we are seeing some very good applications taking advantage of Symmetric Multiprocessing (SMP) technology. Check out www.sun.com/technical-computing/EDA/isv.html for specifics.

The average queue time and to some extent the average run time numbers are a bit misleading. They in fact represent aggregate numbers for all jobs run through our compute pool. The queue time seems very high because the majority of the jobs run through are regression suites. These suites usually consist of a large number of jobs, usually in the thousands. They are queued all at once, so that last job waits a long time--hence the high queue time. In many cases users see very short queue times, on the order of minutes or even seconds. We have over 100 queues, allowing us to control latency and throughput. For jobs that run only a few minutes, we experience low-latency queues, while the queues for the regression suites have higher latencies but also higher throughput.

To voice an opinion on this or any other article in Integrated System Design, please e-mail your comments to jeff@isdmag.com.