Distributed time-management can be problematic for scaling. There are solutions for it. They involve structuring communication so time management can be performed locally and incrementally rather than as a global pass. Lightweight time warp protocol does this with a little hierarchy. My reactive demand programming model manages time point-to-point (part of managing signal updates) in order to remain scalable, but hasn't been validated in practice yet.
Time warp protocol (~1985) was also designed for parallel and distributed simulations. It uses optimistic parallelism with rollback when a message occurs out of order. But time warp was not really designed for interactive simulations where intermediate results might be observed and action might be taken by an agent outside the protocol, more for scientific computing. Lightweight time warp (~2009) is far more suitable for interactive systems, though still not designed for real-time interaction. HLA sounds pretty big, and I'm not familiar with any of it. I don't know whether the right solutions for time management scalability issues would conflict with some other mandate in HLA. >From what you say, the architects of HLA did see the problems with naive time management... but, rather than solving the problems architecturally, they simply provided a bunch of configuration options of dubious benefit then called it `your` problem. Unfortunately, that sounds like situation normal to me. Regards, Dave On Mon, Apr 9, 2012 at 11:29 AM, Miles Fidelman <[email protected]>wrote: > David Barbour wrote: > >> Going back to this post (to avoid distraction), I note that >> >> Aggregate Level Simulation Protocol >> and its successor >> High Level Architecture >> >> Both provide "time management" to achieve consistency, i.e. "so that the >> times for all simulations appear the same to users and so that event >> causality is maintained – events should occur in the same sequence in all >> simulations." >> > > and Alan Kay wrote: > > Yes "time management" is a good idea. >> >> Looking at the documentation here I see no mention of the (likely) >> inventor of the idea -- John McCarthy ca 1962-3, or the most adventurous >> early design to actually use the idea (outside of AI robots/agents work) -- >> David Reed in his 1978 MIT thesis "A Network Operating System". >> >> Viewpoints implemented a strong "real-time enough" version of Reed's >> ideas about 10 years ago -- "Croquet" >> >> The ALSP blurb on Wikipedia does mention the PARC Pup Protocol and >> Netword (the "Internet" before the Internet). >> > > Actually, last time I looked (admittedly about 4 years, when I last worked > for a firm that sold low-level libraries for simulation protocols, both DIS > and HLA), larger network sims (e.g., the Air Force's Distributed Mission > Training net) used DIS (Distributed Internet Simulation) rather than HLA. > > The DIS protocol is essentially distributed information stuffed into > multi-cast UDP packets. HLA is a an object oriented middleware - basic > model is that objects are replicated across sims, with background protocols > keeping those copies in sync - essentially publish-subscribe applied to > replicated objects. As I remember, HLA just proves to complicated and > injects too much overhead as the number of players on the net grows. > > As I recall, DIS PDUs contain time stamps referenced to exercise time, > which is generally synchronized with GPS time. Part of the problem with > using HLA for larger sims has to do with time synchronization, particularly > if using the time management service for synchronization (one now has to > wait for the time management events to traverse the network) - and there > are also various options the different simulators can/do use for > synchronizing with exercise time. It all becomes a management nightmare. > Lots of papers on the topic, though. > > Miles > > > > > > > > > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > ______________________________**_________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/**listinfo/fonc<http://vpri.org/mailman/listinfo/fonc> > -- bringing s-words to a pen fight
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
