Menu
▾
▴
Re: [GridSim-users] Fwd: WWG Testbed
|
From: Marcos D. de A. <mar...@gm...> - 2010-04-02 07:51:30
|
Hi Maria,
I'm sorry for the delay in answering your message, but things have been
a little hectic here.
> About the difference time between the cpu time, I think it is a bug,
but I don´t understand why? because the two gridlets sends the
> intervalevent at its time and the response had to be different if
they sent it at different time...
I'm not sure if my explanation was clear. What I meant to say is that
the SpaceShared policy does the following:
1 - Receives Gridlet1, and schedules an internal event (after 4.0
seconds) to update the processing of Gridlets and check which gridlets
have finished. Let's call the internal event "event1".
2 - Receives Gridlet2, and schedules an internal event (after 4.0
seconds) to update the processing of Gridlets and check which gridlets
have finished. Let's call this event "event2".
3 - The policy receives event1, updates the processing of Gridlets and
realises that both Gridlet1 and Gridlet2 finished. Then it gets the
current simulation time to calculate the CPU time of both Gridlets. The
problem here is: Gridlet1 will have CPU time of 4.0, but Gridlet2 will
have a smaller CPU time because the actual event that marks its finish
time would come some time later.
4 - The policy receives event2, updates the processing of Gridles and
does nothing, because Gridlet2 that initially triggered this event is no
longer there; it finished in the previous event.
And yes, we can call it a bug. I think you can use the TimeShared policy
for what you need, but I'm afraid I can't help you with that because I
have never used the TimeShared policy myself. I'm copying your message
to the list, so people might help you.
Cheers,
Marcos
Maria Arsuaga wrote:
> Hi Marcos,
>
> Thanks a lot!! You are right about the submission time, it is because
> I put a 0.1 delay for the connection between routers, so I think it is
> the difference.
>
> About the difference time between the cpu time, I think it is a bug,
> but I don´t understand why? because the two gridlets sends the
> intervalevent at its time and the response had to be different if they
> sent it at different time...
>
> The Space-Shared I think is not important in this case, because there
> are just one PE per Machine, and the Space-Shared affects when there
> are more than one PE isn´t?
>
> How can I handle this problem? Because I just need the cpu time and I
> not want this affect to the finishTime...
>
> Thanks again, because your explanations help me.
>
> 2010/3/31 Marcos Dias de Assuncao <mar...@gm...
> <mailto:mar...@gm...>>
>
>
> Hi Maria,
>
> I'm no longer at the University of Melbourne, hence you can
> contact me on this gmail address because the other account should
> be cancelled soon.
>
> About the SpaceShared policy, the internal event is scheduled for
> the policy to know that it needs to check which gridlets have
> completed at that given time. The rounding is done probably
> because the simulation time is a double and I remember that
> whoever coded GridSim at the start had a few issues when comparing
> doubles. I particularly don't like the simulation time as a double
> and for my simulations during my PhD I changed everything to longs
> and didn't make such kind of rounding.
>
> If you look at that submission times of the Gridlets, you will
> notice that they arrive at the resource at different times.
> Something is delaying them, probably the input and output ports of
> the resource simulating the network. Then, what happens in my
> opinion is that one internal event is scheduled for Gridlet1 (to
> be received in 4.0 seconds) and another a little later for
> Gridlet2. When an internal event is received, the policy updates
> the processing of Gridlets (i.e. how much of them has already been
> executed). When the internal event for Gridlet1 is handled, and
> the policy updates the processing of Gridlets, it identifies that
> both Gridlet1 and Gridlet2 have 0 MIs left to be executed and thus
> considers both as completed. In this case the first takes 4
> seconds to execute and the second a little less. I know that it is
> not a result that one would expect, and I suppose we can call it a
> bug.
>
> Also, you need to be careful with the SpaceShared policy because
> it tries to simulate the load of a resource in addition to the
> scheduling, something that comes from Raj's thesis. As I said, for
> my simulations I was not happy with this behaviour and implemented
> my all resource allocation policies. I have incorporated some of
> them in the latest version of GridSim, in the gridsim.parallel
> package.
>
> I hope it helps you.
>
> Regards,
>
> Marcos
>
>
> Maria Arsuaga wrote:
>
> Hi Marcos,
>
> I have a problem to understand the cpu execution time:
>
> The problem is in this part of the code (Space-Shared.java;
> method: allocatePEtoGridlet()):
> // Identify Completion Time and Set Interrupt
> int rating = machineRating_[ rgl.getMachineID() ];
> double time = forecastFinishTime( rating ,
>
> rgl.getRemainingGridletLength() );
>
> * int roundUpTime = (int) (time+1)*; // rounding up
> rgl.setFinishTime(roundUpTime);
>
> // then send this into itself
> * super.sendInternalEvent(roundUpTime);*
> return true;
> }
>
> 1. Why you add 1? And the forecasting calculate MI/MIPS, so
> for each job is the same 3.0
> And adding one is 4.0.
>
> 2. Then it sends an internal event to simulate this time,
> that´s ok.
>
> And when the gridletFinalize and changes the status
> (ResGridlet.java; method: setGridletStatus())
>
> // if a previous Gridlet status is INEXEC
> if (prevStatus == Gridlet.INEXEC)
> {
> // and current status is either CANCELED,
> PAUSED or SUCCESS
> if (status == Gridlet.CANCELED || status ==
> Gridlet.PAUSED ||
> status == Gridlet.SUCCESS)
> {
> // then update the
> Gridlet completion time
> * totalCompletionTime_ += (clock -
> startExecTime_);*
> index_ = 0;
> return true;
> }
> }
>
> 3. The totalCompletionTime is not the same like *4.0 +
> StartExecTime_* if not *is clock -startExecTime_*.
>
> The problem here is that sometimes the cpu time is different
> and always in the second job, please see below.
> Why this happen?
>
> Asumming the jobs are the same 1000 MI, 0 File_size, 0 Output_size
> I have 1 Resource with 2 Machines, each one with 1 PE with 500
> MIPS.
>
> UserID | GridLetID | Status | Resource ID | GL_SubmissionTime
> | GL_StartTime | Gl_FinishTime | GL_actualCPUtime |
> GL_WallClockTime | Resource Name
> User_0 | 0 | Success | 6 | 486.0259999999999 |
> 486.0259999999999 | 490.0259999999999 | *4.0* | 4.0 |
> Resource_LYON
> User_0 | 1 | Success | 6 | 486.16885714285706 |
> 486.16885714285706 | 490.0259999999999 | *3.857142857142833* |
> 3.857142857142833 | Resource_LYON
> User_0 | 2 | Success | 6 | 486.31171428571423 |
> 490.0259999999999 | 494.0259999999999 |* 4.0* |
> 7.714285714285666 | Resource_LYON
> User_0 | 3 | Success | 6 | 486.4545714285714 |
> 490.0259999999999 | 494.0259999999999 | *4.0* |
> 7.571428571428498 | Resource_LYON
>
> Thanks a lot!
>
>
> 2010/3/30 Saurabh Kumar GARG <sg...@cs...
> <mailto:sg...@cs...>
> <mailto:sg...@cs...
> <mailto:sg...@cs...>>>
>
>
> Hi Maria
>
> Arrival time should depend on the submission time of the
> gridlet.
> thus, if
> submission times are different, arrival time will also vary.
> regarding cpu_time, please check the configuration of the
> resources. It seems
> the gridlet are submitted to CPU with different configuration.
>
>
> saurabh
>
> n Tue, 30 Mar 2010 17:03:25 +0200, Maria Arsuaga wrote
> > Dear Saurabh Kumar Garg,
> >
> > I have some questions about my simulation in GridSim.
> >
> > This is my output:
> >
> ---------------------------------------------------------------
> > Broker_User_0 *send_time gridlet 0 time 485.59582857142846*
> >
> > Gridlet 0 on resourceResource_LYON
> > Broker_User_0 *send_time gridlet 1 time 485.59582857142846*
> > Gridlet 1 on resourceResource_LYON
> > Broker_User_0 *send_time gridlet 2 time 485.59582857142846*
> >
> > Gridlet 2 on resourceResource_LYON
> >
> > *
> > Gridlet 0 arrival_time 699.8876428571427
> > Gridlet 1 arrival_time 771.3162142857142
> > Gridlet 2 arrival_time 842.7447857142856*
> >
> > User_0:: Experiment Schedule
> > -----------------------------------------
> > UserID | GridLetID | Status | Resource ID |
> GL_SubmissionTime |
> GL_StartTime
> > | Gl_FinishTime | GL_actualCPUtime | GL_WallClockTime |
> Resource
> Name
> >
> > User_0 | 0 | Success | 6 | *699.8876428571427* |
> 699.8876428571427 |
> > 4319.887642857143 | *3620.0* | 3620.0 | Resource_LYON
> >
> > User_0 | 1 | Success | 6 | *771.3162142857142* |
> 771.3162142857142 |
> > 4319.887642857143 | *3548.571428571429* | 3548.571428571429 |
> Resource_LYON
> >
> > User_0 | 2 | Success | 6 |* 842.7447857142856* |
> 4319.887642857143 |
> > 7919.887642857143 | 3600.0 | 7077.142857142857 |
> Resource_LYON
> >
>
> -------------------------------------------------------------------------------------------------------
> >
> > Questions:
> >
> > 1. Why the arrival_time is different from all the
> gridlets? Is
> it because
> > the Resource just receive one gridlet at time?
> >
> > 2. Why the GL_actualCPUtime (execution time) is different for
> each gridlet
> > if the gridlets are the same? Why always the two first
> gridlets
> > finisht at the same time, when they start the execution
> at different
> > time?
> >
> > Thanks a lot!
> >
> > --
> > María Arsuaga Ríos
>
>
> --
> Saurabh kumar Garg
> Computer Science and Software Engineering
> The University of Melbourne
> Australia
>
>
>
>
> --
> María Arsuaga Ríos
>
>
>
> --
> María Arsuaga Ríos
>
>
>
> --
> Marcos DIAS DE ASSUNCAO - Postdoctoral researcher
> INRIA RESO - LIP Bureau 337, Ecole Normale Superieure
> 46, allee d'Italie - 69364 - Lyon Cedex 07 - France
> Phone: +33 4 72 72 82 28
>
>
>
>
> --
> María Arsuaga Ríos
--
Marcos DIAS DE ASSUNCAO - Postdoctoral researcher
INRIA RESO - LIP Bureau 337, Ecole Normale Superieure
46, allee d'Italie - 69364 - Lyon Cedex 07 - France
Phone: +33 4 72 72 82 28
|
