Hi Avadh, Let's say I wanted to port my stats collection over to the stats module you guys are implementing. I started looking at the code in ptlsim/stats/ but it's a bit unclear to me what I should be focusing on.
It seems that stats.h and dataStore.* belong to the old stats system -- should I just be ignoring these files and only looking at statsBuilder.* ? Going forward, are you guys planning on supporting both BSON and YAML? -Paul On Thu, Jun 2, 2011 at 12:40 PM, avadh patel <[email protected]> wrote: > This indeed seems very interesting and useful to many people. > Please send me the patches or link to your git repo. > > About the new stats module we might find a way to incorporate it into new > Statistics Builder module. It can be categorized as time/cycle relative > counters that can be dumped into separate stats/csv file. Also we can > easily implement dumping new Statistics Builder counters to new format. > > One thing that I personally would get hands to is your gmail poll script > that email back the response of running simulations. > > - Avadh > > On Wed, Jun 1, 2011 at 1:50 PM, DRAM Ninjas <[email protected]> wrote: > >> Hello All, >> >> While using marss I've developed a kind of ad hoc set of tools comprised >> of various scripts that make my life easier. I've been considering packaging >> them up and throwing them out to a github repo for people to use, but I >> wanted to gauge interest before I took the time to clean these up and push >> them out. >> >> Most of these are outside of MARSS with the exception of a stats module I >> wrote. While the PTLStats is great for overall simulation stats, I don't >> think it really has a time-based component (please correct me if I'm wrong). >> The stats module I wrote is basically a single global object that acts like >> a map where you can say >> >> mystats["bus_rejections"]++; >> or >> mystats["cache_latency"]+=5; >> >> It's nothing fancy -- just a single .h file with some definitions, but it >> allows me to do averages, sums, per-cycle averages, etc. It automatically >> dumps these stats to a file every X cycles and then a python script graphs >> them. I've been reluctant to submit a patch for this since uh, it seems like >> the last thing marss needs is another stats collection system. This one is >> pretty lightweight and since it's mostly meant to be used with a script to >> draw graphs, it doesn't have a lot of complexity of trying to be human >> readable. >> >> The other scripts do things like: >> >> 1. Create a bunch of time varying plots (from the stats module described >> above or any csv file you generate), throw them into a png. I've attached an >> example png (not actually sure if the listserv allows that, but worth a >> shot). >> 2. Create some time-varying plots, throw them into an eps (which can be >> post processed into pdf and imported as vector graphics into LaTeX). >> 3. Log into a gmail account with an xoauth token (no password) and send an >> email (with arbitrary) attachments (this one already exists in marss and can >> be used with the -execute-after-kill patch I wrote a while ago) >> 4. Display the simulation status (including cycle count, which cores are >> in kernel/user/library RIPs) >> 5. Poll a gmail account for a specific label -- when something appears in >> that label, send back a reply with the status of all running simulation. >> >> So if any of this sounds interesting or useful, let me know and I'll >> expend the effort to clean these things up and push them out somewhere. >> >> -Paul >> >> _______________________________________________ >> http://www.marss86.org >> Marss86-Devel mailing list >> [email protected] >> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >> >> >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
