advanced software and control for astronomy astronomical telescopes and instrumentation / spie 2006...

Advanced Software and Control for AstronomyAstronomical Telescopes and Instrumentation / SPIE 2006 5/26/2006

Optimizing interactive performance for long-distance remote observing

Robert Kibrick and Steven L. Allen

University of California Observatories / Lick Observatory

Al Conrad and Gregory D. Wirth

W.M. Keck Observatory

Advanced Software and Control for Astronomy

Orlando, Florida May 26, 2006

Remote observing with the Keck Telescopes – The first 10 years

Robert Kibrick and Steven L. Allen

University of California Observatories / Lick Observatory

Al Conrad and Gregory D. Wirth

W.M. Keck Observatory

Advanced Software and Control for Astronomy

Orlando, Florida May 26, 2006

Overview of Presentation

• Background– Historical evolution of Keck remote observing– The Keck Remote Observing Model– Remote observing from Waimea and California

• Redirecting displays– Using X protocol– Using VNC protocol

• Advantages and disadvantages of using VNC• Current usage patterns• Scheduling issues• Future plans

The Keck Telescopes

From 1993 to 1995, all Keck observing was done at the summit

Observers at the summit work remotely from control rooms located adjacent to the telescope domes

Conducting observations involves coordinated effort by 3 groups

• Telescope operator (observing assistant)–Responsible for telescope safety & operation–Keck employee; normally works at summit

• Instrument scientist (support astronomer)–Expert in operation of specific instruments–Keck employee; works at summit or Waimea

• Observers–Select objects and conduct observations–Employed by Caltech, UC, NASA, UH, or other

Keck 2 Control Room at the Mauna Kea Summit

Telescope operator, instrument scientist, and observers work side by side, each at their own remote X Display

Observing at the Mauna Kea summit is both difficult and risky

•Oxygen is only 60% of that at sea level

•Lack of oxygen reduces alertness

•Observing efficiency significantly impaired

•Altitude sickness afflicts some observers

•Some are not even permitted on summit:

–Pregnant women

–Those with heart or lung problems

Keck 2 Remote Control Room at the Keck Headquarters in Waimea

Observer and instrument scientist in Waimea use video conferencing system to interact with telescope operator at the summit

The initial model for Keck Remote Observing

All observing applications run on summit control computers

All displays are re-directed to display hosts at each site

Why did Keck initially choose this approach?

•Operational Simplicity

•Operational control software runs only at the summit

•All users run identical software on same computer

•Simplifies management at each site

•Allowed us to focus on commonality

•Different sites / teams developed instrument software

•Large variety of languages and protocols were used

•BUT: all instruments used X-based GUIs

•Legacy GUI applications (e.g., not web-based)

Initiative to support remote observing from Keck Headquarters

• 1995: Remote control rooms built at Keck HQ

• 1996: Remote observing with Keck 1 begins

• 1997: >50% of Keck 1 observing done remotely

• 1999: remote observing >90% for Keck 1 and 2

• 2000: remote observing became the default mode

Remote Observing from Waimea is not cost effective for short runs

•Round trip travel time is 2 days

•Travel costs > $1,000 U.S. per observer

•About 50% of runs are for 1 night or less

•Cost / run is very high for such short runs

•Such costs limit student participation

Explore the feasibility of remote observing from the mainland

•Initial experiments 1996-2000–Caltech experiments with NASA satellite–UCSC experiments with Internet-2 link

•2000-2001 ISDN fallback tests at UCSC

•2001 ISDN router installed at Keck summit

•2001 Prototype facility at UCSC online

•UCSC facility used as model for other sites

Location First Use

Remote Ops 1, Waimea, HI 1996

Remote Ops 2, Waimea, HI 1997

UC Santa Cruz, CA 2001

UC San Diego, CA 2003

Caltech, Pasadena, CA 2004

UC Berkeley/LBNL, CA 2005

UC Los Angeles, CA 2006

Keck Observatory remote observing sites

Global view of multi-site topology

Type your question here, and then click Search.

Santa Cruz Remote Observing Facility

Remote observer in California uses video conferencing system to interact with colleague in Waimea

UC Los Angeles (UCLA) remote observing facility

The newest Keck remote observing facility in CA

UC Los Angeles (UCLA) remote observing facility

Initial efforts to extend remote observing model to the mainland

Type your question here, and then click Search.

Limitations of using X to redirect displays to the mainland

• Sluggish performance for some operations

– very slow application startup compared to Waimea

– slow creation of new windows and pulldown menus

– guider display update rate is too low• Inability to share “single-user” applications

– figdisp realtime image display (LRIS, HIRES, ESI)

– various data reduction packages• Some applications sensitive to inter-site font variations

Virtual Network Computing (VNC)

• VNC server provides shareable virtual desktop

• VNC clients (viewer) offer remote access to that desktop• All clients share that desktop (application sharing)• All state is retained in the server, none in the clients• Clients can connect/disconnect without affecting session• VNC protocol works at the framebuffer level• VNC available on most OS / windowing systems

Redirecting displays to remote sites using VNC protocol & ssh

An ssh port-forwarding tunnel is used to relay VNC protocol packets and authentication across network firewalls to the remote site.

Benefits of using VNC

• Single-user applications can be shared between sites– Shared desktop promotes training and collaboration– All sites have identical view and see each others actions– Shared desktop persists even if remote VNC client crashes– Optional read-only sharing for “look but don’t touch”

• X clients connect to a local X server (short RTTs)– X client applications run on control computer at summit– VNC server runs on computer at the summit– X clients see the VNC server as their local X server

• Speeds up client functions that require multiple X transactions– Application startup and initial painting of displays– Creation of pop-up windows and sub-panels– Instantiation of pull-down menus– Loading of fonts

Disadvantages of using VNC

• Some operations are slower across a low bandwidth link– iconify / de-iconify operations are very slow (no backing store)– color map scrolling is slower than under a native X connection

• Ssh has no built-in capability for forwarding VNC packets– must start port-forwarding tunnel (ssh –L) before VNC viewer

• Shared desktop is sometimes a source of user confusion– Keyboard / mouse input from all connected clients are merged– Users at different sites could type or move mouse at same time– Potential for multiple users to create conflicting inputs–These conflicts can be reduced via use of '-viewonly' mode

• ADVANTAGES OF VNC OUTWEIGH THE DISADVANTAGES

•X Visuals:–Depth: 8-, 16-, and 24-bit–PseudoColor, StaticColor, and TrueColor–Many X servers support multiple X visuals–VNC server supports only 1 visual at a time–VNC server must satisfy least capable client–Legacy X clients need 8-bit PseudoColor

Issues and Interactions between VNC and X

•We run a mix of 8-bit and 24-bit VNC desktops•Distinguish by using distinct desktop BG color•Use 8-bit VNC desktops wherever possible

–More efficient image updates / colormap–Lots of legacy GUIs require 8-bit visuals

•Use 24-bit VNC desktops when required–Some GUIs require 24-bit visuals–Mix of GUIs exhausts 8-bit color map

Working within VNC's constraints:8- or 24-bit desktops?

•Sites typically have a 3-screen and 1-screen W/S–3-screen W/S typically runs instrument s/w–1-screen W/S typically runs telescope s/w

•Run virtual window manager on local desktop–Have >= 4 window panes on each local screen–Run 8-bit VNC viewer in one window pane–Run 24-bit VNC viewer in another pane–Other panes allow access to local desktop

Example configurations

•Xinerama–Allows multiple screens to be treated as one–Windows can span screens or move between–Does not work well in conjunction with VNC

•Graphon's GO-Global product (proprietary)–Provides very efficient remote access–All state saved on server side (like VNC)–Does not provide desktop sharing

Other options explored

•x11vnc–Allows access to a non-virtual X11 desktop–Remote access w/out running within VNC–Relies on physical polling of frame buffer–Useful for remote troubleshooting–Current version is prototype / pre-release–Not yet sufficiently robust for remote observing

Other options explored

• Remote eavesdropping: (approximately 90%)–At least one member of observing team in Waimea–Other members of the team work from the mainland–Observers in Waimea have primary responsibility for operations–Observers on the mainland can 'eavesdrop' via VNC–Observers on the mainland can also operate instrument

• Mainland-only: (approximately 10%)–All members of observing team observe from mainland site(s)–Observers on the mainland have sole responsibility for operations

Two Modes of Remote Observing from the Mainland

• Overall usage has increased with growing number of sites• First three months of 2006: average 8 nights per month• May 2006: 12 nights of remote observing from mainland• Significant number of nights involve multiple mainland sites:

– Multi-site teams– Split nights: (e.g., UCSC first half on night, UCLA second half)– Both telescopes:

• UCB/LBNL remote observer using LRIS on Keck I Telescope• UCLA remote observer using OSIRIS/LGS-AO on Keck 2 Telescope

Current Usage Statistics for Keck mainland remote observing

• Waimea has two remote ops rooms, one for each telescope• Each mainland site has only a single remote ops room• Potential conflict if both observing teams from same site:

–20 out of 181 nights (or 11%) in 2006A semester–Of those: 55% Caltech, 30% UCB, 10% UCLA, 5% UCSC–To date, no such conflicts have arisen

• Only enough ISDN lines at summit to backup one site–Not a problem for split nights–A potential problem for mainland-only from two sites on same night

Scheduling Issues and current constraints

• Upgrade ISDN capacity at summit to support multiple sites (install more lines & upgrade router, Summer 2006)

• Installation of dedicated VNC server hosts at Keck summit• Continue to optimize VNC configurations and performance• Implement RO facilities at other Keck partner institutions• Develop scheme for dynamic allocation of VNC server #s• Develop improved procedures for coordination between sites

Future plans

•Mainland remote observing (MRO) is operational– For all Keck optical instruments and most IR insts.

– From 5 mainland sites: (UCSC ,UCSD , Caltech, UCB/LBNL,UCLA)

– Shared VNC desktops used for most remote ops.

– Provides competitive performance for most GUIs

– Provides acceptable performance for image displays

•MRO efficiency would be enhanced by:– A distributed image display server / client (VO?)

– VNC server w/ simultaneous 8- & 24-bit support

Conclusion

•U.S. National Science Foundation

•University of Hawaii

•Gemini Telescope Consortium

•University Corp. for Advanced Internet Development (UCAID)

•Corporation for Education Network Initiatives in California (CENIC)

Acknowledgments

Robert Kibrick, UCO/Lick Observatory

University of California, Santa Cruz

California 95064, U.S.A.

E-mail: kibrick@ucolick.org

WWW: http://www.ucolick.org/~kibrick

Phone: +1-831-459-2262

FAX: +1-831-459-2298

Author Information

END OF PRESENTATION !!!

SPARE SLIDES FOLLOW

Limitations of Remote Observing from Keck HQ in Waimea

Most Keck observers live on the mainland.

Mainland observers fly > 3,200 km to get to Waimea

Collective direct travel costs exceed $400,000 U.S. / year

Keck Telescopes use Classical Scheduling

•Kecks not designed for queue scheduling

•Schedules cover a semester (6 months)

•Approved proposals get 1 or more runs

–Each run is between 0.5 to 5 nights long

–Gaps between runs vary from days to months

Factors contributing to sluggish performance at mainland sites

Lower inherent bandwidth• High round trip time (RTT) between Keck and California

– Yields lower effective bandwidth for un-tuned TCP

– Slows any functions requiring multiple round trips

– High RTT limits benefit of tuning or compression• Routing and propagation delays change over time

– Keck/California link: hops / RTT• 1998: 12 hops / 70 millisecond average RTT• 2004: 22 hops / 100 millisecond average RTT• 2006: 17 hops / 90 millisecond average RTT

•Colormap issues

– slower scrolling if pixel retransmit needed

– colormap flashing if insufficient colors

– private color maps (Not supported in v4)

•Whitepixel and blackpixel conflicts

•Fonts are supplied by the X server

– Using X model, X server is local to observer

– Using VNC model, X server is at summit

Issues and Interactions between VNC and X

An alternative topology for using VNC with ssh and X

The VNC server and VNC viewer are both run on the same computer at the summit. The X display generated by the VNC viewer is re-directed to the remote site via a standard ssh tunnel.

Benefits of this topology

• Retains most benefits of the first VNC topology:–Single-user applications can be shared between sites–Observing X clients connect to a local X server (short RTTs)–Speeds up functions that require multiple X transactions

• VNC not needed at remote sites; only at the summit

• Avoids ssh port-forward complexity

• Neither protocol is optimal for all applications & sites

• Some functions work better under X– image display functions (pan, zoom in / out, color map scroll)– iconifying / de-iconifying windows (if backing store enabled)– any functions more sensitive to bandwidth than to RTT

• Some functions work better under VNC– creation of new windows, pop-ups, and sub-panels– instantiation of pull-down menus– any applications that are RTT sensitive (Keck guider eavesdrop)

• Most output-only applications work OK using either

Using a mix of both protocols

Multiple monitors facilitates a mix of X and VNC protocols

For example, one monitor can display a shared VNC desktop while the others carry the redirected X displays of X clients running at the summit.

•Local ds9ds9 X client and server: 6.6 seconds

•Summit ds9 display redirected to mainland

– direct to mainland X server: 72.0 (76.0*)

– via mainland VNC viewer: 11.0 (27.5*)

– via VNC viewer at summit: 10.6 (26.2*)

–* values in ( ) are without ssh compression

•In-stream compression helps in all cases

Measurements of remote performance: ds9 startup

– via mainland VNC viewer: 3.0 ( 7.7*)

– via VNC viewer at summit: 3.0 ( 6.8*)

Measurements of remote performance: file chooser popup

Measurements of remote performance: ds9 zoom in

– direct to mainland X server: 0.1 ( 3.0*)

Measurements of remote performance: ds9 draw cut for plot

•Can redirect displays of legacy X clients:

– using X protocol

– using VNC protocol

– using a combination of both protocols

•Choice depends on functionality of each X client

•Good remote performance for most X GUI clients

•Need better remote performance for ds9

Summary

Future directions

•Explore distributed ds9-like image displays:

– “ds9server”: an image / image section server• Runs on the instrument control computer on summit

• Interfaces to multi-HDU FITS images on disk or in shmem

• Extracts subset of pixels requested by display client(s)

• Efficiently transmits pixels and WCS-info to display client(s)

– “ds9viewer”: an image / image section client• Runs at remote site and provides local GUI to observer

• Convert GUI events into requests to transmit to ds9server

• Receives pixel / WCS-info stream transmitted by ds9server

• Displays pixel stream locally as a bitmap image or plot

Future directions

•Explore distributed ds9-like image displays:

– design image server / viewer protocol to:• Minimize round trips between client(s) and server

• Support progressive/lossy transmission of image sections

• Enable support of a web-based client/viewer

• Enable support of a X-based client/viewer

– challenges: ds9 live plots, magnifier window

•Test protocol with NIST Network Emulation Tool

– Simulates network latency, bandwidth, jitter

– http://www.antd.nist.gov/tools/nistnet/index.html

Keck 2 Remote Observing Room as seen from the Keck 2 summit

Telescope operators at the summit converse with astronomer at Keck HQ in Waimea via the videoconferencing system.

Videoconferencing has proved vital for remote observing from Waimea

•Visual cues (body language) important!

•Improved audio quality extremely valuable

•A picture is often worth a thousand words

•Troubleshooting: live oscilloscope images

•“Cheap” desktop sharing (LCD screens)

•Chose dedicated versus PC-based units:

–Original (1996) system was PictureTel 2000

–Upgrading to Polycom Viewstations

Interaction between video-conferencing and type of monitors

•Compression techniques motion sensitive

•“Moving” scene requires more bandwidth

•CRT monitors cause “flicker” in VC image– Beating of frequencies: camera .vs. CRT

– CRT phosphor intensity peaking, persistence

•CRT monitor “flicker” causes problems:– Wastes bandwidth and degrades resolution

– Visually annoying / nausea inducing

•Use LCD monitors to avoid this problem

The Keck Headquarters in Waimea

Most Keck technical staff live and work in Waimea. Allows direct contact between observers and staff. Visiting Scientist’s Quarters (VSQ) located in same complex.

Motivations for Remote Observing from the U.S. Mainland

•Travel time and costs greatly reduced

•Travel restrictions accommodated–Sinus infections and ruptured ear drums

–Late stages of pregnancy

•Increased options for:–Student participation in observing runs

–Large observing teams with small budgets

•Capability for remote engineering support

Santa Cruz Remote Observing Video Conferencing

Remote observer’s colleague in Waimea as seen from Santa Cruz remote ops

The Weather in Waimea

Remote observer in California points remotely-controlled camera at the window in Waimea remote ops

The Remote Observing Facility at Keck Headquarters in Waimea

•Elevation of Waimea is 800 meters

•Adequate oxygen for alertness

•Waimea is 32 km NW of Mauna Kea

•45 Mbps fiber optic link connects 2 sites

•A remote control room for each telescope

•Videoconferencing for each telescope

•On-site dormitories for daytime sleeping

Mainland remote observing goals and implementation strategy

•Goals:–Target mainland facility to short duration runs

–Avoid duplicating expensive Waimea resources

–Avoid overloading Waimea support staff

•Strategy:–No mainland dormitories; observers sleep at home

–Access existing Waimea support staff remotely

–Restrict mainland facility to experienced observers

–Restrict to mature, fully-debugged instruments

Mainland remote observing facility is an extension of Keck HQ facility

•Only modest hardware investment needed:–Workstations for mainland remote observers

–Network-based videoconferencing system

–Routers and firewalls

–Backup power (UPS) – especially in California!!!

–Backup network path to Mauna Kea and Waimea

•Avoids expensive duplication of resources

•Share existing resources wherever possible–Internet-2 link to the mainland

–Keck support staff and operational software

The initial model for Keck Remote Observing

•The control computers at the summit:–Each telescope and instrument has its own computer

–All operational software runs only on these computers

–All observing data written to directly-attached disks

–Users access data disks remotely via NFS or ssh/scp

•The display workstations–Telescopes and instruments controlled via X GUIs

–All users access these X GUIs via remote X displays

–X Client software runs on summit control computers

–Displays to X server on remote display workstation

Operational simplifications

• Only one copy of operational software to maintain• Only “vanilla” hardware / software needed at remote site• Simplifies sparing and swapping of equipment• Simplifies system maintenance at remote site• Simplifies authentication / access control

Focus effort on X standardization and optimization over long links

•Maintain consistent X environment between sites

•Optimize X performance between sites

•Eliminates need to maintain:

•Diverse instrument software at multiple sites

•Diverse telescope software at multiple sites

•Coordinate users accounts at multiple sites

•Fewer protocols for firewalls to manage

Remote observing differences: Waimea versus the mainland

•System Management:

–Keck summit and HQ share a common domain

–Mainland sites are autonomous

•Remote File Access:

–Observers at Keck HQ access summit data via NFS

–Observers on mainland access data via ssh/scp

•Propagation Delays:

–Summit to Waimea round trip time is about 1 ms.

–Summit to mainland round trip time is about 100 ms.

Shared access and control of instruments

•Most software for Keck optical instruments provides native multi-user/multi-site control

•All users have consistent view of status and data

•Instrument control can be shared between sites

•Multipoint video conferencing key to coordination

•Some single-user applications can be shared via X-based application sharing environments:

– XMX http://www.cs.brown.edu/software/xmx– VNC http://www.uk.research.att.com/vnc

Increased propagation delay to mainland presents challenges

•Initial painting of windows is much slower

•But once created, window updates fast enough

•All Keck applications display to Waimea OK

•A few applications display too slowly to mainland

•System and application tuning very important

–TCP window-size parameter (Web100 Initiative)

–X server memory and backing store

–Minimize operations requiring round trip transactions

Shared access and control of instruments

•Most software for Keck optical instruments provides native multi-user/multi-site control

•All users have consistent view of status and data

•Instrument control can be shared between sites

•Multipoint video conferencing key to coordination

•Some single-user applications can be shared via X-based application sharing environments:

– XMX http://www.cs.brown.edu/software/xmx– VNC http://www.uk.research.att.com/vnc

Fast and reliable network needed for mainland remote observing

• 1997: 1.5 Mbps Hawaii -> Oahu -> mainland

• 1998: 10 Mbps from Oahu to mainland• 1999: First phase of Internet-2 upgrades:

– 45 Mbps commodity link Oahu -> mainland– 45 Mbps Internet-2 link Oahu -> mainland

• 2000: Second phase upgrade:– 35 Mbps Internet-2 link from Hawaii -> Oahu– Now 35 Mbps peak from Mauna Kea to mainland

• 2002: 155 Mbs from Oahu to mainland

End-to-end reliability is critical to successful remote operation

•Keck Telescope time is valued at $1 per second

•Observers won’t use facility if not reliable

•Each observer gets only a few nights each year

•What happens if network link to mainland fails?

–Path from Mauna Kea to mainland is long & complex

–At least 14 hops crossing 6 different network domains

–While outages are rare, consequences are severe

–Even brief outages cause session collapse & panic

–Observing time loss can extend beyond outage

Keck Observatory policy on mainland remote observing

•If no backup data path is available from mainland site, at least one member of observing team must be in Waimea

•Backup data path must be proven to work before mainland remote observing is permitted without no team members in Waimea

Mitigation plan: install end-to-end ISDN-based fall-back path

•Install ISDN lines and routers at:

–Each mainland remote observing site

–Keck 1 and Keck 2 control rooms

•Fail-over and fall-back are rapid and automatic

•Toll charges incurred only during network outage

•Lower ISDN bandwidth reduces efficiency, but:

–Observer retains control of observations

–Sessions remain connected and restarts avoided

–Prevents observer panic

Summary of ISDN-based fallback path

•Install 3 ISDN lines (6 B channels) at each site

•Install Cisco 2600-series routers at each end

–Quad BRI interfaces• Inverse multiplexing

• Caller ID (reject connections from unrecognized callers)

• Multilink PPP with CHAP authentication

• Dial-on-demand (bandwidth-on-demand)

•No manual intervention needed at either end

•Fail-over occurs automatically within 40 seconds

•Uses GRE tunnels, static routes, OSPF routing

Running OSPF routing over aGRE tunnel

•On each router, we configure 3 mechanisms:–A GRE tunnel to the other endpoint

–A floating static route that routes all traffic to the other endpoint via the ISDN dialer interface

–A private OSPF domain that runs over the tunnel

•OSPF maintains its route through the tunnel only if the tunnel is “up”

•OSPF dynamic routes take precedence over floating static route

Fail-over to ISDN backup data path

•If the Internet-2 path is “up”, OSPF “hello” packets flow across the tunnel between routers

•As long as “hello” packets flow, OSPF maintains the dynamic route, so traffic flows through tunnel

•If Internet-2 path is “down”, OSPF “hello” packets stop flowing, and OSPF deletes dynamic route

•With dynamic route gone, floating static route is enabled, so traffic flows through ISDN lines

The hardest problem was the lodging!

•LRIS operated from Santa Cruz all 5 nights

•ISDN backup path activated several times

•Observing efficiency comparable to Waimea

•Lodging was the biggest problem

•Motel check-in/check-out times incompatible

•Required booking two motels for the same night

•Motels are not a quiet place for daytime sleep

•OSPF keeps trying to send “hello” packets through the tunnel, even with Internet is down

•As long as Internet-2 path remains down the “hello” packets can’t get through

•Once the Internet-2 path is restored, “hello” packets flow between routers

•OSPF re-instates dynamic route through tunnel

•All current traffic gets routed through the tunnel

•All ISDN calls are terminated

Fall-back to the normal Internet-2 path

Operational costs of ISDN backup data path

•Fixed leased cost is $70 per line per month

•Three lines at each site -> $2,500 per site/year

•Both sites -> $5,000/year

•Long distance cost (incurrent only when active)

– $0.07 per B-channel per minute

– If all 3 lines in use:• $0.42 per minute

• $25.20 per hour

Recent operational experience

•Remote observing science from Santa Cruz:

– Low Resolution Imaging Spectrograph (LRIS)

– Echellete Spectrograph and Imager (ESI)

•Remote engineering and instrument support

– ESI

– High Resolution Echelle Spectrometer (HIRES)

•Remote Commissioning Support

– ESI

– DEIMOS (see SPIE paper 4841-155 & 4841-186)

Unplanned use of the facility during week of Sept. 11, 2001

•All U.S. commercial air traffic grounded

•Caltech astronomers have a 5-day LRIS run on Keck-I Telescope starting September 13

•No flights available

•Caltech team leaves Pasadena morning of 9/13

•Drives to Santa Cruz, arriving late afternoon

•Online with LRIS well before sunset in Hawaii

Extending mainland remote observing to other sites

•Other sites motivated by Santa Cruz success

•Caltech remote facility is nearly operational

– Equipment acquired

– ISDN lines and router installed

– Will be operational once routers are configured

•U.C. San Diego facility being assembled

– Equipment specified and orders in progress

•Other U.C. campuses considering plans

Administrative challenges: scheduling shared facilities

•Currently only one ISDN router at Mauna Kea

•Limits mainland operation to one site per night

•Interim administrative solution

•Longer term solution may require:

– Installation of additional ISDN lines at Mauna Kea

– Installation of an additional router at Mauna Kea

Remaining challenges

•TCP/IP tuning of end-point machines

–Needed to achieve optimal performance

–Conflicts with using “off-the-shelf” workstations

–Conflict between optimal TCP/IP parameters for the normal Internet-2 path .vs. the ISDN fall-back path

–Hoping for vendor-supplied auto-tuning

–Following research efforts of Web100 Project

•Administrative challenges

–Mainland sites are currently autonomous

–Need to develop coordination with Keck

•Internet-2 makes mainland operation feasible

•Backup data path protects against interruptions

•Keck HQ is the central hub for remote operation

•Mainland remote observing model is affordable:–Mainland sites operate as satellites of Keck HQ

• Leverage investment in existing facilities and staff• Leverage investment in existing software

–Share existing resources wherever feasible

–Avoid expensive and inefficient travel for short runs

• Model is being extended to multiple sites

Summary

advanced software and control for astronomy astronomical telescopes and instrumentation / spie 2006...

Documents

spie astronomical telescopes and instrumentation ·...

comparison of on-axis tma telescopes m. lampton & m. sholl...

astronomical telescopes + instrumentation call for...

this paper was (will be) published in proceedings of spie...

cosmology with vhe gamma ray telescopes. manel martinez...

development of ge jfets for deep-cryogenic preamplifiers...

off-axis telescopes for dark energy investigations spie...

spie astronomical telescopes and instrumentation, san diego,...

lev weisfeiler aware, inc. spie medical imaging 2006 san...

towers for telescopes with extreme stability, active or...

astronomical telescopes + instrumentation call for...

fizeau interferometry testbed: wavefront control - nasa ·...

adaptive membrane for gossamer space...

imaging systems...35 holst g c, electro-optical imaging...

new proceedings of spie · 2019. 9. 12. · proceedings of...

spie astronomical telescopes and instrumentation, san diego,...

space telescopes after jwst steven beckwith space telescope...

automatic brain segmentation in rhesus monkeys february...

spie astronomical telescopes and instrumentation · –...

the use of remote access telescopes in science education:...