1 / 7

A Thing of Beauty

A Thing of Beauty. Outline. Event Builder - Configuration/Control NT-side Client/Server Performance / Control Logging Compiler/Library Options CYGWIN, g++, gmake STLPort/Boost. Configuration/Control. Proposed NT side Server/Client with caching implimented (centralized or at the Node)

sybil
Download Presentation

A Thing of Beauty

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Thing of Beauty

  2. Outline Event Builder - Configuration/Control NT-side Client/Server Performance / Control Logging Compiler/Library Options CYGWIN, g++, gmake STLPort/Boost

  3. Configuration/Control Proposed NT side Server/Client with caching implimented (centralized or at the Node) Recovery from single Node failures, Dynamic configuration of EVB runtime parameters Get back to a system that has Node Server persistence Dividing configuration into trigger configuration dependent/independent components Fake data mode EVB sans PartitionServer/RC Currently EvBServer/RC communicates to individual EVB nodes from phoncs0 via CORBA – Server start up is slow Node failure/Reconfiguration implies reinitialzation Node server persistence is problematic with the current method of thread termination Configuration data is amalgamated into a single CORBA object Operating the EVB in “fake” data mode requires the full RC

  4. NT Side Server trigger dependent trigger independent fake data mode Issues CORBA 2000, CORBA 3.3 Startup overhead mitigate by centralized CORBA server on NT side ? Newer CORBA version PHONCS-land EVB-land

  5. Monitoring/Logging Detailed monitoring information is necessary to understand the performance of the current EVB Natural NT side server integration Logging is currently to ascii files with monitoring scripts in python using NetBIOS or ssh CORBA Logger or other ?

  6. Node Configuration Current node configuration is done manually, takes > 20 minutes /node and is not devoid of error This model does not scale well to a > 200 node EVB (Chun doesn’t want to configure 200+ nodes by hand) Set up NT Server (RTFM) How much does this buy us ? Application server for developement and debugging utilities ?

  7. Compiler/Library Options g++/gmake L2/offline compatibility Makefile stewardship / Porting overhead STLPort ANSI standard compliance Thread safe Hashed containers and standard allocators SEB code ported but not functioning BOOST The future of STL, shared pointers, object pools, platform independent threads, tuples... much more MSVC 6.0+ Can’t discount the evil empire

More Related