[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: floating point time scheduling
From: |
Andre Costa |
Subject: |
Re: floating point time scheduling |
Date: |
Fri, 24 Nov 2000 16:19:00 +1030 (CST) |
Hi all,
Marcus Daniels wrote:
> > pjrepeater4 exercises the setSynchronizationType method for a Swarm.
> > (The default synchronization policy is to run co-occuring merged events
> > in the order they were called during activateIn.)
> >
> > Perhaps the easiest way to get what you want is just to have a single shared
> > schedule configured with the secondary concurrent schedule for the
> > fractional
> > parts.
Paul Johnson wrote:
> In that pjrepeater series, there was one that had the swarms in a swarm
> example, each with its own schedule. I did some time trials and found
> the model ran faster with just the master schedule in the higher swarm
> and the lower level things added their actions to the bigger swarm's
> schedule (dynamic scheduling). In other words, I think Marcus is
> correct.
Yes, thanks. This is infact what I have ended up doing.
It is actually what i have always done in the past with my models,
My departure from the the usual was due to two separate needs:
1) the desire to use the <DoubleSchedule.java> method to schedule
fractional-time events, rather than a cruder method I had used earlier
without the use of ConcurrentSchedules and so forth,
and at the same time to satisfy
2) the desire to write the simulation with each component of the model
having its own schedule, purely for the sake of having it conceptually
closer to a "decentralized" system. This was infact following the
philosophy espoused by Marcus (and Alex?) in writing the SDG simulation
as example code for the SFI Summer School; the agents have their
own schedule rather than being scheduled to act by the Organization
(the SDG).
Clearly all the scheduling is ultimately centralized on a serial
processor, so this conceptually-inspired appraoch is of no great
importance until multi-agent simulations are actually run
with appropriate true parallel processors...
And, as Paul points out, it is much faster and simpler to schedule events
dynamically via the ModelSwarm ! I have a deadline coming up so I'm doing
it the easy way !
Andre.
---------------------------------------------------------------------
Andre Costa
Research Student
Teletraffic Research Centre Telephone: (08) 8303 3237
Department of Applied Mathematics Fax: (08) 8303 4395
University of Adelaide Email:address@hidden
South Australia 5005
----------------------------------------------------------------------
==================================
Swarm-Support is for discussion of the technical details of the day
to day usage of Swarm. For list administration needs (esp.
[un]subscribing), please send a message to <address@hidden>
with "help" in the body of the message.
- floating point time scheduling, (continued)
- floating point time scheduling, Andre Costa, 2000/11/13
- Re: floating point time scheduling, Marcus G. Daniels, 2000/11/22
- Re: floating point time scheduling, Andre Costa, 2000/11/22
- Re: floating point time scheduling, Marcus G. Daniels, 2000/11/22
- Re: floating point time scheduling, Paul E Johnson, 2000/11/24
- Re: floating point time scheduling, Marcus G. Daniels, 2000/11/24
- Re: floating point time scheduling,
Andre Costa <=
- Re: floating point time scheduling, Marcus G. Daniels, 2000/11/22