Fortunately, this problem is well-known in the high-speed networking
community. Networks such as ours are known as ``long fat networks''
(LFN; see RFC
1323
). In the case of
the SunOS operating system (to which we are constrained by legacy
control software at Keck), we obtained the TCP-LFN package from Sun
Consulting, which purports to support the RFC 1323 extensions.
Unfortunately, a number of limitations of SunOS 4.1.4 conspire to
prohibit one from obtaining extremely large window sizes, regardless
of the TCP-LFN software. In our case, the compiled-in kernel limit of
2 Mbytes of Mbuf memory (i.e., IP packet wrappers) turned out to be
the major constraint, limiting our window size to no more than
1 Mbyte. Indeed, our final tuned network delivered the expected
maximum TCP/IP performance of approximately 15 Mbit/sec (
of OC-1). Although perhaps disappointing in a relative
sense, this bandwidth is far in excess of T1 Ethernet speed
(1.44 Mbit/sec) and allows an 8 Mbyte image to be transferred in
approximately 5 seconds. As a further comparison, this bandwidth
exceeds by 50% that which is available on the local area Ethernet
network at the Keck Telescope itself. Figure 2
illustrates typical bandwidth measurements of our network for UDP and
TCP, the latter before and after the network was upgraded to fiber in
Hawaii.
While network performance was perhaps not at the level desired, due to
developing infrastructure in Hawaii and idiosyncrasies within the
operating system, issues of network reliability had far greater impact
on our remote observing operation. The experimental and limited
nature of the ACTS program created a number of difficulties which one
would almost certainly not face if using a more developed and/or
commercial satellite system. The impact of the reliability issue is
that at least one observer must be sent to Hawaii to use the
telescope, in case of ACTS-related problems.