Review Board 2.0.15


NetworkTest: added sim_cycles parameter to the network tester.

Review Request #660 - Created April 25, 2011 and submitted

Information
Tushar Krishna
gem5
default
Reviewers
Default
ali, beckmann, gblack, nate, stever 
NetworkTest: added sim_cycles parameter to the network tester.

The network tester terminates after injecting for sim_cycles
(default=1000), instead of having to explicitly pass --maxtick from the
command line as before. If fixed_pkts is enabled, the tester stops
scheduling itself after injecting maxpackets number of packets.
The tester also works with zero command line arguments now.

   

  


 


 

  

  









  
 


  

 


















 

  


 


  




   
Ship it!



   

   
Brad Beckmann

   
Posted  (April 27, 2011, 9:28 a.m.)


  


  


  

   
This looks good to me, though it does appear to be a combination of a bug fix and the added sim_cycle parameter.  However, I understand why they are related so I don't think it is necessary to split them.



  

   

   
    
    
   


  





  

 


  

 

















 



 

  


 


  



   

   
Tushar Krishna

   
Posted  (April 29, 2011, 8:27 a.m.)


  


  


  

   



  

   

   
    
    
   


  




   







    

     
     
    

    


     
Hey Brad,
One concern that I have with my current implementation here is that if --fixed-pkts is enabled, then the tester is not scheduled after injecting maxPackets. 
Once all packets are delivered (=> no more events from the network side as well), there is no agent to call exitSimLoop to end the simulation, so it ends at m5's max tick (9223372036854775807) cycles. This does not slow down the simulation (since there are no events after all delivery), and is ok. But it does screw up the power stats etc which use Ruby_cycles, and sort of looks ugly since m5 prints out that the simulation ended after 9223372036854775807 cycles.

One option is to end the simulation as soon as the tester injects maxPackets, but that wont result in all packets getting delivered, defeating the purpose of fixed-pkts which I added for network debugging.

The other option is to keep scheduling the tester till simCycles, but simply stopping the generation of packets after maxPackets (this was what I was doing earlier). But this requires the simCycles input to be greater than the time by which all packets are expected to be injected (which depends upon maxPackets and injection rate).

[Unlike the ruby random tester, the tester here does not track anything to determine when everything is delivered].

Any suggestions?

Thanks,
Tushar




  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    I don't think there is an easy way to support the fixed-pkts option based on the current NetworkTest implementation.  Ending the simulation as soon as the tester injects maxPackets seems likek the only reasonable thing to do.  Unless we can remove the fixed-pkts option all together.  The other options seem like brittle hacks.

If you want to spend a bit more time on it, I suspect we could provide the directory a pointer to the NetworkTest object and have the directory call say a NetworkTest.finish() function.
    
    
    
   
    2.