Changes between Version 9 and Version 10 of Installation_and_Configuration


Ignore:
Timestamp:
11/16/11 13:03:53 (10 years ago)
Author:
branden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Installation_and_Configuration

    v9 v10  
    22 
    33= Installation and Configuration = 
    4 The following notes are intended to be a general guide to installing an Automatic [wiki:Earthworm Earthworm] system. Note that, the [wiki:Earthworm Earthworm] project consists of the Automatic and Interactive portions of [wiki:Earthworm Earthworm]. As described in [wiki:Overview Overview], the Automatic portion consists of the "real-time", rapid-response modules, and the Interactive portion consists of the DBMS (Data Base Management System) and web-page codes. These notes deal with the installation of the Automatic portion of [wiki:earthworm Earthworm]. 
     4The following notes are intended to be a general guide to installing an Automatic Earthworm system. Note that, the Earthworm project consists of the Automatic and Interactive portions of Earthworm. As described in [wiki:Overview Overview], the Automatic portion consists of the "real-time", rapid-response modules, and the Interactive portion consists of the DBMS (Data Base Management System) and web-page codes. These notes deal with the installation of the Automatic portion of Earthworm. 
    55 
    66These notes are based on the experiences gained from numerous installations, and represent an idealized, average situation. In practice, of course, each installation presents unique challenges which require specific solutions. It is hoped, however, that these notes may be of use in preventing common problems and expediting the process. 
     
    1414== 1. DETERMINE THE DESIRED FUNCTIONS == 
    1515 
    16 [wiki:Earthworm Earthworm] currently offers the following general features: 
     16Earthworm currently offers the following general features: 
    1717 
    18181.1. Analog data acquisition (e.g., [wiki:adsend adsend]): 12 or 16 bit A/D conversion, up to 256 channels per Windows 2000 machine, any number of such machines per system. 
     
    34341.9 On-line Trace Data Storage (XXX): all acquired trace data can be made available via an IP server for a configurable time period, ranging from hours to weeks. 
    3535 
    36 1.10. Distributed systems (XXX): Any number of [wiki:Earthworm Earthworm] systems can be linked via IP communication links. The extend of such linkages is configurable. Possible configurations include a 'master' central site and any number of remote nodes operating as one integrated system, as well as limited, negotiated linkages between two sovereign central systems. 
    37  
    38 1.11. Multi-machine configurations (XXX): Any number of networked Linux, Windows 2000 or Solaris computers can be combined to run one [wiki:Earthworm Earthworm] system. 
    39  
    40 1.12 Data Exchange (e.g., [wiki:export_generic export_generic], [wiki:import_generic import_generic]): Any type of internal data can be exchanged in real time with other [wiki:Earthworm Earthworm] systems. This exchange mechanism has proved to be quite reliable, and has performed well in numerous applications. It requires a communications link capable of physically interfacing to a computer's ethernet port and capable of carrying IP messages. It functions over the public internet as well as private dedicated links. 
     361.10. Distributed systems (XXX): Any number of Earthworm systems can be linked via IP communication links. The extend of such linkages is configurable. Possible configurations include a 'master' central site and any number of remote nodes operating as one integrated system, as well as limited, negotiated linkages between two sovereign central systems. 
     37 
     381.11. Multi-machine configurations (XXX): Any number of networked Linux, Windows 2000 or Solaris computers can be combined to run one Earthworm system. 
     39 
     401.12 Data Exchange (e.g., [wiki:export_generic export_generic], [wiki:import_generic import_generic]): Any type of internal data can be exchanged in real time with other Earthworm systems. This exchange mechanism has proved to be quite reliable, and has performed well in numerous applications. It requires a communications link capable of physically interfacing to a computer's ethernet port and capable of carrying IP messages. It functions over the public internet as well as private dedicated links. 
    4141 
    42421.13. Long period Events (XXX): A volcanic long-period event detector, developed by John Evans at Menlo Park.  
     
    4646== 2. ESTIMATE THE HARDWARE REQUIREMENTS == 
    4747 
    48 [wiki:Earthworm Earthworm] has been developed under the mandate of speed and reliability. It therefore tends to use fast, low-level operating system services rather than high-level end-user packages. A side effect of this is that [wiki:Earthworm Earthworm] is fairly economical in terms of hardware requirements. In general, a contemporary Pentium- or Ultra- class machine is adequate for most regional network loads. Specifically, the hardware requirements can be divided into four categories: 
     48Earthworm has been developed under the mandate of speed and reliability. It therefore tends to use fast, low-level operating system services rather than high-level end-user packages. A side effect of this is that Earthworm is fairly economical in terms of hardware requirements. In general, a contemporary Pentium- or Ultra- class machine is adequate for most regional network loads. Specifically, the hardware requirements can be divided into four categories: 
    4949 
    5050a. Data acquisition: This can be via the ethernet network port, system bus, or serial ports. In practice, we have not observed problems in the first two cases. We have observed problems with serial port acquisition, especially when running on the same machine as the bus-based A/D acquisition. The symptoms are intermittent data loss from the serial ports, and warning messages from the A/D subsystem. 
     
    5656Network bandwidth requirements are critical on the input side, as the trace input streams are real-time. The server-side responses, or course, are not. In situations where this is a concern, a second, dedicated ethernet subnet is usually established to carry real-time trace data, and the participating machines are equipped with two (or more) network adapters. 
    5757 
    58 d. Event storage and processing: As mentioned above, [wiki:Earthworm Earthworm] can produce directories of event files from various triggers in various formats. Adequate disk space has to be provided to hold such events until they are moved to off-line media. Considerations there include the expected worst-case seismicity levels, time of storage, and off-line media capacity and life-time. 
     58d. Event storage and processing: As mentioned above, Earthworm can produce directories of event files from various triggers in various formats. Adequate disk space has to be provided to hold such events until they are moved to off-line media. Considerations there include the expected worst-case seismicity levels, time of storage, and off-line media capacity and life-time. 
    5959 
    6060* Determine the hardware required (or available) at each node and the central site. 
     
    6868== 3. PRODUCE A TEST EVENT == 
    6969 
    70 This is an optional step which has proven to be extremely useful in rapidly producing a reliable configuration in low-seismicity areas. It will not be needed until testing, but the effort should be initiated early to produce a timely result. The procedure is to find a suitable past event recorded on digital media, and to convert this to an [wiki:Earthworm Earthworm] 'player' file. [wiki:Earthworm Earthworm] includes a 'player' module ([wiki:waveserverV waveserverV]) which can be used to repeatedly inject the trace data of the event to test the operation of the system. 
    71  
    72 This usually requires help from members of the [wiki:Earthworm Earthworm] development team, and may require some effort, although some conversion software from other formats exists (such as PC-SUDS, CUSP, SAC, MSEED,...).  
     70This is an optional step which has proven to be extremely useful in rapidly producing a reliable configuration in low-seismicity areas. It will not be needed until testing, but the effort should be initiated early to produce a timely result. The procedure is to find a suitable past event recorded on digital media, and to convert this to an Earthworm 'player' file. Earthworm includes a 'player' module ([wiki:waveserverV waveserverV]) which can be used to repeatedly inject the trace data of the event to test the operation of the system. 
     71 
     72This usually requires help from members of the Earthworm development team, and may require some effort, although some conversion software from other formats exists (such as PC-SUDS, CUSP, SAC, MiniSEED,...).  
    7373   
    7474  
     
    7878* Request an FDSN network code by submitting the form at http://www.fdsn.org/forms/netcode_request.htm. This two-letter code is used throughout the system as part of the trace data naming convention. It is also essential if any data exchange with other networks is contemplated. 
    7979 
    80 * Request an [wiki:Earthworm Earthworm] "Installation Id" from Mitch Withers, [http://www.ceri.memphis.edu/index.shtml CERI] (Center for Earthquake Research and Information, University of Memphis, USA). Mitch will update the distribution to include your new Installation Id, and issue an updated [wiki:earthworm_global earthworm_global] to all involved installations. 
    81  
    82 * [wiki:Earthworm Earthworm] uses the IRIS SCNL (Station, Component, Network, Location) channel naming convention. See the IRIS web site for details. An installation is free to define its own naming convention, but this may present problems if linkages to other institutions are desired. 
     80* Request an Earthworm "Installation Id" from Mitch Withers, [http://www.ceri.memphis.edu/index.shtml CERI] (Center for Earthquake Research and Information, University of Memphis, USA). Mitch will update the distribution to include your new Installation Id, and issue an updated [wiki:earthworm_global earthworm_global] to all involved installations. 
     81 
     82* Earthworm uses the IRIS SCNL (Station, Component, Network, Location) channel naming convention. See the IRIS web site for details. An installation is free to define its own naming convention, but this may present problems if linkages to other institutions are desired. 
    8383 
    8484* Define all station names and locations, and produce a station list in [wiki:hypoinverse hypoinverse] format. If some parameters are not known, use unique temporary names and values which can later be search-and-replaced with real values.  
     
    8686  
    8787 
    88 == 5. CREATE THE [wiki:Earthworm Earthworm] SOFTWARE DIAGRAMS == 
     88== 5. CREATE THE Earthworm SOFTWARE DIAGRAMS == 
    8989 
    9090For each node, draw a diagram showing modules, message rings, and message paths. Examples are given at [wiki:Example_Configurations Example Configurations]. The diagram should include: 
     
    102102  
    103103 
    104 5.1 [wiki:Earthworm Earthworm] NAMING SCHEME (BACKGROUND): 
    105  
    106 There are four types of names within the [wiki:Earthworm Earthworm] system: "Installation Id", "Module Id", "Message Type", and "Ring Name". Each type of name is represented as an ASCII string at the human interface level, but is resolved to a numeric value when the system is running. The motivation for the naming scheme is that 
    107  
    108 * [wiki:Earthworm Earthworm] is a message-passing system, 
    109  
    110 * An [wiki:Earthworm Earthworm] system consists of many modules which listen to and produce messages, and 
    111  
    112 * Many [wiki:Earthworm Earthworm] systems can exchange messages. 
    113  
    114 To implement this, each message, as it is generated, is given a 'shipping label' which contains the numeric values of "Installation Id", "Module Id", "Message Type". The "Installation Id" is the name of the installation at which this [wiki:Earthworm Earthworm] is running. The "Module Id" is the name of the module which generated this message, and "Message Type" is the name of the type of message this is (eg. trace data, pick, location, heartbeat, etc) 
    115  
    116 Since any message may be shipped to any installation, this combination has to be unique amongst all [wiki:Earthworm Earthworm] installations. This is assured by keeping the "Installation Id" unique. These are assigned by Mitch Withers at [http://www.ceri.memphis.edu/index.shtml CERI] (Center for Earthquake Research and Information, University of Memphis, USA). 
     1045.1 Earthworm NAMING SCHEME (BACKGROUND): 
     105 
     106There are four types of names within the Earthworm system: "Installation Id", "Module Id", "Message Type", and "Ring Name". Each type of name is represented as an ASCII string at the human interface level, but is resolved to a numeric value when the system is running. The motivation for the naming scheme is that 
     107 
     108* Earthworm is a message-passing system, 
     109 
     110* An Earthworm system consists of many modules which listen to and produce messages, and 
     111 
     112* Many Earthworm systems can exchange messages. 
     113 
     114To implement this, each message, as it is generated, is given a 'shipping label' which contains the numeric values of "Installation Id", "Module Id", "Message Type". The "Installation Id" is the name of the installation at which this Earthworm is running. The "Module Id" is the name of the module which generated this message, and "Message Type" is the name of the type of message this is (e.g., trace data, pick, location, heartbeat, etc) 
     115 
     116Since any message may be shipped to any installation, this combination has to be unique amongst all Earthworm installations. This is assured by keeping the "Installation Id" unique. These are assigned by Mitch Withers at [http://www.ceri.memphis.edu/index.shtml CERI] (Center for Earthquake Research and Information, University of Memphis, USA). 
    117117 
    118118A module specifies which messages it is interested in listening to by specifying the 'shipping label'. Therefore, to be general, the "Module Id" must be unique within an installation. (Note that a module may specify a list of desired 'shipping labels', as well as specify wild-card values for selected portions of a label.) 
     
    120120In order to facilitate meaningful data exchange, there have to be "Message Type" values which are common to all installations. That is, if two installations decide to exchange pick data, both systems must have the same value for "Message Type" pick. Any installation can, of course, define additional private "Message Type" for its own internal purposes. 
    121121 
    122 "Ring Names" are used by each module to specify which message ring the module is to 'listen to', and which ring it is to broadcast messages into. These names must be unique to each node. A set of traditional names have evolved, (eg. WAVE_RING, PICK_RING, HYPO_RING, etc) and it is recommend to adhere to those, as it greatly reduces the amount of editing required. 
    123  
    124 The names appear in the configuration files of each module in the form of ASCII strings. The tables which define the numeric values of those strings are stored in two files: [wiki:earthworm earthworm].d and [wiki:earthworm_global earthworm_global].d. "earthworm_global.d" contains the definitions which are common to all [wiki:Earthworm Earthworm] sites: the "Installation Id" and "Message Type" values which are exchanged between installations. Changes to this file are coordinated through Mitch Withers at [http://www.ceri.memphis.edu/index.shtml CERI] (Center for Earthquake Research and Information, University of Memphis, USA). "earthworm.d" contains definitions for local "Message Type", "Module Id", and "Ring Name". 
    125  
    126 In the [wiki:Earthworm Earthworm] release these two files are included in the subdirectory "environment". They have to be moved from there to the local /run/params directory. 
    127  
    128   
    129  
    130 == 6. LOAD THE [wiki:Earthworm Earthworm] SOFTWARE == 
    131  
    132 The [wiki:Earthworm Earthworm] Directory Structure: 
     122"Ring Names" are used by each module to specify which message ring the module is to 'listen to', and which ring it is to broadcast messages into. These names must be unique to each node. A set of traditional names have evolved, (e.g., WAVE_RING, PICK_RING, HYPO_RING, etc) and it is recommend to adhere to those, as it greatly reduces the amount of editing required. 
     123 
     124The names appear in the configuration files of each module in the form of ASCII strings. The tables which define the numeric values of those strings are stored in two files: [wiki:earthworm earthworm].d and [wiki:earthworm_global earthworm_global].d. "earthworm_global.d" contains the definitions which are common to all Earthworm sites: the "Installation Id" and "Message Type" values which are exchanged between installations. Changes to this file are coordinated through Mitch Withers at [http://www.ceri.memphis.edu/index.shtml CERI] (Center for Earthquake Research and Information, University of Memphis, USA). "earthworm.d" contains definitions for local "Message Type", "Module Id", and "Ring Name". 
     125 
     126In the Earthworm release these two files are included in the subdirectory "environment". They have to be moved from there to the local /run/params directory. 
     127 
     128  
     129 
     130== 6. LOAD THE Earthworm SOFTWARE == 
     131 
     132The Earthworm Directory Structure: 
    133133 
    134134 
     
    148148                        /environment 
    149149where 
    150 /earthworm is the root of the [wiki:Earthworm Earthworm] software; 
    151  
    152 /run is the directory which specifies and contains all data specific to an [wiki:Earthworm Earthworm] configuration. Many such 'run' directories can be stored under /[wiki:Earthworm Earthworm], each specifying a distinct construction. Note that only one such construction can be running at a time. 
    153  
    154 /params contains the files specifying the configuration and environment for this [wiki:Earthworm Earthworm] construction. 
     150/earthworm is the root of the Earthworm software; 
     151 
     152/run is the directory which specifies and contains all data specific to an Earthworm configuration. Many such 'run' directories can be stored under /Earthworm, each specifying a distinct construction. Note that only one such construction can be running at a time. 
     153 
     154/params contains the files specifying the configuration and environment for this Earthworm construction. 
    155155 
    156156/log contains all log files generated by this construction. 
    157157 
    158 /vx.xx represents some [wiki:Earthworm Earthworm] version, as obtained from the distribution. 
     158/vx.xx represents some Earthworm version, as obtained from the distribution. 
    159159 
    160160/bin contains all executables for this version, as obtained from the distribution, or by local compilation. 
     
    166166Loading the Software: 
    167167 
    168 * Create the root directory for [wiki:Earthworm Earthworm] (e.g. c:\earthworm). Bring the current [wiki:Earthworm Earthworm] release from [wiki:Downloads Downloads] into this directory, and unpack it there. 
     168* Create the root directory for Earthworm (e.g. c:\earthworm). Bring the current Earthworm release from [wiki:Downloads Downloads] into this directory, and unpack it there. 
    169169 
    170170* Note that the executable binaries are in separate directories of the ftp site. The appropriate version of the executables should be placed in the \bin directory (e.g. c:\earthworm\v#.#\bin). 
     
    182182* Under each such run directory create a \log and a \params directory. The \log directory will contain all log files witten by modules in this node. The \params directory will contain all configuration files (.d and .desc) neccessary to run this node. 
    183183 
    184 * Copy three files from the release the each of the \parms directories. These are [wiki:earthworm_global earthworm_global].d, [wiki:earthworm earthworm].d, and "ew_nt.cmd" (or "ew_sol_sparc.cmd", or "ew_sol_intel.cmd", depending on the platform). These files are located in the [wiki:Earthworm Earthworm] release in the \environment directory.  
    185    
    186   
    187  
    188 == 8. CONFIGURE THE [wiki:Earthworm Earthworm] ENVIRONMENT FILES == 
     184* Copy three files from the release the each of the \parms directories. These are [wiki:earthworm_global earthworm_global].d, [wiki:earthworm earthworm].d, and "ew_nt.cmd" (or "ew_sol_sparc.cmd", or "ew_sol_intel.cmd", depending on the platform). These files are located in the Earthworm release in the \environment directory.  
     185   
     186  
     187 
     188== 8. CONFIGURE THE Earthworm ENVIRONMENT FILES == 
    189189 
    190190* The [wiki:earthworm_global earthworm_global].d file should contain your Installation Id. Contact Mitch Withers at [http://www.ceri.memphis.edu/index.shtml CERI] (Center for Earthquake Research and Information, University of Memphis, USA), who acts as control for this file. Local editing of this file is possible, but will prevent the installation form exchanging data with other sites. 
    191191 
    192 * Edit [wiki:earthworm earthworm].d: Using your [wiki:Earthworm Earthworm] software diagram, enter a definition for each each mesasage Ring Name and Module ID at each node. At this point, do not alter the Message Types found there, but use the default entries. 
    193  
    194 * Create a .cmd file for each node. This file contains the environment variables used by the [wiki:Earthworm Earthworm] system. As mentioned above, these files are platform specific, and currently three versions exist: for Windows 2000 and NT: "ew_nt.cmd", for Solaris on Sparc: "ew_sol_sparc.cmd", and for Solaris on Intel: "ew_sol_intel.cmd". (OS/2 has sadly been dropped). Thus, for example, one would create files such as "ew_sol_sparc_central.cmd", "ew_nt_remote1.cmd", and "ew_nt_remote2.cmd". 
     192* Edit [wiki:earthworm earthworm].d: Using your Earthworm software diagram, enter a definition for each each mesasage Ring Name and Module ID at each node. At this point, do not alter the Message Types found there, but use the default entries. 
     193 
     194* Create a .cmd file for each node. This file contains the environment variables used by the Earthworm system. As mentioned above, these files are platform specific, and currently three versions exist: for Windows 2000 and NT: "ew_nt.cmd", for Solaris on Sparc: "ew_sol_sparc.cmd", and for Solaris on Intel: "ew_sol_intel.cmd". (OS/2 has sadly been dropped). Thus, for example, one would create files such as "ew_sol_sparc_central.cmd", "ew_nt_remote1.cmd", and "ew_nt_remote2.cmd". 
    195195 
    196196In each file, edit the definitions for EW_INSTALLATION, EW_HOME, EW_VERSION, EW_PARAMS and EW_LOG. The remainder of the file requires no change: 
     
    198198EW_INSTALLATION is the installation id of this institution, as listed in [wiki:earthworm_global earthworm_global].d. 
    199199 
    200 EW_HOME is the [wiki:Earthworm Earthworm] root directory ("/earthworm"). 
    201  
    202 EW_VERSION is the version of the [wiki:Earthworm Earthworm] release to be used (eg. v7.5). This permits several versions to be stored concurrently. Changing this definition will cause various versions to be run. 
    203  
    204 EW_PARAMS specifies the path to the dirctory from will paramete files will be read (eg. /earthworm/run_central/params). This will be different for each node. 
     200EW_HOME is the Earthworm root directory ("/earthworm"). 
     201 
     202EW_VERSION is the version of the Earthworm release to be used (e.g., v7.5). This permits several versions to be stored concurrently. Changing this definition will cause various versions to be run. 
     203 
     204EW_PARAMS specifies the path to the dirctory from will paramete files will be read (e.g., /earthworm/run_central/params). This will be different for each node. 
    205205 
    206206EW_LOG similarly determines where log files will be written.  
     
    214214To configure a module, first create the invocation paragraph for the module in [wiki:startstop_nt startstop_nt].d (see below). Then copy the sample .d and .desc files from that module's source directory. Change the names to match the name of the Module Id. Edit the files to suit the configuration. At a minimum this involves changing the name of the Module Id (this is where the executable learns its Module Id), Installation Id (in the .desc file) and possibly the ring names. Change any other parameters to suit the configuration. 
    215215 
    216 [wiki:startstop startstop] and [wiki:statmgr statmgr] are required to run in all nodes an an [wiki:Earthworm Earthworm] system. Since the [wiki:startstop startstop] and [wiki:statmgr statmgr] module's parameter and error processing files contain settings that control and effect the overall node it is advised to first configure these modules. [wiki:startstop startstop] is the module which starts first, and brings up the system by creating the specified rings and starting each module. [wiki:statmgr statmgr] is responsible for processing error messages created by other modules, monitoring their heartbeats, and issuing restart requests when a module's heartbeat ceases (see below). 
     216[wiki:startstop startstop] and [wiki:statmgr statmgr] are required to run in all nodes an an Earthworm system. Since the [wiki:startstop startstop] and [wiki:statmgr statmgr] module's parameter and error processing files contain settings that control and effect the overall node it is advised to first configure these modules. [wiki:startstop startstop] is the module which starts first, and brings up the system by creating the specified rings and starting each module. [wiki:statmgr statmgr] is responsible for processing error messages created by other modules, monitoring their heartbeats, and issuing restart requests when a module's heartbeat ceases (see below). 
    217217 
    218218=== 9.1 [wiki:startstop startstop] === 
    219219 
    220 This module is system-specific. Therefore, there are system-specific configuration files (startstop_nt.d and startstop_sol.d) It's configuration file contains the substance of the [wiki:earthworm Earthworm] configuration diagram (Sect.4). It first lists the rings required for this construction, and then lists a paragraph for each module to be started. This paragraph lists the name of the module's executable, the configuration file it is to read when starting, the priority it is to run at, and (in the Windows 2000 case) whether the module is to have its own window. 
     220This module is system-specific. Therefore, there are system-specific configuration files (startstop_nt.d and startstop_sol.d) It's configuration file contains the substance of the Earthworm configuration diagram (Sect.4). It first lists the rings required for this construction, and then lists a paragraph for each module to be started. This paragraph lists the name of the module's executable, the configuration file it is to read when starting, the priority it is to run at, and (in the Windows 2000 case) whether the module is to have its own window. 
    221221 
    222222=== 9.2 [wiki:statmgr statmgr] === 
     
    230230=== 9.3 OTHER MODULES === 
    231231 
    232 The [wiki:Earthworm Earthworm] release currently includes over 100 modules. However, several key modules are discussed below: 
     232The Earthworm release currently includes over 100 modules. However, several key modules are discussed below: 
    233233 
    234234* Import / Export 
    235235 
    236 These modules perform long-distance message exchange between [wiki:Earthworm Earthworm] systems. The Import (e.g., [wiki:import_generic import_generic]) module is supplied with the IP address and port of the Export it is to accept connections from. When it senses a connect request, it connects, and places all incoming messages on it's specified output message ring. The 'shipping label' of the message is that of the incoming message. It exchanges predetermined heartbeat texts with it's Import at specified rates. If the incoming heartbeat text does not match the specification in its configuration file, it closes the connection. If the heartbeat from its Import does not arrive on time, it re-initialized the connection. 
     236These modules perform long-distance message exchange between Earthworm systems. The Import (e.g., [wiki:import_generic import_generic]) module is supplied with the IP address and port of the Export it is to accept connections from. When it senses a connect request, it connects, and places all incoming messages on it's specified output message ring. The 'shipping label' of the message is that of the incoming message. It exchanges predetermined heartbeat texts with it's Import at specified rates. If the incoming heartbeat text does not match the specification in its configuration file, it closes the connection. If the heartbeat from its Import does not arrive on time, it re-initialized the connection. 
    237237 
    238238The Export (e.g., [wiki:export_generic export_generic])module is given the address of the network port through which they are to communicate - the assumption is that the host machine may have several ports - and the port number to use. Its is given the heartbeat text which it is to send to its Imports, the rate to send them, as well as the text and expected rate of the incoming heartbeats. If the incoming heartbeat does not arrive on time, the connection is closed and re-initialized. It has buffering capability to prevent loss of messages during this process. The Export module comes in two varieties: 
     
    274274In the startstop configuration file ([wiki:startstop_nt startstop_nt].d), each module which is to be run has a "NewConsole" / "NoNewConsole" specification. This determines whether the module's standard output is written to its own command window or into the window used to start the system. For initial testing, it is recommended to set all these to "NoNewConsole". In routine operation, individual windows are convenient for checking on system status. During initial debugging, however, modules tend to exit due to gross configuration errors (typical are invalid "Module Id" and "Ring Name" values). Under Windows 2000 this causes the window of the deceased module to vanish, carrying with it the module's error messages. The "NoNewConsole" setting permits the user to analyze terminal error messages. 
    275275 
    276 As mentioned above, [wiki:Earthworm Earthworm] includes a logging scheme in which each module can produce a log file in the /run/log directory. When a module has identity information to create a log file, it will do so, creating a new log file at midnight. These log files are the primary method for analyzing system malfunctions after initial setup. Note that under Windows 2000,a log file which is in use cannot be edited. One solution is to copy the current log file to a scratch file, and then look at that scratch file with an editor. 
     276As mentioned above, Earthworm includes a logging scheme in which each module can produce a log file in the /run/log directory. When a module has identity information to create a log file, it will do so, creating a new log file at midnight. These log files are the primary method for analyzing system malfunctions after initial setup. Note that under Windows 2000,a log file which is in use cannot be edited. One solution is to copy the current log file to a scratch file, and then look at that scratch file with an editor. 
    277277 
    278278Another possible problem during initial configuration is that a configuration file error may cause [wiki:startstop startstop] to exit. Since [wiki:startstop startstop] is responsible for terminating any modules which may be running, this can leave modules running, which will cause chaos when the system is re-started again. To clean up such 'wild' modules, either terminate them via the Win2000 Task Manager, or simply reboot the machine. 
     
    282282Often, there are many messages in a ring, and one wishes to know if trace data from a specified channel is flowing through that ring. The program [wiki:sniffwave sniffwave] is similar to [wiki:sniffring sniffring] above, but in addition takes as command line arguments the "Station", "Component", "Network" and "Location" name of the channel to be displayed. 
    283283 
    284 After starting an [wiki:Earthworm Earthworm] system with [wiki:startstop startstop], a short list of the modules in operation, and their status is displayed. This list can be re-displayed by pressing return in the window in which "startstop" was invoked. The same display can be produced by entering the command [wiki:status status] in a window in which "ew_nt.cmd" has been executed.  
     284After starting an Earthworm system with [wiki:startstop startstop], a short list of the modules in operation, and their status is displayed. This list can be re-displayed by pressing return in the window in which "startstop" was invoked. The same display can be produced by entering the command [wiki:status status] in a window in which "ew_nt.cmd" has been executed.  
    285285   
    286286