Re: [Gems-users] Tester.exec and event triggering

[Dan Gibson <degibson@xxxxxxxx>]

Daniele,
I can't comment on the DNUCA issues, as I know very little about it 
myself. But as far as triggerEvents() vs. triggerAllEvents(), changing 
between them will definately change Ruby's functionality. Specifically, 
triggerAllEvents() would essentially cause all outstanding accesses to 
complete... at which time Ruby would have no remaining events. 
triggerEvents(current+1000) *may* do the same thing, but, depending on 
latencies, contention, etc., may leave some requests only partially 
completed.
Regards,
Dan

Daniele Bordes wrote:

> Hi all. I'm using tester.exec to perform trace driven simulations, and
> I have a question: after all references in the trace file have been
> read and a void line is found in the file by the tracer, are all the
> events generated by the last reference processed or does the
> simulation end without processing some of the events?
>
> I have this doubts because I don't understand some ruby output
> statistics about DNUCA_L2CACHE hits, misses, allocations and
> promotions.
>
> Another question:
>
> Do I introduce a bug or problems if in function
> "Tracer::playbackTrace" I substitute the function call:
>
> g_eventQueue_ptr->triggerEvents(g_eventQueue_ptr->getTime() + 1000);
> // FIXME - should be smarter
>
> with:
>
> g_eventQueue_ptr->triggerAllEvents()
>
> ?
>
> Sorry if I am a nuisance.
> Thank you all very much.
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>
>
>