Linux in the Rugged Field
Traditionally, seismologists have used laboratory-based Sun computers to analyze data recorded in the field. But the advent of inexpensive Intel-based laptops and Linux has allowed us to take workstations out of the lab and into the field. This has involved the routine porting of code across OS platforms as well as kernel level development. After a year of hard work, scientists affiliated with the PASSCAL Instrument Center have been using Linux as a portable workstation for seismic studies from Missouri to Massachusetts and from Micronesia to Tanzania.
Contrary to the implications of our name, we are not a group dedicated to or affiliated with the Pascal programming language. PASSCAL, or the Program for Array Seismic Studies of the Continental Lithosphere, is a member program of IRIS (the Incorporated Research Institutions for Seismology), which is a consortium of 90 U.S. universities (there are a number of affiliate members, both foreign and domestic). We have been located at Columbia University's Lamont-Doherty Earth Observatory since 1989, while a second instrument center was established at Stanford University in 1992.
In seismology, it is common for a scientist to run an experiment requiring the use of many expensive instruments for a relatively short period of time. Having individual scientists spend hundreds of thousands of dollars on equipment, only to have it collect dust on a shelf for 80% of its life, makes little sense in this era of fiscal belt-tightening. In addition, few scientists have the time to master and integrate equipment from a variety of manufacturers into a reliable data acquisition system.
Therefore, the PASSCAL Instrument Center was organized to service the seismic community—providing a powerful and flexible portable instrument along with expertise that can only be obtained via experience. We supply logistic and technical support, provide for system integration and maintenance, and deliver comprehensive feedback to the manufacturers. Since experiments are returning from the field with Terra-Bytes of data, an extensive suite of programs have been developed to assist the seismologists with the acquisition and archiving of data and for assuring data quality. The popularity of this program has grown to the point that experiment scheduling for 1997 is currently underway.
Historically PASSCAL experiments have utilized two separate computer systems, one for data acquisition and one for data analysis. The data acquisition system (DAS) is comprised of a series of weather-tight grey boxes (CPU, SCSI disks, batteries), peripherals (solar panels, GPS receiver), and a hand terminal with an LCD touch-screen to program the DAS and retrieve data. A standard Sparcstation running SunOS, which may or may not be located anywhere near the seismic station, is used for data analysis and quality assurance.
The portable aspect of the PASSCAL instrument explains the program's popularity, at the same time it also introduces logistic difficulties. Investigators frequently erect stations in remote locations, making access difficult and/or expensive. Hence station visits are infrequent, with users allowing the DAS to run for months before they return for data retrieval. Retrieval is accomplished by copying to tape (or spare disk), which is then brought back to the lab for quality control, data analysis and archiving. Detecting problems with the instrument at this stage requires a return trip. (At one of our stations in Micronesia, there is only one flight a week to the island. You fly in, work for 4 hours, wait a week, fly back, check your data, and, if there were any problems, fly back a week later.)
In November of 1993, I installed Linux at home simply to have a operating environment similar to the one I used at work. I got X up and running and discovered the XView libraries sitting there serendipitously on my hard disk. One major piece of code for which I was responsible uses X (via XView) for displaying seismic traces, and approximately 17 milliseconds later I decided to port this program to Linux, just so I could work at home.
One day I dragged my PC into work to show everyone what Linux could do. A member of our team remarked that if we could run this on a portable computer, we could actually look at the raw data and perform spectral analyses of the data in the field, while there is still time to correct mistakes. That led to the thought that if we had a computer with X-windows in the field, we could even write some user-friendly and powerful software to program the DAS, instead of using the hand-terminal.
At the time we were actually experiencing a dilemma concerning the programming of the DAS's. Epson manufactures the hand terminal, which runs a simple basic program and interfaces to the DAS via a serial port. This hand terminal is fairly user-friendly: Just point with your finger and push. The problem is that only rudimentary diagnoses can be made with the hand terminal. There is a DOS-based alternative to this program that is more powerful (i.e. has many options), but “user friendly” is not a phrase we use to describe it.
Since many of our users only perform field work every few years, and many are novice grad students, user friendliness is of utmost importance to guarantee data integrity. The idea of combining the power of the DOS program with the ease of use of the hand terminal into a beautiful X-windows program was compelling.
With a dream and a need, we did what many of you have done: We went looking for money. Selling the laptop idea was actually quite easy; selling Linux was another matter. Since all of our existing code was written to run under SunOS and X Windows we did not even entertain the idea of porting our code to MS-Windows or OS2.
However I was not actually sold on Linux, myself. My first PC-Unix experience was with Interactive Unix, back when it was owned by Kodak. I really had no objection to going with them again (or SCO, or whomever). We investigated the alternatives, and as many of you have also discovered: chances are good that Linux provides better support than the other PC-Unixes for any given piece of hardware. After demonstrating that to ourselves and our boss, we went with Linux.
We purchased our first two laptops in early 1994, primarily to study the feasibility of running Linux laptops in the field. When my co-workers Paul Friberg and John Webber and I began porting major pieces of our code, we hit our first bottleneck in very short time: SCSI. All of our data is acquired and stored on SCSI devices, and much of our code required data just to be tested. Our quick-fix was to purchase a docking station and install a SCSI adapter here. Obviously this was neither a permanent nor portable solution, but it was enough to get us started.
We looked into PCMCIA SCSI, but no support existed at that time. We reasoned that with the infancy of the technology, support could not be expected immediately, but would be coming along shortly. Foolishly, we decided to wait for it while proceeding with the development of all the other code we would need.
Because we are also heavily entrenched in Tcl/Tk, we decided to write a Tcl/Tk-based replacement for the hand terminal. We managed to combine the hand terminal's point-and-click ease of use with the functionality of the DOS program. The BLT extensions to Tcl/Tk made this program downright fancy.
We also wrote a program to display seismic data in real time, allowing users to examine the background signal of the seismometer before walking away and leaving it for a few months. (The alternative has always been to acquire data to disk, run some data conversion programs, load up the data into the viewer, make changes to the instrument and repeat the procedure. This, of course, assumes that you have a workstation near the seismometer.) The new option of acquiring and displaying in real-time while making adjustments can easily save time and effort.
At this point we had assembled a sizeable suite of programs, and all that remained was getting the data. Again we asked around the net, but no-one knew of a Linux supported PCMCIA SCSI card. Gennady Pratusevich, our engineer, decided to write a driver for Linux, and we decided to go with the Trantor/Adaptec card. Since most of the other Adaptec cards were well-supported, we figured that Adaptec would provide us with the programming information. We were quite wrong.
We started searching around for SCSI cards from companies that would supply us with programming information. We found a small producer of such cards in Colorado, initially he seemed interested in Linux, but he never got back to us again. We considered developing our own card when some Linux newsgroup wisdom indicated that the New Media Bus Toaster used the AIC6360 chipset. This is the same chipset used by the Adaptec 1522 board. We purchased a Bus Toaster and, armed with the source code for the Adaptec 1522 driver, David Hind's PCMCIA code, and a few assorted manuals, Pratusevich managed to create a fully functional SCSI driver. With the subsequent introduction of loadable SCSI modules, the real power of PCMCIA was realized, allowing us to swap disks on the fly. We were finally ready for prime time.
I would like to point out here that if we had chosen an operating system that did not release the source code, this would have been the tragic end of our story.
Last December we attended the fall meeting of the American Geophysical Union in San Francisco, having just taken delivery of 5 additional laptops. Usually we have our Sun Sparcstations on prominent display, but this year they were hidden behind our Linux laptops (as if a full-sized workstation could hide behind a 7-pound laptop). Linux was a hit, and everyone wanted one.
The second week of January saw us shipping four laptops into the field. Preliminary reports are encouraging. The laptops work and are making life easier for our users. The people using these machines are not Linux experts, but the machines are easy enough to use that people would rather utilize these than any currently available DOS alternative.
We did not originally expect Linux to be the way to go for us. Obviously porting to a Sparc laptop would have required much less work, but they are prohibitively expensive. We also looked into Solaris for PC's, but the minimal volume of hardware that Solaris supports turned us away. If any of you are trying to convince your supervisors to go with Linux, first sell the idea of Unix, and then have them compare Linux to Solaris and the like. The best decision becomes obvious at this point.
The work described in this article was supported by the Incorporated Research Institutions for Seismology and by the National Science Foundation under Cooperative Agreement No. EAR-9023505. Any opinions and conclusions or recommendations expressed in this material are those of the author and do not necessarily reflect the views of the National Science Foundation.
Shortly after Sid Hellman earned his masters in physics, a knee injury diverted him into programming. A Systems Analyst at Columbia University's Lamont-Doherty Earth Observatory since 1990 (seismology since 1993), his duties have ranged from programming to electronics to field work. The PASSCAL Instrument Center can be reached at firstname.lastname@example.org or via the WWW at www.ldeo.columbia.edu/Passcal/passcal.intro.html
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Control Your Linux Desktop with D-Bus
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide