This discussion is archived
4 Replies Latest reply: Nov 23, 2008 1:05 PM by 807557 RSS

Show resolution of timer service in Sun RTS

807557 Newbie
Currently Being Moderated
RTSJ provides a "high-resolution" timer service, and I want to know exactly how high that resolution is. I'm using Sun RTS 2.1. As I recall, the RTS used to print out the resolution on start-up, but it's not doing that anymore. I checked the documentation, but I don't see a command for that. Am I missing something?
  • 1. Re: Show resolution of timer service in Sun RTS
    807557 Newbie
    Currently Being Moderated
    Hi Trevor,

    I'm not aware that we ever reported resolution information on startup ... perhaps back in 1.0 but I don't know about that.

    The resolution of the "timer service" is platform dependent as it comes from the underlying services of the OS on a given platform, and so depends on the timing hardware available on that platform. I don't have hard numbers - and you'd have to define exactly what resolution you were referring to to try and get hard numbers. The main thing is that these services are not tied to "clock tick" processing so they aren't limited by the 10ms/1ms resolution of the time-of-day clock.

    David Holmes
  • 2. Re: Show resolution of timer service in Sun RTS
    807557 Newbie
    Currently Being Moderated
    davidholmes wrote:
    The resolution of the "timer service" is platform dependent as it comes from the underlying services of the OS on a given platform, and so depends on the timing hardware available on that platform.
    Right, it's not something I can just look up somewhere. That's why I need some way (whether via RTS or something else) of finding out what that resolution is. For instance, if I call System.nanoTime, I'd like to know how precise it will be.
    davidholmes wrote:
    The resolution of the "timer service" is platform dependent as it comes from the underlying services of the OS on a given platform, and so depends on the timing hardware available on that platform.
    I'm running RTS on a Solaris 10 SPARC machine, which I believe uses something called a "cyclic driver" to provide the timer service. I'm wanting to know what the resolution is for that service.
  • 3. Re: Show resolution of timer service in Sun RTS
    807557 Newbie
    Currently Being Moderated
    trevor@vocaro.com wrote:
    davidholmes wrote:
    The resolution of the "timer service" is platform dependent as it comes from the underlying services of the OS on a given platform, and so depends on the timing hardware available on that platform.
    Right, it's not something I can just look up somewhere. That's why I need some way (whether via RTS or something else) of finding out what that resolution is. For instance, if I call System.nanoTime, I'd like to know how precise it will be.
    Do you mean what the smallest non-zero observable update will be? The VM can't tell you because the OS doesn't (can't?) tell it; and it ultimately depends on what hardware is used and how the OS is configured. For example on linux you can select the clock source to be one of a number of devices that may be available: hpet, acpi, TSC etc. The resolution of the reported time is dependent on that. The TSC can be read in a couple of cycles but is generally an unreliable clocksource, whereas the HPET can take a few micros to read.

    On Solaris on sparc and x86 we use gethrtime underneath nanoTime and the value read is typically close to a cycle counter so updates are only a few nanoseconds apart at the lowest level (again this ultimately depends on the exact hardware). But there are overheads associated with reading the value through something like nanoTime.
    davidholmes wrote:
    The resolution of the "timer service" is platform dependent as it comes from the underlying services of the OS on a given platform, and so depends on the timing hardware available on that platform.
    I'm running RTS on a Solaris 10 SPARC machine, which I believe uses something called a "cyclic driver" to provide the timer service. I'm wanting to know what the resolution is for that service.
    The Cyclic driver is used for periodic thread control ( managing waitForNextPeriod), deadline monitoring for periodic threads, RealtimeThread.sleep and HighResolutionTime.wait. The POSIX timer API (timer_create etc with CLOCK_HIGHRES) is used for actual javax.realtime.Timer and for deadline monitoring for AsyncEventHandlers. Ultimately these all use the Solaris cyclic subsystem, but their observable performance can be quite different at the RTSJ API level.

    I can quote the following regarding the cyclic subsystem:
    The heap maintained by the cyclic subsystem assures that the granularity of interval timers will be that of the interrupt source (on UltraSPARC, this granularity is typically on the order of ~4 nanoseconds).
    but of course there are layers of software to go through that increase that value in terms of an observable minimum time between events.

    I hope this helps, but ultimately it's a question of measuring the performance of a given API under actual use conditions.

    David Holmes
  • 4. Re: Show resolution of timer service in Sun RTS
    807557 Newbie
    Currently Being Moderated
    On Linux with high res timer enabled there should be a file /proc/timer_list that lists the timer resolutions.
    ========================================================
    % cat /proc/timer_list
    Timer List Version: v0.3
    HRTIMER_MAX_CLOCK_BASES: 2
    now at 253192951251 nsecs

    cpu: 0
    clock 0:
    .index: 0
    .resolution: 1 nsecs
    .get_time: ktime_get_real
    .offset: 1227473379261463477 nsecs
    active timers:
    clock 1:
    .index: 1
    .resolution: 1 nsecs
    .get_time: ktime_get
    .offset: 0 nsecs
    active timers:
    #0: <f6307ea8>, tick_sched_timer, S:01, tick_setup_sched_timer, sirq-timer/0/6
    # expires at 253193000000 nsecs [in 48749 nsecs]
    ...
    ======================================================================

    We have found that Linux has trouble enabling the high resolution timers on some older industrial control boards and may default back to 1mSec resolution.

    If you are running Redhat MRG there is also a rtcheck utility you can install and run to see if the environment is ready for real-time Java:

    =======================================================================
    % /usr/bin/rtcheck -v
    RTCheck v0.6 - Linux Real-time Environment Checker
    --------------------------------------------------
    Global tests:
    Retrieving cache validator: ok
    Validating cache /var/cache/rtcheck: failed
    cache file does not exist
    Using cached result status: failed
    result status is: -1
    Re-running tests...
    Checking for out-of-tree RT extensions: ok
    Checking for robust (PI) mutex support: ok
    Testing for acceptable hrtimer resolution (<=20us): ok
    Testing for acceptable clock resolution (<=200us): ok
    Caching results in /var/cache/rtcheck: ok
    User-specific tests:
    Trying to lock memory: ok
    Trying to request real-time scheduling: ok
    All tests passed
    =============================================================