[vwnc] Anyone having problems with Delays?

On Thu, Aug 14, 2008 at 4:49 PM, cstb <[hidden email]> wrote:
[snip]

 You actually need 3 distinct clocks

 to always get the right results:

 1) upTime

 2) wallTime

 3) elapsedWallTime

[snip]

I think this analysis is almost right.

I think you need two clocks.

I think I'm right that UTC does...

...that UTC does not change
except for leap seconds and then only increases,
so there are occasionally second duration jumps forward;
there are never two adjacent seconds
that have the same second count in UTC.

So at least terrestrially
UTC can be used for wall time,

and a non-adjusting clock
that starts with current UTC
and doesn't adjust with leap seconds
can provide up-time and duration.

Hence the vw7.x clock

which is UTC microseconds from 1901 in 64 bits which wraps after 57k years.
Further, if the system can adjust UTC with leap-seconds without missing delays
(i.e. spotting delays which expire within a leap second) you only need one clock.

Since there is only ever zero or one delay in effect
when adjusting for leap seconds this can't be that hard to do.

This applies at least terrestrially where UTC provides a locally absolute clock.

Tell me!

Chris Winemiller escreveu:
[snipped]

  

Nice in theory, but not in practice.  This is the fundamental flaw of 
7.x's implementation.  Computer times *do* drift, and are periodically 
corrected forward or backward by a command from some kind of time 
provider (may or may not be NTP).  By tying duration Delays to the 
computer's "absolute" (but drifting) time, 7.x completely broke duration 
Delays.  They break when the time corrections occur.
    

Chris,

I'm a bit confused right now.

For what time span are you considering the delays you need to implement?
  

On Wed, Aug 20, 2008 at 6:31 AM, Chris Winemiller <[hidden email]> wrote:

Cesar Rabak wrote:

Chris Winemiller escreveu:
[snipped]

  

Nice in theory, but not in practice.  This is the fundamental flaw of 
7.x's implementation.  Computer times *do* drift, and are periodically 
corrected forward or backward by a command from some kind of time 
provider (may or may not be NTP).  By tying duration Delays to the 
computer's "absolute" (but drifting) time, 7.x completely broke duration 
Delays.  They break when the time corrections occur.
    

Chris,

I'm a bit confused right now.

For what time span are you considering the delays you need to implement?
  

The spans do not matter but, for the record, anywhere from a few seconds to perhaps a few minutes.  And the spans are not predetermined; they are dictated by customer-created "recipes" that the application must execute.

Why do you think the span matters?  If the Delay governs the length of time of a recipe step, altering that Delay's duration by even a few seconds can change the step time by 20%, 50%, 75%, or whatever.  And that is enough to ruin a product whose current value can be as much as a million dollars.

Chris, are you running on windows?  If so, what happens if you run with -walltime?  As has been pointed out to me by Andreas Raab the high-performance counter on modern CPUs is no longer constant frequency.  On-chip cpu power-management will alter the frequency of the HPC and make it entirely unsuitable as the basis for the clock, something that didn't happen back in the day.

Eliot Miranda wrote:

On Wed, Aug 20, 2008 at 6:31 AM, Chris Winemiller <[hidden email]> wrote:

Cesar Rabak wrote:

Chris Winemiller escreveu:
[snipped]

  

Nice in theory, but not in practice.  This is the fundamental flaw of 
7.x's implementation.  Computer times *do* drift, and are periodically 
corrected forward or backward by a command from some kind of time 
provider (may or may not be NTP).  By tying duration Delays to the 
computer's "absolute" (but drifting) time, 7.x completely broke duration 
Delays.  They break when the time corrections occur.
    

Chris,

I'm a bit confused right now.

For what time span are you considering the delays you need to implement?
  

The spans do not matter but, for the record, anywhere from a few seconds to perhaps a few minutes.  And the spans are not predetermined; they are dictated by customer-created "recipes" that the application must execute.

Why do you think the span matters?  If the Delay governs the length of time of a recipe step, altering that Delay's duration by even a few seconds can change the step time by 20%, 50%, 75%, or whatever.  And that is enough to ruin a product whose current value can be as much as a million dollars.

Chris, are you running on windows?  If so, what happens if you run with -walltime?  As has been pointed out to me by Andreas Raab the high-performance counter on modern CPUs is no longer constant frequency.  On-chip cpu power-management will alter the frequency of the HPC and make it entirely unsuitable as the basis for the clock, something that didn't happen back in the day.

I have not tried -walltime.  But it won't be adequate anyway because our product is a mult-image application, and only some of those images run on Windows.  We also have other VW-based products that customers typically run on a Unix flavor.  We need a cross-platform solution.

Chris

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
  

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@...
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

Sorry to jump into the middle of this at this late point,
but I have been on vacation.
Just a note -- no solution needed.
We had a problem with Delays running on Windows on Xen on Linux.
Seems that as it switched processors the time we got shifted a tiny (both directions)
amount -- enough to cause VW to appear to freeze.  We solved that specific
issue by binding a VW image to on processor.  We never determined what
was exactly at fault.  -walltime did not appear to solve that particular problem.

Chris Winemiller wrote:

Eliot Miranda wrote:

On Wed, Aug 20, 2008 at 6:31 AM, Chris Winemiller <[hidden email]> wrote:

Cesar Rabak wrote:

Chris Winemiller escreveu:
[snipped]

  

Nice in theory, but not in practice.  This is the fundamental flaw of 
7.x's implementation.  Computer times *do* drift, and are periodically 
corrected forward or backward by a command from some kind of time 
provider (may or may not be NTP).  By tying duration Delays to the 
computer's "absolute" (but drifting) time, 7.x completely broke duration 
Delays.  They break when the time corrections occur.
    

Chris,

I'm a bit confused right now.

For what time span are you considering the delays you need to implement?
  

The spans do not matter but, for the record, anywhere from a few seconds to perhaps a few minutes.  And the spans are not predetermined; they are dictated by customer-created "recipes" that the application must execute.

Why do you think the span matters?  If the Delay governs the length of time of a recipe step, altering that Delay's duration by even a few seconds can change the step time by 20%, 50%, 75%, or whatever.  And that is enough to ruin a product whose current value can be as much as a million dollars.

Chris, are you running on windows?  If so, what happens if you run with -walltime?  As has been pointed out to me by Andreas Raab the high-performance counter on modern CPUs is no longer constant frequency.  On-chip cpu power-management will alter the frequency of the HPC and make it entirely unsuitable as the basis for the clock, something that didn't happen back in the day.

I have not tried -walltime.  But it won't be adequate anyway because our product is a mult-image application, and only some of those images run on Windows.  We also have other VW-based products that customers typically run on a Unix flavor.  We need a cross-platform solution.

Chris

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
  

Dennis,

We've recently noticed this problem on an HP-UX system (i.e. that each processor has its own time base).  However, that is not the source of the bug I've been describing. The bug happens on many (all?) supported platforms; it occurs whenever the OS time is changed (by command or otherwise) forward or backward.