Rick, 1) Just to follow up, did you figure out a good speed for the checkpoint producing run?
2) Did you ever find why everything was 404'ed? Lisa On Wed, Jan 28, 2009 at 9:44 PM, Lisa Hsu <h...@eecs.umich.edu> wrote: > I couldn't say exactly, so much in M5 has changed since that paper to give > an exact number, but I'd imagine whatever instructions/second you're getting > in the detailed, if you make the checkpoint run the appropriate speed > considering its 1 IPC, you'd probably be in the right range. > > Lisa > > > On Wed, Jan 28, 2009 at 8:26 PM, Rick Strong <rstr...@cs.ucsd.edu> wrote: > >> The clock rate on the server is only set to 1GHz on the checkpoint run >> (as opposed to 3GHz for the detailed simulation). How slow should it be >> set? Are we talking nearer to 250MHz? >> >> Thanks, >> -Rick >> >> Ali Saidi wrote: >> > That's almost certainly what is happening. Different packets are >> > trying to be sent, both originating from the kernel. This isn't a >> > device bug. It's exactly what that paper described. The delay observed >> > by the server has changed dramatically, that a retransmit is occurring >> > because since the ack didn't arrive in twice the round trip latency. >> > You should add some latency to the ethernet link, and drive the server >> > with a slower CPU during the checkpoint run. That will normally fix >> > the problem. >> > >> > Ali >> > >> > >> > >> > >> > On Jan 28, 2009, at 5:59 PM, Rick Strong wrote: >> > >> > >> >> This is an interesting. Thanks for the link. >> >> >> >> -Rick >> >> >> >> Lisa Hsu wrote: >> >> >> >>> Your description that it only occurs when you switch to a timing sim >> >>> makes me think of this (not to toot my own horn or anything): >> >>> >> >>> http://www.eecs.umich.edu/~hsul/pubs/mobs05.pdf<http://www.eecs.umich.edu/%7Ehsul/pubs/mobs05.pdf> >> >>> <http://www.eecs.umich.edu/%7Ehsul/pubs/mobs05.pdf> >> >>> >> >>> Just throwing that out as a possibility. You might want to "slow >> >>> down" your checkpoint dropping run so that it's not so disruptive >> >>> when >> >>> you switch over to timing. >> >>> >> >>> Lisa >> >>> >> >>> On Wed, Jan 28, 2009 at 5:32 PM, Rick Strong <rstr...@cs.ucsd.edu >> >>> <mailto:rstr...@cs.ucsd.edu>> wrote: >> >>> >> >>> I have posted tar.gz files that include EthernetAll output (in >> >>> ethernet_all.trace) @ http://rickshin.ucsd.edu. Once you have a >> >>> chance, >> >>> if you could take a look at the trace and figure what is wrong >> >>> that is >> >>> great. >> >>> >> >>> I ended restoring from the checkpoint for two runs. One run >> >>> stays in >> >>> atomic mode while the other switches to timing and detailed. The >> >>> run >> >>> that stays in atomic mode works fine. This leads me to believe >> >>> that the >> >>> checkpoint restore mechanism is fine. The fault likely lies in the >> >>> switching to timing or detailed mdoe. >> >>> >> >>> The differences between the runs: >> >>> >> >>> (1) m5out-atomic-run-aftercheckpoint.tar.gz is a run that stays in >> >>> atomic mode (no switching to timing mode) >> >>> >> >>> (2) m5out-timing-run-aftercheckpoint.tar.gz is a run that >> >>> switches to >> >>> timing and then to detailed mode. >> >>> >> >>> >> >>> Thanks and good luck, >> >>> >> >>> -Rick >> >>> >> >>> Ali Saidi wrote: >> >>> >> >>>> Looking at the trace, it appears as though you just restored from a >> >>>> checkpoint. Is this the case? If so, what does the checkpoint >> >>>> >> >>> dropping >> >>> >> >>>> run do after that checkpoint is created? It's so early in the trace >> >>>> that I would guess it's a serialization bug, particularly in >> >>>> >> >>> the TSO >> >>> >> >>>> code. However, I looked quickly at the code and and nothing >> >>>> >> >>> seemed to >> >>> >> >>>> jump out at me. If you can provide me with an EthernetAll trace from >> >>>> the checkpoint run and from the restored run I can work on figuring >> >>>> out what the problem is. >> >>>> >> >>>> Ali >> >>>> >> >>>> >> >>>> >> >>>> On Jan 28, 2009, at 2:53 AM, Rick Strong wrote: >> >>>> >> >>>> >> >>>> >> >>>>>> There are three possibilities here: >> >>>>>> a) A kernel bug >> >>>>>> b) a device model/driver bug >> >>>>>> c) a checkpointing bug (as it relates to (b)) >> >>>>>> >> >>>>>> What kernel version are you using? Could you put the ethernet >> >>>>>> >> >>> trace >> >>> >> >>>>>> somewhere so I could look at it? >> >>>>>> >> >>>>>> Ali >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> I am using the kernel 2.6.18 with M5 patches. >> >>>>> >> >>>>> I have put the ethernet traces up at http://rickshin.ucsd.edu. >> >>>>> >> >>> It is >> >>> >> >>>>> the >> >>>>> only link. If you take a look, let me know what you think. >> >>>>> >> >>>>> Best, >> >>>>> -Rick >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> m5-dev mailing list >> >>>>> m5-dev@m5sim.org <mailto:m5-dev@m5sim.org> >> >>>>> http://m5sim.org/mailman/listinfo/m5-dev >> >>>>> >> >>>>> >> >>>>> >> >>>> _______________________________________________ >> >>>> m5-dev mailing list >> >>>> m5-dev@m5sim.org <mailto:m5-dev@m5sim.org> >> >>>> http://m5sim.org/mailman/listinfo/m5-dev >> >>>> >> >>>> >> >>>> >> >>> _______________________________________________ >> >>> m5-dev mailing list >> >>> m5-dev@m5sim.org <mailto:m5-dev@m5sim.org> >> >>> http://m5sim.org/mailman/listinfo/m5-dev >> >>> >> >>> >> >>> >> ------------------------------------------------------------------------ >> >>> >> >>> _______________________________________________ >> >>> m5-dev mailing list >> >>> m5-dev@m5sim.org >> >>> http://m5sim.org/mailman/listinfo/m5-dev >> >>> >> >>> >> >> _______________________________________________ >> >> m5-dev mailing list >> >> m5-dev@m5sim.org >> >> http://m5sim.org/mailman/listinfo/m5-dev >> >> >> >> >> > >> > _______________________________________________ >> > m5-dev mailing list >> > m5-dev@m5sim.org >> > http://m5sim.org/mailman/listinfo/m5-dev >> > >> > >> >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev >> >> >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
