3 Replies Latest reply: Apr 14, 2008 1:52 AM by 807557 RSS

    Clock goes backwards.

    807557
      Hi,

      I think the my clock sometimes goes backwards. This is a stripped down version of my code.

      This is running on a Realtime maxpriority thread.

      Clock clock=Clock.getRealtimeClock();
      long t1=clock.getTime().getNanoseconds();
      work();
      long t2=clock.getTime().getNanoseconds();
      assert(t2>=t1); // this fails

      --- setup

      java -version
      java version "1.5.0_13"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13_JavaRTS-2.1_EA-nb021_RTSJ-1.0.2)
      Java Real-Time System HotSpot(TM) Client VM (build 1.5.0_13, mixed mode)

      ubuntu 8.04

      uname -a
      Linux bunty 2.6.24-15-generic #1 SMP Tue Apr 8 00:33:51 UTC 2008 i686 GNU/Linux

      Thinkpad X61 dual core.

      ----

      I do get this message in dmesg on boot "Clocksource tsc unstable".

      Which can apparently be caused by frequency switching. I use the gnome scaling monitor to force the CPUs to be fixed to 1.6Ghz

      Does any one know how to fix this problem ?

      Does the java Clock get the time from the current (possibly different?) CPU ?

      Can I force the realtime thread to live on a given CPU?


      cheers Paul.
        • 1. Re: Clock goes backwards.
          807557
          $ uname -a
          Linux bunty 2.6.24-15-rt #1 SMP PREEMPT RT Tue Apr 8 02:25:55 UTC 2008 i686 GNU/Linux

          This does not help. I also disabled the CPU frequency and power save options in the BIOS.

          I still get this message on boot

          [   18.958304] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
          [   19.070491] checking TSC synchronization [CPU#0 -> CPU#1]:
          [   19.090481] Measured 261160 cycles TSC warp between CPUs, turning off TSC clock.
          [   19.090484] Marking TSC unstable due to: check_tsc_sync_source failed.

          Does this explain problem? If so is there any way around it? My application requires one realtime thread that would be OK if it just ran on 1 CPU leaving the other to do the non realtime tasks.

          PJ.
          • 2. Re: Clock goes backwards.
            807557
            DR_PJ wrote:
            I think the my clock sometimes goes backwards. This is a stripped down version of my code.

            Clock clock=Clock.getRealtimeClock();
            long t1=clock.getTime().getNanoseconds();
            work();
            long t2=clock.getTime().getNanoseconds();
            assert(t2>=t1); // this fails
            Did you perhaps overstrip this - getNanoseconds() only returns the nanosecond portion of the time, you also have to check the milliseconds part.?
            eg. Try assert(t2.compareTo(t1) >=0)

            BTW Always use the getTime(dest) version to avoid the allocation overhead.
            I do get this message in dmesg on boot "Clocksource tsc unstable".
            This is very common - the tsc is unstable on most mp systems.

            Check the available and current clocksource used by the kernel (you need to be root):
            ~ # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
            hpet acpi_pm jiffies tsc
            ~ # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
            hpet
            You want to use hpet if available, else acpi_pm. You do not want jiffies. You do not want TSC if you have an unstable TSC. To set the clocksource just write to the current_clocksource file eg:

            echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource
            Can I force the realtime thread to live on a given CPU?
            Not directly. Java RTS allows all RealtimeThreads and all NoHeapRealtimeThreads to be bound to particular cpu or group of CPUs (processor sets on Solaris, cpusets on Linux). But this functionality is only available on Linux in the forthcoming 2.1 beta

            David Holmes
            • 3. Re: Clock goes backwards.
              807557
              David,

              Thanks, adding the getMilliseconds() has sorted out my current problem .
              Also thanks for insight about allocation and the timers.

              best regards Paul.