Tags:
create new tag
view all tags

2015-12-16 Sixth Steering Board Meeting

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

Topic attachments
I Attachment History Action SizeSorted ascending Date Who Comment
PDFpdf psi-t3-board-20151216.pdf r1 manage 2699.5 K 2015-12-16 - 13:18 DerekFeichtinger Presentation for Steering Board 2015-12-16
Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r6 - 2016-01-05 - FabioMartinelli
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback