...

Commits (62)
COPYRIGHT deleted 100644 → 0
 COPYRIGHT The following is a notice of limited availability of the code, and disclaimer which must be included in the prologue of the code and in all source listings of the code. Copyright Notice + 2013 University of Chicago Permission is hereby granted to use, reproduce, prepare derivative works, and to redistribute to others. This software was authored by: Mathematics and Computer Science Division Argonne National Laboratory, Argonne IL 60439 (and) Computer Science Department Rensselaer Polytechnic Institute, Troy NY 12180 GOVERNMENT LICENSE Portions of this material resulted from work developed under a U.S. Government Contract and are subject to the following license: the Government is granted for itself and others acting on its behalf a paid-up, nonexclusive, irrevocable worldwide license in this computer software to reproduce, prepare derivative works, and perform publicly and display publicly. DISCLAIMER This computer code material was prepared, in part, as an account of work sponsored by an agency of the United States Government. Neither the United States, nor the University of Chicago, nor any of their employees, makes any warranty express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights.
LICENSE 0 → 100644
LICENSE.md 0 → 100644
 # **IMPORTANT NOTICE** ## THE CODES PROJECT HAS BEEN MOVED https://github.com/codes-org/codes As of June 21, 2019, the location of the repo has been moved to GitHub as part of the codebase's shift to its open source BSD License. All issues will be moved in some form to the new location followed by merge requests (if possible). I will do my best to keep the master branch of the two repositories up to date with each other. That being said, if there is any conflict, the GitHub repo should be taken as the truth. Thank you, Neil McGlohon https://github.com/codes-org/codes # CODES Discrete-event Simulation Framework https://xgitlab.cels.anl.gov/codes/codes/wikis/home Discrete event driven simulation of HPC system architectures and subsystems has emerged as a productive and cost-effective means to evaluating potential HPC designs, along with capabilities for executing simulations of extreme scale systems. The goal of the CODES project is use highly parallel simulation to explore the design of exascale storage/network architectures and distributed data-intensive science facilities. Discrete event driven simulation of HPC system architectures and subsystems has emerged as a productive and cost-effective means to evaluating potential HPC designs, along with capabilities for executing simulations of extreme scale systems. The goal of the CODES project is to use highly parallel simulation to explore the design of exascale storage/network architectures and distributed data-intensive science facilities. Our simulations build upon the Rensselaer Optimistic Simulation System (ROSS), a discrete event simulation framework that allows simulations to be run in parallel, decreasing the simulation run time of massive simulations to hours. We are using ROSS to explore topics including large-scale storage systems, I/O workloads, HPC network fabrics, distributed science systems, and data-intensive computation environments. ... ...
 ## README for using ROSS instrumentation with CODES For details about the ROSS instrumentation, see the [ROSS Instrumentation blog post](http://carothersc.github.io/ROSS/instrumentation/instrumentation.html) For details about the ROSS instrumentation, see the [ROSS Instrumentation blog post](http://ross-org.github.io/instrumentation/instrumentation.html) on the ROSS webpage. There are currently 4 types of instrumentation: GVT-based, real time sampling, virtual time sampling, and event tracing. See the ROSS documentation for more info on the specific options or use --help with your model. To collect data about the simulation engine, no changes are needed to model code for any of the instrumentation modes. Some additions to the model code is needed in order to turn on any model-level data collection. See the "Model-level data sampling" section on [ROSS Instrumentation blog post](http://carothersc.github.io/ROSS/instrumentation/instrumentation.html). See the "Model-level data sampling" section on [ROSS Instrumentation blog post](http://ross-org.github.io/instrumentation/instrumentation.html). Here we describe CODES specific details. ### Register Instrumentation Callback Functions ... ... @@ -37,13 +37,13 @@ The second pointer is for the data to be sampled at the GVT or real time samplin In this case the LPs have different function pointers since we want to collect different types of data for the two LP types. For the terminal, I set the appropriate size of the data to be collected, but for the router, the size of the data is dependent on the radix for the dragonfly configuration being used, which isn't known until runtime. *Note*: You can only reuse the function for event tracing for LPs that use the same type of message struct. *Note*: You can only reuse the function for event tracing for LPs that use the same type of message struct. For example, the dragonfly terminal and router LPs both use the terminal_message struct, so they can use the same functions for event tracing. However the model net base LP uses the model_net_wrap_msg struct, so it gets its own event collection function and st_trace_type struct, in order to read the event type correctly from the model. use the same functions for event tracing. However the model net base LP uses the model_net_wrap_msg struct, so it gets its own event collection function and st_trace_type struct, in order to read the event type correctly from the model. In the ROSS instrumentation documentation, there are two methods provided for letting ROSS know about these st_model_types structs. In CODES, this step is a little different, as codes_mapping_setup() calls tw_lp_settype(). In the ROSS instrumentation documentation, there are two methods provided for letting ROSS know about these st_model_types structs. In CODES, this step is a little different, as codes_mapping_setup() calls tw_lp_settype(). Instead, you add a function to return this struct for each of your LP types: C static const st_model_types *dragonfly_get_model_types(void) ... ... @@ -73,7 +73,7 @@ static void router_register_model_types(st_model_types *base_type) At this point, there are two different steps to follow depending on whether the model is one of the model-net models or not. ##### Model-net Models In the model_net_method struct, two fields have been added: mn_model_stat_register and mn_get_model_stat_types. In the model_net_method struct, two fields have been added: mn_model_stat_register and mn_get_model_stat_types. You need to set these to the functions described above. For example: C ... ... @@ -109,27 +109,27 @@ st_model_types svr_model_types[] = { static void svr_register_model_types() { st_model_type_register("server", &svr_model_types[0]); st_model_type_register("ns-lp", &svr_model_types[0]); } int main(int argc, char **argv) { // ... some set up removed for brevity model_net_register(); svr_add_lp_type(); if (g_st_ev_trace || g_st_model_stats) svr_register_model_types(); codes_mapping_setup(); //... }  g_st_ev_trace is a ROSS flag for determining if event tracing is turned on and g_st_model_stats` determines if the GVT-based or real time instrumentation modes are collecting model-level data as well. modes are collecting model-level data as well. ### CODES LPs that currently have event type collection implemented: ... ... @@ -144,4 +144,3 @@ If you're using any of the following CODES models, you don't have to add anythin - slimfly router and terminal LPs (slimfly.c) - fat tree switch and terminal LPs (fat-tree.c) - model-net-base-lp (model-net-lp.c)
 ... ... @@ -2,7 +2,7 @@ # Process this file with autoconf to produce a configure script. AC_PREREQ([2.67]) AC_INIT([codes], [1.0.0], [http://trac.mcs.anl.gov/projects/codes/newticket],[],[http://www.mcs.anl.gov/projects/codes/]) AC_INIT([codes], [1.1.0], [http://trac.mcs.anl.gov/projects/codes/newticket],[],[http://www.mcs.anl.gov/projects/codes/]) LT_INIT ... ...
 ... ... @@ -2,12 +2,12 @@ NOTE: see bottom of this file for suggested configurations on particular ANL machines. 0 - Checkout, build, and install the trunk version of ROSS (https://github.com/carothersc/ROSS). At the time of (https://github.com/ross-org/ROSS). At the time of release (0.6.0), ROSS's latest commit hash was 10d7a06b2d, so this revision is "safe" in the unlikely case incompatible changes come along in the future. If working from the CODES master branches, use the ROSS master branch. git clone http://github.com/carothersc/ROSS.git git clone http://github.com/ross-org/ROSS.git # if using 0.5.2 release: git checkout d3bdc07 cd ROSS mkdir build ... ... @@ -22,7 +22,7 @@ working from the CODES master branches, use the ROSS master branch. ROSS/install/ directory> For more details on installing ROSS, go to https://github.com/carothersc/ROSS/blob/master/README.md . https://github.com/ross-org/ROSS/blob/master/README.md . If using ccmake to configure, don't forget to set CMAKE_C_COMPILER and CMAKE_CXX_COMPILER to mpicc/mpicxx ... ...
 ... ... @@ -16,7 +16,7 @@ per compute node or one multi-port NIC per node. Adding a generic template for building new network models. For simplest case, only 2 functions and premable changes should suffice to add a new network. Updated Express Mesh network model to serve as an example. For details, see Updated Express Mesh network model to serve as an example. For details, see Darshan workload generator has been updated to use Darshan version 3.x. ... ... @@ -28,11 +28,11 @@ https://xgitlab.cels.anl.gov/codes/codes/wikis/Using-ROSS-Instrumentation-with-C Compatible with ROSS version that enables statistics collection of simulation performance. For details see: http://carothersc.github.io/ROSS/instrumentation/instrumentation.html http://ross-org.github.io/instrumentation/instrumentation.html Online workload replay functionality has been added that allows SWM workloads to be simulated insitu on the network models. WIP to integrate Conceptual domain specific language for network communication. domain specific language for network communication. Multiple traffic patterns were added in the background traffic generation including stencil, all-to-all and random permutation. ... ... @@ -93,7 +93,7 @@ Background network communication using uniform random workload can now be generated. The traffic generation gets automatically shut off when the main workload finishes. Collectives can now be translated into point to point using the CoRTex library. Collectives can now be translated into point to point using the CoRTex library. Performance of MPI_AllReduce is reported when debug_cols option is enabled. ... ...
 ... ... @@ -121,7 +121,7 @@ xleftmargin=6ex % IEEEtran.cls handling of captions and this will result in nonIEEE style % figure/table captions. To prevent this problem, be sure and preload % caption.sty with its "caption=false" package option. This is will preserve % IEEEtran.cls handing of captions. Version 1.3 (2005/06/28) and later % IEEEtran.cls handing of captions. Version 1.3 (2005/06/28) and later % (recommended due to many improvements over 1.2) of subfig.sty supports % the caption=false option directly: %\usepackage[caption=false,font=footnotesize]{subfig} ... ... @@ -188,7 +188,7 @@ easily shared and reused. It also includes a few tips to help avoid common simulation bugs. For more information, ROSS has a bunch of documentation available in their repository/wiki - see \url{https://github.com/carothersc/ROSS}. repository/wiki - see \url{https://github.com/ross-org/ROSS}. \end{abstract} \section{CODES: modularizing models} ... ... @@ -394,7 +394,7 @@ action upon the completion of them. More generally, the problem is: an event issuance (an ack to the client) is based on the completion of more than one asynchronous/parallel events (local write on primary server, forwarding write to replica server). Further complicating the matter for storage simulations, there can be any number of outstanding requests, each waiting on multiple events. can be any number of outstanding requests, each waiting on multiple events. In ROSS's sequential and conservative parallel modes, the necessary state can easily be stored in the LP as a queue of statuses for each set of events, ... ... @@ -488,7 +488,7 @@ Most core ROSS examples are design to intentionally hit the end timestamp for the simulation (i.e. they are modeling a continuous, steady state system). This isn't necessarily true for other models. Quite simply, set g\_tw\_ts\_end to an arbitrary large number when running simulations that have a well-defined end-point in terms of events processed. that have a well-defined end-point in terms of events processed. Within the LP finalize function, do not call tw\_now. The time returned may not be consistent in the case of an optimistic simulation. ... ... @@ -515,7 +515,7 @@ section(s). \item generating multiple concurrent events makes rollback more difficult \end{enumerate} \item use dummy events to work around "event-less" advancement of simulation time \item use dummy events to work around "event-less" advancement of simulation time \item add a small amount of time "noise" to events to prevent ties ... ...
 ... ... @@ -44,7 +44,7 @@ Notes on how to release a new version of CODES 4. Upload the release tarball - Our release directory is at ftp.mcs.anl.gov/pub/CODES/releases . There's no web interface, so you have to get onto an MCS workstation and copy the release in that way (the ftp server is mounted at /homes/ftp). release in that way (the ftp server is mounted at /mcs/ftp.mcs.anl.gov). 5. Update website - Project wordpress: http://www.mcs.anl.gov/projects/codes/ (you need ... ...
 ... ... @@ -246,7 +246,7 @@ int main( /* calculate the number of servers in this simulation, * ignoring annotations */ num_servers = codes_mapping_get_lp_count(group_name, 0, "server", NULL, 1); num_servers = codes_mapping_get_lp_count(group_name, 0, "nw-lp", NULL, 1); /* for this example, we read from a separate configuration group for * server message parameters. Since they are constant for all LPs, ... ... @@ -273,7 +273,7 @@ static void svr_add_lp_type() { /* lp_type_register should be called exactly once per process per * LP type */ lp_type_register("server", svr_get_lp_type()); lp_type_register("nw-lp", svr_get_lp_type()); } static void svr_init( ... ...
 ... ... @@ -3,14 +3,14 @@ # of application- and codes-specific key-value pairs. LPGROUPS { # in our simulation, we simply have a set of servers, each with # in our simulation, we simply have a set of servers (nw-lp), each with # point-to-point access to each other SERVERS { # required: number of times to repeat the following key-value pairs repetitions="16"; # application-specific: parsed in main server="1"; nw-lp="1"; # model-net-specific field defining the network backend. In this example, # each server has one NIC, and each server are point-to-point connected modelnet_simplenet="1"; ... ...
 ... ... @@ -18,6 +18,7 @@ argobots_libs=@ARGOBOTS_LIBS@ argobots_cflags=@ARGOBOTS_CFLAGS@ swm_libs=@SWM_LIBS@ swm_cflags=@SWM_CFLAGS@ swm_datarootdir=@SWM_DATAROOTDIR@ Name: codes-base Description: Base functionality for CODES storage simulation ... ... @@ -25,4 +26,4 @@ Version: @PACKAGE_VERSION@ URL: http://trac.mcs.anl.gov/projects/CODES Requires: Libs: -L${libdir} -lcodes${ross_libs} ${argobots_libs}${swm_libs} ${darshan_libs}${dumpi_libs} ${cortex_libs} Cflags: -I${includedir} ${swm_datarootdir}${ross_cflags} ${darshan_cflags}${swm_cflags} ${argobots_cflags}${dumpi_cflags} ${cortex_cflags} Cflags: -I${includedir} -I${swm_datarootdir}${ross_cflags} ${darshan_cflags}${swm_cflags} ${argobots_cflags}${dumpi_cflags} \${cortex_cflags}