CMSThroughputTests < LCGTier2

Tags: view all tags

<!-- keep this as a security measure:
   * Set ALLOWTOPICCHANGE = Main.TWikiAdminGroup,Main.LCGAdminGroup
   * Set ALLOWTOPICRENAME = Main.TWikiAdminGroup,Main.LCGAdminGroup
   #uncomment this if you want the page only be viewable by the internal people
   * #Set ALLOWTOPICVIEW = Main.TWikiAdminGroup,Main.LCGAdminGroup
-->

---+ Throughput Tests

Throughput tests to find maximal effective bandwidth and optimum conditions for specific channels. These tests are done with
low level tools to discover principal problems of routes. There is no sense in doing complicated measurements on top of the whole
middleware stack if issues already appear at this level.

These measurements were done from our DPM machine running on a Linux 2.4 kernel. 
   * [[ThroughputTestFNAL][FNAL]] (Some problems!)
   * [[ThroughputTestFZK][FZK]] (ok)
   * [[ThroughputTestASGC][ASGC]] (bad, lossy connection; improvement seen on May 5th 2007)

Measurements using a Linux 2.6 kernel machine:
   * [[ThroughputTestASGC2][ASGC]] (improved)


Wenji Wu from FNAL has pointed out that the TCP congestion algorithm can play a big role. For connections with very
long RTT (> 100 ms) he had quite good results using the _CUBIC_ algorithm instead of the standard _TCP Reno_ algorithm. Linux 2.4 does not offer the possibilities of choosing these algorithms via sysctl. So we should remeasure some of our connections using another host running Linux 2.6.
Also, we need to study how to tune our Solaris10 Thumpers, which now make up the new SE.

I had done some FTS tests in September 2006, but rather in an unsystematic way:

   * [[FTSChannelDebugging][FTS STAR-CSCS channel debugging]]

-- Main.DerekFeichtinger - 30 Apr 2007