The computer with the network name nevis1.nevis.columbia.edu
is an SGI Challenge XL. It is the primary network, mail, data, and backup server at Nevis Labs.
We are planning important upgrades to the system drives, operating system, processors, and network interface. Of these, the operating system upgrade raises the greatest number of issues, since it will take nevis1 off-line for a full day, and cause existing programs to break.
Note: These upgrades were finally completed by August, 1999. This web page is being left available for reference purposes.
The first question that you might ask is why we are upgrading at all. Since nevis1 is our mail server, any interruptions at all can interfere with our work. So if it works, why fix it?
There are two primary factors that motivate an upgrade at this time:
At present, we tentatively plan to upgrade nevis1 in March, April, and May. The exact schedule depends on the following:
When these bottlenecks are resolved, we will complete the upgrade schedule. The upgrades themselves are discussed in more detail below.
|System Drive Upgrade|
Note: The system drive upgrade was completed on 23-Mar-1999. The following section has been left intact to document the change.
If you type df on nevis1, you'll see that the / and /usr system partitions are being stored on a single 1GB drive. This is not enough disk space for the IRIX 6.5 upgrade, which requires roughly 2GB. It's also not enough disk space for our use of nevis1; the system has crashed in the past because all the disk space on /usr was used up.
We plan to replace the 1GB system drive with a 9GB drive, which is more than enough space for the installation of IRIX 6.5. In addition, we will partition the new drive in a manner suitable for a network server: /tmp and /var will have their own partitions, so a user cannot crash nevis1 by printing a long Acrobat document or starting a process that generates a gigabyte of error messages. Incidentally, nevis1 has in fact crashed for both those reasons in the past.
Note: For technical reasons (you can't have four mountable partitions on an SGI root drive) no separate /tmp partition was created. We will create such a partition on another drive at a later date.
To perform this upgrade, we will have to:
The total system downtime due to this upgrade will probably be 2-3 hours. It will be scheduled during non-work hours to minimize the impact on the users. Once the system is back up, there should be no difference in the functionality of nevis1.
Why are we installing two new 9GB disk drives? The reason is the IRIX 6.5 upgrade discussed below.
|IRIX 6.5 Upgrade|
Note: The operating system upgrade was completed on 13-May-1999. The following section has been left intact to document the change.
As discussed above, we must upgrade from IRIX 5.3 to IRIX 6.5 on nevis1 for Year 2000 compliance. However, the upgrade brings other benefits and changes as well. Among the changes:
These time estimates imply that, effectively, nevis1 will completely unavailable for about a day. We will try to schedule this upgrade at a time that minimizes the impact of the loss of services (particularly mail).
It may be that for some users, nevis1 will continue to be unusable until certain programs are upgraded or re-compiled. This leads to the next question...
The newer compilers bring the promise of performance improvements since they will take better advantage of the architecture of the R4400 processors. However, before this benefit is realized, there is a serious hurdle to overcome: some of the software compiled under IRIX 5.3 will not execute under IRIX 6.5.
As far as your own programs are concerned, this only affects you if for some reason you can't re-compile your code after you upgrade.
If this affects you, your first question probably is, "Are any of my own programs dynamically linked?" If you don't know, then they're almost certainly not dynamically linked. Dynamic linking requires special setup and software configuration; if you don't already know that you use shared libraries, then chances are that you don't. If you want to check if any of your code uses shared libraries, look for files with the .so extension, or for the compiler options -shared or -Bdynamic. If you don't see these files or extensions, then you don't use shared libraries.
A testbench installation of IRIX 6.5.3 has been set up on nevis3. It is not intended to be the full-fledged physics-analysis environment that used to be supported on nevis3, but most of the common utilities are available. If you would like an account on nevis3 to see if your programs will work, let me know.
The main problem is with a large number of utility and analysis programs that have been installed on nevis1 over the years. Some software, especially the GNU-based compilers, use shared libraries. Here's the current list of programs (as of 25-Feb-1999) that have been tested under IRIX 6.5. If you don't see a program you use on the list, please ask me to test it.
|5.3 version works on 6.5||5.3 version does not work on 6.5||Notes with post-upgrade comments|
|AFS 3.3||AFS 3.4a (a beta version) works with IRIX 6.5. We have received the software and tested that it works on nevis3.|
|CERNLIB 98 (including PAW and PAW++)||Eventually, I'll upgrade to the IRIX 6.5 binaries available from CERN. The IRIX 6 versions of CERNLIB 98 and CERNLIB 99 were installed on 14-May-1999.|
|Native compilers (cc, CC, f77)||GNU compilers (gcc, g++, g77)||The GNU compilers (and all other GNU software) will be re-compiled.|
|emacs||Eventually I'll re-compile this for the performance benefits of the new system.|
|ghostscript||Because ghostscript was tricky to configure, I probably won't re-compile this unless a major new version of ghostscript is released.|
|/usr/bin/X11/ghostview||/usr/local/bin/ghostview||Use the older ghostview until the new one is re-compiled.|
|GNU file, find, text, and shell utilities (such as less)||Eventually I'll re-compile these for the performance benefits of the new system.|
|IMAP||Actually, I'm uncertain about this, since I was only able to partially test the imapd program under IRIX 6.5 on nevis3. I'll probably compile and install the latest version of IMAP (4.5) to be sure.|
|latex and dvips||Because latex is so difficult to configure, I'll probably never re-compile the distribution, unless a major new version of latex is released.|
|Netscape 4.07||After we upgrade, I'll also install Netscape 4.5, which is only available for IRIX 6.5. Note: SGI has configured Netscape so that Netscape 4.07 and 4.51 cannot be on the same system at the same time. The installation of Netscape 4.51 awaits a software upgrade from SGI.|
|pine||Eventually I'll re-compile this for the performance benefits of the new system.|
|root||I'll upgrade to the 6.5 version available at http://root.cern.ch/. Completed 14-May-1999. However, some users report problems linking root with their own programs.|
|ssh||sshd||Until sshd is re-compiled, you will be able to ssh from nevis1, but you will not be able to ssh to nevis1. This turned out not to be true. Sshd functioned normally after the upgrade.|
|tcsh||We are presently running a buggy version of tcsh on nevis1. I'll upgrade to the latest version (6.0.8) during the IRIX 6.5 upgrade.|
|xemacs||Although xemacs will continue to work, I suggest you consider migrating to emacs instead.|
|xv (xview)||Eventually I'll re-compile this for the performance benefits of the new system.|
As you can see from the above table, there are a number of important programs that must be upgraded or re-compiled as part of the IRIX 6.5 upgrade. Please send me your comments on which programs are the most important to you; this will help me plan the order in which I'll upgrade or re-compile the software.
Added 09-Mar-1999: At present, I plan to compile/install the software in this order:
The issue being addressed here is: What if you compile a program under IRIX 6.5 and make it available on another system running IRIX 5.3? "Make it available" includes copying the binary program to the other computer, or mounting a nevis1 disk drive remotely via AFS or NFS.
As mentioned above, if a program was compiled on nevis1 running IRIX 5.3, and that program was statically linked, it will execute under IRIX 6.5. However, the reverse may not be true: a program compiled under IRIX 6.5 may not execute under IRIX 5.3. Programs that use shared libraries must be re-compiled for their target systems. But even statically-linked programs can have problems if you don't consider the processor configuration in the target machine.
In brief, if you want to make sure your binary code will execute if it's copied to IRIX 5.3, you must include the -o32 -mips2 compiler options:
f77 -o32 -mips2 myprog.f -o myprog
The -o32 -mips1 options were the effective default under IRIX 5.3; they generate 32-bit code compatible with the old R3000 processors.
When we upgrade to IRIX 6.5, the -n32 -mips3 options will become the default. They will generate 32-bit code that takes advantage of nevis1's R4400 64-bit processor architecture. When we upgrade to the R10000 processors, you'll be able to use the -64 -mips4 options, which will generate 64-bit code that will take full advantage of the R10000 processor architecture. However, code generated by these compiler options will not run under IRIX 5.3, or on systems with processors older than R8000.
You can read more about this issue in the developer manuals that will be available via the insight command after we've upgraded to IRIX 6.5.
As Dave Leon discussed in an earlier memo, the SGI currently has four 150MHz R4400 processors. We plan to upgrade them to four 250MHz R10000 processors. This should approximately double the speed of the system and help ease the processing bottlenecks we encountered last summer.
The installation of the upgrade is simple compared to the previous two upgrades. The system will be down for about an hour in order for an SGI technician to remove a one card and replace it with another.
After the processor upgrade, in order to see the full benefits you should consider compiling your software with the all the optimization options:
f77 myprog.f -64 -mips4 -pfa -ipa -O3 -o myprog.
The developer manuals that will be available via the insight command after we've upgraded will describe the full set of optimization options.
However, any such code will not execute on an SGI with anything less than an R10000 processor. This issue only affects you if you copy compiled programs from one system to another.
After the processor upgrade, I may re-compile some of our commonly-used software packages (such as emacs) with the optimization options to get the best possible speed. However, if I re-compile the GNU compilers (gcc, g++, g77) with all the MIPSPro optimization options, they will only generate R10000 code (the GNU compilers don't recognize SGI compiler options; only the native compilers do). Should I enhance the GNU compilers for speed on nevis1, or leave them unchanged for compatibility of binary code? Please send me your comments on this issue.
The final nevis1 hardware upgrade we plan to do is an upgrade of the SGI's network card to 100 Mbit. This will remove a major network bottleneck in preparation for this summer.
Again, this upgrade should be comparatively simple, and take about an hour.
to the Nevis Home Page.
Send any comments or questions to the webmaster.