Sponsored Content
Special Forums UNIX and Linux Applications High Performance Computing Benchmarking a Beowulf Cluster Post 302315137 by otheus on Monday 11th of May 2009 03:48:18 PM
Old 05-11-2009
Quote:
Oh the software was already installed by the university...have been told by the administrator that they are all working properly
Uh-hunh. I wouldn't completely trust that if I were you. Let's take it step-by-step.
  1. Use "type" or "which" or "whence" to find the full path of the linpack executable:
    Code:
    type -a hpl

  2. verify this has been compiled dynamically and not statically:
    Code:
    file <hpl path from step 1>

    You should see something like "Dynamically linked i386 object". As long as you don't see "statically linked binary" proceed to the next step. Otherwise, talk to your system admin and ask him/her very specifically how he/she compiled it.
  3. Next, run
    Code:
    ldd <hpl path from step 1>

    You should see something like "libopen-rte.so" in the output. If you do not, ask your sysadmin to point you to the correct hpl, the one this is compiled "against" (with) the openMPI runtimes.
  4. The libopen-rte.so should point to the full path of a file. If it does not, again, go to your system administrator and ask him/her for the full LD_LIBRARY_PATH that you should have to run against this hpl program.
  5. The path should be available to you by default on all machines in the cluster. If not, add the LD_LIBRARY_PATH setting into the .bashrc file and include your .bashrc from your .bash_profile (if you're using csh, god help you; if ksh, just change the names to .kshrc and .profile). Now log into the other machine and run the ldd command as above; you should see the line pointing to the full path of the MPI rte library.
  6. Make sure this all works by running:
    Code:
    mpirun -np 8 printenv LD_LIBRARY_PATH

    You should get 8 instances of the correct LD_LIBRARY_PATH.
  7. Now go back and try getting this to run for exactly 2 processes. (P=2, Q=1, -np 2)
  8. Now modify the machine file so it has two lines in it, one for each hostname, and run it again.
  9. If we're at this point, try again with 8; if it fails, there are some other things to look at and try.
 

9 More Discussions You Might Find Interesting

1. UNIX Benchmarks

Server and Workstation benchmarking

This is from my server AMD K6 133MHz 64Mb RAM 4GB HDD (Maxtor - ATA33) 2x10Mb NIC 1Mb Intel Graphic Card BYTE UNIX Benchmarks (Version 3.11) System -- FreeBSD sergiu.tarnita.net 5.0-RELEASE FreeBSD 5.0-RELEASE #2: Thu Mar 17 15:49:16 EET 2005... (0 Replies)
Discussion started by: Sergiu-IT
0 Replies

2. HP-UX

HP-Unix Hardware benchmarking

Hi everyone, I'm working on one HP-Unix application which we have to port completely onto Windows xp. Before that I have to compare performance of two different machines. My HP-Unix is running on HP-C8000 workstation and windows XP machine is intel Xeon. Now the problem is to evaluate the... (0 Replies)
Discussion started by: dgatkal
0 Replies

3. High Performance Computing

Building a Solaris Cluster Express cluster in a VirtualBox on OpenSolaris

Provides a description of how to set up a Solaris Cluster Express cluster in a VirtualBox on OpenSolaris. More... (0 Replies)
Discussion started by: Linux Bot
0 Replies

4. High Performance Computing

MySQL Cluster - Designing, Evaluating and Benchmarking (reg. req'd)

Registration is required. In this white paper learn the fundamentals of how to design and select the proper components for a successful MySQL Cluster evaluation. Explore hardware, networking and software requirements. Work through basic functional testing and evaluation best practices. More... (0 Replies)
Discussion started by: Linux Bot
0 Replies

5. High Performance Computing

Tuning HPL.dat for Beowulf Cluster [Linpack]

Hi guys, I am having some issues tuning the HPL.dat file for the Linpack benchmark test across 2 nodes. I am very new to this with minimal Linux experience, however i am trying my luck. The specs for the two nodes are: 3GHZ QX6850 CORE 2 EXTREME (QUAD CORE) 4GB RAM I have been typing these... (1 Reply)
Discussion started by: mercthunder
1 Replies

6. UNIX for Advanced & Expert Users

Benchmarking a new Solaris, with four different clients

Good morning, for the impatient: I have a new backup-server and need to monitor, what the machine can do, what's the best way of finding that out? I will tell the story right from the beginning, so you have a clue about what's going on: I have a setup of three machines: A new... (6 Replies)
Discussion started by: PatrickBaer
6 Replies

7. UNIX for Dummies Questions & Answers

benchmarking application

Where i get a open source benchmark program using pthread library for benchmarking our multicore system for the first stage.I need the source code too for that application ,because in later stage we need to develop our application so that i need to study pthread more. please anybody guide me . (0 Replies)
Discussion started by: sujith4u87
0 Replies

8. UNIX and Linux Applications

Benchmarking and performance analyzing in OS

Is/Are there an/some application/applications , package/packages for benchmarking or system performance measuring which are there for almost all Linux releases and distributions? (2 Replies)
Discussion started by: nixhead
2 Replies

9. Solaris

Sun cluster 4.0 - zone cluster failover doubt

Hello experts - I am planning to install a Sun cluster 4.0 zone cluster fail-over. few basic doubts. (1) Where should i install the cluster s/w binaries ?. ( global zone or the container zone where i am planning to install the zone fail-over) (2) Or should i perform the installation on... (0 Replies)
Discussion started by: NVA
0 Replies
LD.SO(8)						     Linux Programmer's Manual							  LD.SO(8)

NAME
ld.so, ld-linux.so* - dynamic linker/loader SYNOPSIS
The dynamic linker can be run either indirectly by running some dynamically linked program or library (in which case no command-line options to the dynamic linker can be passed and, in the ELF case, the dynamic linker which is stored in the .interp section of the program is executed) or directly by running: /lib/ld-linux.so.* [OPTIONS] [PROGRAM [ARGUMENTS]] DESCRIPTION
The programs ld.so and ld-linux.so* find and load the shared libraries needed by a program, prepare the program to run, and then run it. Linux binaries require dynamic linking (linking at run time) unless the -static option was given to ld(1) during compilation. The program ld.so handles a.out binaries, a format used long ago; ld-linux.so* handles ELF (/lib/ld-linux.so.1 for libc5, /lib/ld- linux.so.2 for glibc2), which everybody has been using for years now. Otherwise both have the same behavior, and use the same support files and programs ldd(1), ldconfig(8) and /etc/ld.so.conf. The shared libraries needed by the program are searched for in the following order: o (ELF only) Using the directories specified in the DT_RPATH dynamic section attribute of the binary if present and DT_RUNPATH attribute does not exist. Use of DT_RPATH is deprecated. o Using the environment variable LD_LIBRARY_PATH. Except if the executable is a set-user-ID/set-group-ID binary, in which case it is ignored. o (ELF only) Using the directories specified in the DT_RUNPATH dynamic section attribute of the binary if present. o From the cache file /etc/ld.so.cache which contains a compiled list of candidate libraries previously found in the augmented library path. If, however, the binary was linked with the -z nodeflib linker option, libraries in the default library paths are skipped. o In the default path /lib, and then /usr/lib. If the binary was linked with the -z nodeflib linker option, this step is skipped. $ORIGIN and rpath ld.so understands the string $ORIGIN (or equivalently ${ORIGIN}) in an rpath specification (DT_RPATH or DT_RUNPATH) to mean the directory containing the application executable. Thus, an application located in somedir/app could be compiled with gcc -Wl,-rpath,'$ORIGIN/../lib' so that it finds an associated shared library in somedir/lib no matter where somedir is located in the directory hierarchy. This facili- tates the creation of "turn-key" applications that do not need to be installed into special directories, but can instead be unpacked into any directory and still find their own shared libraries. OPTIONS
--list List all dependencies and how they are resolved. --verify Verify that program is dynamically linked and this dynamic linker can handle it. --library-path PATH Override LD_LIBRARY_PATH environment variable setting (see below). --inhibit-rpath LIST Ignore RPATH and RUNPATH information in object names in LIST. This option is ignored if ld.so is set-user-ID or set-group-ID. ENVIRONMENT
There are four important environment variables. LD_BIND_NOW (libc5; glibc since 2.1.1) If set to a nonempty string, causes the dynamic linker to resolve all symbols at program startup instead of deferring function call resolution to the point when they are first referenced. This is useful when using a debugger. LD_LIBRARY_PATH A colon-separated list of directories in which to search for ELF libraries at execution-time. Similar to the PATH environment vari- able. LD_PRELOAD A whitespace-separated list of additional, user-specified, ELF shared libraries to be loaded before all others. This can be used to selectively override functions in other shared libraries. For set-user-ID/set-group-ID ELF binaries, only libraries in the standard search directories that are also set-user-ID will be loaded. LD_TRACE_LOADED_OBJECTS (ELF only) If set to a nonempty string, causes the program to list its dynamic library dependencies, as if run by ldd(1), instead of running normally. Then there are lots of more or less obscure variables, many obsolete or only for internal use. LD_AOUT_LIBRARY_PATH (libc5) Version of LD_LIBRARY_PATH for a.out binaries only. Old versions of ld-linux.so.1 also supported LD_ELF_LIBRARY_PATH. LD_AOUT_PRELOAD (libc5) Version of LD_PRELOAD for a.out binaries only. Old versions of ld-linux.so.1 also supported LD_ELF_PRELOAD. LD_AUDIT (glibc since 2.4) A colon-separated list of user-specified, ELF shared objects to be loaded before all others in a separate linker namespace (i.e., one that does not intrude upon the normal symbol bindings that would occur in the process). These libraries can be used to audit the operation of the dynamic linker. LD_AUDIT is ignored for set-user-ID/set-group-ID binaries. The dynamic linker will notify the audit libraries at so-called auditing checkpoints--for example, loading a new library, resolving a symbol, or calling a symbol from another shared object--by calling an appropriate function within the audit library. For details, see rtld-audit(7). The auditing interface is largely compatible with that provided on Solaris, as described in its Linker and Libraries Guide, in the chapter Runtime Linker Auditing Interface. LD_BIND_NOT (glibc since 2.1.95) Do not update the GOT (global offset table) and PLT (procedure linkage table) after resolving a symbol. LD_DEBUG (glibc since 2.1) Output verbose debugging information about the dynamic linker. If set to all prints all debugging information it has, if set to help prints a help message about which categories can be specified in this environment variable. Since glibc 2.3.4, LD_DEBUG is ignored for set-user-ID/set-group-ID binaries. LD_DEBUG_OUTPUT (glibc since 2.1) File where LD_DEBUG output should be fed into, default is standard output. LD_DEBUG_OUTPUT is ignored for set- user-ID/set-group-ID binaries. LD_DYNAMIC_WEAK (glibc since 2.1.91) Allow weak symbols to be overridden (reverting to old glibc behavior). For security reasons, since glibc 2.3.4, LD_DYNAMIC_WEAK is ignored for set-user-ID/set-group-ID binaries. LD_HWCAP_MASK (glibc since 2.1) Mask for hardware capabilities. LD_KEEPDIR (a.out only)(libc5) Don't ignore the directory in the names of a.out libraries to be loaded. Use of this option is strongly dis- couraged. LD_NOWARN (a.out only)(libc5) Suppress warnings about a.out libraries with incompatible minor version numbers. LD_ORIGIN_PATH (glibc since 2.1) Path where the binary is found (for non-set-user-ID programs). For security reasons, since glibc 2.4, LD_ORI- GIN_PATH is ignored for set-user-ID/set-group-ID binaries. LD_POINTER_GUARD (glibc since 2.4) Set to 0 to disable pointer guarding. Any other value enables pointer guarding, which is also the default. Pointer guarding is a security mechanism whereby some pointers to code stored in writable program memory (return addresses saved by setjmp(3) or function pointers used by various glibc internals) are mangled semi-randomly to make it more difficult for an attacker to hijack the pointers for use in the event of a buffer overrun or stack-smashing attack. LD_PROFILE (glibc since 2.1) Shared object to be profiled, specified either as a pathname or a soname. Profiling output is written to the file whose name is: "$LD_PROFILE_OUTPUT/$LD_PROFILE.profile". LD_PROFILE_OUTPUT (glibc since 2.1) Directory where LD_PROFILE output should be written. If this variable is not defined, or is defined as an empty string, then the default is /var/tmp. LD_PROFILE_OUTPUT is ignored for set-user-ID and set-group-ID programs, which always use /var/profile. LD_SHOW_AUXV (glibc since 2.1) Show auxiliary array passed up from the kernel. For security reasons, since glibc 2.3.5, LD_SHOW_AUXV is ignored for set-user-ID/set-group-ID binaries. LD_USE_LOAD_BIAS By default (i.e., if this variable is not defined) executables and prelinked shared objects will honor base addresses of their dependent libraries and (nonprelinked) position-independent executables (PIEs) and other shared objects will not honor them. If LD_USE_LOAD_BIAS is defined wit the value, both executables and PIEs will honor the base addresses. If LD_USE_LOAD_BIAS is defined with the value 0, neither executables nor PIEs will honor the base addresses. This variable is ignored by set-user-ID and set- group-ID programs. LD_VERBOSE (glibc since 2.1) If set to a nonempty string, output symbol versioning information about the program if querying information about the program (i.e., either LD_TRACE_LOADED_OBJECTS has been set, or --list or --verify options have been given to the dynamic linker). LD_WARN (ELF only)(glibc since 2.1.3) If set to a nonempty string, warn about unresolved symbols. LDD_ARGV0 (libc5) argv[0] to be used by ldd(1) when none is present. FILES
/lib/ld.so a.out dynamic linker/loader /lib/ld-linux.so.{1,2} ELF dynamic linker/loader /etc/ld.so.cache File containing a compiled list of directories in which to search for libraries and an ordered list of candidate libraries. /etc/ld.so.preload File containing a whitespace separated list of ELF shared libraries to be loaded before the program. lib*.so* shared libraries NOTES
The ld.so functionality is available for executables compiled using libc version 4.4.3 or greater. ELF functionality is available since Linux 1.1.52 and libc5. SEE ALSO
ldd(1), rtld-audit(7), ldconfig(8) COLOPHON
This page is part of release 3.25 of the Linux man-pages project. A description of the project, and information about reporting bugs, can be found at http://www.kernel.org/doc/man-pages/. GNU
2009-01-12 LD.SO(8)
All times are GMT -4. The time now is 10:02 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy