cool - thanks for finding that.  Sorry I could not test - nothing setup 
here - but I can test the fix monday.

sam
On 01/26/2014 02:07 PM, Michael Haberler wrote:
> I have a fix which works for me: 
> https://github.com/mhaberler/linuxcnc/commit/10924b5509a2d2e38533a9f9e876d139a2cf5d4b
>  (branch unified-build-candidate-3)
>
> I'd appreciate reports - this should repair the "latency-test: jitter going 
> down" error
>
> NB: this error did show only on i386 kernels, not on x86_64
>
> the clocksource was not involved
>
> - Michael
>
> Am 26.01.2014 um 18:02 schrieb Peter C. Wallace <[email protected]>:
>
>> On Sun, 26 Jan 2014, Michael Haberler wrote:
>>
>>> Date: Sun, 26 Jan 2014 17:40:19 +0100
>>> From: Michael Haberler <[email protected]>
>>> To: Peter C. Wallace <[email protected]>,
>>>     EMC developers <[email protected]>
>>> Subject: Re: [Emc-developers] reports on rt-preempt / latency-test: max 
>>> jitter
>>>      going down
>>>
>>> Am 26.01.2014 um 17:28 schrieb Peter C. Wallace <[email protected]>:
>>>
>>>> On Sun, 26 Jan 2014, Michael Haberler wrote:
>>>>
>>>>> Date: Sun, 26 Jan 2014 09:59:52 +0100
>>>>> From: Michael Haberler <[email protected]>
>>>>> To: EMC developers <[email protected]>
>>>>> Subject: Re: [Emc-developers] reports on rt-preempt / latency-test: max 
>>>>> jitter
>>>>>     going down
>>>>> could the folks observing this behaviour please run the following 
>>>>> commands on their systems:
>>>>>
>>>>> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>>>>>
>>>>> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>>>>>
>>>>> background: Answer 2 of: 
>>>>> http://stackoverflow.com/questions/5930621/problem-of-understanding-clock-gettime
>>>>>
>>>>> thanks!
>>>>
>>>> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>>>> tsc acpi_pm
>>>>
>>>> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>>>> tsc
>>> hm, I would have expected to find 'hpet' there (see also link below)
>>> maybe for some reason HPET isnt enabled in the kernel so not settable
>>>
>>> (is that by chance my howegrown 3.1x-mah rt-preempt kernel..?)
>> Yes
>>
>>>
>>>>
>>>> I changed the clocksource to acpi_pm but the error remains
>>> acpi_pm is probably the worst of all in terms of resolution, 3.58Mhz: 
>>> http://stackoverflow.com/questions/7987671/what-is-the-acpi-pm-linux-clocksource-used-for-what-hardware-implements-it
>>>
>>> it's probably a good idea to figure out the best clock source, and make 
>>> sure in the startup phase it's actually selected (assuming this is related 
>>> at all)
>>>
>>>> One interesting thing is that the error is periodic with a ~4 second period
>>>> (like an uncaught 32 bit ns count wrap)
>>> hm, thats an interesting observation. Need to read the timedelta and 
>>> rtapi_time code once more to see if there's something smelly.
>>>
>>> does that 4 second period show up with either clock source just alike? if 
>>> so, this would suggest the clock source not be the cause
>>
>>
>> Yes, same ~4 second period with either clock source, I HAL 'scoped
>> the baddelta staircase and its 4.3 seconds as you would expect with a
>> uncaught 32 bit wrap
>>
>>> I should be next to real hardware soon
>>>
>>> thanks!
>>>
>>> - Michael
>>>
>>>>
>>>>
>>>>
>>>>> - Michael
>>>>>
>>>>>
>>>>> Am 25.01.2014 um 17:03 schrieb Michael Haberler <[email protected]>:
>>>>>
>>>>>> Peter Wallace kindly help to locate the error, it is rtapi_get_time() 
>>>>>> going backwards occasionally on rt-preempt, suggesting the cause is this 
>>>>>> function:
>>>>>>
>>>>>> https://github.com/mhaberler/linuxcnc/blob/e3de5bb74857bbd9935c1a1d1f031a0558ca0f85/src/rtapi/rtapi_time.c#L166
>>>>>>
>>>>>> this cause the 'del' variable in 
>>>>>> https://github.com/mhaberler/linuxcnc/blob/e3de5bb74857bbd9935c1a1d1f031a0558ca0f85/src/hal/components/timedelta.comp
>>>>>>  to become negative at times, causing the decreasing jitter
>>>>>>
>>>>>> no fix yet, but we know where to look
>>>>>>
>>>>>> -m
>>>>>>
>>>>>>
>>>>>> Am 25.01.2014 um 08:43 schrieb Michael Haberler <[email protected]>:
>>>>>>
>>>>>>> Reading back on IRC I found hints at rt-preempt ubc3 builds showing the 
>>>>>>> max latency going down occasionally.
>>>>>>>
>>>>>>> Please:
>>>>>>>
>>>>>>> 1. report the exact kernel version, in particular if this is stock 
>>>>>>> debian rt-preempt kernel.
>>>>>>> 2. check if ntp is running or not, i.e. the output of 'ps ax|grep ntp'
>>>>>>> 3. If yes, please stop the ntp demon with 'sudo /etc/init.d/ntp stop' 
>>>>>>> or equivalent
>>>>>>> 4. Re-run latency-test after ntp is stopped. Does the problem reoccur?
>>>>>>> 5. Please report your results using the ubc issue tracker as mentioned 
>>>>>>> here 
>>>>>>> http://static.mah.priv.at/public/html/common/UnifiedBuild.html#_issue_tracker
>>>>>>>  , for this issue: https://github.com/zultron/linuxcnc/issues/72
>>>>>>>
>>>>>>> background: there is a chance that the issue is related to the behavior 
>>>>>>> described here, in particular the subtle difference between 
>>>>>>> CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW:
>>>>>>>
>>>>>>> http://stackoverflow.com/questions/3657289/linux-clock-gettimeclock-monotonic-strange-non-monotonic-behavior
>>>>>>> http://markmail.org/thread/54bb663vi47kjxnu
>>>>>>>
>>>>>>> - Michael
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>>>>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>>>>>> Critical Workloads, Development Environments & Everything In Between.
>>>>>>> Get a Quote or Start a Free Trial Today.
>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>>>>>> _______________________________________________
>>>>>>> Emc-developers mailing list
>>>>>>> [email protected]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>>>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>>>>> Critical Workloads, Development Environments & Everything In Between.
>>>>>> Get a Quote or Start a Free Trial Today.
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>>>>> _______________________________________________
>>>>>> Emc-developers mailing list
>>>>>> [email protected]
>>>>>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>>> Peter Wallace
>>>> Mesa Electronics
>>>>
>>>> (\__/)
>>>> (='.'=) This is Bunny. Copy and paste bunny into your
>>>> (")_(") signature to help him gain world domination.
>> Peter Wallace
>> Mesa Electronics
>>
>> (\__/)
>> (='.'=) This is Bunny. Copy and paste bunny into your
>> (")_(") signature to help him gain world domination.
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Emc-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to