Time>>eventMillisecondClock and event timestamps
Locked
Time>>eventMillisecondClock and event timestamps
 
|
Christoph has fixed a bug in event timestamps on the Windows VM. Background
is at https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/518. This led us to a question about Time>>eventMillisecondClock. To summarize: Events are delivered to the image by the VM, and processed in the image as e.g. MorphicEvent. Each event has a timeStamp that is an integer number of milliseconds since some arbitrary starting point. The actual time basis (starting point) of those timestamps is not important, just as long as they are consistent. In the Windows VM, the event timeStamps are derived from the Windows event system, and are in milliseconds relative to the time that the Windows system was started. Other VMs obtain their event time stamps differently, but normally through ioMSecs() in the VM. Thus, for any VM, the events must have internally consistent time stamps, but the timestamps may or may not be aligned with ioMSecs() in the VM. All good so far, but then Christoph pointed out this in the image: Time>>eventMillisecondClock "In order to make certain event handling code work (cf MouseEvent>asMouseMove) we need access to the tick kept by ioMSecs() " "Time eventMillisecondClock" <primitive: 135> ^0 This is being used in multiple places in the image, and it explicitly assumes that event timestamps are relative to ioMSecs() in the VM which is not the case on Windows. This leads me to ask three questions: 1) Does #eventMillisecondClock need to exist? It looks like it might be a kludge, if so could we make it go away? 2) If the eventMillisecondClock method does need to exist, should it be changed to retrieve a millisecond value that is aligned with that of the events? 3) If not 2) then do we need to change the Windows VM to somehow use event timestamps that match eventMillisecondClock? Dave |
Re: Time>>eventMillisecondClock and event timestamps
|
|
I think the key thing is that the answers from the primitive 135 must be aligned with the tick values obtained from primitive 94.
Of course if prim 94 is properly functional (all elements of the event array are correctly filled in) then prim 135 should never be needed; it was created for those machines that waaaaay back when I added the input events still couldn't provide such data. I'm not entirely sure there actually were any.... The only usage of prim 135 not related directly to events seems to be SmalltalkImage>>#vmStatisticsReportOn:, though there are several methods that looks a bit iffy. EventSensor>>#createMouseEvent is only used in a couple of places to do with rectangle transforming interactively, and probably ought to be improved. EventSensor>>#nextEventSynthesized is only used if the EventSensor has no event queue and that is ... a bit complex but probably should never happen since we removed the old InputSensor years and years ago. EventSensor>>#primGetNextEvent: - since we declare the prim essential maybe we should drop the fake-it code and really insist on the prim being there? MorphicEvent>>#timeStamp looks like a probably redundant backup? MouseEvent>>#asMouseMove looks like the new MouseMoveEvent ought to copy the time stamp from the receiver? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim There are no stupid questions. But, there are a lot of inquisitive idiots. |
Re: Time>>eventMillisecondClock and event timestamps
|
|
In reply to this post by David T. Lewis
I don't know the answer to those questions, but in checking its
senders in my image, I did notice a couple by RFB-Server, which is a pretty important external package. Whatever answer is arrived at would be nice if it involves keeping RFB in a functioning state for the community (and hopefully eventually included in the base image). Best, Chris On Fri, Sep 11, 2020 at 4:54 PM David T. Lewis <[hidden email]> wrote: > > Christoph has fixed a bug in event timestamps on the Windows VM. Background > is at https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/518. > > This led us to a question about Time>>eventMillisecondClock. To summarize: > > Events are delivered to the image by the VM, and processed in the image > as e.g. MorphicEvent. Each event has a timeStamp that is an integer number > of milliseconds since some arbitrary starting point. The actual time basis > (starting point) of those timestamps is not important, just as long as they > are consistent. > > In the Windows VM, the event timeStamps are derived from the Windows event > system, and are in milliseconds relative to the time that the Windows system > was started. Other VMs obtain their event time stamps differently, but > normally through ioMSecs() in the VM. > > Thus, for any VM, the events must have internally consistent time stamps, > but the timestamps may or may not be aligned with ioMSecs() in the VM. > > All good so far, but then Christoph pointed out this in the image: > > Time>>eventMillisecondClock > "In order to make certain event handling code work (cf MouseEvent>asMouseMove) we need access > to the tick kept by ioMSecs() " > "Time eventMillisecondClock" > <primitive: 135> > ^0 > > This is being used in multiple places in the image, and it explicitly > assumes that event timestamps are relative to ioMSecs() in the VM which > is not the case on Windows. > > This leads me to ask three questions: > > 1) Does #eventMillisecondClock need to exist? It looks like it might be > a kludge, if so could we make it go away? > > 2) If the eventMillisecondClock method does need to exist, should it be changed > to retrieve a millisecond value that is aligned with that of the events? > > 3) If not 2) then do we need to change the Windows VM to somehow use event > timestamps that match eventMillisecondClock? > > Dave > > > |
Re: Time>>eventMillisecondClock and event timestamps
|
|
Hi all,
aside from the current senders of #eventMillisecondClock in the Trunk image, I wonder whether we would like to keep this possibility open in general. For instance, you could use this value to compare the time of events from different VM- and other image-based sources such as incoming network requests ... This is just a vague guess, what do you think?
With regard to existing dependencies, if we don't really need this selector, we could surely deprecate it and write a fallback to use primitive 240 instead, couldn't we?
Best, Christoph Von: Squeak-dev <[hidden email]> im Auftrag von Chris Muller <[hidden email]>
Gesendet: Samstag, 12. September 2020 02:35:44 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Time>>eventMillisecondClock and event timestamps I don't know the answer to those questions, but in checking its
senders in my image, I did notice a couple by RFB-Server, which is a pretty important external package. Whatever answer is arrived at would be nice if it involves keeping RFB in a functioning state for the community (and hopefully eventually included in the base image). Best, Chris On Fri, Sep 11, 2020 at 4:54 PM David T. Lewis <[hidden email]> wrote: > > Christoph has fixed a bug in event timestamps on the Windows VM. Background > is at https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/518. > > This led us to a question about Time>>eventMillisecondClock. To summarize: > > Events are delivered to the image by the VM, and processed in the image > as e.g. MorphicEvent. Each event has a timeStamp that is an integer number > of milliseconds since some arbitrary starting point. The actual time basis > (starting point) of those timestamps is not important, just as long as they > are consistent. > > In the Windows VM, the event timeStamps are derived from the Windows event > system, and are in milliseconds relative to the time that the Windows system > was started. Other VMs obtain their event time stamps differently, but > normally through ioMSecs() in the VM. > > Thus, for any VM, the events must have internally consistent time stamps, > but the timestamps may or may not be aligned with ioMSecs() in the VM. > > All good so far, but then Christoph pointed out this in the image: > > Time>>eventMillisecondClock > "In order to make certain event handling code work (cf MouseEvent>asMouseMove) we need access > to the tick kept by ioMSecs() " > "Time eventMillisecondClock" > <primitive: 135> > ^0 > > This is being used in multiple places in the image, and it explicitly > assumes that event timestamps are relative to ioMSecs() in the VM which > is not the case on Windows. > > This leads me to ask three questions: > > 1) Does #eventMillisecondClock need to exist? It looks like it might be > a kludge, if so could we make it go away? > > 2) If the eventMillisecondClock method does need to exist, should it be changed > to retrieve a millisecond value that is aligned with that of the events? > > 3) If not 2) then do we need to change the Windows VM to somehow use event > timestamps that match eventMillisecondClock? > > Dave > > >
Carpe Squeak!
|
Re: Time>>eventMillisecondClock and event timestamps
|
|
In reply to this post by timrowledge
Thanks Tim,
I've been digging through version control history, and I think what I see is that the assumption of prim 94 matching prim 135 was valid through the life of the interpreter VM (squeakvm.org SVN sources) but that it had changed for Windows as of the public release of Cog. I don't see anything wrong with the Windows VM implementation (aside from the one bug that Christoph fixed), instead I think we may just be dealing with a holdover assumption that is no longer valid. I'm inclined to think we should see if we can make the prim 135 dependence go away in the image. Some other way of synthesizing event time stamps maybe? Dave On Fri, Sep 11, 2020 at 03:45:35PM -0700, tim Rowledge wrote: > I think the key thing is that the answers from the primitive 135 must be aligned with the tick values obtained from primitive 94. > > Of course if prim 94 is properly functional (all elements of the event array are correctly filled in) then prim 135 should never be needed; it was created for those machines that waaaaay back when I added the input events still couldn't provide such data. I'm not entirely sure there actually were any.... > > The only usage of prim 135 not related directly to events seems to be SmalltalkImage>>#vmStatisticsReportOn:, though there are several methods that looks a bit iffy. > > EventSensor>>#createMouseEvent is only used in a couple of places to do with rectangle transforming interactively, and probably ought to be improved. > EventSensor>>#nextEventSynthesized is only used if the EventSensor has no event queue and that is ... a bit complex but probably should never happen since we removed the old InputSensor years and years ago. > EventSensor>>#primGetNextEvent: - since we declare the prim essential maybe we should drop the fake-it code and really insist on the prim being there? > MorphicEvent>>#timeStamp looks like a probably redundant backup? > MouseEvent>>#asMouseMove looks like the new MouseMoveEvent ought to copy the time stamp from the receiver? > > > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > There are no stupid questions. But, there are a lot of inquisitive idiots. > > > |
Re: Time>>eventMillisecondClock and event timestamps
|
Hi all. Here is a quick thought: It should be possible to synthesize events from within the image to then use those synthesized events along with regular events. Think about testing, mouse over etc. Thus, either #eventMillisecondClock should be platform-specific, or all event timestamps that come from the VM should be similar ... which means that the Windows VM code needs to be changed to not use the MSG structure but ioMSecs. Best, Marcel
|
Re: Time>>eventMillisecondClock and event timestamps
|
|
I do not have any specific solution or approach in mind, but I think
that we should first look at how we might handle this better in the image. The Windows VM is not doing anything wrong, on the contrary I think that its policy of using native MSG timestamps feels like the right thing to do. It seems to me that the problem is our assumption that event timestamps should match the millisecond clock in the VM. Certainly that can be made to work, but seems to me like fixing the wrong problem. Time class>>eventMillisecondClock is a recent addition. Maybe we can find another way to synthesize event time stamps in the image. Dave On Tue, Sep 15, 2020 at 04:32:59PM +0200, Marcel Taeumel wrote: > Hi all. > > Here is a quick thought: It should be possible to synthesize events from within the image to then use those synthesized events along with regular events. Think about testing, mouse over etc. Thus, either #eventMillisecondClock should be platform-specific, or all event timestamps that come from the VM should be similar ... which means that the Windows VM code needs to be changed to not use the MSG structure but ioMSecs. > > Best, > Marcel > Am 12.09.2020 21:58:50 schrieb David T. Lewis <[hidden email]>: > Thanks Tim, > > I've been digging through version control history, and I think what > I see is that the assumption of prim 94 matching prim 135 was valid > through the life of the interpreter VM (squeakvm.org SVN sources) but > that it had changed for Windows as of the public release of Cog. > > I don't see anything wrong with the Windows VM implementation (aside > from the one bug that Christoph fixed), instead I think we may just > be dealing with a holdover assumption that is no longer valid. > > I'm inclined to think we should see if we can make the prim 135 > dependence go away in the image. Some other way of synthesizing event > time stamps maybe? > > Dave > > On Fri, Sep 11, 2020 at 03:45:35PM -0700, tim Rowledge wrote: > > I think the key thing is that the answers from the primitive 135 must be aligned with the tick values obtained from primitive 94. > > > > Of course if prim 94 is properly functional (all elements of the event array are correctly filled in) then prim 135 should never be needed; it was created for those machines that waaaaay back when I added the input events still couldn't provide such data. I'm not entirely sure there actually were any.... > > > > The only usage of prim 135 not related directly to events seems to be SmalltalkImage>>#vmStatisticsReportOn:, though there are several methods that looks a bit iffy. > > > > EventSensor>>#createMouseEvent is only used in a couple of places to do with rectangle transforming interactively, and probably ought to be improved. > > EventSensor>>#nextEventSynthesized is only used if the EventSensor has no event queue and that is ... a bit complex but probably should never happen since we removed the old InputSensor years and years ago. > > EventSensor>>#primGetNextEvent: - since we declare the prim essential maybe we should drop the fake-it code and really insist on the prim being there? > > MorphicEvent>>#timeStamp looks like a probably redundant backup? > > MouseEvent>>#asMouseMove looks like the new MouseMoveEvent ought to copy the time stamp from the receiver? > > > > > > > > tim > > -- > > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > > There are no stupid questions. But, there are a lot of inquisitive idiots. > > > > > > > > |
Re: Time>>eventMillisecondClock and event timestamps
|
|
Hi Dave. > ... but I think that we should first look at how we might handle this better in the image ... To some extent, this will be the good'ol discussion about how to achieve cross-platform compatibility. Whose job is it? VM? Image? Both? Do we want to have "platformName = 'Win32'" (or similar) checks in the image? Or can we rely on platform-independent information coming from the VM? Well, thinking about maybe the future role of FFI for Squeak, we may not want to change too much in the VM at this point. A minimal-effort approach with in-image change might be the right thing to do. :-) Best, Marcel
|
Re: Time>>eventMillisecondClock and event timestamps
|
|
Hi Marcel, Hi Dave,
On Sep 15, 2020, at 8:28 AM, Marcel Taeumel <[hidden email]> wrote:
1. The wrapping millisecond clock is a baaaaaad idea. It wraps in 49 days. The code that used to exist in Time was extremely complex and hard to maintain (fooling the system into being close to wrap around is not easy). And now we do have applications which are expected to run for long periods. But even though it is a bad idea we presumably have applications in images (someone mentioned RFB) which depend on the vm stamping events using the wrapping millisecond clock, and if possible the vm should continue to do so 2. we have a much better much simpler clock that does not wrap and can be used to compare times between images across the globe, the utc microsecond clock. If we want timestamps we should derive them from this clock 3. backwards compatibility. If we change event timestamps do we lose the ability to run 5.x images on the new vm? Is there a way that the vm can be informed by the image whether it wants timestamps? (We can add another image header flag to control the vm response) Regarding 3. I can imagine adding a 32-bit field at the end of a vm event and have having 64 bits (existing time stamp plus new field) to allow stamping the event with the utc clock (& not utc now but the utc updated by the vm heartbeat at 500Hz).
|
Re: Time>>eventMillisecondClock and event timestamps
|
|
Hi all,
I still have very little experience with the VM side stuff, but what Dave says is precisely what I would have claimed, too:
> The Windows VM is not doing anything wrong, on the contrary I think that its policy of using native MSG timestamps feels like the right thing to do.
Best,
Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Dienstag, 15. September 2020 23:07:57 An: The general-purpose Squeak developers list Cc: Open Smalltalk Virtual Machine Development Discussion Betreff: Re: [squeak-dev] Time>>eventMillisecondClock and event timestamps Here's the VM event template:
typedef struct sqInputEvent
{
sqIntptr_t type; /* type of event; either one of EventTypeXXX */
usqIntptr_t timeStamp; /* time stamp */
/* the interpretation of the following fields depend on the type of the event */
sqIntptr_t unused1;
sqIntptr_t unused2;
sqIntptr_t unused3;
sqIntptr_t unused4;
sqIntptr_t unused5;
sqIntptr_t windowIndex; /* SmallInteger used in image to identify a host window structure */
} sqInputEvent;
The interesting thing here is that the timeStamp is already a 64-bit quantity on 64-bit platforms. So it is trivial to use UTC microseconds divided by 1000, or (UTC
microseconds minus start microseconds) divided by 1000, to timestamp events on 64-bit platforms.
On 32-bit platforms we could either add an extra field at the end, or do something heinous with type. We could use 8 bits for the type and the top 24 bits to extend the 32-bit timestamp to 56 bits, which gives us 2.28 million years
of milliseconds, or 2.28 thousand years of microseconds, while still leaving us 248 new event types (we use 8 at the moment).
So why don't we
- modify the VM to stamp events with the utc second clock, either using the full 64-bits of the timestamp on 64-bit platforms, or the 32-bit timestamp and the top 24 bits of the type field on 32-bit platforms.
- add a flag to the image flags that says whether events are time stamped in utc microseconds (if set) or in wrapping milliseconds from startup (or whatever the cross-platform backward-compatiblity semantics should be)
- modify primitive 94 primitiveGetNextEvent to examine the flag and either pass the event up as is, or convert it into a backards=compatible event depending on the flag copied from the image header at startup?
The benefit is that we can ditch support for millisecond time stamps in all parts of the VM other than in primitive 94 primitiveGetNextEvent.
On Tue, Sep 15, 2020 at 9:04 AM Eliot Miranda <[hidden email]> wrote:
_,,,^..^,,,_
best, Eliot
Carpe Squeak!
|
Re: Time>>eventMillisecondClock and event timestamps
|
|
In reply to this post by Eliot Miranda-2
> On 2020-09-15, at 2:07 PM, Eliot Miranda <[hidden email]> wrote: > > > > So why don't we > - modify the VM to stamp events with the utc second clock, The one possible problem I can foresee is if any OS event stuff we try to talk to expects timestamps consistent with its own view; imagine getting some event that needs to be replied to with everything the same except for one field updated etc. If we've stuck our own timestamp in then it could bollix things up. No idea if such events actually exist outside the realm of ancient, faintly remembered, RISC OS cases. *IF* this seems to have any plausibility, then we could stick with using the OS timestamp for the incoming events, but derive our prim 135 tick value from a) catching the first event, reading its timestamp, deriving an offset from our uSec tick, saving that and then doing the math anytime someone wants a prim 135 value, or b) finding out which OS time api is being used by the OS to stamp events; it really should be documented. Of course, we have plenty of experience of OS doc being... imprecise. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: PIC: Permute Instruction Codes |
Re: Time>>eventMillisecondClock and event timestamps
|
|
Hi Tim,
> On Sep 16, 2020, at 10:36 AM, tim Rowledge <[hidden email]> wrote: > > > >> On 2020-09-15, at 2:07 PM, Eliot Miranda <[hidden email]> wrote: >> >> >> >> So why don't we >> - modify the VM to stamp events with the utc second clock, > > The one possible problem I can foresee is if any OS event stuff we try to talk to expects timestamps consistent with its own view; imagine getting some event that needs to be replied to with everything the same except for one field updated etc. If we've stuck our own timestamp in then it could bollix things up. No idea if such events actually exist outside the realm of ancient, faintly remembered, RISC OS cases. Well, having the vm insert the timestamp into the event means that the timestamp can be accurate. What we have now with the proposed changes is that the image timestamps events *immediately after the image retrieves the event via primGetNextEvent:*. This could be significantly later than when the event was delivered to the vm, and quite different to what timestamp, if any, the GUI applied to the event. My proposal merely determines the representation of the timestamp in the image. If, for example, the is timestamps an e end with the time from system startup, then my proposal would require that we obtain the time of system startup and stamp the event delivered up to Smalltalk with the event timestamp plus the startup time, all respires enters as microseconds from the epoch. Mapping back to the GUI’s timestamp is therefore trivial. So using utc microseconds is not the issue. The issue is whether we derive the timestamp from the event itself, or we timestamp the event ourselves. If the GUI timestamps events then overriding that timestamp in the image is incorrect. If the GUI does not timestamp events then having the vm supply a timestamp at the earliest opportunity gives us more accurate timestamps. So in fact your concern makes the case for the vm applying the timestamp: - whether or not the GUI timestamps events is something platform-dependent that the vm must know about, and is in the best position to know about - representing their event timestamp as utc microseconds does nothing other than apply an offset to an event’s timestamp. The events actual timestamp is easily reconstructed given the scale and the offset of the timestamp from microseconds and the epoch. > *IF* this seems to have any plausibility, then we could stick with using the OS timestamp for the incoming events, but derive our prim 135 tick value from > > a) catching the first event, reading its timestamp, deriving an offset from our uSec tick, saving that and then doing the math anytime someone wants a prim 135 value, or > > b) finding out which OS time api is being used by the OS to stamp events; it really should be documented. Of course, we have plenty of experience of OS doc being... imprecise. > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Strange OpCodes: PIC: Permute Instruction Codes > > > |
Re: Time>>eventMillisecondClock and event timestamps
|
|
> On 2020-09-16, at 4:37 PM, Eliot Miranda <[hidden email]> wrote: > > Well, having the vm insert the timestamp into the event means that the timestamp can be accurate. > > What we have now with the proposed changes is that the image timestamps events *immediately after the image retrieves the event via primGetNextEvent:*. Tiny nitpick - *only* if the primitive code didn't provide it or we're synthesizing an event. Otherwise, yes, we're already having the VM do the timestamp. Right now (assuming I'me reading the right files!) a look through all the getevent routines suggests - unix adds the timestamp from a call to ioMSecs, mac does the same except *maybe* for some tablet events?, Windows appears to use OS provided timestamp in the minheadless branch, or a value from GetTickCount() in the host window plugin, or something that looks like an OS provided value in sqWin32DirectInput * sqWin32Window. I'm sure we'll all be relieved to hear that RISC OS & Plan 9 use ioMSecs(). ;-) So we shouldn't ever see the timestamp being empty (for events fetched from the VM) and so shouldn't ever be manually fudging it. I'm pretty sure that is an ancient artefact of no value. It looks like the only platform deriving the timestamp from OS event provided data is Windows. I think that there could only be a problem if synthesized events were being used, AND the time ordering had to be monotonic - do we ever sort events by timestamp? AND the clock used by the Windows to provide the stamp is not aligned with whatever we use fo ioMSecs() etc. But otherwise, yah, no problems, the VM is already providing the timestamp and can use whatever mechanism we want. As for 64/32bit, whatever, I'm sure it can work OK. Would it be too problematic to simply make an LPI to stick into the event buffer? Sure, a bit more garbage but maybe? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Manual Writer's Creed: Garbage in, gospel out. |
Re: Time>>eventMillisecondClock and event timestamps
|
|
In reply to this post by David T. Lewis
For purposes of closing out my original questions for this thread,
conclusions are inline below. On Fri, Sep 11, 2020 at 05:54:16PM -0400, David T. Lewis wrote: > > This leads me to ask three questions: > > 1) Does #eventMillisecondClock need to exist? It looks like it might be > a kludge, if so could we make it go away? > No, eventMillisecondClock does not need to exist. Following recent updates in trunk, it is no longer used for anything related to event time stamps. > 2) If the eventMillisecondClock method does need to exist, should it be changed > to retrieve a millisecond value that is aligned with that of the events? > No. See above. No change is needed. > 3) If not 2) then do we need to change the Windows VM to somehow use event > timestamps that match eventMillisecondClock? > No. Event timestamps from the VM do not need to match eventMillisecondClock. The VM does not need to be fixed. Dave |
Re: Time>>eventMillisecondClock and event timestamps
|
|
I am RSS.i will rto home server to pack my Tape backups in Kim 1 supertape format and take fruity 3.14 witm me to line star74464. z999 = 1935 a..d. Synonym 0 b.c. RSS On Wed, Sep 16, 2020, 8:47 PM David T. Lewis <[hidden email]> wrote: For purposes of closing out my original questions for this thread, |
Re: Time>>eventMillisecondClock and event timestamps
|
|
Will revive Vac on return to line star VAX On Wed, Sep 16, 2020, 9:27 PM Richard Snow <[hidden email]> wrote:
 17499e5bb92b84004151 (8K) Download Attachment rtc-snapshot-2665781299070614601.jpeg (24K) Download Attachment |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |