oh and one thing I forgot to mention is that you should change config.py to match your own paths....
On Thu, Jun 2, 2011 at 12:55 PM, DRAM Ninjas <[email protected]> wrote: > Alrighty, I actually decided to push these out anyways since I'm always > muddling my commits with changes to these scripts since they used to sit > inside of my marss tree. > > https://github.com/dramninjasUMD/marss.utils > > poll_gmail.py turns out to be ridiculously simple once you have a valid > xoauth token for your gmail account (instructions to get a token and what to > do with it are in send_gmail.py). I use a simple filter on my gmail account > where I say 'if I get a message from me that has this string in the title, > send it to the label marss'. The script then picks up any unread messages > from that folder, marks them as read, and sends back a status string. This > can be extended to actually using the subject as an argument for specific > actions, but I've not really needed that kind of functionality to date. > > The status string is generated from sim_status.py -- which reads the output > of ps and looks for qemu-system. It's tailored to my naming scheme of disk > images, so it probably won't work out of the box, but it should be easy > enough to modify. > > I'll try to add some comments so that people have an easier time > understanding what's going on ... > > > > 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
