Hi Tobi, Hi Levente,
> On Oct 28, 2020, at 7:06 AM, Tobias Pape <Das.Linux@gmx.de> wrote:
>
>
> Hi
>
>>>>> On 27.10.2020, at 23:39, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
>> Hi Tim,
>> what is the result on that box with threaded heartbeat VM of:
>> [SUnitToolBuilderTests new testHandlingNotification] timeToRun.
>> If it is more than 5000 ms, then you would confirm the problem that I encounter.
>> This testHandlingNotification is repeating 10 loops with a 200ms delay wait.
>> The problem I've got with threaded heartbeat VM is that first 5 delays run normally, but next 5 will last for 1 second instead of 200ms...
>> This is probably what happens on the CI server too (the test times out and CI fails).
>
> Also note that the CI test builds both vms but uses the last one built (because it overwrites the first), and that happens to be the itimer one, not th ethreaded.
>
> The code above runs in around ~2000 ms on my machine (~2015, with ubuntu 18.04)
>
> Things that happened:
> - I just ran the test suite in the DEBUG itimer headful and headless variant and it passes.
> - I just ran the test suite in the DEBUG threaded headful and headless variant and it passes.
> - I ran the RELEASE itimer headful and headless variant and it passes
> - I ran the RELEASE threaded headless variant and it FAILED as on the CI
> - I ran the RELEASE threaded headful variant and it FAILED LESS
> I mean: testHandlingNotification passed, and so did testValueWithinTimingBasic and testValueWithinTimingNestedInner
> but testValueWithinTimingNestedOuter testValueWithinTimingRepeat still fail!
>
> So there are discrepancies between
> debug and release and
> headful and headless (at least for threaded release)
>
> TL;DR: The linux x86_32 cog v3 threaded release vm has a timing problem ...
>
> Does that help anyone?
If you add code to extract the number of ioProcessEvents calls etc (see About Squeak VM parameters tab for the relevant info) does that tell us more? IIRC one available vm parameter is the number of heartbeats. So we should be able to see if it is the heartbeat itself that is failing or if it is further up stream.
Hi Eliot,
I instrumented the code like that:
testHandlingNotification
| receivedSignal resumed |
receivedSignal := resumed := false.
[ | count |
"client-code puts up progress, and signals some notications"
Transcript cr; nextPutAll: 'test begins:'; print: Time utcMicrosecondClock \\ 3600000000.
count := 0.
'doing something'
displayProgressFrom: 0
to: 10
during:
[ : bar | 10 timesRepeat:
[ bar value: (count := count + 1).
Transcript cr; nextPutAll: 'count:'; print: count.
Transcript cr; nextPutAll: 'before wait:'; print: Time utcMicrosecondClock \\ 3600000000.
(Delay forMilliseconds: 200) wait.
Transcript cr; nextPutAll: 'after wait:'; print: Time utcMicrosecondClock \\ 3600000000.
Notification signal: 'message'.
Transcript cr; nextPutAll: 'after notified:'; print: Time utcMicrosecondClock \\ 3600000000.
Transcript cr; nextPutAll: '# ioProcessEvents: '; print: (Smalltalk vmParameterAt: 57).
Transcript cr; nextPutAll: '# forceInterruptCheck: '; print: (Smalltalk vmParameterAt: 58).
Transcript cr; nextPutAll: '# check event calls: '; print: (Smalltalk vmParameterAt: 59).
resumed := true ] ] ]
on: Notification
do:
[ : noti | receivedSignal := true.
Transcript cr; nextPutAll: 'notified at:'; print: Time utcMicrosecondClock \\ 3600000000.
noti resume ].
Transcript endEntry.
self
assert: receivedSignal ;
assert: resumed
The result I obtain with an updated trunk image and 64bits threaded VM:
build.linux64x64/squeak.cog.spur/build$ ./squeak ../../../image/trunk6-64.image
test begins:80631205
notified at:80631251
count:1
before wait:80633324
after wait:80834614
after notified:80834670
# ioProcessEvents: 94
# forceInterruptCheck: 3368
# check event calls: 815
count:2
before wait:80835008
after wait:81036398
after notified:81036454
# ioProcessEvents: 103
# forceInterruptCheck: 3459
# check event calls: 906
count:3
before wait:81036755
after wait:81238355
after notified:81238374
# ioProcessEvents: 113
# forceInterruptCheck: 3549
# check event calls: 996
count:4
before wait:81238633
after wait:81440889
after notified:81440909
# ioProcessEvents: 123
# forceInterruptCheck: 3639
# check event calls: 1086
count:5
before wait:81441151
after wait:82609021
after notified:82609053
# ioProcessEvents: 132
# forceInterruptCheck: 4119
# check event calls: 1161
count:6
before wait:82609520
after wait:83611465
after notified:83611497
# ioProcessEvents: 133
# forceInterruptCheck: 4536
# check event calls: 1162
count:7
before wait:83611974
after wait:84614429
after notified:84614462
# ioProcessEvents: 134
# forceInterruptCheck: 4961
# check event calls: 1165
count:8
before wait:84614926
after wait:85617377
after notified:85617404
# ioProcessEvents: 135
# forceInterruptCheck: 5368
# check event calls: 1166
count:9
before wait:85617840
after wait:86618396
after notified:86618428
# ioProcessEvents: 136
# forceInterruptCheck: 5776
# check event calls: 1167
count:10
before wait:86618896
after wait:87620232
after notified:87620291
# ioProcessEvents: 137
# forceInterruptCheck: 6196
# check event calls: 1168
Notice 10 ioProcessEvents and about 200ms wait on loop 1-5.
Then a single ioProcessEvent and about 1000ms wait on loops 6-10 (single check event call too).