 |
|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass00/P1-49/
Дата изменения: Mon Jun 4 20:05:33 2001 Дата индексирования: Tue Oct 2 04:49:59 2012 Кодировка: Поисковые слова: arp 220 |
We chose CORBA because it is available on many platforms with bindings for many programming languages, enabling remote object support in a heterogeneous computing environment. We chose Java for its cross-platform support and its rich set of lightweight graphical objects, in particular the JTable.
Because of its observatory-independent data model built on top of CORBA, CDV can in principle be used with any interferometer (e.g., SMA, ALMA, VLT).
CARMA (the Combined Array for Research in Millimeter-wave Astronomy) is a university consortium of Caltech, U. C. Berkeley, the University of Illinois, the University of Maryland, and the University of Chicago. CARMA will combine the existing Owens Valley Millimeter Array, the BIMA Millimeter Array, and new antennas from the University of Chicago at a high altitude site in California. The combined array will consist of six 10.4m, nine 6.1m, and six 3.5m antennas. CARMA's 21 antennas will have unique multi-scale imaging capabilities.
|
CDV is a workspace application, with individual data viewers running as windows inside the workspace. Multiple Data Sources (i.e., observatories) may be monitored simultaneously, and a variety of representations of the data are possible.
 |
Future enhancements will include server and client side caches for low-bandwidth operation and the ability to sort and filter the data (e.g., by time, frequency, baseline separation) using the Java 2 Comparator classes.
CORBA allows convenient access to remote objects. For the CARMA Data Viewer, the remote objects (ObsRecords) contain a rich hierarchy of header and data that are updated on timescales of a few to tens of seconds. The data alone for a 45 baseline BIMA continuum-only ObsRecord is about 13.5 KB. For 4 spectral windows with 512 channels, the size increases to 200 KB. With 15 baselines, the OVRO data scales to one third the size of the BIMA data. Directly accessing the remote ObsRecord with standard accessor calls to update the Data Viewer would require hundreds of remote method invocations.
The latency, overhead, and data transport time can all make significant contributions to performance and must be examined. Latency for calls over the general Internet is typically 100 to 200 msec. There is negligible latency over a 100 Mbps LAN. The overhead in a CORBA call that transfers no information is very small--approximately 1msec. For transferring data (large CORBA objects) over the Internet, measured transfer speeds were at least 60% of the nominal T1 connecting observatory sites to the Internet. Note that for the largest objects (200 KB), the transfer time is in excess of one second. From measured performance components, the Internet latency (100 to 200 msec) can severely limit CDV if many remote method calls are required per update.
The solution adopted was to create a structure that contained all the data items for an ObsRecord. The remote method then returned this structure, effectively moving all of the data for the object in one transaction. The structure can then be used to form a local cloned copy of the remote object. The measured overhead is about 6 msec per transaction for the OVRO continuum data packet (3.5 KB) and should scale with packet size.
Using this technique of moving a large structure, it is possible to update a large ObsRecord every few seconds with reasonable latency and CPU loads of a few percent or less on modern CPUS.