UNIX Platform Notes

This section covers any special notes pertaining to certain UNIX platforms. Also check the README file shipped with the product. The README file contains the most current information for the product, and may contain information on platforms not covered in this book or information that is more current for your platform.

Sun Solaris

Solaris 64-Bit Shared Libraries

SmartSockets for Solaris includes a set of 64-bit shared libraries for building 64-bit RTclients. The rtlink shell script builds 64-bit versions of RTclients when you specify the -64bit flag. These libraries support the LP64 data model, using the compiler flag -xarch=generic64.

Build an RTclient application with the 64-bit client libraries by including the -64bit flag in the rtlink shell script. For example, this builds send64.x with the appropriate compiler flags and SmartSockets and operating system libraries for 64-bit applications:

See the Solaris 64-bit Developer's Guide in the Solaris Software Developer Collection for further details, including the trade-offs involved in the use of 64-bit applications.

Hardware and Software Requirements

To use the 64-bit RTclient libraries you must have a 64-bit version of Solaris installed on hardware that supports a 64-bit instruction set (sparcv9, EM64T, or AMD64). Use isainfo -b to confirm that you have a suitable Solaris 64-bit environment. These patches are also recommended (XX represents the current Sun Microsystems patch revision number):

106327-XX — shared library patch for 32 bit C++

106300-XX — shared library patch for 64-bit C++

107311-XX, where XX is at least number 18, if you are using the Sun Workshop 5.0 C++ compiler

See the Solaris 64-bit Developer's Guide in the Solaris Software Developer Collection for further details, including the trade-offs involved in the use of 64-bit applications.

GMD Restrictions

Solaris supports tmpfs, a memory-based file system used for increased performance, particularly with small, short-lived files. This file system type can be mounted on /tmp, which can severely disrupt file-based GMD functions. File-based GMD requires data to be written to an actual physical storage medium, and not simply cached in memory, so that GMD can continue to function after a possible reboot.

The tmpfs file system contents do not remain after restarting your system. In fact, they may never be written to a hard disk at all. Even when they are, it is to the swap filespace. Do not allow file-based GMD to be written to such partitions. Change the Ipc_Gmd_Directory RTclient option to a path on a different file system, or discontinue use of the tmpfs file system for /tmp.

High CPU Load and Scheduling Classes

Although it is not recommended that SmartSockets, especially RTservers, be used on machines with already overloaded CPUs, it is sometimes necessary. In these cases, it is important to recognize that lack of response from SmartSockets is generally caused by the overall system load and not a failure of the software. Understanding how your system allocates CPU time and setting process priorities and scheduling groups appropriately can make a large difference. For example, it might be necessary to do more than simply changing the priority with nice. In these cases, moving RTserver or other time-critical SmartSockets processes into a higher-priority, Real-Time scheduling class is useful. To change the scheduling class of a process, use the Solaris priocntl tool. For details of which classes are available and how to use priocntl, check your system’s priocntl man page.

WorkShop Version 5.0 -xO4 Optimization Level

SmartSockets is compiled on SPARC Solaris using the -xO4 optimization option of the Sun Microsystems WorkShop 5.0 C and C++ compilers. The rtlink shell script builds optimized RTclients on Solaris using the -xO4 optimization option. This is Sun Microsystems’ recommended optimization level with the WorkShop Version 5.0 compilers.

Hewlett-Packard HP-UX

HP-UX Version 11.x 64-Bit Shared Libraries

SmartSockets for HP-UX Version 11.x includes a set of 64-bit shared libraries for building 64-bit RTclients. The rtlink shell script builds 64-bit versions of RTclients when you specify the -64bit flag. These libraries support the HP-UX Version 11.x LP64 data model, using the compiler flag +DD64 (c) or +DA2.0W (cxx/cpp on HP 9000/7xx hardware).

builds send64.x with the appropriate compiler flags and SmartSockets and operating system libraries for 64-bit applications.

See the Hewlett-Packard document HP-UX 64-bit Porting and Transition Guide for HP9000 Computers for more information on issues associated with 64-bit applications.

Hardware and Software Requirements

To use the HP-UX 64-bit RTclient libraries you must have a 64-bit version of HP-UX 11.x installed on Itanium hardware, or on PA_RISC 2.0 hardware that supports a 64-bit instruction set. Use getconf KERNEL_BITS to confirm that you have a suitable HP-UX Version 11.x 64-bit environment. Hewlett-Packard recommends configuring HP-UX Version 11.x for additional system resources to run 64-bit applications. Increase disk space and physical memory to provide more than 4 GB of swap and 4GB of memory, and increase these kernel parameters:


Parameter	Minimum Value
`maxdsiz`	`0x40000000`
`maxdsiz_64bit`	`0x400000000`
`maxswapchunks`	`10000`

See the Hewlett-Packard document HP-UX 64-bit Porting and Transition Guide for HP9000 Computers for more information on issues associated with 64-bit applications.

HP-UX Thread Support

The HP-UX Version 11.x release uses the POSIX FINAL 1003.1c thread API to implement the SmartSockets cross-platform thread API.

If a SmartSockets application mixes calls to the SmartSockets cross-platform thread API with calls to the native POSIX thread API they must be POSIX FINAL 1003.1c calls when using the SmartSockets HP-UX Version 11.x release. See /usr/include/pthread.h for more information on how API calls are handled on HP-UX.

Advanced Tuning

If you do advanced tuning with your HP-UX system, you might not want to use the defaults provided by SmartSockets and your HP system, especially the defaults for _M_ARENA_OPTS and _M_SBA_OPTS. We provide some tips here for tuning them. If you have any questions about tuning, contact your HP technical advisor.

_M_ARENA_OPTS can be used to to adjust the number of arenas and how many pages are used each time an arena expands itself (the expansion factor), assuming that the page size is 4096 bytes. In general, the more threads in an application, the more arenas are needed to improve performance. _M_ARENA_OPTS does not affect non-threaded applications.

_M_ARENA_OPTS = arena_num:expansion_factor


`arena_num`	specifies the number of arenas. For non-threaded applications, only one arena is used. For threaded applications, the valid range is 4 to 64, and the default value is 8. If `arena_num` is not set or you specify a number outside the valid range, the default of 8 is used.
`expansion_factor`	specifies the expansion factor. The valid range is 1 to 4096. The default value is 32. If you specify a value outside the valid range, the default is used.

This sets the number of arenas to 16 and the expansion factor to 8 pages, each page being 4096 bytes. In general, the more arenas you use, the smaller the expansion factor should be, and the fewer the arenas, the larger the expansion factor.

_M_SBA_OPTS turns on the small block allocator, and sets up the maxfast, grain, and numblks parameters for the small block allocator. _M_SBA_OPTS affects both threaded and non-threaded applications. Applications usually run faster with the small block allocator turned on. The small block allocator can be turned on using mallopt(). However, that does not work well for C++ or Java applications. The environment variable turns it on before the application starts. The mallopt() call can still be used the same way. If the environment variable is set, and no small block allocator has been used, the subsequent mallopt()calls can still overwrite whatever is set using _M_SBA_OPTS. If the environment variable is set, and small block allocator has been used, then mallopt() has no effect.

_M_SBA_OPTS = maxfast:numblks:grain


`maxfast`	specifies the maxfast size.
`numblks`	specifies the number of small blocks.
`grain`	specifies the grain size.

This sets the maxfast size to 512, the number of small blocks to 100, and the grain size to 16. You must supply all three values, in the order shown. If you do not, the default values are used instead.

Linux

SmartSockets Software Release 6.8 was built with Red Hat Enterprise Linux Version 3.

SmartSockets on Linux includes the runtime RTmon only with its Command Interface (CI) and does not support the RTmon graphical user interface (GUI).

To build C++ RTclients using the g++ compiler set the CC environment variable to g++ when using the rtlink shell script, as in this example:

SmartSockets Software Release 6.8 running on Red Hat Linux looks for a shared library libg++.so. Create a symbolic link to the latest version of libg++ on your system. For example:

Linux 64-Bit Shared Libraries

SmartSockets for x86 Linux includes a set of 64-bit shared libraries for building 64-bit RTclients. The rtlink shell script builds 64-bit versions of RTclients when you specify the -64bit flag. These libraries support the LP64 data model, using the compiler flag -m64.

builds send64.x with the appropriate compiler flags and SmartSockets and operating system libraries for 64-bit applications.

Hardware and Software Requirements

To use the x86 64-bit RTclient libraries you must have a 64-bit version of Linux installed on hardware that supports the AMD64 or EM64T instruction set. Use uname -m to confirm that you have a suitable Linux 64-bit environment.

IBM AIX

Hardware and operating system software must support 64-bit to run the 64-bit version of SmartSockets.

To build and run 64-bit SmartSockets applications, LIBPATH must include $RTHOME/lib/$RTARCH/64bit before $RTHOME/lib/$RTARCH. Because AIX is not able to fall back on additional paths when a library mismatch (64-bit vs. 32-bit) occurs, RTserver must be started with the command rtserver64_o.x (to run optimized) or rtserver64_d.x (to run debug), and will normally run in the foreground. Not all options will be available when starting RTserver in this manner.

To stop RTserver, you must use the rtserver command, and $RTHOME/lib/$RTARCH/64bit must not appear in your $LIBPATH.

HP Alpha Tru64 UNIX

Silicon Graphics IRIX

This section presents brief information about the IRIX object code formats. For more information, see the abi(5) man page.

Supported Object Code Format

An Application Binary Interface (ABI) defines a system interface for executing compiled programs, defining the supported instruction set architectures (ISA), and the object file formats and calling conventions. IRIX Version 6.2 supports these ABIs:


Option	Description
-32 (O32)	The old 32 bit ABI that was standard on IRIX Version 5 systems. The -32 option is the default when compiling on any non-R8000 based machine. This ABI is not supported by SmartSockets.
-n32 (N32)	This high performance 32 bit ABI was introduced on IRIX Version 6.2, and generates an -n32 object. All SGI platforms support the development and execution of -n32 applications, but the subsystems containing the appropriate libraries are not always installed by default. This is the only ABI supported by SmartSockets.
-n64 (N64)	The 64 bit ABI was introduced on IRIX Version 6.0 systems. This is the default when compiling on any R8000 based machine, if no default specification file is present. This ABI is not supported by SmartSockets.

Each of these ABIs defines unique interfaces that make it impossible to link objects files of one ABI with object files of another ABI.

Thread Support on IRIX 6.5

An SGI Indy running IRIX 6.5 was used to test and release the latest SmartSockets distribution for IRIX. See the README file for the SmartSockets IRIX release for any recommended SGI patches to provide thread support.