EARTHWORM
Status Report
Alex Bittenbinder (alex@gldage.cr.usgs.gov) May. 4,
1998
This is an update of Earthworm status since the notes of 2/12/98 and those of Feb 12, 1998.
Like the stock market, the Earthworm community continues to grow at an
amazing rate. At last count over seventeen individuals either had, or
were, developing software for their Earthworm installations. The
web-based documentation, thanks to the unrelenting drive provided by
Steve Malone of the CNSS, has proven to be a powerful method for people
to gain familiarity with the system. New installations have been
brought up with minimal involvement of the core development team, and
there are rumors of Earthworm running at sites with which we've had no
contact. Further, several vendors of data loggers are moving to provide
compatible acquisiton modules.
The next challenge may well be one of 'growth managment': On one hand,
Earthworm is publicly available, with no strings attached. On the other
hand, one of the basic objectives of the Earthworm effort is to provide
cost savings by preventing duplication of effort. This implies
substantial coordination and cooperation amonst the participating
sites; and given the traditional nature of regional networks, this is a
task wich tends to offer much fascination and color.
A straightforward solution would be to simply scale up: Create
a larger Earthworm Central which would be capable of handling
the increasing number (and complexity) of tasks. But this has
the problem of potentially changing the nature of the effort,
as a larger central organization might well weaken the role of
the grass-roots membership. Such a trend would be disasterous,
as it would undermine the basic strength of the effort.
Another solution may be to distribute the work load among
several community organizations. The creation of the Earthworm
Advisory Board (EWAB) was a step in this direction, and a
lesson has been learned from this experiment: Regional network
personnel really are very busy. Not surprising, since Earthworm
came into existence precisely because regional networks
suffered major cuts in funding and personnel. As a result, the
surviving personnel face daunting work-loads, both in terms of
volume and 'dynamic range' of tasks. In this environment it is
not reasonable to expect ongoing, working involvement with an
new effort which is not directly supported. EWAB involvement,
however, implied exactly that.
A variation of this idea may be short term special interest
groups. These could be convened as needed to resolve specific
issues and dissolve promptly after the task was completed. The
participants would be volunteers who have an active interest in
the specific issue. Several such groups have functioned well so
far: the specifications for CarlTrig were successfully set by
an ad hoc group of seismologists, and numerous engineering
promblems have been resolved by 'techie' group discussions. The
scheme is attractive in that the participants have strong
interests in resolving the issue and know that they are free
once resolution has been reached (and not until then).
Ideas and comments are welcome.
CURRENT DIRECTIONS:
- 1. Earthworm organization: As mentioned above, a number of
organizational problems have to be resolved. It is anticipated that
this will proceed with close cooperation with CNSS leadership. Issues
include creation and operation of various forums, tracking mechansims,
communications channels, etc.
- 2. CNSS Earthworm web site: It is expected that item (1)
above will result in various enhancements to the web site.
- 3. Ruggedized NT Earthworm: Work is progessing on an
NT-based Earthworm which will be able to operate in remote locations.
Initial specs include sufficient remote access to permit routine
operations and modification to operating parameters, unattended
survival of power interruptions, and a remote reboot capability.
Completion is optimistically projected for late summer.
RECENT DEVELOPMENTS:
- CarlTrig: The originall
CarlTrig written at PNL Hanford, has been enhanced as per email
discussions. The new code is reportedly doing very well in tests at
UofW. The new version consists of two modules: one which performs the
station logic, and another which does the subnet association. The
modules communicate via short messages. The objective is to permit
remote earthworm nodes to run the station module and send station
triggers to a central site via a narrow bandwidth comm channel.
Documentation and release are eagerly awaited.
- Documentation: Documentation has been expanded to
include two examples of earthworm configurations, further explanation
of internals, and more module descriptions. An Earthworm logo seems to
have been selected, and is being browser-ized by the artist. It is
hoped that the site now offers enough material to permit a new user to
understand basic operation, and to perform most (but not all) of the
initial configuration chores.
- REFTEK Earthworm
Interface: RefTek is working to integrate their latest data logger
system to Earthworm. The product will be a well-behaved Earthworm
module which would acquire telemetered data, manage the two-way
protocol to the data logger, and output Earthworm compatible trace data
messages. It will also permit control of the outstation. RefTek
presonnel are working on the effort, with support from the Earthworm
developer community. UofW has been designated as the test site.
- Guralp Earthworm Interface: A similar effort is underway
with Guralp. The effort is being undertaken by UofA Fairbanks, with
support from Guralp and the Earthworm developer group as requested.
- Compression/Decompression Module: A trace data
compressor and decompressor module pair has been written and is going
into testing, initially between Menlo Park and Fairbanks. The algorithm
originates with Boulder Real Time Technology (BRTT), as provided by
UofA Fairbanks. The understanding is that the algorithm is available
without restrictions.
- Improved rcv_ew Module: Currently
running in prologned tests. Recent improvements include a meaningful
heartbeat and the option to issue an error message if no data is
received from a station for a user-specified period. Previously, there
were failure modes in which the heartbeats would continue, and the loss
of one station's data was not a detected error.
- Wave_serverV
Module:WaveServerV has finally been released in v3.1. It sports
various improvements over ealier incarnations: crash recovery features,
incorporation of the new system-independent socket wrapper routines,
and numberous bug fixes and enhancements. It functions well within a
known performance envelope, but malfunctions (gracefully) when the
hardware is overdriven. WaveServerV can be a resource hog by its
nature: continuous trace saving to disk, crash recovery, and service of
multiple concurrent clients for hundreds of channels can easily
saturate a machine's network, bus, CPU, and SCSI bus, and head motion
resources. Stress testing is currently underway, and results will be
posted on the CNSS earthworm web site.
Return to EARTHWORM main page, or
CNSS main page.