Prev: CyaSSL Java SSL Provider Alpha
Next: How do I rewrite this in a cleaner way?
From: Lew on 30 Jul 2010 07:48
Chris Seidel wrote:
> OK; I got it:
>
> http://communities.vmware.com/thread/215461
>
> Damned, so my Software will not run in VMWare!? :/

The answer lies in the information you neglect to provide.

Your evidence shows that your software does run under VMWare, further, that it
runs according to spec, just not the way you hoped.

--
Lew
From: Thomas Pornin on 30 Jul 2010 08:40
According to Chris Seidel <cseidel(a)arcor.de>:
> i'm using a ScheduledExecutorService to schedule a task. The problem is,
> that the task gets execute about 10 - 20 percent too late, e.g. when I
> schdule it with 20 s delay, it gets executed after 24 s.
>
> Is this "normal"?

No. And I do not have that problem.

ScheduledExecutorService, and the underlying operating system, do not
offer real-time guarantees, and your assertEquals() are overly
optimistic (you could easily get a jitter of a few milliseconds; on
my machine, I get execution after 20001 ms, not 20000). Nevertheless,
4 seconds is a very long time for a PC which executes billions of
instructions every second. If you get 24 seconds instead of 20 then
there is something wrong somewhere.

Also, at least theoretically, you should protect access to the
"executedAtMillis" field, which is modified by one thread and read
by another. Try making it "volatile".

I suggest that you run a minimal test program, without JUnit and
whatever compilation framework you have. Just a single .java file,
javac, and direct command-line invocation. This would help you narrow
the issue a bit.


--Thomas Pornin
From: Chris Seidel on 30 Jul 2010 08:44
On Fri, 30 Jul 2010 14:40:52 +0200, Thomas Pornin <pornin(a)bolet.org> wrote:

> According to Chris Seidel <cseidel(a)arcor.de>:
>> i'm using a ScheduledExecutorService to schedule a task. The problem is,
>> that the task gets execute about 10 - 20 percent too late, e.g. when I
>> schdule it with 20 s delay, it gets executed after 24 s.
>>
>> Is this "normal"?
>
> No. And I do not have that problem.

I already found out, that the problem is that VMWare does not give the
correct values for System.nanoTime() on which SES relies.
Running it outside of VMWARE - everything is ok, only a small diff (ms)
which is acceptable.

Thank you
From: Kevin McMurtrie on 31 Jul 2010 01:11
In article <op.vgngjipjw1eelo(a)msrvcn04.belkin>,
"Chris Seidel" <cseidel(a)arcor.de> wrote:

> On Fri, 30 Jul 2010 10:57:50 +0200, Chris Seidel <cseidel(a)arcor.de> wrote:
>
> > On Thu, 29 Jul 2010 22:27:44 +0200, Daniel Pitts
> > <newsgroup.spamfilter(a)virtualinfinity.net> wrote:
> >
> >> There is no guarantee of the latest it will run, only the earliest.
> >
> > I know. But in my opinion there is absolute no reason for a CONSTANT
> > offset in percent between delay and execution. This is absolute weird.
>
> OK; I got it:
>
> http://communities.vmware.com/thread/215461
>
> Damned, so my Software will not run in VMWare!? :/

This is a Solaris bug, not a VMWare bug. Many threads or processes
reading the high resolution system clock concurrently will cause a
random extra bit along a 32 bit word boundary. A patch is available.

This isn't the bug you're seeing. The extra bit causes an extreme clock
jump that scrambles the JVM. GC and HotSpot will self-tune into
oblivion and scheduled tasks completely halt until the next glitch.
--
I won't see Google Groups replies because I must filter them as spam
From: Chris Seidel on 31 Jul 2010 02:45
On Sat, 31 Jul 2010 07:11:04 +0200, Kevin McMurtrie
<mcmurtrie(a)pixelmemory.us> wrote:

>> http://communities.vmware.com/thread/215461
>>
>> Damned, so my Software will not run in VMWare!? :/
>
> This is a Solaris bug, not a VMWare bug.

No.

I could fix it with the following VMWare settings:

monitor_control.disable_tsc_offsetting=TRUE
monitor_control.disable_rdtscopt_bt=TRUE

Now everything schedules fine, no more constant offset.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: CyaSSL Java SSL Provider Alpha
Next: How do I rewrite this in a cleaner way?