SteerBoardMeeting07 < CmsTier3

Tags: view all tags
<!-- keep this as a security measure:
   #uncomment if the subject should only be modifiable by the listed groups 
   # * Set ALLOWTOPICCHANGE = Main.TWikiAdminGroup,Main.CMSAdminGroup
   # * Set ALLOWTOPICRENAME = Main.TWikiAdminGroup,Main.CMSAdminGroup
   #uncomment this if you want the page only be viewable by the listed groups
   # * Set ALLOWTOPICVIEW = Main.TWikiAdminGroup,Main.CMSAdminGroup,Main.CMSAdminReaderGroup
-->

---+ 2015-12-16 Sixth Steering Board Meeting

   * Preparatory information can be found in the documentation and minutes of the [[SteerBoardMeeting06][virtual preparation meeting]]
   * [[%ATTACHURL%/psi-t3-board-20151216.pdf][Presentation for Steering Board 2015-12-16]] _Errata Corrige_ : Slide 13 and Slide 14  ">= 512GB RAM"

---++ Meeting Minutes

   * *Discussion on upgrade Scenarios* 
      * longer discussion on hyperthreading, how much RAM per phys core 
      * Users are ok with current UIs. There is no big need based on the users' requirements to replace the UIs. 
         * Fabio asked wheter they are ok with the scratch space. Seemingly yes. 
         * Question, what is the meaning of "not scalable" that is affixed to the storage upgrade. Not scalable in the sense of IO throughput (i.e. another added disk extension to the same controllers would not increase throughput). 
      * Derek: You need to be aware of two possible deadlocks: 
         * not having enough storage: More frequent cleaning, not being able to have enough data locally 
         * too many cores per storage leading to not enough IO. 
      * Clemens on UIs: explains that he proposed the upgrade of the UIs as reflected in the two scenarios because he says that many users run a lot of jobs interactively. 
      * *Decision*: Board members agree that the proposed Scenario 1 (moderate increase in of both storage and computational power) seems the best. 
   * *General Discussion* 
      * Urs says that for him the T3 is still the most efficient resource. His analysis does not yet work with Condor (the std glite submission is no longer available), and with CRAB3 he needs to invest a lot of time to babysit jobs. 
      * Clemens 
         * There seem to be intentions by some groups (e.g. the _matrix-element method_ group) to use the T3 more intensively in the near future. 
      * UI discussion 
         * Joosep says that they have very good experience with providing a high memory UI. He does not remember completely, but its around 500 GB on 60 cores. 
      * UniZ says that the 75kCHF will be accorded. Probably there is no time constraint on these funds, though we are planning on using them anyhow by Q1/2016.  We have a time constraint on the remaining FLARE2015 funds of 35 kCHF. 
      * Do we need to provide CRAB3 access to the T3? 
         * Joosep and Lea say that they are successfully using GridControl EKP developed by KIT. 
         * Need is not urgent, but at least UniZ would be happy to have it in place. Willing to wait. 
   * *Action Items* 
      * For the implementation of Scenario 1. 
         * Fabio and Derek, end of Dec: Send Scenario 1 upgrade plan to board members. Ask UniZ for the needed funds (ca 75 kCHF). 
         * Fabio, until Jan 2016: Get quotes from the providers. Decide when the best time for the procurement of HW from the remaining FLARE funds + UniZ funds is. 
      * Fabio until Jan 2016: information for the cost of one (or multiple) "fat" UIs. Could also be one machine of the 4 servers in a twin compartment. 3-4 TB of scratch space will be enough. The active calculation anyhow will take place on the files in memory. Joosep has experience working on these machines and should be a primary contact. [[http://hep.kbfi.ee/~joosep/quasar.txt][fat node currently used by Joosep]]
         * If this is feasible and wanted, also need to propose the usage policy for such a resource. Establishing a convention vs. putting it behind a queue, etc. 

---++ References
   * [[https://w3.hepix.org/benchmarks/doku.php?id=bench:results_sl6_x86_64_gcc_445][CPUs HS06 benchmarks]]
   * [[http://www.cisco.com/c/en/us/products/collateral/switches/nexus-2000-series-fabric-extenders/data_sheet_c78-507093.html][CISCO 10Gb/s Expander - Model 2232TM-E 10GE]]