[vwnc] Anyone having problems with Delays?

All,

On VW 7.4 through VW 7.6, we see really bad problems with Delay behavior
when the underlying OS time is changed (such as the two times a year
when Daylight Savings causes the OS time to be changed).

Here's an example:

1. In a workspace, create a Delay for 2 minutes and start it.
2. Now, set the OS time ahead by 1 minute.
3. The Delay will finish in about 1 minute rather than 2.

Another example:

1. In a workspace, create a Delay for 2 minutes and start it.
2. Now, set the OS time backward by 1 minute.
3. The Delay will finish in about 3 minutes rather than 2.

Has anyone else seen this?

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

Chris

Hmm, as I see it that is how you want it to work if you
want to wait until a specific time of day.

I think the only way around this is to have two kinds of
Delay, one that waits for N microseconds and ignores clock
changes, and one that waits until a specific time and responds
to clock changes.

Terry
 
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Terry,

Yes, a Delay can be created that way using Delay untilSeconds: (or similar methods).

But there are many delays created strictly as durations (Delay forSeconds: for example).  These types of Delays stopped working properly somewhere around VW 7.2 or so.  They were certainly broke as of VW 7.4.

I'm not particularly asking how this bug should be fixed.  I'm asking if others have seen this problem, and is it a significant issue for them.

Chris

Terry Raymond wrote:

Chris

Hmm, as I see it that is how you want it to work if you
want to wait until a specific time of day.

I think the only way around this is to have two kinds of
Delay, one that waits for N microseconds and ignores clock
changes, and one that waits until a specific time and responds
to clock changes.

Terry
 
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================
  

-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Chris Winemiller
Sent: Tuesday, August 12, 2008 7:04 PM
To: [hidden email]
Subject: [vwnc] Anyone having problems with Delays?

All,

On VW 7.4 through VW 7.6, we see really bad problems with Delay behavior
when the underlying OS time is changed (such as the two times a year
when Daylight Savings causes the OS time to be changed).

Here's an example:

1. In a workspace, create a Delay for 2 minutes and start it.
2. Now, set the OS time ahead by 1 minute.
3. The Delay will finish in about 1 minute rather than 2.

Another example:

1. In a workspace, create a Delay for 2 minutes and start it.
2. Now, set the OS time backward by 1 minute.
3. The Delay will finish in about 3 minutes rather than 2.

Has anyone else seen this?

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

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

Chris Winemiller wrote:  From the release notes ($VISUALWORKS\doc\ReleaseNotes7.6.pdf):
-------------------------------------------------------------------------
Delay and Time Change Interaction

It has been noted, particularly on Windows systems, that changing the
time clock adversely affects applications that are in a Delay. The results
vary, but can be as severe as an image hang or crash.
The problem occurs if the system gets out of synchronization with
network time, so that a large correction is necessary. The problem can be
minimized by configuring windows to run a full NTP server, which
changes time gradually, rather than the default SNTP server that corrects
the time all at once.
Arbitrary changes to the clock will continue to cause problems with
running applications in a Delay.
-------------------------------------------------------------------------

You also write: "...such as the two times a year when Daylight Savings
causes the OS time to be changed"

IIRC this only happens on old OSes, nowadays an OS will track time in
UTC so its clock should not change around DST switching days.



Reinout
-------
> Chris
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>  
\
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck wrote:

Chris Winemiller wrote:
  

All,

On VW 7.4 through VW 7.6, we see really bad problems with Delay behavior 
when the underlying OS time is changed (such as the two times a year 
when Daylight Savings causes the OS time to be changed).

Here's an example:

1. In a workspace, create a Delay for 2 minutes and start it.
2. Now, set the OS time ahead by 1 minute.
3. The Delay will finish in about 1 minute rather than 2.

Another example:

1. In a workspace, create a Delay for 2 minutes and start it.
2. Now, set the OS time backward by 1 minute.
3. The Delay will finish in about 3 minutes rather than 2.

Has anyone else seen this?
  
    

 From the release notes ($VISUALWORKS\doc\ReleaseNotes7.6.pdf):
-------------------------------------------------------------------------
Delay and Time Change Interaction

It has been noted, particularly on Windows systems, that changing the
time clock adversely affects applications that are in a Delay. The results
vary, but can be as severe as an image hang or crash.
The problem occurs if the system gets out of synchronization with
network time, so that a large correction is necessary. The problem can be
minimized by configuring windows to run a full NTP server, which
changes time gradually, rather than the default SNTP server that corrects
the time all at once.
Arbitrary changes to the clock will continue to cause problems with
running applications in a Delay.
-------------------------------------------------------------------------
  

Yes, Cincom knows about this problem.  But is the bug a problem for *your* applications?

You also write: "...such as the two times a year when Daylight Savings 
causes the OS time to be changed"

IIRC this only happens on old OSes, nowadays an OS will track time in 
UTC so its clock should not change around DST switching days.
  

Unless they've changed it, Windows keeps its time in local time, not UTC.  Besides, I've seen this bug manifest itself on Windows, Solaris, and Linux, so it seems to be irrelevant whether or not the OS keeps its base time UTC.

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

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Tuesday, August 12, 2008 4:26 PM

Subject: Re: [vwnc] Anyone having problems with Delays?

Terry,

Yes, a Delay can be created that way using Delay untilSeconds: (or similar methods).

But there are many delays created strictly as durations (Delay forSeconds: for example).  These types of Delays stopped working properly somewhere around VW 7.2 or so.  They were certainly broke as of VW 7.4.

I'm not particularly asking how this bug should be fixed.  I'm asking if others have seen this problem, and is it a significant issue for them.

Chris

Terry Raymond wrote:

Chris

Hmm, as I see it that is how you want it to work if you
want to wait until a specific time of day.

I think the only way around this is to have two kinds of
Delay, one that waits for N microseconds and ignores clock
changes, and one that waits until a specific time and responds
to clock changes.

Terry
 
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================
  

-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Chris Winemiller
Sent: Tuesday, August 12, 2008 7:04 PM
To: [hidden email]
Subject: [vwnc] Anyone having problems with Delays?

All,

On VW 7.4 through VW 7.6, we see really bad problems with Delay behavior
when the underlying OS time is changed (such as the two times a year
when Daylight Savings causes the OS time to be changed).

Here's an example:

1. In a workspace, create a Delay for 2 minutes and start it.
2. Now, set the OS time ahead by 1 minute.
3. The Delay will finish in about 1 minute rather than 2.

Another example:

1. In a workspace, create a Delay for 2 minutes and start it.
2. Now, set the OS time backward by 1 minute.
3. The Delay will finish in about 3 minutes rather than 2.

Has anyone else seen this?

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

---

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

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

Bruce Boyer wrote:

Does this note, from the 7.6 release notes, address your problem, or is it yet something else?

Yes, it addresses the problem.  But we are having trouble getting Cincom to fix it immediately because they apparently don't think it's important for most of their customers.  We reported this bug one year ago.  They worked on it for a few months, then dropped their activity on it.  We're trying to discover if this is a significant problem for other VW customers.  Our application uses "duration" Delays in critical processing steps; a significant change in the actual delay time can ruin a single product unit worth many thousands of dollars.  This is why we need this fixed ASAP.

Chris

 

Bruce

 

 

Delay and Time Change Interaction

It has been noted, particularly on Windows systems, that changing the time clock adversely affects applications that are in a Delay. The results vary, but can be as severe as an image hang or crash.

The problem occurs if the system gets out of synchronization with network time, so that a large correction is necessary. The problem can be minimized by configuring windows to run a full NTP server, which changes time gradually, rather than the default SNTP server that corrects the time all at once.

Arbitrary changes to the clock will continue to cause problems with running applications in a Delay.

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Tuesday, August 12, 2008 4:26 PM

Subject: Re: [vwnc] Anyone having problems with Delays?

Terry,

Yes, a Delay can be created that way using Delay untilSeconds: (or similar methods).

But there are many delays created strictly as durations (Delay forSeconds: for example).  These types of Delays stopped working properly somewhere around VW 7.2 or so.  They were certainly broke as of VW 7.4.

I'm not particularly asking how this bug should be fixed.  I'm asking if others have seen this problem, and is it a significant issue for them.

Chris

Terry Raymond wrote:

Chris

Hmm, as I see it that is how you want it to work if you
want to wait until a specific time of day.

I think the only way around this is to have two kinds of
Delay, one that waits for N microseconds and ignores clock
changes, and one that waits until a specific time and responds
to clock changes.

Terry
 
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================
  

-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Chris Winemiller
Sent: Tuesday, August 12, 2008 7:04 PM
To: [hidden email]
Subject: [vwnc] Anyone having problems with Delays?

All,

On VW 7.4 through VW 7.6, we see really bad problems with Delay behavior
when the underlying OS time is changed (such as the two times a year
when Daylight Savings causes the OS time to be changed).

Here's an example:

1. In a workspace, create a Delay for 2 minutes and start it.
2. Now, set the OS time ahead by 1 minute.
3. The Delay will finish in about 1 minute rather than 2.

Another example:

1. In a workspace, create a Delay for 2 minutes and start it.
2. Now, set the OS time backward by 1 minute.
3. The Delay will finish in about 3 minutes rather than 2.

Has anyone else seen this?

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

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

Hi Chris;

 

Cincom recognizes the problem, and its importance.  The correct fix for this was determined to be Posix style delays, which will involve changes to both the VM and the VI, and extensive testing.  Unfortunately, this is not an easy or quick problem to fix.  However we did push to get this included as a priority item for our next release, which is a significant commitment of resources.  My perception is that the typical use of delays is fairly short term, and the current implementation works well.  If others are pushing delays to a breaking point, I would like to hear about it.  Thanks.

 

Regards

 

Arden Thomas

Cincom Smalltalk Product Manager

[hidden email]

 

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Winemiller
Sent: Wednesday, August 13, 2008 9:28 AM
To: [hidden email]
Subject: Re: [vwnc] Anyone having problems with Delays?

 

Bruce Boyer wrote:

Does this note, from the 7.6 release notes, address your problem, or is it yet something else?

Yes, it addresses the problem.  But we are having trouble getting Cincom to fix it immediately because they apparently don't think it's important for most of their customers.  We reported this bug one year ago.  They worked on it for a few months, then dropped their activity on it.  We're trying to discover if this is a significant problem for other VW customers.  Our application uses "duration" Delays in critical processing steps; a significant change in the actual delay time can ruin a single product unit worth many thousands of dollars.  This is why we need this fixed ASAP.

Chris

 

Bruce

 

 

Delay and Time Change Interaction

It has been noted, particularly on Windows systems, that changing the time clock adversely affects applications that are in a Delay. The results vary, but can be as severe as an image hang or crash.

The problem occurs if the system gets out of synchronization with network time, so that a large correction is necessary. The problem can be minimized by configuring windows to run a full NTP server, which changes time gradually, rather than the default SNTP server that corrects the time all at once.

Arbitrary changes to the clock will continue to cause problems with running applications in a Delay.

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Tuesday, August 12, 2008 4:26 PM

Subject: Re: [vwnc] Anyone having problems with Delays?

 

Terry,

Yes, a Delay can be created that way using Delay untilSeconds: (or similar methods).

But there are many delays created strictly as durations (Delay forSeconds: for example).  These types of Delays stopped working properly somewhere around VW 7.2 or so.  They were certainly broke as of VW 7.4.

I'm not particularly asking how this bug should be fixed.  I'm asking if others have seen this problem, and is it a significant issue for them.

Chris

Terry Raymond wrote:

Chris

Hmm, as I see it that is how you want it to work if you

want to wait until a specific time of day.

I think the only way around this is to have two kinds of

Delay, one that waits for N microseconds and ignores clock

changes, and one that waits until a specific time and responds

to clock changes.

Terry

===========================================================

Terry Raymond

Crafted Smalltalk

80 Lazywood Ln.

Tiverton, RI  02878

(401) 624-4517      [hidden email]

<http://www.craftedsmalltalk.com>

===========================================================

-----Original Message-----

From: [hidden email] [[hidden email]] On Behalf Of Chris Winemiller

Sent: Tuesday, August 12, 2008 7:04 PM

To: [hidden email]

Subject: [vwnc] Anyone having problems with Delays?

All,

On VW 7.4 through VW 7.6, we see really bad problems with Delay behavior

when the underlying OS time is changed (such as the two times a year

when Daylight Savings causes the OS time to be changed).

Here's an example:

1. In a workspace, create a Delay for 2 minutes and start it.

2. Now, set the OS time ahead by 1 minute.

3. The Delay will finish in about 1 minute rather than 2.

Another example:

1. In a workspace, create a Delay for 2 minutes and start it.

2. Now, set the OS time backward by 1 minute.

3. The Delay will finish in about 3 minutes rather than 2.

Has anyone else seen this?

Chris

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.138 / Virus Database: 270.6.1/1607 - Release Date: 8/12/2008 7:19 AM

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

At 09:03 AM 8/13/2008, Chris Winemiller wrote:

Reinout Heeck wrote:

Chris Winemiller wrote:
 

All,

On VW 7.4 through VW 7.6, we see really bad problems with Delay behavior 
when the underlying OS time is changed (such as the two times a year 
when Daylight Savings causes the OS time to be changed).

Here's an example:

1. In a workspace, create a Delay for 2 minutes and start it.
2. Now, set the OS time ahead by 1 minute.
3. The Delay will finish in about 1 minute rather than 2.

Another example:

1. In a workspace, create a Delay for 2 minutes and start it.
2. Now, set the OS time backward by 1 minute.
3. The Delay will finish in about 3 minutes rather than 2.

Has anyone else seen this?
  
   

 From the release notes
($VISUALWORKS\doc\ReleaseNotes7.6.pdf):
-------------------------------------------------------------------------
Delay and Time Change Interaction

It has been noted, particularly on Windows systems, that changing the
time clock adversely affects applications that are in a Delay. The
results
vary, but can be as severe as an image hang or crash.
The problem occurs if the system gets out of synchronization with
network time, so that a large correction is necessary. The problem can
be
minimized by configuring windows to run a full NTP server, which
changes time gradually, rather than the default SNTP server that
corrects
the time all at once.
Arbitrary changes to the clock will continue to cause problems with
running applications in a Delay.
-------------------------------------------------------------------------
 

Yes, Cincom knows about this problem.  But is the bug a problem for *your* applications?

You also write: "...such as the two times a year when Daylight
Savings 
causes the OS time to be changed"

IIRC this only happens on old OSes, nowadays an OS will track time in 
UTC so its clock should not change around DST switching days.
 

Unless they've changed it, Windows keeps its time in local time, not UTC.  Besides, I've seen this bug manifest itself on Windows, Solaris, and Linux, so it seems to be irrelevant whether or not the OS keeps its base time UTC.

There are, I think, at least two different scenarios here. One is dealing with clock drift via NTP. As I understand it, a full NTP server, which you typically get on Unix, but not on Windows, will slowly move the clock to be correct. However, if the drift is significant, and the delay is longer than the drift, you'll still have an issue. That's also different from if you manually set the clock on the system to a different time. I'm not sure where daylight savings time adjustments come into the picture, although it ought to be possible to work around them, as they're rare and predictable.



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

Arden Thomas wrote: Our applications involve events that get scheduled hours if not days before.

Our scheduler computes the required delay till the next event but then
waits for only half that time, and then calculates a new delay - again
for half the time needed etc (with a lower bound of course).

This 'binary search hackery' made our scheduler work...


R
-


--
*********************************************************************

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).

Gebruik door anderen is niet toegestaan. Indien u niet degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368.
Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.
**********************************************************************

This e-mail message is intended to be exclusively for the addressee.

If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.

Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368.
Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189
**********************************************************************


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

Arden,

While most of our Delays are for seconds (or at most a few minutes), the current Delay implementation does NOT work well.  If a "duration" Delay is in progress when the OS time changes (such as at Daylight Savings Time boundaries), its duration shortens or lengthens by the amount of the change.  This happens even on OS's like Solaris that keep their internal time in UTC.

If a Visualworks application is applying process steps to a product, and the step lengths are determined by Delays, and the Delay durations get changed due to OS time changes, the potential for ruining product is huge, possibly as much as a million dollars per product unit.  And factory using such applications is not going to shut down its operations for one hour twice a year (to accomodate DST) just to work around its applications' bugs; the cost is too great.

I must also point out that we have been using Visualworks for a very long time.  In fact, many of our applications in the field are built on VW 2.5.  We have always used Delays as mentioned above, and Delays never exhibited this problem until the VW 7.x series.  So we are not "pushing delays to a breaking point."  Cincom broke long-standing proven Delay behavior in 7.x.

Chris

Arden Thomas wrote:

Hi Chris;

 

Cincom recognizes the problem, and its importance.  The correct fix for this was determined to be Posix style delays, which will involve changes to both the VM and the VI, and extensive testing.  Unfortunately, this is not an easy or quick problem to fix.  However we did push to get this included as a priority item for our next release, which is a significant commitment of resources.  My perception is that the typical use of delays is fairly short term, and the current implementation works well.  If others are pushing delays to a breaking point, I would like to hear about it.  Thanks.

 

Regards

 

Arden Thomas

Cincom Smalltalk Product Manager

[hidden email]

 

---

From: [hidden email] [[hidden email]] On Behalf Of Chris Winemiller
Sent: Wednesday, August 13, 2008 9:28 AM
To: [hidden email]
Subject: Re: [vwnc] Anyone having problems with Delays?

 

Bruce Boyer wrote:

Does this note, from the 7.6 release notes, address your problem, or is it yet something else?

Yes, it addresses the problem.  But we are having trouble getting Cincom to fix it immediately because they apparently don't think it's important for most of their customers.  We reported this bug one year ago.  They worked on it for a few months, then dropped their activity on it.  We're trying to discover if this is a significant problem for other VW customers.  Our application uses "duration" Delays in critical processing steps; a significant change in the actual delay time can ruin a single product unit worth many thousands of dollars.  This is why we need this fixed ASAP.

Chris

 

Bruce

 

 

Delay and Time Change Interaction

It has been noted, particularly on Windows systems, that changing the time clock adversely affects applications that are in a Delay. The results vary, but can be as severe as an image hang or crash.

The problem occurs if the system gets out of synchronization with network time, so that a large correction is necessary. The problem can be minimized by configuring windows to run a full NTP server, which changes time gradually, rather than the default SNTP server that corrects the time all at once.

Arbitrary changes to the clock will continue to cause problems with running applications in a Delay.

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Tuesday, August 12, 2008 4:26 PM

Subject: Re: [vwnc] Anyone having problems with Delays?

 

Terry,

Yes, a Delay can be created that way using Delay untilSeconds: (or similar methods).

But there are many delays created strictly as durations (Delay forSeconds: for example).  These types of Delays stopped working properly somewhere around VW 7.2 or so.  They were certainly broke as of VW 7.4.

I'm not particularly asking how this bug should be fixed.  I'm asking if others have seen this problem, and is it a significant issue for them.

Chris

Terry Raymond wrote:

Chris

Hmm, as I see it that is how you want it to work if you

want to wait until a specific time of day.

I think the only way around this is to have two kinds of

Delay, one that waits for N microseconds and ignores clock

changes, and one that waits until a specific time and responds

to clock changes.

Terry

===========================================================

Terry Raymond

Crafted Smalltalk

80 Lazywood Ln.

Tiverton, RI  02878

(401) 624-4517      [hidden email]

<http://www.craftedsmalltalk.com>

===========================================================

-----Original Message-----

From: [hidden email] [[hidden email]] On Behalf Of Chris Winemiller

Sent: Tuesday, August 12, 2008 7:04 PM

To: [hidden email]

Subject: [vwnc] Anyone having problems with Delays?

All,

On VW 7.4 through VW 7.6, we see really bad problems with Delay behavior

when the underlying OS time is changed (such as the two times a year

when Daylight Savings causes the OS time to be changed).

Here's an example:

1. In a workspace, create a Delay for 2 minutes and start it.

2. Now, set the OS time ahead by 1 minute.

3. The Delay will finish in about 1 minute rather than 2.

Another example:

1. In a workspace, create a Delay for 2 minutes and start it.

2. Now, set the OS time backward by 1 minute.

3. The Delay will finish in about 3 minutes rather than 2.

Has anyone else seen this?

Chris

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.138 / Virus Database: 270.6.1/1607 - Release Date: 8/12/2008 7:19 AM

-- 
Chris Winemiller                mailTo:c-winemiller@...
Adventa Control Technologies    Voice: 972-543-1683
3001 East Plano Parkway #100
Plano TX 75074-7422
http://www.AdventaCT.com

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

In VW 2.5 the Delay implementation would not have been subject to issues with the OS clock changing because it would have completely ignored the OS clock value. It would have read the value once on image startup, and thereafter kept time itself, gradually drifting further and further away from the system clock. This was considered undesirable behaviour for a long-running application, and in addition, relied on keeping track of any daylight savings or similar transitions in the image, or else the image clock would just disagree with the rest of the world, which also caused scheduling issues.

If the only issue you're encountering is with Daylight Savings changes, then these would seem to me to be quite predictable. Wouldn't it be possible to work around the issue by simply scheduling the delays as

    self wouldCrossDaylightSavingsTransition ifTrue: [self addOrSubtractAsAppropriate]

That wouldn't help with arbitrary changes to the system clock, but those should be exceptional.

At 11:52 AM 8/13/2008, Chris Winemiller wrote:

Arden,

While most of our Delays are for seconds (or at most a few minutes), the current Delay implementation does NOT work well.  If a "duration" Delay is in progress when the OS time changes (such as at Daylight Savings Time boundaries), its duration shortens or lengthens by the amount of the change.  This happens even on OS's like Solaris that keep their internal time in UTC.

If a Visualworks application is applying process steps to a product, and the step lengths are determined by Delays, and the Delay durations get changed due to OS time changes, the potential for ruining product is huge, possibly as much as a million dollars per product unit.  And factory using such applications is not going to shut down its operations for one hour twice a year (to accomodate DST) just to work around its applications' bugs; the cost is too great.

I must also point out that we have been using Visualworks for a very long time.  In fact, many of our applications in the field are built on VW 2.5.  We have always used Delays as mentioned above, and Delays never exhibited this problem until the VW 7.x series.  So we are not "pushing delays to a breaking point."  Cincom broke long-standing proven Delay behavior in 7.x.

Chris

Arden Thomas wrote:

Hi Chris;
 
Cincom recognizes the problem, and its importance.  The correct fix for this was determined to be Posix style delays, which will involve changes to both the VM and the VI, and extensive testing.  Unfortunately, this is not an easy or quick problem to fix.  However we did push to get this included as a priority item for our next release, which is a significant commitment of resources.  My perception is that the typical use of delays is fairly short term, and the current implementation works well.  If others are pushing delays to a breaking point, I would like to hear about it.  Thanks.
 
Regards
 
Arden Thomas
Cincom Smalltalk Product Manager
[hidden email]
 

---

From: [hidden email] [[hidden email]] On Behalf Of Chris Winemiller
Sent: Wednesday, August 13, 2008 9:28 AM
To: [hidden email]
Subject: Re: [vwnc] Anyone having problems with Delays?
 
Bruce Boyer wrote:
Does this note, from the 7.6 release notes, address your problem, or is it yet something else?
Yes, it addresses the problem.  But we are having trouble getting Cincom to fix it immediately because they apparently don't think it's important for most of their customers.  We reported this bug one year ago.  They worked on it for a few months, then dropped their activity on it.  We're trying to discover if this is a significant problem for other VW customers.  Our application uses "duration" Delays in critical processing steps; a significant change in the actual delay time can ruin a single product unit worth many thousands of dollars.  This is why we need this fixed ASAP.

Chris

 
Bruce
 

 

Delay and Time Change Interaction

It has been noted, particularly on Windows systems, that changing the time clock adversely affects applications that are in a Delay. The results vary, but can be as severe as an image hang or crash.

The problem occurs if the system gets out of synchronization with network time, so that a large correction is necessary. The problem can be minimized by configuring windows to run a full NTP server, which changes time gradually, rather than the default SNTP server that corrects the time all at once.

Arbitrary changes to the clock will continue to cause problems with running applications in a Delay.

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Tuesday, August 12, 2008 4:26 PM

Subject: Re: [vwnc] Anyone having problems with Delays?

 

Terry,

Yes, a Delay can be created that way using Delay untilSeconds: (or similar methods).

But there are many delays created strictly as durations (Delay forSeconds: for example).  These types of Delays stopped working properly somewhere around VW 7.2 or so.  They were certainly broke as of VW 7.4.

I'm not particularly asking how this bug should be fixed.  I'm asking if others have seen this problem, and is it a significant issue for them.

Chris

Terry Raymond wrote:

Chris

Hmm, as I see it that is how you want it to work if
you

want to wait until a specific time of
day.

I think the only way around this is to have two kinds
of

Delay, one that waits for N microseconds and ignores
clock

changes, and one that waits until a specific time and
responds

to clock
changes.

Terry

===========================================================

Terry
Raymond

Crafted
Smalltalk

80 Lazywood
Ln.

Tiverton, RI 
02878

(401) 624-4517     
[hidden email]

<
http://www.craftedsmalltalk.com
>

===========================================================

-----Original
Message-----

From:
[hidden email]
[[hidden email]] On Behalf Of Chris
Winemiller

Sent: Tuesday, August 12, 2008 7:04
PM

To:
[hidden email]

Subject: [vwnc] Anyone having problems with
Delays?

All,

On VW 7.4 through VW 7.6, we see really bad problems with Delay
behavior

when the underlying OS time is changed (such as the two times a
year

when Daylight Savings causes the OS time to be
changed).

Here's an
example:

1. In a workspace, create a Delay for 2 minutes and start
it.

2. Now, set the OS time ahead by 1
minute.

3. The Delay will finish in about 1 minute rather than
2.

Another
example:

1. In a workspace, create a Delay for 2 minutes and start
it.

2. Now, set the OS time backward by 1
minute.

3. The Delay will finish in about 3 minutes rather than
2.

Has anyone else seen
this?

Chris

_______________________________________________

vwnc mailing
list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.138 / Virus Database: 270.6.1/1607 - Release Date: 8/12/2008 7:19 AM

-- 
Chris
Winemiller               

mailTo:c-winemiller@...
Adventa Control Technologies    Voice: 972-543-1683
3001 East Plano Parkway #100
Plano TX 75074-7422
http://www.AdventaCT.com

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

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

Alan Knight wrote:

In VW 2.5 the Delay implementation would not have been subject to issues with the OS clock changing because it would have completely ignored the OS clock value. It would have read the value once on image startup, and thereafter kept time itself, gradually drifting further and further away from the system clock. This was considered undesirable behaviour for a long-running application, and in addition, relied on keeping track of any daylight savings or similar transitions in the image, or else the image clock would just disagree with the rest of the world, which also caused scheduling issues.

If the only issue you're encountering is with Daylight Savings changes, then these would seem to me to be quite predictable. Wouldn't it be possible to work around the issue by simply scheduling the delays as

    self wouldCrossDaylightSavingsTransition ifTrue: [self addOrSubtractAsAppropriate]

That wouldn't help with arbitrary changes to the system clock, but those should be exceptional.

No, this is not feasible:

1. Within the application, at any given time, there will be hundreds of active Processes and Delays.  Changing all the corresponding code would be not only impossible, but poor OO design.  If the problem is a bug in the Delay object, then the fix should be in the Delay object, not in the hundreds of objects using Delay objects.

2. I raise DST as the most egregious example.  In reality, within our industry, it is common for factory software systems to send industry-standard "set time" commands to the applications, and these commands, by definition, must alter the OS times.  This can occur as frequently as every 10 minutes, or perhaps more infrequently.  The point is that our application cannot dictate frequency of time updates to our customers.  Nor can we guarantee that the customer will want to use NTP services rather than the "set time" commands.

While time drift in VW 2.5 may have been an annoyance, it's nothing compared to the full-fledged breakage introduced in VW 7.x.

Chris

At 11:52 AM 8/13/2008, Chris Winemiller wrote:

Arden,

While most of our Delays are for seconds (or at most a few minutes), the current Delay implementation does NOT work well.  If a "duration" Delay is in progress when the OS time changes (such as at Daylight Savings Time boundaries), its duration shortens or lengthens by the amount of the change.  This happens even on OS's like Solaris that keep their internal time in UTC.

If a Visualworks application is applying process steps to a product, and the step lengths are determined by Delays, and the Delay durations get changed due to OS time changes, the potential for ruining product is huge, possibly as much as a million dollars per product unit.  And factory using such applications is not going to shut down its operations for one hour twice a year (to accomodate DST) just to work around its applications' bugs; the cost is too great.

I must also point out that we have been using Visualworks for a very long time.  In fact, many of our applications in the field are built on VW 2.5.  We have always used Delays as mentioned above, and Delays never exhibited this problem until the VW 7.x series.  So we are not "pushing delays to a breaking point."  Cincom broke long-standing proven Delay behavior in 7.x.

Chris

Arden Thomas wrote:

Hi Chris;
 
Cincom recognizes the problem, and its importance.  The correct fix for this was determined to be Posix style delays, which will involve changes to both the VM and the VI, and extensive testing.  Unfortunately, this is not an easy or quick problem to fix.  However we did push to get this included as a priority item for our next release, which is a significant commitment of resources.  My perception is that the typical use of delays is fairly short term, and the current implementation works well.  If others are pushing delays to a breaking point, I would like to hear about it.  Thanks.
 
Regards
 
Arden Thomas
Cincom Smalltalk Product Manager
[hidden email]
 

---

From: [hidden email] [[hidden email]] On Behalf Of Chris Winemiller
Sent: Wednesday, August 13, 2008 9:28 AM
To: [hidden email]
Subject: Re: [vwnc] Anyone having problems with Delays?
 
Bruce Boyer wrote:
Does this note, from the 7.6 release notes, address your problem, or is it yet something else?
Yes, it addresses the problem.  But we are having trouble getting Cincom to fix it immediately because they apparently don't think it's important for most of their customers.  We reported this bug one year ago.  They worked on it for a few months, then dropped their activity on it.  We're trying to discover if this is a significant problem for other VW customers.  Our application uses "duration" Delays in critical processing steps; a significant change in the actual delay time can ruin a single product unit worth many thousands of dollars.  This is why we need this fixed ASAP.

Chris

 
Bruce
 

 

Delay and Time Change Interaction

It has been noted, particularly on Windows systems, that changing the time clock adversely affects applications that are in a Delay. The results vary, but can be as severe as an image hang or crash.

The problem occurs if the system gets out of synchronization with network time, so that a large correction is necessary. The problem can be minimized by configuring windows to run a full NTP server, which changes time gradually, rather than the default SNTP server that corrects the time all at once.

Arbitrary changes to the clock will continue to cause problems with running applications in a Delay.

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Tuesday, August 12, 2008 4:26 PM

Subject: Re: [vwnc] Anyone having problems with Delays?

 

Terry,

Yes, a Delay can be created that way using Delay untilSeconds: (or similar methods).

But there are many delays created strictly as durations (Delay forSeconds: for example).  These types of Delays stopped working properly somewhere around VW 7.2 or so.  They were certainly broke as of VW 7.4.

I'm not particularly asking how this bug should be fixed.  I'm asking if others have seen this problem, and is it a significant issue for them.

Chris

Terry Raymond wrote:

Chris

Hmm, as I see it that is how you want it to work if
you

want to wait until a specific time of
day.

I think the only way around this is to have two kinds
of

Delay, one that waits for N microseconds and ignores
clock

changes, and one that waits until a specific time and
responds

to clock
changes.

Terry

===========================================================

Terry
Raymond

Crafted
Smalltalk

80 Lazywood
Ln.

Tiverton, RI 
02878

(401) 624-4517     
[hidden email]

<
http://www.craftedsmalltalk.com
>

===========================================================

-----Original
Message-----

From:
[hidden email]
[[hidden email]] On Behalf Of Chris
Winemiller

Sent: Tuesday, August 12, 2008 7:04
PM

To:
[hidden email]

Subject: [vwnc] Anyone having problems with
Delays?

All,

On VW 7.4 through VW 7.6, we see really bad problems with Delay
behavior

when the underlying OS time is changed (such as the two times a
year

when Daylight Savings causes the OS time to be
changed).

Here's an
example:

1. In a workspace, create a Delay for 2 minutes and start
it.

2. Now, set the OS time ahead by 1
minute.

3. The Delay will finish in about 1 minute rather than
2.

Another
example:

1. In a workspace, create a Delay for 2 minutes and start
it.

2. Now, set the OS time backward by 1
minute.

3. The Delay will finish in about 3 minutes rather than
2.

Has anyone else seen
this?

Chris

_______________________________________________

vwnc mailing
list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

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

At 03:41 PM 8/13/2008, Chris Winemiller wrote:

Alan Knight wrote:

In VW 2.5 the Delay implementation would not have been subject to issues with the OS clock changing because it would have completely ignored the OS clock value. It would have read the value once on image startup, and thereafter kept time itself, gradually drifting further and further away from the system clock. This was considered undesirable behaviour for a long-running application, and in addition, relied on keeping track of any daylight savings or similar transitions in the image, or else the image clock would just disagree with the rest of the world, which also caused scheduling issues.

If the only issue you're encountering is with Daylight Savings changes, then these would seem to me to be quite predictable. Wouldn't it be possible to work around the issue by simply scheduling the delays as

    self wouldCrossDaylightSavingsTransition ifTrue: [self addOrSubtractAsAppropriate]

That wouldn't help with arbitrary changes to the system clock, but those should be exceptional.

No, this is not feasible:

1. Within the application, at any given time, there will be hundreds of active Processes and Delays.  Changing all the corresponding code would be not only impossible, but poor OO design.  If the problem is a bug in the Delay object, then the fix should be in the Delay object, not in the hundreds of objects using Delay objects.

So what about putting a fix of that form into the Delay object? But that's somewhat moot from your point 2.

2. I raise DST as the most egregious example.  In reality, within our industry, it is common for factory software systems to send industry-standard "set time" commands to the applications, and these commands, by definition, must alter the OS times.  This can occur as frequently as every 10 minutes, or perhaps more infrequently.  The point is that our application cannot dictate frequency of time updates to our customers.  Nor can we guarantee that the customer will want to use NTP services rather than the "set time" commands.

While time drift in VW 2.5 may have been an annoyance, it's nothing compared to the full-fledged breakage introduced in VW 7.x.

OK, I was just trying to find out if the DST change was actually the only concern.

So, if I understand what you're saying, it is not a problem for you to have all of these "set time" commands completely ignored by the Delay system, and have it go by its own internal notion of elapsed time? I'm also reminded that the 2.5 implementation wrapped around every 3 weeks.

Chris

At 11:52 AM 8/13/2008, Chris Winemiller wrote:

Arden,

While most of our Delays are for seconds (or at most a few minutes), the current Delay implementation does NOT work well.  If a "duration" Delay is in progress when the OS time changes (such as at Daylight Savings Time boundaries), its duration shortens or lengthens by the amount of the change.  This happens even on OS's like Solaris that keep their internal time in UTC.

If a Visualworks application is applying process steps to a product, and the step lengths are determined by Delays, and the Delay durations get changed due to OS time changes, the potential for ruining product is huge, possibly as much as a million dollars per product unit.  And factory using such applications is not going to shut down its operations for one hour twice a year (to accomodate DST) just to work around its applications' bugs; the cost is too great.

I must also point out that we have been using Visualworks for a very long time.  In fact, many of our applications in the field are built on VW 2.5.  We have always used Delays as mentioned above, and Delays never exhibited this problem until the VW 7.x series.  So we are not "pushing delays to a breaking point."  Cincom broke long-standing proven Delay behavior in 7.x.

Chris

Arden Thomas wrote:

Hi Chris;
 
Cincom recognizes the problem, and its importance.  The correct fix for this was determined to be Posix style delays, which will involve changes to both the VM and the VI, and extensive testing.  Unfortunately, this is not an easy or quick problem to fix.  However we did push to get this included as a priority item for our next release, which is a significant commitment of resources.  My perception is that the typical use of delays is fairly short term, and the current implementation works well.  If others are pushing delays to a breaking point, I would like to hear about it.  Thanks.
 
Regards
 
Arden Thomas
Cincom Smalltalk Product Manager
[hidden email]
 

---

From: [hidden email] [ [hidden email]] On Behalf Of Chris Winemiller
Sent: Wednesday, August 13, 2008 9:28 AM
To: [hidden email]
Subject: Re: [vwnc] Anyone having problems with Delays?
 
Bruce Boyer wrote:
Does this note, from the 7.6 release notes, address your problem, or is it yet something else?
Yes, it addresses the problem.  But we are having trouble getting Cincom to fix it immediately because they apparently don't think it's important for most of their customers.  We reported this bug one year ago.  They worked on it for a few months, then dropped their activity on it.  We're trying to discover if this is a significant problem for other VW customers.  Our application uses "duration" Delays in critical processing steps; a significant change in the actual delay time can ruin a single product unit worth many thousands of dollars.  This is why we need this fixed ASAP.

Chris

 
Bruce
 

 

Delay and Time Change Interaction

It has been noted, particularly on Windows systems, that changing the time clock adversely affects applications that are in a Delay. The results vary, but can be as severe as an image hang or crash.

The problem occurs if the system gets out of synchronization with network time, so that a large correction is necessary. The problem can be minimized by configuring windows to run a full NTP server, which changes time gradually, rather than the default SNTP server that corrects the time all at once.

Arbitrary changes to the clock will continue to cause problems with running applications in a Delay.

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Tuesday, August 12, 2008 4:26 PM

Subject: Re: [vwnc] Anyone having problems with Delays?

 

Terry,

Yes, a Delay can be created that way using Delay untilSeconds: (or similar methods).

But there are many delays created strictly as durations (Delay forSeconds: for example).  These types of Delays stopped working properly somewhere around VW 7.2 or so.  They were certainly broke as of VW 7.4.

I'm not particularly asking how this bug should be fixed.  I'm asking if others have seen this problem, and is it a significant issue for them.

Chris

Terry Raymond wrote:

Chris

Hmm, as I see it that is how you want it to work if

you

want to wait until a specific time of

day.

I think the only way around this is to have two kinds

of

Delay, one that waits for N microseconds and ignores

clock

changes, and one that waits until a specific time and

responds

to clock

changes.

Terry

===========================================================

Terry

Raymond

Crafted

Smalltalk

80 Lazywood

Ln.

Tiverton, RI 

02878

(401) 624-4517     
[hidden email]

<


http://www.craftedsmalltalk.com

>

===========================================================

-----Original

Message-----

From:

[hidden email]

[

[hidden email]] On Behalf Of Chris

Winemiller

Sent: Tuesday, August 12, 2008 7:04

PM

To:

[hidden email]

Subject: [vwnc] Anyone having problems with

Delays?

All,

On VW 7.4 through VW 7.6, we see really bad problems with Delay

behavior

when the underlying OS time is changed (such as the two times a

year

when Daylight Savings causes the OS time to be

changed).

Here's an

example:

1. In a workspace, create a Delay for 2 minutes and start

it.

2. Now, set the OS time ahead by 1

minute.

3. The Delay will finish in about 1 minute rather than

2.

Another

example:

1. In a workspace, create a Delay for 2 minutes and start

it.

2. Now, set the OS time backward by 1

minute.

3. The Delay will finish in about 3 minutes rather than

2.

Has anyone else seen

this?

Chris

_______________________________________________

vwnc mailing

list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

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

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

Alan

 

It seems to me that Delay needs to work in two different ways.

1. Trigger at a particular time, and be synchronized to the computer clock.
2. Trigger after N microseconds have elapsed and ignore clock changes.

 

The current Delay public api can accommodate both needs, we just need

the internal implementation to handle it.

 

There may be an additional problem with DST if one platform reflects

the DST as a time shift while another platform does not. But, I don’t

think there is a general solution to this. I think the application must

be aware that a shift can occur and adapt for it. This is because the

required action may be different for different applications. I have worked

on two apps that needed to accommodate DST shifts and they were

done differently.

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Alan Knight
Sent: Thursday, August 14, 2008 9:47 AM
To: Chris Winemiller; [hidden email]
Subject: Re: [vwnc] Anyone having problems with Delays?

 

At 03:41 PM 8/13/2008, Chris Winemiller wrote:

Alan Knight wrote:

In VW 2.5 the Delay implementation would not have been subject to issues with the OS clock changing because it would have completely ignored the OS clock value. It would have read the value once on image startup, and thereafter kept time itself, gradually drifting further and further away from the system clock. This was considered undesirable behaviour for a long-running application, and in addition, relied on keeping track of any daylight savings or similar transitions in the image, or else the image clock would just disagree with the rest of the world, which also caused scheduling issues.

If the only issue you're encountering is with Daylight Savings changes, then these would seem to me to be quite predictable. Wouldn't it be possible to work around the issue by simply scheduling the delays as

    self wouldCrossDaylightSavingsTransition ifTrue: [self addOrSubtractAsAppropriate]

That wouldn't help with arbitrary changes to the system clock, but those should be exceptional.

No, this is not feasible:

1. Within the application, at any given time, there will be hundreds of active Processes and Delays.  Changing all the corresponding code would be not only impossible, but poor OO design.  If the problem is a bug in the Delay object, then the fix should be in the Delay object, not in the hundreds of objects using Delay objects.

So what about putting a fix of that form into the Delay object? But that's somewhat moot from your point 2.

2. I raise DST as the most egregious example.  In reality, within our industry, it is common for factory software systems to send industry-standard "set time" commands to the applications, and these commands, by definition, must alter the OS times.  This can occur as frequently as every 10 minutes, or perhaps more infrequently.  The point is that our application cannot dictate frequency of time updates to our customers.  Nor can we guarantee that the customer will want to use NTP services rather than the "set time" commands.

While time drift in VW 2.5 may have been an annoyance, it's nothing compared to the full-fledged breakage introduced in VW 7.x.

OK, I was just trying to find out if the DST change was actually the only concern.

So, if I understand what you're saying, it is not a problem for you to have all of these "set time" commands completely ignored by the Delay system, and have it go by its own internal notion of elapsed time? I'm also reminded that the 2.5 implementation wrapped around every 3 weeks.

Chris

At 11:52 AM 8/13/2008, Chris Winemiller wrote:

Arden,

While most of our Delays are for seconds (or at most a few minutes), the current Delay implementation does NOT work well.  If a "duration" Delay is in progress when the OS time changes (such as at Daylight Savings Time boundaries), its duration shortens or lengthens by the amount of the change.  This happens even on OS's like Solaris that keep their internal time in UTC.

If a Visualworks application is applying process steps to a product, and the step lengths are determined by Delays, and the Delay durations get changed due to OS time changes, the potential for ruining product is huge, possibly as much as a million dollars per product unit.  And factory using such applications is not going to shut down its operations for one hour twice a year (to accomodate DST) just to work around its applications' bugs; the cost is too great.

I must also point out that we have been using Visualworks for a very long time.  In fact, many of our applications in the field are built on VW 2.5.  We have always used Delays as mentioned above, and Delays never exhibited this problem until the VW 7.x series.  So we are not "pushing delays to a breaking point."  Cincom broke long-standing proven Delay behavior in 7.x.

Chris

Arden Thomas wrote:

Hi Chris;
 
Cincom recognizes the problem, and its importance.  The correct fix for this was determined to be Posix style delays, which will involve changes to both the VM and the VI, and extensive testing.  Unfortunately, this is not an easy or quick problem to fix.  However we did push to get this included as a priority item for our next release, which is a significant commitment of resources.  My perception is that the typical use of delays is fairly short term, and the current implementation works well.  If others are pushing delays to a breaking point, I would like to hear about it.  Thanks.
 
Regards
 
Arden Thomas
Cincom Smalltalk Product Manager
[hidden email]
 

---

From: [hidden email] [ [hidden email]] On Behalf Of Chris Winemiller
Sent: Wednesday, August 13, 2008 9:28 AM
To: [hidden email]
Subject: Re: [vwnc] Anyone having problems with Delays?
 
Bruce Boyer wrote:
Does this note, from the 7.6 release notes, address your problem, or is it yet something else?
Yes, it addresses the problem.  But we are having trouble getting Cincom to fix it immediately because they apparently don't think it's important for most of their customers.  We reported this bug one year ago.  They worked on it for a few months, then dropped their activity on it.  We're trying to discover if this is a significant problem for other VW customers.  Our application uses "duration" Delays in critical processing steps; a significant change in the actual delay time can ruin a single product unit worth many thousands of dollars.  This is why we need this fixed ASAP.

Chris

 
Bruce
 

 

Delay and Time Change Interaction

It has been noted, particularly on Windows systems, that changing the time clock adversely affects applications that are in a Delay. The results vary, but can be as severe as an image hang or crash.

The problem occurs if the system gets out of synchronization with network time, so that a large correction is necessary. The problem can be minimized by configuring windows to run a full NTP server, which changes time gradually, rather than the default SNTP server that corrects the time all at once.

Arbitrary changes to the clock will continue to cause problems with running applications in a Delay.

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Tuesday, August 12, 2008 4:26 PM

Subject: Re: [vwnc] Anyone having problems with Delays?

 

Terry,

Yes, a Delay can be created that way using Delay untilSeconds: (or similar methods).

But there are many delays created strictly as durations (Delay forSeconds: for example).  These types of Delays stopped working properly somewhere around VW 7.2 or so.  They were certainly broke as of VW 7.4.

I'm not particularly asking how this bug should be fixed.  I'm asking if others have seen this problem, and is it a significant issue for them.

Chris

Terry Raymond wrote:

Chris

 

 

Hmm, as I see it that is how you want it to work if

you

 

want to wait until a specific time of

day.

 

 

I think the only way around this is to have two kinds

of

 

Delay, one that waits for N microseconds and ignores

clock

 

changes, and one that waits until a specific time and

responds

 

to clock

changes.

 

 

Terry

 

 

===========================================================

 

Terry

Raymond

 

Crafted

Smalltalk

 

80 Lazywood

Ln.

 

Tiverton, RI 

02878

 

(401) 624-4517     

[hidden email]

[hidden email]

[hidden email]

 

< 

http://www.craftedsmalltalk.com

> 

 

===========================================================

 

 

-----Original

Message-----

 

From:

[hidden email]

[

[hidden email]

[hidden email]] On Behalf Of Chris

Winemiller

 

Sent: Tuesday, August 12, 2008 7:04

PM

 

To:

[hidden email]

 

Subject: [vwnc] Anyone having problems with

Delays?

 

 

All,

 

 

On VW 7.4 through VW 7.6, we see really bad problems with Delay

behavior

 

when the underlying OS time is changed (such as the two times a

year

 

when Daylight Savings causes the OS time to be

changed).

 

 

Here's an

example:

 

 

1. In a workspace, create a Delay for 2 minutes and start

it.

 

2. Now, set the OS time ahead by 1

minute.

 

3. The Delay will finish in about 1 minute rather than

2.

 

 

Another

example:

 

 

1. In a workspace, create a Delay for 2 minutes and start

it.

 

2. Now, set the OS time backward by 1

minute.

 

3. The Delay will finish in about 3 minutes rather than

2.

 

 

Has anyone else seen

this?

 

 

Chris

 

_______________________________________________

 

vwnc mailing

list

 

[hidden email]

 

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

 

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

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

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

Alan Knight wrote:

At 03:41 PM 8/13/2008, Chris Winemiller wrote:

Alan Knight wrote:

In VW 2.5 the Delay implementation would not have been subject to issues with the OS clock changing because it would have completely ignored the OS clock value. It would have read the value once on image startup, and thereafter kept time itself, gradually drifting further and further away from the system clock. This was considered undesirable behaviour for a long-running application, and in addition, relied on keeping track of any daylight savings or similar transitions in the image, or else the image clock would just disagree with the rest of the world, which also caused scheduling issues.

If the only issue you're encountering is with Daylight Savings changes, then these would seem to me to be quite predictable. Wouldn't it be possible to work around the issue by simply scheduling the delays as

    self wouldCrossDaylightSavingsTransition ifTrue: [self addOrSubtractAsAppropriate]

That wouldn't help with arbitrary changes to the system clock, but those should be exceptional.

No, this is not feasible:

1. Within the application, at any given time, there will be hundreds of active Processes and Delays.  Changing all the corresponding code would be not only impossible, but poor OO design.  If the problem is a bug in the Delay object, then the fix should be in the Delay object, not in the hundreds of objects using Delay objects.

So what about putting a fix of that form into the Delay object? But that's somewhat moot from your point 2.

2. I raise DST as the most egregious example.  In reality, within our industry, it is common for factory software systems to send industry-standard "set time" commands to the applications, and these commands, by definition, must alter the OS times.  This can occur as frequently as every 10 minutes, or perhaps more infrequently.  The point is that our application cannot dictate frequency of time updates to our customers.  Nor can we guarantee that the customer will want to use NTP services rather than the "set time" commands.

While time drift in VW 2.5 may have been an annoyance, it's nothing compared to the full-fledged breakage introduced in VW 7.x.

OK, I was just trying to find out if the DST change was actually the only concern.

So, if I understand what you're saying, it is not a problem for you to have all of these "set time" commands completely ignored by the Delay system, and have it go by its own internal notion of elapsed time? I'm also reminded that the 2.5 implementation wrapped around every 3 weeks.

Actually, the VW 2.5 wraparound was 49.x days, not 21 days.

Delays that were created as durations (#for{Seconds:, #milliseconds:, etc.}) should never be sensitive to OS time changes.  But these delays must reflect elapsed time as accurately as the underlying hardware timer(s) and OS (and OS time-slicing) will permit.  I.e. if I want a 5-second duration, the Delay must actually wait 5 seconds regardless of whether or not the OS's timestamp has been changed while the Delay was active.

Delays that were created with a target microsecond clock value (#until{Seconds:, #milliseconds:, etc.}) go could either way, in my opinion.  I can see the case for making them either sensitive or non-sensitive to OS time changes.  I could live with either approach.

Chris

At 11:52 AM 8/13/2008, Chris Winemiller wrote:

Arden,

While most of our Delays are for seconds (or at most a few minutes), the current Delay implementation does NOT work well.  If a "duration" Delay is in progress when the OS time changes (such as at Daylight Savings Time boundaries), its duration shortens or lengthens by the amount of the change.  This happens even on OS's like Solaris that keep their internal time in UTC.

If a Visualworks application is applying process steps to a product, and the step lengths are determined by Delays, and the Delay durations get changed due to OS time changes, the potential for ruining product is huge, possibly as much as a million dollars per product unit.  And factory using such applications is not going to shut down its operations for one hour twice a year (to accomodate DST) just to work around its applications' bugs; the cost is too great.

I must also point out that we have been using Visualworks for a very long time.  In fact, many of our applications in the field are built on VW 2.5.  We have always used Delays as mentioned above, and Delays never exhibited this problem until the VW 7.x series.  So we are not "pushing delays to a breaking point."  Cincom broke long-standing proven Delay behavior in 7.x.

Chris

Arden Thomas wrote:

Hi Chris;
 
Cincom recognizes the problem, and its importance.  The correct fix for this was determined to be Posix style delays, which will involve changes to both the VM and the VI, and extensive testing.  Unfortunately, this is not an easy or quick problem to fix.  However we did push to get this included as a priority item for our next release, which is a significant commitment of resources.  My perception is that the typical use of delays is fairly short term, and the current implementation works well.  If others are pushing delays to a breaking point, I would like to hear about it.  Thanks.
 
Regards
 
Arden Thomas
Cincom Smalltalk Product Manager
[hidden email]
 

---

From: [hidden email] [ [hidden email]] On Behalf Of Chris Winemiller
Sent: Wednesday, August 13, 2008 9:28 AM
To: [hidden email]
Subject: Re: [vwnc] Anyone having problems with Delays?
 
Bruce Boyer wrote:
Does this note, from the 7.6 release notes, address your problem, or is it yet something else?
Yes, it addresses the problem.  But we are having trouble getting Cincom to fix it immediately because they apparently don't think it's important for most of their customers.  We reported this bug one year ago.  They worked on it for a few months, then dropped their activity on it.  We're trying to discover if this is a significant problem for other VW customers.  Our application uses "duration" Delays in critical processing steps; a significant change in the actual delay time can ruin a single product unit worth many thousands of dollars.  This is why we need this fixed ASAP.

Chris

 
Bruce
 

 

Delay and Time Change Interaction

It has been noted, particularly on Windows systems, that changing the time clock adversely affects applications that are in a Delay. The results vary, but can be as severe as an image hang or crash.

The problem occurs if the system gets out of synchronization with network time, so that a large correction is necessary. The problem can be minimized by configuring windows to run a full NTP server, which changes time gradually, rather than the default SNTP server that corrects the time all at once.

Arbitrary changes to the clock will continue to cause problems with running applications in a Delay.

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Tuesday, August 12, 2008 4:26 PM

Subject: Re: [vwnc] Anyone having problems with Delays?

 

Terry,

Yes, a Delay can be created that way using Delay untilSeconds: (or similar methods).

But there are many delays created strictly as durations (Delay forSeconds: for example).  These types of Delays stopped working properly somewhere around VW 7.2 or so.  They were certainly broke as of VW 7.4.

I'm not particularly asking how this bug should be fixed.  I'm asking if others have seen this problem, and is it a significant issue for them.

Chris

Terry Raymond wrote:

Chris

Hmm, as I see it that is how you want it to work if

you

want to wait until a specific time of

day.

I think the only way around this is to have two kinds

of

Delay, one that waits for N microseconds and ignores

clock

changes, and one that waits until a specific time and

responds

to clock

changes.

Terry

===========================================================

Terry

Raymond

Crafted

Smalltalk

80 Lazywood

Ln.

Tiverton, RI 

02878

(401) 624-4517     
[hidden email]

<


http://www.craftedsmalltalk.com

>

===========================================================

-----Original

Message-----

From:

[hidden email]

[

[hidden email]] On Behalf Of Chris

Winemiller

Sent: Tuesday, August 12, 2008 7:04

PM

To:

[hidden email]

Subject: [vwnc] Anyone having problems with

Delays?

All,

On VW 7.4 through VW 7.6, we see really bad problems with Delay

behavior

when the underlying OS time is changed (such as the two times a

year

when Daylight Savings causes the OS time to be

changed).

Here's an

example:

1. In a workspace, create a Delay for 2 minutes and start

it.

2. Now, set the OS time ahead by 1

minute.

3. The Delay will finish in about 1 minute rather than

2.

Another

example:

1. In a workspace, create a Delay for 2 minutes and start

it.

2. Now, set the OS time backward by 1

minute.

3. The Delay will finish in about 3 minutes rather than

2.

Has anyone else seen

this?

Chris

_______________________________________________

vwnc mailing

list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

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

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

At 06:47 AM 8/14/2008, Alan Knight wrote:
>At 03:41 PM 8/13/2008, Chris Winemiller wrote:
>>Alan Knight wrote:
>>>In VW 2.5 the Delay implementation would not have been subject to issues with the OS clock changing because it would have completely ignored the OS clock value.


  This is *effectively* upTime.

  But, instead of counting from zero,
  VW2.5 adds in a one-time bias value at image startup.
  The bias value is functionally equivalent to
      (wallTime at imageStart) asDuration.


>>> It would have read the value once on image startup, and thereafter kept time itself,


  which is fine, until someone tries to take advantage
  of the fact that the counter is 'biased' to a value
  which resembles wallTime, but is not the same as wallTime,

    because (upTime asWallTime) will be seen to be

>>> gradually drifting further and further away from the system clock.

  (with 'the system clock', in this case,
   meaning 'the system's notion of wallTime'
  ).


>>> This was considered undesirable behaviour for a long-running application,


  (unfortunately, this undesireability arises from
   an ill-conceived dual-use of the upTime value,
   rather than from the clock skew, per se.
  )


>>> and in addition, relied on keeping track of any daylight savings
>>> or similar transitions in the image,


  (i.e. the ill-conceived dual-use of upTime)


>>> or else the image clock


  (with 'image clock', here, meaning the same thing as (upTime asWallTime)).


>>> would just disagree with the rest of the world, which also caused scheduling issues.


  (another variant of 'dual-use', here, because 'scheduling' comes in two flavors).


>>>I'm also reminded that the 2.5 implementation wrapped around every 3 weeks.


  Someone else mentioned it was 49 and a fraction of days,
  I'm recalling it as either 43 and a fraction.
  In any case, it wraps when the count value
  overflows the memory word which contains it
  (at 2**31, give or take 2 bits).
 
  Apparently, 7x has 'fixed' both problems,
  (i.e. the 'wrapping', and the 'drift')
  by modifying the implementation of upTime.

  The 'wrapping' problem is fixed by increasing
  the container size (shades of Java - horrors!).

  The 'drift' problem was 'fixed' by switching
  the notion of time used by Delay,
  from upTime, to (I'm guessing here) wallTime.

  Which sees to suggest that upTime is no longer maintained.

  YIKES!

  You actually need 3 distinct clocks
  to always get the right results:

  1) upTime
  2) wallTime
  3) elapsedWallTime

  The first is required for internal-duration based scheduling,
  and MUST NOT be affected by changing values of systemWallTime.
  This includes all timeout scheduling; most, but not all,
  periodic scheduling; and most, but not all, sensor/controller
  scheduling.  Note that upTime CAN NOT be adjusted by anything
  except a periodic increment, nor can said period be modified.
  And upTime must either count "forever", without overflowing,
  or ALL deltas must be calculated modulo the container size.
 
  The second is required for (most) timeOfDay based scheduling,
  and MUST BE affected by any changes to the system's timeOfDay.
  This is rarely the correct clock to use for scheduling, because
  of susceptibility to time dilation, a common error.  Very low
  resolution schedules - mostly for dates, rather than times.

  Note that a single clock CANNOT perform both functions correctly.
  You can fake one, using the other, but you'll have to maintain
  multiple, distinct offsets and skews, and use them in every
  calculation. Merging of values (such as the biased upTime of VW2.5)
  destroys necessary information - guaranteed to result in heisenbugs.

  The third of these is hard to obtain, and not often considered
  but required for (most) external-duration based scheduling.
  Most applications that care about it use an estimated version.
  The simpler versions rely on an external counter surviving a reboot.
  Some also save a snapshot of (wallTime at system boot) somewhere
  in persistant store, and compare it with the previous version
  to figure out how much wallTime has elapsed while the system
  was down. This variation is important in fault-tolerant contexts,
  where processes in the 'scheduled environment' continue even
  while the system is down.

  ======
  A 'quick' fix would be to keep the container size update,
  but revert to biased upTime for Delay and friends.

  At least until a better solution is ready.

Regards,

-cstb


(TSPTCPM, perhaps,
 but still...JAP
)

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

Am 15.08.2008 um 01:49 schrieb cstb:


Regarding upTime, there is no need to reason about absurd  
"milliseconds since big bang" resolutions or some sophisticated  
overflow mechanism.

If the container is large enough to contain, say, 20 years, that'll be  
pretty sufficient. I guess there is no single application that is  
continously up for that long. Actually computers don't live that long  
anyway.

In an industrial production environment, I would base all delays on  
uptime only. The required delay time could be determined based on  
walltime (because "now" is always valid), but the /wait/ should look  
at elapsing uptime only.

Andre

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

At 11:53 PM 8/14/2008, Andre Schnoor wrote:


Right.  You can, if you want to, add "milliseconds since bigBang",
or any other biasing value that strikes your fancy, as long as you
do it before scheduling begins.  Likewise, you can just reset to 0,
as long as you do so before scheduling begins.

The important property of upTime
is that it is 'monotonically increasing'
over the entire lifetime of every execution instance
of every application which utilizes it.

Same for elapsedWallTime, but which extends the constraint
to hold across the entire lifetime
    of every execution *session*
of every execution instance of every application which utilizes it.



>If the container is large enough to contain, say, 20 years, that'll be  
>pretty sufficient. I guess there is no single application that is  
>continously up for that long. Actually computers don't live that long  
>anyway.


Agreed - 20 years is sufficiently close to "forever".

Since the old counter was good for at least 3 weeks,
adding 6 bits makes it good for a year, 16 for 1000 years,
and 32 for a 64 million years, we'll probably be ok for
a while, regardless of how much the field is/was extended.


>In an industrial production environment, I would base all delays on  
>uptime only. The required delay time could be determined based on  
>walltime (because "now" is always valid), but the /wait/ should
>look at elapsing uptime only.


Yes - "now" is always valid, but "next tuesday" is not.

So, if we add the obvious interface
        Delay class>>until: aTimestamp
then we should expect this variant to provide wallTime scheduling,
and thus not be tempted to use it for things like
        Delay until: (Time now + 10 milliseconds) asTimestamp
when we mean
        Delay forMilliseconds: 10


Regards,

-cstb



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