Loading ...
Sorry, an error occurred while loading the content.

Apparent Time Drift - JT65/JT9

Expand Messages
  • Joe
    Randy, I have experienced similar time differences using VAC with PSDR for home made rigs on an XP machine. The creep is always of the other stations having a
    Message 1 of 5 , Mar 18, 2014
    • 0 Attachment
      Randy,

      I have experienced similar time differences using VAC with PSDR for home
      made rigs on an XP machine.

      The creep is always of the other stations having a positive difference.
      The shifts seem to be about a 1/2 second at a time every 5 hours or
      so. The creep isn't gradual as far as I can tell, it seems to be more
      like a step function.

      When looking at the D4 or Meinberg update logs, the the corrections
      always were a .01 second or so and the longer time displays (daily or
      weekly) did not show a sawtooth pattern which would have been shown if
      there was a CPU clock drift and subsequent correction.

      In my case, my get-around was to re-boot the machine and I would see the
      time differences on received stations to return to the more normal +/- 1
      second.

      I don't remember if I saw the same correction by just ending PSDR (and
      VAC) and re-running them.

      The problem was fairly (maybe totally) consistent over a day to day
      period. I tend to never turn that machine off when not in use. Since I
      feed reports to the PSKReporter, PSDR runs for at least 20 hours between
      restarts. The CPU usage tends to be under 40% for most of the Rx minute
      with peaks above 70% but not above 90% during the decode period.

      I wonder what OS you are running and if you tend to let PSDR run for
      extended periods of time (days?). Typical CPU usage would also be of
      interest.

      The problem may be more prevalent on machines running close to 100% CPU
      utilization.

      Also, can anyone offer an explanation of what may be causing this or as
      to what the mechanism might be?

      I never would have expected a audio function such as VAC to mess with
      the time function in the OS while not affecting the CPU clock itself.

      I hope that this VAC alternative is the solution to our mutual problem.

      Joe, K9HDE
    • Randy Diddel
      Hi Joe, I am running Windows 7 Pro. The issue just started around 2-3 weeks ago. Around that time I purchased the VAC. There was no issue with the trial
      Message 2 of 5 , Mar 18, 2014
      • 0 Attachment
        Hi Joe,  

        I am running Windows 7 Pro.  The issue just started around 2-3 weeks ago.  Around that time I purchased the VAC. There was no issue with the trial version.  Around that same time I installed Microsoft Security Essentials AV.  I removed the latter and there was no improvement.  

        It has been 24 hours with PSDR, WSJTX, and VB virtual audio cable and there has been no drift-everything is +/- 1 second or less for the majority of stations I see.  It appears that it is an issue with the paid version of VAC plain and simple.

        System:

        Windows 7 Pro
        8GB Ram
        Intel Core 2 Duo @ 3 GHZ 
        120 Crucial SATA drive

        CPU is around 10-20% at idle and TX with PSDR
        23% Memory Utilization

        Resources are not an issue here at least on paper.... This particular PC is dedicated to my station and has Log4OM, WSJTX, MySQL (for the log db), VB virtual audio cable.  I have disabled all non essential Windows Services and things running in the background.

        73


        /randy


        On Tue, Mar 18, 2014 at 4:39 AM, Joe <k9hde@...> wrote:
        Randy,

        I have experienced similar time differences using VAC with PSDR for home made rigs on an XP machine.

        The creep is always of the other stations having a positive difference.  The shifts seem to be about a 1/2 second at a time every 5 hours or so.  The creep isn't gradual as far as I can tell, it seems to be more like a step function.

        When looking at the D4 or Meinberg update logs, the the corrections always were a .01 second or so and the longer time displays (daily or weekly) did not show a sawtooth pattern which would have been shown if there was a CPU clock drift and subsequent correction.

        In my case, my get-around was to re-boot the machine and I would see the time differences on received stations to return to the more normal +/- 1 second.

        I don't remember if I saw the same correction by just ending PSDR (and VAC) and re-running them.

        The problem was fairly (maybe totally) consistent over a day to day period.  I tend to never turn that machine off when not in use.  Since I feed reports to the PSKReporter, PSDR runs for at least 20 hours between restarts.  The CPU usage tends to be under 40% for most of the Rx minute with peaks above 70% but not above 90% during the decode period.

        I wonder what OS you are running and if you tend to let PSDR run for extended periods of time (days?).  Typical CPU usage would also be of interest.

        The problem may be more prevalent on machines running close to 100% CPU utilization.

        Also, can anyone offer an explanation of what may be causing this or as to what the mechanism might be?

        I never would have expected a audio function such as VAC to mess with the time function in the OS while not affecting the CPU clock itself.

        I hope that this VAC alternative is the solution to our mutual problem.

        Joe, K9HDE


      • Joe
        Randy, That s great news! It will be interesting to see if others have had the same problem and if VB is a solution for them also. I still can t fathom as to
        Message 3 of 5 , Mar 18, 2014
        • 0 Attachment
          Randy,

          That's great news!   It will be interesting to see if others have had the same problem and if VB is a solution for them also.

          I still can't fathom as to how the time can be reported by wsjt differently than the actual value of the system clock.

          Well good for you and the rest of us.  8-)

          Joe, K9HDE

          On 03/18/2014 09:09 AM, Randy Diddel wrote:
          Hi Joe,  

          I am running Windows 7 Pro.  The issue just started around 2-3 weeks ago.  Around that time I purchased the VAC. There was no issue with the trial version.  Around that same time I installed Microsoft Security Essentials AV.  I removed the latter and there was no improvement.  

          It has been 24 hours with PSDR, WSJTX, and VB virtual audio cable and there has been no drift-everything is +/- 1 second or less for the majority of stations I see.  It appears that it is an issue with the paid version of VAC plain and simple.

          System:

          Windows 7 Pro
          8GB Ram
          Intel Core 2 Duo @ 3 GHZ 
          120 Crucial SATA drive

          CPU is around 10-20% at idle and TX with PSDR
          23% Memory Utilization

          Resources are not an issue here at least on paper.... This particular PC is dedicated to my station and has Log4OM, WSJTX, MySQL (for the log db), VB virtual audio cable.  I have disabled all non essential Windows Services and things running in the background.

          73


          /randy


          On Tue, Mar 18, 2014 at 4:39 AM, Joe <k9hde@...> wrote:
          Randy,

          I have experienced similar time differences using VAC with PSDR for home made rigs on an XP machine.

          The creep is always of the other stations having a positive difference.  The shifts seem to be about a 1/2 second at a time every 5 hours or so.  The creep isn't gradual as far as I can tell, it seems to be more like a step function.

          When looking at the D4 or Meinberg update logs, the the corrections always were a .01 second or so and the longer time displays (daily or weekly) did not show a sawtooth pattern which would have been shown if there was a CPU clock drift and subsequent correction.

          In my case, my get-around was to re-boot the machine and I would see the time differences on received stations to return to the more normal +/- 1 second.

          I don't remember if I saw the same correction by just ending PSDR (and VAC) and re-running them.

          The problem was fairly (maybe totally) consistent over a day to day period.  I tend to never turn that machine off when not in use.  Since I feed reports to the PSKReporter, PSDR runs for at least 20 hours between restarts.  The CPU usage tends to be under 40% for most of the Rx minute with peaks above 70% but not above 90% during the decode period.

          I wonder what OS you are running and if you tend to let PSDR run for extended periods of time (days?).  Typical CPU usage would also be of interest.

          The problem may be more prevalent on machines running close to 100% CPU utilization.

          Also, can anyone offer an explanation of what may be causing this or as to what the mechanism might be?

          I never would have expected a audio function such as VAC to mess with the time function in the OS while not affecting the CPU clock itself.

          I hope that this VAC alternative is the solution to our mutual problem.

          Joe, K9HDE


        • Ton PA0TBR
          Hello all, In the past I experienced drift problems with XP and Dimension 4. The PC s had been running in sync very well for a long time before the problem
          Message 4 of 5 , Mar 19, 2014
          • 0 Attachment
            Hello all,

            In the past I experienced drift problems with XP and Dimension 4. The PC's had been running in sync very well for a long time before the problem started. I was not using VAC at the time. I then changed to Meinberg, which has given me excellent synchronization since.
            I am now using Windows 8, VAC and Meinberg. It works very well and also has a good monitoring tool.

            For a quick check I use www.time.is 

            73,
            Ton PA0TBR
             


            On Tue, Mar 18, 2014 at 10:17 PM, Joe <k9hde@...> wrote:
             

            Randy,

            That's great news!   It will be interesting to see if others have had the same problem and if VB is a solution for them also.

            I still can't fathom as to how the time can be reported by wsjt differently than the actual value of the system clock.

            Well good for you and the rest of us.  8-)

            Joe, K9HDE


            On 03/18/2014 09:09 AM, Randy Diddel wrote:
            Hi Joe,  

            I am running Windows 7 Pro.  The issue just started around 2-3 weeks ago.  Around that time I purchased the VAC. There was no issue with the trial version.  Around that same time I installed Microsoft Security Essentials AV.  I removed the latter and there was no improvement.  

            It has been 24 hours with PSDR, WSJTX, and VB virtual audio cable and there has been no drift-everything is +/- 1 second or less for the majority of stations I see.  It appears that it is an issue with the paid version of VAC plain and simple.

            System:

            Windows 7 Pro
            8GB Ram
            Intel Core 2 Duo @ 3 GHZ 
            120 Crucial SATA drive

            CPU is around 10-20% at idle and TX with PSDR
            23% Memory Utilization

            Resources are not an issue here at least on paper.... This particular PC is dedicated to my station and has Log4OM, WSJTX, MySQL (for the log db), VB virtual audio cable.  I have disabled all non essential Windows Services and things running in the background.

            73


            /randy


            On Tue, Mar 18, 2014 at 4:39 AM, Joe <k9hde@...> wrote:
            Randy,

            I have experienced similar time differences using VAC with PSDR for home made rigs on an XP machine.

            The creep is always of the other stations having a positive difference.  The shifts seem to be about a 1/2 second at a time every 5 hours or so.  The creep isn't gradual as far as I can tell, it seems to be more like a step function.

            When looking at the D4 or Meinberg update logs, the the corrections always were a .01 second or so and the longer time displays (daily or weekly) did not show a sawtooth pattern which would have been shown if there was a CPU clock drift and subsequent correction.

            In my case, my get-around was to re-boot the machine and I would see the time differences on received stations to return to the more normal +/- 1 second.

            I don't remember if I saw the same correction by just ending PSDR (and VAC) and re-running them.

            The problem was fairly (maybe totally) consistent over a day to day period.  I tend to never turn that machine off when not in use.  Since I feed reports to the PSKReporter, PSDR runs for at least 20 hours between restarts.  The CPU usage tends to be under 40% for most of the Rx minute with peaks above 70% but not above 90% during the decode period.

            I wonder what OS you are running and if you tend to let PSDR run for extended periods of time (days?).  Typical CPU usage would also be of interest.

            The problem may be more prevalent on machines running close to 100% CPU utilization.

            Also, can anyone offer an explanation of what may be causing this or as to what the mechanism might be?

            I never would have expected a audio function such as VAC to mess with the time function in the OS while not affecting the CPU clock itself.

            I hope that this VAC alternative is the solution to our mutual problem.

            Joe, K9HDE



          • k3wyc
            I still can t fathom as to how the time can be reported by wsjt differently than the actual value of the system clock. it may be completely unrelated this
            Message 5 of 5 , Mar 19, 2014
            • 0 Attachment

              "I still can't fathom as to how the time can be reported by wsjt differently than the actual value of the system clock. "


              it may be completely unrelated this but, a while ago, I was experimenting with using Spectrum Lab filtering between the audio codec and wsjt-x.  I used VAC  to route the signals.   I wanted to see if there was any advantage to being able to put narrow pass band filters or adjustable notch filters in the signal path.   I was surprised to find that Spectrum Lab introduced up to 2sec delay in the signal path and this showed up in wsjt-x as the signals having a time error of up to 2 seconds.  The clocks were right but the audio signal was delayed.  Leaving VAC and Spectrum Lab  in the loop, but killing the Spectrum Lab filtering, eliminated the time error.


              73,

              Andy k3wyc



            Your message has been successfully submitted and would be delivered to recipients shortly.