gridsim-developers

[GridSim-developers] Problems with Gridlet cancellation and some questions

[Marcos D. de A. <ma...@cs...>]

Dear All,

Firstly, I would like to know if someone has used the gridlet
cancellation capabilities of GridSim? Secondly, I would like to
mention a few things about the gridletCancel() methods in the
allocation policy classes. It seems that at no point the Gridlet
status is changed to CANCELED. The method sendCancelGridlet() of the
AllocPolicy class contains:

[=85]
long gridletSize =3D 0;
        if (gl !=3D null) {
            gridletSize =3D gl.getGridletOutputSize();
        }
[=85]
super.sim_schedule( outputPort_, GridSimTags.SCHEDULE_NOW, tag,
                            new IO_data(gl, gridletSize, destId) );

Which means that the status of the Gridlet is not changed and that the
gridlet is sent back to the user when cancelled. The number of bytes
transmitted is in fact the size of the output files. That means that
even if the Gridlet is cancelled, it is actually not cancelled and the
number of bytes sent back to the sender is equals to the number of
bytes that would be sent if the Gridlet had been completed.

My questions are regarding the advance reservation features. I know
that GridSim uses a resource calendar and some estimates of local
load. It uses this to get information about days of the week and
respective local load. However, I am wondering and intrigued, why do
we need time zones particularly in advance reservations? If this is a
policy related issue, for example, a resource provider accepts advance
reservations on Mondays? Still, I am not sure whether we need the time
zone information in classes like ARObject. GridSim, as any event
driven simulator uses a simulation clock. All entities schedule events
based on this clock. Therefore, why do we need to convert times
between time zones? I would be grateful if anybody could explain to me
the design decisions that have led to the adoption of time zones in
the advance reservation framework.

Regards,

Marcos


--=20
Marcos Dias de Assuncao
Grid Computing and Distributed Systems (GRIDS) Laboratory
Department of Computer Science and Software Engineering
The University of Melbourne, Australia
Email: ma...@cs...

Re: [GridSim-developers] Problems with Gridlet cancellation and some questions

[Anthony S. <an...@cs...>]

> It seems that at no point the Gridlet status is changed to CANCELED.

See SpaceShared.java  line 754 or TimeShared.java line 770:

// if a Gridlet is finished upon cancelling, then set it to success
// instead.
if (rgl.getRemainingGridletLength() == 0.0) {
     rgl.setGridletStatus(Gridlet.SUCCESS);
}
else {
     rgl.setGridletStatus(Gridlet.CANCELED);
}


See the output from Example7 of Test Case 8.
It shows Gridlet #2 has been cancelled.


============= OUTPUT for User_1 ==========
Gridlet ID    STATUS    Resource ID    Cost
     2        Canceled        11        435.12199999999984
     0        Success        7        405.0544
     1        Success        11        1008.9780000000001
     3        Success        7        1200.0


> why do we need time zones particularly in advance reservations?
> Therefore, why do we need to convert times
> between time zones?

the time used by the AR scheduler is the absolute time not relative.
See ARPolicy.java line 4995:

protected long getCurrentTime() {
     return initTime_ + (int) (GridSim.clock() * MILLI_SEC);
}

where initTime_ = Calendar.getInstance().getTimeInMillis()
when you call GridSim.init() method +/- resource time zone.

See AllocPolicy#init() method line 359:

         // looking at the init simulation time
         Calendar calendar = GridSim.getSimulationCalendar();
         long simTime = calendar.getTimeInMillis();
         int simTimeZone = calendar.getTimeZone().getRawOffset() /
                           AdvanceReservation.HOUR;

         // then convert into the local resource time
         initTime_ = AdvanceReservation.convertTimeZone( simTime,
                            simTimeZone,
                            resource_.getResourceTimeZone() );


When you have entities (resources or users) with different time zones,
then the time will be different.

regards,
anthony

Re: [GridSim-developers] Problems with Gridlet cancellation and some questions

[Marcos D. de A. <ma...@cs...>]

Thanks for the prompt reply. I hadn't looked carefully the SpaceShared policy.

Regarding the time zones, the providers having time zones is ok.
However, I still do not understand why all those conversions are
needed since in the end everything is related to the simulation clock.
But never mind that, I will just discard these conversions in my work.

Regards,

Marcos


On 24/09/2007, Anthony Sulistio <an...@cs...> wrote:
>
>
> > It seems that at no point the Gridlet status is changed to CANCELED.
>
> See SpaceShared.java  line 754 or TimeShared.java line 770:
>
> // if a Gridlet is finished upon cancelling, then set it to success
> // instead.
> if (rgl.getRemainingGridletLength() == 0.0) {
>      rgl.setGridletStatus(Gridlet.SUCCESS);
> }
> else {
>      rgl.setGridletStatus(Gridlet.CANCELED);
> }
>
>
> See the output from Example7 of Test Case 8.
> It shows Gridlet #2 has been cancelled.
>
>
> ============= OUTPUT for User_1 ==========
> Gridlet ID    STATUS    Resource ID    Cost
>      2        Canceled        11        435.12199999999984
>      0        Success        7        405.0544
>      1        Success        11        1008.9780000000001
>      3        Success        7        1200.0
>
>
> > why do we need time zones particularly in advance reservations?
> > Therefore, why do we need to convert times
> > between time zones?
>
> the time used by the AR scheduler is the absolute time not relative.
> See ARPolicy.java line 4995:
>
> protected long getCurrentTime() {
>      return initTime_ + (int) (GridSim.clock() * MILLI_SEC);
> }
>
> where initTime_ = Calendar.getInstance().getTimeInMillis()
> when you call GridSim.init() method +/- resource time zone.
>
> See AllocPolicy#init() method line 359:
>
>          // looking at the init simulation time
>          Calendar calendar = GridSim.getSimulationCalendar();
>          long simTime = calendar.getTimeInMillis();
>          int simTimeZone = calendar.getTimeZone().getRawOffset() /
>                            AdvanceReservation.HOUR;
>
>          // then convert into the local resource time
>          initTime_ = AdvanceReservation.convertTimeZone( simTime,
>                             simTimeZone,
>                             resource_.getResourceTimeZone() );
>
>
> When you have entities (resources or users) with different time zones,
> then the time will be different.
>
> regards,
>
> anthony
>


-- 
Marcos Dias de Assuncao
Grid Computing and Distributed Systems (GRIDS) Laboratory
Department of Computer Science and Software Engineering
The University of Melbourne, Australia
Email: ma...@cs...

Re: [GridSim-developers] Problems with Gridlet cancellation and some questions

[Anthony S. <an...@cs...>]

> However, I still do not understand why all those conversions are
> needed since in the end everything is related to the simulation clock.

true that everything is related to the simulation clock,
but the time zone does matter !

For example, the resource is in UTC+10 and the user is in UTC+5
and init time is 05:00:00 (UTC+0) for simplicity.
At the start of simulation, resource time is 15:00:00 and
user time is 00:00:00

If the user submits at GridSim.clock() = 1 hour and
NO time zone conversion, then the resource thinks
the current time is 01:00:00, i.e. user init time + GridSim.clock(),
which is already expired. This is because the ARObject only stores
the user current time and the user has no idea about
the resource time zone is.


regards,
anthony

Re: [GridSim-developers] Problems with Gridlet cancellation and some questions

[Anthony S. <an...@cs...>]

> For example, the resource is in UTC+10 and the user is in UTC+5


oops, the user time zone should be UTC -5.


anthony

Re: [GridSim-developers] Problems with Gridlet cancellation and some questions

[Marcos D. de A. <ma...@cs...>]

Hi Anthony,

thanks for your email. I just want to understand to check if I am not
doing anything wrong by ignoring the conversions.

> For example, the resource is in UTC+10 and the user is in UTC+5
> and init time is 05:00:00 (UTC+0) for simplicity.
> At the start of simulation, resource time is 15:00:00 and
> user time is 00:00:00

> If the user submits at GridSim.clock() = 1 hour and
> NO time zone conversion, then the resource thinks
> the current time is 01:00:00, i.e. user init time + GridSim.clock(),
> which is already expired. This is because the ARObject only stores
> the user current time and the user has no idea about
> the resource time zone is.

I do agree that in a real distributed application the time zones have
to be handled. However, in the simulation, the user will make a
reservation request relative to the simulation clock (in seconds). The
provider will abide to the same clock to check whether it accepts or
rejects the request (in seconds). If a user requests 5 PEs at
simulation time 60 sec. for 1 hour, then the provider will check if
there are 5 PEs available at simulation time 60 sec. for one hour. The
ARObject may handle the times as doubles reflecting the simulation
clock. I do not see the need for time zone here.

However, let's suppose that the provider has a policy that states that
resources may not be reserved on Mondays. The provider has information
in which time zone it is. In this case I see the need for converting
the 60 sec. simulation time to the provider's time zone to check
whether it is a Monday or not. Apart from cases like this one, I do
not see a clear reason for using relative times. I may be wrong.

Regards,

Marcos


-- 
Marcos Dias de Assuncao
Grid Computing and Distributed Systems (GRIDS) Laboratory
Department of Computer Science and Software Engineering
The University of Melbourne, Australia
Email: ma...@cs...