Well, the Rockhopper which ran the IBMZ Jenkins client is a Z12 running z/VM 6.4 running Ubuntu for Z. As soon as the electrical power prices normalize it will be switched on again - according to the owner - and we can have a look. As an alternative we can try QEMU and see what that does.René. On 14 Nov 2022, at 11:42, P.O. Jonsson <oor...@jonases.se> wrote:
Hello, all. Does this problem occur when the virtual machines are hosted by a *real* hypervisor, namely z/VM? :-)
I which I had a S/390 running z/VM to play with. And a nuclear reactor to power it with... Or is it just something that happens on VMWare?
We use Oracle VirtualBox, not VMWare but I think it is the underlying (desktop) hardware that creates the timing fuss.
OK, thanks!
From: Rick McGuire
[mailto:object.r...@gmail.com]
Sent: 13 November 2022
11:13
To: Open Object Rexx Developer Mailing List
Subject:
Re: [Oorexx-devel] Jenkins
I'm not familiar with internals of ooRexx, but reading
this:
I tried to "tune" Virtualbox to get rid of the
timing error
problems but every attempt actually made things
worse, with
more than half of the timing tests failing. I have
reset
Virtualbox to default values now. What *DID* help on the
other hand was to deprive the VMs of resources. Changing from
2 cores/4 GB memory to 1 core/ 2 GB memory made all *nixes
pass all tests, so it looks like the problem were related to
Virtualbox rather than to ooRexx. Only exception are the
BSDs,
that are still a bit problematic to test. But all
platforms (Win
macOS Linux Unix) build without error now.
makes me
wonder a bit: by reducing to one core then anything multithreaded is
forced to run on a single thread which makes race conditions much
less likely than when on multicore where multiple threads can run
simultaneously.
ooRexx is not truly multithreaded. Only one thread at a time is allowed
to run Rexx code at a time, with a cooperative internal dispatch mechanism.
Only threads running external code (e.g., calls to native libraries or running
commands) truly run concurrently. Multiple cores might affect the timing
of which thread happens to get permission to run next, but which thread gets
permission has always been unpredictable.
Which means that there can be no unexpected time glitches between
threads since they run consecutively on one core. And that ooRexx handles
any such race conditions GREAT. This shows IMO how robust ooRexx 5 has
become. Gold standard ;-)
Right, but in the real
world it will be running on multicore
machines...
The failing test cases run just fine on multicore machines, they only
seem to fail in multicore virtual machines. Also, the failures don't really
appear to be race conditions, but rather checks in timer values that are
falling outside expected ranges. There's something funny going on with the
clocks in the virtual machines in those situations.
_______________________________________________
Oorexx-devel
mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/oorexx-devel
|
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
