synchronize a "mocked" clock in a distributed system
in [Ruby]
|
Prev: [Q] synchronize a "mocked" clock in a distributed system
Next: [ANN] SmartImage 0.0.3 - simple yet powerful cross-platformthumbnail generation and image manipulation in Ruby
From: Robert Klemme on 1 Jul 2010 18:05 On 01.07.2010 23:10, Chuck Remes wrote: > My problem is mocking out the time source so that I can run > simulations in faster than real-time. For example, I may send a > request for a data record and give it a 5 second timeout. This works > fine when the clock source is the actual operating system, but if I > want to run faster than real-time I need to mock the clock out. That > is, I want to take a simulation that might run in 4 hours real-time > (with lots of waiting or other timer related delays) to run in 20 > minutes because 1 second of simulation time is only a fraction of a > second in the real world. > > This is simple to do for a single component on a single system > because I can intercept all calls to Time and replace it with my own > source. However, I don't know how to get all of the distributed > components (across multiple machines or multiple processes on one > machine) to use a mocked clock. > > I tried googling around for answers, but all of the papers appear to > be concerned with adjusting clock skew across a network where each > device already has a local time source. I don't know if those > solutions apply here. > > Anyone have any bright ideas? Need more information? A very simplistic solution would be to use DRb and have a centralized clock. Depending on the number of clients this may of course turn out as a bottleneck. In that case you would have to devise a more complex mechanism. Maybe looking at time protocols such as NTP might give you some inspiration. Basically you want to solve the same problem, just with a different time source (I don't think that a mocked NTP server will work because that needs local clocks with a particular precision. Another option might be UDP broadcast with the "current time" - if network latency as precision is good enough. If not, again you need a more complex mechanism (see time protocols). Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
From: Tony Arcieri on 1 Jul 2010 19:43 [Note: parts of this message were removed to make it a legal post.] On Thu, Jul 1, 2010 at 3:10 PM, Chuck Remes <cremes.devlist(a)mac.com> wrote: > The entire system is akin to a distributed state machine. I poke a command > into it from the outside and it sets off a cascade of events which in turn > generate more events until eventually I have my answer. Some the events have > timeouts or other time-based characteristics associated with them. Also, > some of the returned data has time-based characteristics (e.g. a timestamp) > which impacts the transitioning of the state machine. It's all working quite > nicely in real-time. > > My problem is mocking out the time source so that I can run simulations in > faster than real-time. For example, I may send a request for a data record > and give it a 5 second timeout. This works fine when the clock source is the > actual operating system, but if I want to run faster than real-time I need > to mock the clock out. That is, I want to take a simulation that might run > in 4 hours real-time (with lots of waiting or other timer related delays) to > run in 20 minutes because 1 second of simulation time is only a fraction of > a second in the real world. It sounds like the way you've written your program is time-dependent, or as ChucK (the music language) would describe it "strongly timed" Right off the bat my initial advice would be to eliminate the need for a central clock in your system and make it fully asynchronous. Creating "strongly timed" synchronized distributed systems is rather non-trivial. -- Tony Arcieri Medioh! A Kudelski Brand
From: Chuck Remes on 2 Jul 2010 12:40 On Jul 1, 2010, at 6:43 PM, Tony Arcieri wrote: > It sounds like the way you've written your program is time-dependent, or as > ChucK (the music language) would describe it "strongly timed" > > Right off the bat my initial advice would be to eliminate the need for a > central clock in your system and make it fully asynchronous. Creating > "strongly timed" synchronized distributed systems is rather non-trivial. Yes, I suppose it is strongly timed. I didn't realize that was going to be such a problem. Right now it is completely asynchronous when running across multiple nodes. Each machine's clock is NTP synched so it just does the "right thing" when it runs in real-time. This notion of strongly timed doesn't rear its *ugly* head until I try to replace the clock. I'm going to try to broadcast a clock pulse or heartbeat to all components. I can set it up so that each component uses the real clock when no clock pulse message has been received but switch over to the mocked clock when it sees the first clock message. Hopefully the delivery latencies don't cause too much trouble by skewing the time between components. I'll try it and see. Thanks to all for the suggestions. cr
From: Robert Dober on 3 Jul 2010 06:07 On Fri, Jul 2, 2010 at 12:10 AM, Robert Klemme <shortcutter(a)googlemail.com> wrote: <snip> > A very simplistic solution would be to use DRb and have a centralized clock. > Depending on the number of clients this may of course turn out as a > bottleneck. In that case you would have to devise a more complex mechanism. Hmm would a messaging based time mocking server be faster? I say that because that was my idea but I feel that Drb is easier to integrate. Cheers R -- The best way to predict the future is to invent it. -- Alan Kay
From: William Rutiser on 5 Jul 2010 13:44
Chuck Remes wrote: > On Jul 1, 2010, at 6:43 PM, Tony Arcieri wrote: > > >> It sounds like the way you've written your program is time-dependent, or as >> ChucK (the music language) would describe it "strongly timed" >> >> Right off the bat my initial advice would be to eliminate the need for a >> central clock in your system and make it fully asynchronous. Creating >> "strongly timed" synchronized distributed systems is rather non-trivial. >> > > Yes, I suppose it is strongly timed. I didn't realize that was going to be such a problem. > > Right now it is completely asynchronous when running across multiple nodes. Each machine's clock is NTP synched so it just does the "right thing" when it runs in real-time. This notion of strongly timed doesn't rear its *ugly* head until I try to replace the clock. > > I'm going to try to broadcast a clock pulse or heartbeat to all components. I can set it up so that each component uses the real clock when no clock pulse message has been received but switch over to the mocked clock when it sees the first clock message. Hopefully the delivery latencies don't cause too much trouble by skewing the time between components. > > I'll try it and see. Thanks to all for the suggestions. > > cr > > Could you setup a mock NTP time source that supplies "fast" time to its clients then configure each machine to use the mock NTP and update very frequently? This may not be practical and would certainly not work if the machines are being used for anything except your tests. |