Changes between Version 1 and Version 2 of rcv_ew


Ignore:
Timestamp:
03/18/12 16:57:24 (9 years ago)
Author:
branden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • rcv_ew

    v1 v2  
    2121The Earthworm processing function (user_proc) is configured to accept only packets from a user-supplied list of channels (specified by a station, channel and network code, or SCN). Packets from any unlisted SCNs are ignored, with an "Ignoring data from SCN" error being issued. Within user_proc, packets for each listed channel are buffered (up to a user-specified limit) to allow for the re-sequencing of packets on rollbacks. Once the buffer for a channel is full, user_proc will "release" (output) the oldest packet on receipt of a new, in-sequence packet. If user_proc is handed an out-of-sequence packet with an earlier-than-expected timestamp (a rollback packet), it looks through that channel's buffer for a packet with an identical sequence number. If such a packet is found, user_proc overwrites it with the newly received packet. Otherwise, user_proc issues a "Rollback cannot be used" error, and discards the new packet. If user_proc is handed an out-of-sequence packet with a later-than-expected timestamp, it issues a "Gap prior to seq=x" error, and buffers the new packet for later release. When user_proc is handed a packet that is marked "end-of-trace-segment" (triggered data), it releases all packets in the buffer for that channel (who knows how long it will be until the next trigger occurs?). To "release" a packet, user_proc first discards any data in the packet which duplicates previously released data, then it produces a chronological stream of standard Earthworm waveform messages (TYPE_TRACEBUF). Most of the waveform messages will contain the number of data samples specified by the user; but some shorter messages will also be produced. These TYPE_TRACEBUF messages are output to the user-configured Earthworm transport ring where any waveform-processing modules can access them. 
    2222 
    23 The Earthworm code also includes a thread which monitors the time since the last data packet was received for each channel. If this time exceeds a user-specified limit ("MaxSilence" minutes) for any channel, rcv_ew will issue an error message. It will continue to issue an error every "MaxSilence" minutes that no data comes in for that channel. Rcv_ew will issue an "un-error" message when it starts receiving data for that channel again. This thread also monitors the Earthworm termination flag in the transport ring so that rcv_ew will exit in a timely manner when the Earthworm system is stopped. 
     23The Earthworm code also includes a thread which monitors the time since the last data packet was received for each channel. If this time exceeds a user-specified limit ("!MaxSilence" minutes) for any channel, rcv_ew will issue an error message. It will continue to issue an error every "!MaxSilence" minutes that no data comes in for that channel. Rcv_ew will issue an "un-error" message when it starts receiving data for that channel again. This thread also monitors the Earthworm termination flag in the transport ring so that rcv_ew will exit in a timely manner when the Earthworm system is stopped. 
    2424 
    2525=== SEED channel names === 
     
    3333 
    3434=== Earthworm Heartbeats === 
    35 Rcv_ew beats its Earthworm heart from within STATION. STATION calls the function user_heart_beat() first from within the configuration function (user_proc_cmd), and then on receipt of any data or keepalive from RCV. user_heart_beat() will issue a TYPE_HEARTBEAT message only if the time since the last beat is greater than "HeartBeatInt" seconds (set in config file). The actual heartbeat interval will be irregular since it is driven by data coming from Golden. But since "keepalives" should come every minute, so should heartbeats. If the communication link to Golden goes down, rcv_ew will stop beating its heart. The rcv_ew heartbeat contains a process_id so that the rcv_ew module can be restarted by statmgr/startstop. The process_id in the heartbeat is actually that of RCV, STATION's parent (RCV is the only process that startstop knows about). 
     35Rcv_ew beats its Earthworm heart from within STATION. STATION calls the function user_heart_beat() first from within the configuration function (user_proc_cmd), and then on receipt of any data or keepalive from RCV. user_heart_beat() will issue a TYPE_HEARTBEAT message only if the time since the last beat is greater than "!HeartBeatInt" seconds (set in config file). The actual heartbeat interval will be irregular since it is driven by data coming from Golden. But since "keepalives" should come every minute, so should heartbeats. If the communication link to Golden goes down, rcv_ew will stop beating its heart. The rcv_ew heartbeat contains a process_id so that the rcv_ew module can be restarted by statmgr/startstop. The process_id in the heartbeat is actually that of RCV, STATION's parent (RCV is the only process that startstop knows about). 
    3636 
    3737Tip: 
    38 Set "HeartBeatInt" to something under 60 seconds to guarantee a heartbeat for each keepalive. 
     38Set "!HeartBeatInt" to something under 60 seconds to guarantee a heartbeat for each keepalive. 
    3939 
    40 ===User Functions=== 
     40=== User Functions === 
    4141The user functions which contain all the Earthworm-specific code live in the source file user_proc_ew.c. The functions are: 
    4242