From OpenJDK for BSD,
jlong os::javaTimeNanos() {
if (Bsd::supports_monotonic_clock()) {
struct timespec tp;
int status = Bsd::clock_gettime(CLOCK_MONOTONIC, &tp);
assert(status == 0, "gettime error");
jlong result = jlong(tp.tv_sec) * (1000 * 1000 * 1000) + jlong(tp.tv_nsec);
return result;
} else {
timeval time;
int status = gettimeofday(&time, NULL);
assert(status != -1, "bsd error");
jlong usecs = jlong(time.tv_sec) * (1000 * 1000) + jlong(time.tv_usec);
return 1000 * usecs;
}
}
and
jlong os::javaTimeMillis() {
timeval time;
int status = gettimeofday(&time, NULL);
assert(status != -1, "bsd error");
return jlong(time.tv_sec) * 1000 + jlong(time.tv_usec / 1000);
}
Window......
jlong windows_to_java_time(FILETIME wt) {
jlong a = jlong_from(wt.dwHighDateTime, wt.dwLowDateTime);
return (a - offset()) / 10000;
}
FILETIME java_to_windows_time(jlong l) {
jlong a = (l * 10000) + offset();
FILETIME result;
result.dwHighDateTime = high(a);
result.dwLowDateTime = low(a);
return result;
}
// For now, we say that Windows does not support vtime. I have no idea
// whether it can actually be made to (DLD, 9/13/05).
bool os::supports_vtime() { return false; }
bool os::enable_vtime() { return false; }
bool os::vtime_enabled() { return false; }
double os::elapsedVTime() {
// better than nothing, but not much
return elapsedTime();
}
jlong os::javaTimeMillis() {
if (UseFakeTimers) {
return fake_time++;
} else {
FILETIME wt;
GetSystemTimeAsFileTime(&wt);
return windows_to_java_time(wt);
}
}
and
jlong os::javaTimeNanos() {
if (!has_performance_count) {
return javaTimeMillis() * NANOS_PER_MILLISEC; // the best we can do.
} else {
LARGE_INTEGER current_count;
QueryPerformanceCounter(¤t_count);
double current = as_long(current_count);
double freq = performance_frequency;
jlong time = (jlong)((current/freq) * NANOS_PER_SEC);
return time;
}
}
UseFakeTimers is a develop flag so it will always be false in a normal build.
Only Windows uses fake timers.
It looks as if QueryPerformanceCounter uses a TSC.
(http://msdn.microsoft.com/en-us/library/windows/desktop/ms644904(v=vs.85).aspx).
My discussions with the HotSpot team (which is currently evaluating how to use
any monotonic clock that might be available) suggests that gettimeofday uses
the RTC. While TSC is on the chip, the RTC is on a chip of it's own. So this
might account for some of the difference in performance. The MS implementation
requires thread-affinity to work where as the Linux version doesn't. That said,
I still content that thread scheduling has a bigger impact. If you run your
tests in a virtualized environment, one where the hypervisor "interferes" with
the thread scheduler, I think you'll see even worse performance, something that
would not be accounted for by differences in time needed to access a timer.
Regards,
Kirk
On Dec 14, 2011, at 3:16 PM, Peter Lin wrote:
> sorry for the confusion.
>
> There's 2 issues that could result in a performance difference between OS.
>
> The first is getting time from the operating system regardless of
> which method one calls to get a timestamp. Back when I was active in
> jmeter, we used System.currentTimeMillis(). I don't know if it is
> still using that or the newer System.nanoTime().
>
> More succintly
>
> 1. System.nanoTime is slower than System.currentTimeMillis on all OS 20-30%
> 2. getting the system time on linux is slower than on windows and
> solaris. I don't know about aix, hpux or mac.
> 3. getting nanotime on linux is slower than on windows and solaris.
> 4. getting either system time or nano time on linux uses more CPU than windows
>
> The versions of windows doesn't make too much difference. I've tested
> win2K, XP and 7.
> On linux, it doesn't matter which distribution, since it is a feature
> of the kernel. I've had discussion on this topic of henrik stahl, who
> used to lead JRockit at BEA.
>
> Since JMeter gets a timestamp at the start and end of a request, it is
> getting time frequently. This easily accounts for performance
> difference between running JMeter on windows versus linux. The
> difference depends on your stress test.
>
> for example, say I'm testing webpages that are small and fast average
> 100ms per request. The percent of time spent getting timestamp is
> going to be a higher percent of the total CPU time.
>
> In contrast, if I'm testing big webpages that take 60 seconds to load,
> the percent time spent getting timestamp is less.
>
> This is true of any kind of stress test running in Java. I've done
> this with simple POJO that call a main method, JUnit tests, custom
> test framework and JMeter. Basically, the performance difference a
> developer might see between linux and windows with JMeter is the
> result of the JVM + OS. It has nothing to do with JMeter :)
>
>
>
> On Wed, Dec 14, 2011 at 8:59 AM, Deepak Goel <deic...@gmail.com> wrote:
>> @Peter
>>
>> can you please combine your two mails and restate what you are trying
>> to point out. Seems they mean different things:
>>
>> ----------------------
>> Getting currentTimeMillis and nano time has a higher overhead on "linux
>> versus windows"
>>
>> The difference between using currentTimeMillis versus nano time is
>> about 20-30% overhead "regardless of the operating system" or version of
>> JVM.
>> ----------------------
>>
>> Also can you please mention exactly what hardware have you measured
>> your results for?
>>
>> On 12/14/11, Peter Lin <wool...@gmail.com> wrote:
>>> I'll add a little bit more.
>>>
>>> The difference between using currentTimeMillis versus nano time is
>>> about 20-30% overhead regardless of the operating system or version of
>>> JVM.
>>>
>>> I've seen this first hand with Sun, IBM and JRockit on windows and linux.
>>>
>>> OpenJDK is mostly the same as SunJDK, so there's very little
>>> difference from a performance perspective. the SunJDK usually doesn't
>>> include the experimental stuff that OpenJDK might have.
>>>
>>> On Wed, Dec 14, 2011 at 7:41 AM, Deepak Goel <deic...@gmail.com> wrote:
>>>> Hey
>>>>
>>>> Looking at your configuration, here is a possible theory...
>>>>
>>>> Sun Microsystem (Sun JDK) was eaten by Oracle which runs on WINTEL
>>>> platforms so the performance of SUN JDK is optimized on INTEL
>>>> platforms. OpenJDK is meant for Linux platforms a late entry for INTEL
>>>> into this game and hence low performance and high CPU peaks...
>>>>
>>>> Deepak
>>>>
>>>> On 12/14/11, Toni Menendez Lopez <tonime...@gmail.com> wrote:
>>>>> My loadserver is running in this server,
>>>>>
>>>>> Hardware :
>>>>>
>>>>> Proliant BL460C G1
>>>>> 2xIntel Xeon @2,53Ghz (quad)
>>>>> 32 GB of memory
>>>>>
>>>>> O.S :
>>>>> RHEL5.4(Tikanga)
>>>>>
>>>>> I don´t have stats about that but I will collect in few days that I
>>>>> will have again the server available, but my impression is that JMeter
>>>>> is taking much more CPU with OpenJDK and is doing lots of big peaks,
>>>>> seems problems with GC.
>>>>>
>>>>> But I will analyze it later, when my actual testing finished.
>>>>>
>>>>> Toni.
>>>>>
>>>>>
>>>>> 2011/12/13, Deepak Goel <deic...@gmail.com>:
>>>>>> Hey
>>>>>>
>>>>>> Looks like an evolution and quality problem..Sun JDK more evolved v/s
>>>>>> OpenJDK
>>>>>>
>>>>>> What is the hardware? What is the performance difference? Stats
>>>>>> please...
>>>>>>
>>>>>> Deepak
>>>>>>
>>>>>> On 12/13/11, Toni Menendez Lopez <tonime...@gmail.com> wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> I want to ask all of you on question !
>>>>>>>
>>>>>>> I am normally working with SunJDK for Jmeter and running in non-gui
>>>>>>> mode, but now I want to migrate the openJDK ( OpenJDK 64-Bit Server VM
>>>>>>> (build 1.6.0-b09, mixed mode)).
>>>>>>>
>>>>>>> I have executed the same test in SunJDK and OpenJDK and I have
>>>>>>> experienced that Jmeter has worst performance sending the traffic with
>>>>>>> OPenJDK that with SunJDK.
>>>>>>>
>>>>>>> Any of you have got some similar experience ?
>>>>>>>
>>>>>>> My O.S is RHEL5.4
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Toni.
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
>>>>>>> For additional commands, e-mail: user-h...@jmeter.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Namaskara~Nalama~Guten Tag~Bonjour
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Keigu
>>>>>>
>>>>>> Deepak
>>>>>> +91-9765089593
>>>>>> deic...@gmail.com
>>>>>> http://www.simtree.net
>>>>>>
>>>>>> Skype: thumsupdeicool
>>>>>> Google talk: deicool
>>>>>> Blog: http://loveandfearless.wordpress.com
>>>>>> Facebook: http://www.facebook.com/deicool
>>>>>>
>>>>>> "Contribute to the world, environment and more :
>>>>>> http://www.gridrepublic.org
>>>>>> "
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
>>>>>> For additional commands, e-mail: user-h...@jmeter.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
>>>>> For additional commands, e-mail: user-h...@jmeter.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Namaskara~Nalama~Guten Tag~Bonjour
>>>>
>>>>
>>>> --
>>>> Keigu
>>>>
>>>> Deepak
>>>> +91-9765089593
>>>> deic...@gmail.com
>>>> http://www.simtree.net
>>>>
>>>> Skype: thumsupdeicool
>>>> Google talk: deicool
>>>> Blog: http://loveandfearless.wordpress.com
>>>> Facebook: http://www.facebook.com/deicool
>>>>
>>>> "Contribute to the world, environment and more :
>>>> http://www.gridrepublic.org
>>>> "
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
>>>> For additional commands, e-mail: user-h...@jmeter.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
>>> For additional commands, e-mail: user-h...@jmeter.apache.org
>>>
>>>
>>
>>
>> --
>> Namaskara~Nalama~Guten Tag~Bonjour
>>
>>
>> --
>> Keigu
>>
>> Deepak
>> +91-9765089593
>> deic...@gmail.com
>> http://www.simtree.net
>>
>> Skype: thumsupdeicool
>> Google talk: deicool
>> Blog: http://loveandfearless.wordpress.com
>> Facebook: http://www.facebook.com/deicool
>>
>> "Contribute to the world, environment and more : http://www.gridrepublic.org
>> "
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
>> For additional commands, e-mail: user-h...@jmeter.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
> For additional commands, e-mail: user-h...@jmeter.apache.org
>
