Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
The Almighty Buck Hardware

Experiences When Transitioning to Low-End Workstations? 60

Posted by Cliff from the cutting-costs-by-cutting-the-heavy-iron dept.
gerddie asks: "Lately, we have seen a lot of companies starting to move their graphics stuff from high end to low end linux workstations (e.g. Dreamworks). Of course one reason to do such thing is cut costs, and therefore, at our institute we are going to replace or aging SGI O2s with Linux workstations. I wonder if you have experience with such a transition - especially regarding the usability of such machines for (scientific) visualization? What is working well, and where did you encounter pitfalls?"
This discussion has been archived. No new comments can be posted.

Experiences When Transitioning to Low-End Workstations? More

Experiences When Transitioning to Low-End Workstations?

Comments Filter:

  • I'm considering upgrading my Linux workstation to SGI. Ive heard it plays doom really well.

  • Linux will be faster (Score:5, Informative)

    by Atrapose ( 611668 ) on Tuesday May 06, 2003 @10:09AM (#5890591)
    SGI O2's run on a shared memeory idea. This format makes graphics on O2's quick because the common operation of sending data from what would be main memory to what would be texture / video memory on a PC extremely quick. Instead of having to travel through a latency timer and a PCI or AGP bus, the memory is just copied or a far jump send to the video controllers.

    However... With as fast as linux boxes are now, and as old as O2's are, I think you'll see a performace increase on the Linux side. I suggest you run a non-free windowing system instead of XFree86 (you'll find there are some commercial X-es out there that benchmark dramatically faster than XFree), and do a little streamlining of your kernel before putting the boxes live.

    Ta!
    • wouyld you be kind enough to name the non-free but "better and faster" windowing environments for linux, as opposed to the xfree86 "stock" dealie that comes with most distros? Thank you.

      • Re:such as? (Score:2, Informative)

        by Anonymous Coward
        Here's a link. [portalux.com]

        Metro-X and Xi are the two I've heard about.

      • Re:such as? (Score:3, Interesting)

        by sydlexic ( 563791 )
        better yet, just buy a system with an nvidia card and use nvidia's binary driver (it's free as in beer) for XFree. that'll be as fast as the commercial X distros alluded to but a bit cheaper.
        • Unfortunately the 2D image quality on NVidia cards is crap (3D probably is as well), so for a high-resolution workstation that's probably not a good path to take.
          • that's an interesting assertion. what, exactly, do you mean by it? I use nvidia cards to drive several LCD displays (from 1280x1024 to 1600x1200). the image is crisp and clean. and the binary drivers are very, very fast. perhaps your information is out of date.
            • Well, I've got a GeForce2 card in the PC here at work and a GeForce4 at home. At both locations I have a dual-input Dell (rebranded Sony) 21" monitor. On the other input of each is an old Beige G3 Mac (which is an ATI Rage Pro I believe) and a Matrox G400 respectively.

              Switching between the two inputs, the output from the ATI and Matrox cards is _amazingly_ better. Crisp, clean, easily usable @ 1600x1200. Comparitively, the output from the Nvidia cards is blurry and unusable for any length of time . Ev

    • O2 and Textures (Score:3, Informative)

      by green pizza ( 159161 )
      One of the best original uses for O2 was graphics with a lot of textures. As O2 uses a shared bank of ram for everything, a texture could be nearly any size. Some crazy people even wrote demos that would fly over 800MB+ texture maps. The downside of O2 is the rather limited geometry performance. This is why many of the "Killer Apps" for O2 are in the video industry... such as controlling the weather graphics for The Weather Channel and for local TV stations. Not much geometry there, it's mostly textures and

  • my experience (Score:1, Informative)

    by Anonymous Coward
    Where I work, we recently transitioned. It turned out to be a big headache due to minor annoyances.... XFree86 didn't support the video cards, so we had to get new ones. Linux didn't support the audio card, so we had to get new ones... Linux couldn't support more than 2 gig of ram, so we had to stick to that.


    Our biggest problem has been that many of the cheap boxes were cheap, and at least one needs maintenence weekly.

    • Re:my experience (Score:2, Informative)

      by vadim_t ( 324782 )
      Linux supports up to 64GB RAM, IIRC. See highmem support in the kernel config.

    • Re:my experience (Score:2, Insightful)

      by Anonymous Coward
      So let me get this right...

      you bought some fuckton of machines to run Linux without first ensuring that they -would- run Linux? A little common sense would've saved you here...

    • easy, done it several times before (Score:1, Interesting)

      by Anonymous Coward
      SGI, Sun, HP, IBM all basically want to sell you more or less proprietary hardware with expensive support contracts.

      I can almost buy, each and every year, a new fast Dell machine with a fast video card for what we paid in support for our old unix workstations.

      We go with this general platform:
      1. One or two steps below the fastest cpu
      2. One step below the fastest video card
      3. Default values for all of the other parts including IDE hard disks
      4. No monitor - we buy a new one when the old ones brea

  • O2s to Linux (Score:4, Informative)

    by Outland Traveller ( 12138 ) on Tuesday May 06, 2003 @10:24AM (#5890730)
    Well, if you did what we did and transition your SGI 02 R10-12ks to 2+Ghz PCs w/ a good quality graphics card, you can expect to see 5-10x the rendering performance at 1/3rd of the price.

    If you're used to SGI's extremely high quality "no bullshit" service department you might be in for a rude surprise, however. Even the very high end Dell service plans will only get you someone who goes on site for 30mins to change a component. They neither have the willingness nor the ability to diagnose symptoms, and none of them know ANYTHING about Linux.

    This can cause you a lot of pain and suffering if you have difficult-to-localize hardware issues in a demanding environment. My advice would be to either keep your own inventory for severe support scenarios, or go with a system vendor that provides a much higher quality level of field service than Dell's "partners".

  • There are some issues with Nvidia's OpenGL support (Score:4, Informative)

    by shocking ( 55189 ) on Tuesday May 06, 2003 @10:27AM (#5890760)
    While Nvidia's OpenGL is pretty good, there are a few obscure corners used by our seismic applications that they don't seem to support. In particular, the facility to use colour indexed textures is not supported in their current driver. It was supported in the earlier drivers, but there's not support for the later cards and a bunch of other bugs to cope with as well. It just means 4 times the texture usage or using vertex programs for the same effect, but not all high end hardware appears to support the vertex stuff. From what we can tell ATI has their own set of problems. Sigh.

  • I am doing this right now... (Score:4, Informative)

    by floydman ( 179924 ) <floydman@gmail.com> on Tuesday May 06, 2003 @11:51AM (#5891645)
    Well , i am in the middle of the project right now, and it was a hard way. We had simulation packages tunning on SC nodes, and that have been converted to linux. The visualization and data extraction tools are currently being migrated to linux too(from AIX, SGI and and Solaris 8). We are using UNIRAS graphics librarybya avs.
    Problems you are going to meet are:

    1) Big/Little endian issue, and this is one of the worst problems u will meet in your life :).

    2) There are minor code changes that you are going to do, concerning memory allocation.

    3) Ofcorse you will have to take care of large file support. :) (that one was fun)..

    Well, thats what i can remeber at the moment.. /*Why is there a penguin on my desktop?!*/
    • "Big/Little endian issue, and this is one of the worst problems u will meet in your life :)."

      I agree. Even when just communicating between processors with different endian schemes it's a mess if you're using a binary protocol. The worst thing is that you can't isolate the higher-level code from the translation unless you create a middle-layer that understands all of the messages.
      • One method u can overcome this endian issue, is to make al ur files in big endian, use htonl, and nltoh in ur reads and writes, where htonl is "host to netowrk language". Network language is known to be in big endian, so all ur calls will write with htonl to the file system(in big endian), and read with nltoh(will convert the big to little endian on the fly)...

        you can type: $man htonl

        /*Why is there a penguin on my desktop?!*/

    • ) Big/Little endian issue, and this is one of the worst problems u will meet in your life :).

      Aside from the daily erosion of the English language?

      Main Entry: u

      Pronunciation: 'yü
      Function: noun
      Inflected Form(s): plural u's or us /'yüz/
      Usage: often capitalized, often attributive
      Date: before 12th century
      1 a : the 21st letter of the English alphabet b : a graphic representation of this letter c : a speech counterpart of orthographic u
      2 : a graphic device for reproducing the letter u
      3 : on

  • Some useful comments here, but... (Score:4, Insightful)

    by kiwimate ( 458274 ) on Tuesday May 06, 2003 @01:01PM (#5892436) Journal
    ...wouldn't it be rather a good idea to try out a couple of the proposed new workstations in a, you know, pilot programme? For the cost of a couple of boxes, a couple of licenses of the software you're interested in, and the hours to set it all up, you'll be able to set up these PCs in an area where some of your people can try running their visualizations on them and see how it works out.

    From the post:

    I wonder if you have experience with such a transition - especially regarding the usability of such machines for (scientific) visualization?

    Not to take anything away from the posters (many of whom are making comments from obvious experience -- e.g. the comments about the different architectures (big-endian vs. little-endian), but usability is, after all, in the eye of the beholder.

    One other point (and please note I am not familiar with much outside of FEA type packages) is the software you're using -- does it have a Linux platform support, or are you contemplating making an application switch as well? If so, be prepared for some resistance from the users who will be used to how things work in their big and complex package, and will not want to learn a different big and complex package.
  • The O2 is about 7 years old. While it did have some specific uses and advantages (mainly video and high texture usage), it was not quite a powerhouse when it was originally announced. O2 replaced the low end Indy... both were 32-bit machines with significant memory limits. (Indy was limited to 256 MB RAM, O2 was limited to 1 GB RAM).

    It was the R10K Indigo2 and its replacement, the Octane that were the 64-bit desktop beasts back in their days.

    You'll find the Linux PC to be much faster. The O2 had its advan

  • Know your requirements and eval based on them (Score:5, Informative)

    by lcarstensen ( 130248 ) on Tuesday May 06, 2003 @01:47PM (#5893006)
    Speaking as someone from Dreamworks, I can tell you that it works incredibly well for us. But that's all I can say - you have to be able to figure out what the best platform is for your needs based on your own criteria, which should probably include:
    • ISV support. You should ask your ISV's how well their products work and how well they are supported. You should ask them what hardware and distributions they use to QA their applications.
    • Development environment for in-house code. GNU C++, STL compliance, and ATI/NVIDIA OpenGL support is pretty much just catching up to and is now ready to surpass SGI's support now. Java support has been far superior on Linux for years. What do you write your apps in?
    • IHV support. We picked a hardware vendor that had UNIX graphics desktop experience and was actively applying that experience to Linux. They pick supportable graphics cards and spend lots of time qualifying drivers for customer environments. You too can then ask them for help in working through the inevitable graphics and desktop bugs. There aren't many IHV's that can offer this.

    Absolutely, positively have multiple vendors come in with their graphics workstations and then proceed to evaluate how well your critical applications can run. Expect this process to take months.

    Finally, I'm not sure how large and mature your present environment is, but if you're talking about more than a few seats and two or three apps, expect a transition that takes a long time. Let people run their O2's next to their Linux boxes. Eventually, if you give the Linux systems proper care and feeding, you'll see dust start to collect on the O2's. Then, and only then, have you successfully completed your transition.

  • ROTFL! (Score:2, Interesting)

    by Anonymous Coward
    Sorry, I had to laugh.

    You are moving from O2s to PCs with Linux, and you are worried because the new machines won't be able to handle the visualization tasks? Worry about what to do with the lack of ethernal coffee pauses while you wait for programs to load or thing to compile, but don't worry about the PCs not handling the task.

    Problems you are going to find:

    * No 4Dwm replacement, your users are going to have to learn another window manager, sorry. (yes, I know there's a 4Dwm for non-Irix but the thin

    • Re:ROTFL! (Score:3, Informative)

      by green pizza ( 159161 )
      While I agree that a modern PC will be much faster than any O2 (that machine is 7 years old, good grief!), I do have to point out a few things...

      unless you were attached to those funny 4 bit visuals on the O2s
      Do you mean 5-bit visuals? The two most common visuals on O2 were RGBA5551 (common for analog video work) and 8-bit visuals -- RGBA8888 (common for everything else, but slightly slower for realtime video).

      Some OpenGL extensions are not available (think those funky SGI, SGIS, SGIX ones, and ARB_mu
    • You are moving from O2s to PCs with Linux, and you are worried because the new machines won't be able to handle the visualization tasks? Worry about what to do with the lack of ethernal coffee pauses while you wait for programs to load or thing to compile, but don't worry about the PCs not handling the task.

      It should come as no surprise that a 2003 PC is faster for some tasks than a 1996 workstation! What might come as a surprise is that for tasks bound by memory bandwidth or disk I/O rather than raw CPU,
  • What about AMD Opteron? That's a 64-bit workstation-like architecture at PC-like prices. You can run 64-bit SuSE, Mandrake or Red Hat on it, and avoid the pitfalls of downporting from 64-bits to 32-bits.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close