1. Experiences Using Web100 for Visible Human Testbeds Thomas Hacker Center for Advanced Computing, University of Michigan Brian Athey Michigan Center for Biological Information, University of Michigan Web100 Evaluators Workshop Boulder, CO August 1, 2002

2. Outline Visible Human Project Edgewarp Visualization Application Performance Problems Tuning Methodology ResultsConclustion

3. Visible Human Project Sponsored by the National Library of Medicine Goal is to deliver rendered images of anatomic content to teaching stations in the anatomy lab Scaling requirements are stringent At least 40 teaching stations per lab At least 40 teaching stations per lab Simultaneous access by teaching centers across the nation Simultaneous access by teaching centers across the nation

4. Edgewarp Core component of the Visible Human Project content delivery Designed and developed by Dr. Fred Bookstein and Dr. William Green Delivers filmstrip fly-thorough of anatomical data Allows students to navigate freely through anatomical data

7. Edgewarp Data Access Edgewarp pulls image voxels from data server Only the voxels necessary to draw the current image in detail are pulled Successively higher resolution voxels are pulled as the image fills in Allows fast navigation (low-res) Provides high resolution still images

8. Performance Problems U-M VHP demonstration at NASA AMES Gigabit Ethernet Workshop in August, 2000 End-to-end TCP performance from University of Michigan to NASA AMES was around 3 Mb/sec. Network bottleneck was OC-12! No clear cause for performance problems

9. Web100 Tuning Methodology developed in collaboration with PSC staff (Matt Mathis) Used Web100 as TCP oscilloscope to guide tuning efforts Methodology Start with the wire Start with the wire Work up to TCP Work up to TCP Finish with the application Finish with the application

10. Pre-tuning Transmission test performed from PSC Visible Human Server to University of Michigan Edgewarp test rig used with voxel server Initial throughput approximately 12 Mb/sec Network bottleneck was 100 Mb/sec link at University of Michigan

11. Pre-tuning Web100 showed small receiver socket buffers, little packet loss, poor throughput

12. Tuning Methodology Start with the wire Used Cat-5e cabling Used Cat-5e cabling Used good network adapters Used good network adapters No congestion losses reported by Network Operations website No congestion losses reported by Network Operations website Network adaters in full-duplex mode Network adaters in full-duplex mode

13. Tuning Methodology Work up to TCP Client host tuned to support SACK, MTU discovery, Timestamps, and Window Scaling Client host tuned to support SACK, MTU discovery, Timestamps, and Window Scaling The TCP maximum and default send and receive socket buffer set to 2 MB The TCP maximum and default send and receive socket buffer set to 2 MB The server was checked to ensure that these options were enabled.

14. Web100 Reality Check Check settings in Web100 to make sure they take effect

15. Check tcpdump to Make Sure… # /usr/sbin/tcpdump port 8694 Kernel filter, protocol ALL, datagram packet socket tcpdump: listening on all devices 19:07:26.172433 eth1 > spbuild.engin.umich.edu.1088 > vh.psc.edu.8694: S 1067517561:1067517561(0) win 32758 (DF) 19:07:26.192439 eth1 spbuild.engin.umich.edu.1088: S 1021853801:1021853801(0) ack 1067517562 win 4060 (DF)

16. Results Web100 indicated sawtooth transmission behavior, higher throughput, and packet loss

17. Results Throughput improved by about a factor of four nSD95% CI of MeanMedian Mistuned Bandwidth 6011.312111.728to 11.93812.395 Tuned Bandwidth 6019.075140.613to 42.06741.578

18. Conclusion Web100 is an effective tool for diagnosing TCP performance problems Web100 is an essential aid in tuning Web100 helps to close the wizard gap necessary to improve performance