At 9:43 AM +0100 11/4/99, Georg Gollmann wrote:
>At 12:44 Uhr -0500 03.11.1999, John Duncan wrote:
>>from VM statistics:
>>
>>	incr		738781 in 3,842,182ms (210.0% uptime), avg 5.0ms
>>
>>Is this known to be broken?
>
>The statistics primitives use SmallIntegers, AFAIR. So if your image 
>has been up for a long time or is very large you will get garbage 
>(been there, done that).

Looks like "Uptime" is not calculated properly on some platforms. In
Utilities class>vmStatisticsReportString, the line:

	upTime _ Time millisecondClockValue.

Gets the uptime. on a Unix-like or Linux-like, I think the
millisecondClockValue is based on the time since Squeak was
launched. On the Mac, it is based on the time since the Mac's
clock last wrapped around (i.e., it's fairly meaningless).

It would be a pretty simple matter to capture the current time
(from the seconds clock, not the milliseconds one) when the image
starts up. You could then compute Squeak's uptime to the nearest
second and would not have to worry about clock wrap-arounds.

Meanwhile, I guess I wouldn't trust the VM statistics reports
that refer to % of uptime unless you know that your platform's
millisecond clock starts at zero whenever you launch Squeak...

Georg is correct that the VM statistic counters could overflow,
but that's not the problem here. You could run into it if you had
a server that ran for weeks on end.

Incidentally, that 5 ms average for incremental GC's is pretty
typical of todays machines (it's often less on a G3! :->). So,
Squeak can do lots of things like MIDI in "real time". The Interval
folks were after a much tighter real-time constraints: 100 microseconds
maximum interrupt response time. See Tim Rowledge's paper at

	http://www.squeak.org/oopsla99_vmworkshop

for the four things they had to do to Squeak to achieve that goal.

	-- John