Experiences Using Web100 for Visible Human Testbeds

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
• Results
• Conclustion

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
• 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

5
(No Transcript)
6
(No Transcript)
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
• Work up to TCP
• 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 good network adapters
• No congestion losses reported by Network
  Operations website
• 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
• 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
• 190726.172433 eth1 gt spbuild.engin.umich.edu.108
  8 gt vh.psc.edu.8694 S 10675175611067517561(0)
  
• win 32758 ltmss 1460,sackOK,timestamp
  29833739 0,nop,wscale 5gt (DF)
• 190726.192439 eth1 lt vh.psc.edu.8694 gt
  spbuild.engin.umich.edu.1088 S
  10218538011021853801(0)
• ack 1067517562 win 4060 ltmss
  1460,sackOK,timestamp 1073113995
  29833739,nop,wscale 5gt (DF)

16
Results

• Web100 indicated sawtooth transmission
  behavior, higher throughput, and packet loss

17
Results

• Throughput improved by about a factor of four

  n SD 95 CI of Mean 95 CI of Mean Median
Mistuned Bandwidth  601 1.3121 11.728 to 11.938 12.395
Tuned Bandwidth  601 9.0751 40.613 to 42.067 41.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