On Tue, Sep 13, 2011 at 02:27:37PM +, thomas.sch...@ascom.com wrote:
> Hi Mroslav,
> > My first guess would be that your kernel doesn't really support the
> > readonly adjtime and every call cancels the previous adjustment. Can
> > you please try it again without noselect and with this patch
On Tue, Sep 13, 2011 at 12:43:54PM +, thomas.sch...@ascom.com wrote:
> PC6: noselect on all servers:
>chronyc> sourcestats
>210 Number of sources = 3
>Name/IP AddressNP NR Span Frequency Freq Skew Offset Std
> Dev
>
>
Hi Miroslav,
> Excellent, I assume you now don't see the frequent source switching.
No, PC6 is stable and using all the time.
>
> I have looked in the linux git and I think I have found the cause:
>
> http://git390.marist.edu/cgi-bin/gitweb.cgi?p=linux-
>
Hi Mroslav,
> My first guess would be that your kernel doesn't really support the
> readonly adjtime and every call cancels the previous adjustment. Can
> you please try it again without noselect and with this patch included?
> Again, the sourcestats output after 15 minutes should be enough.
PC6
> Ok, with noselect the WAN-IP1 and WAN-IP3 servers are tracked very
> well, the third server is the one in virtual machine, so no surprise
> it's a bit off.
>
> Well, this means there is a serious problem in the clock discipline.
>
> Your log says the kernel version is 2.6.27, which was the
Hi Miroslav,
>I'm interested in the test without the application running and the
>test with noselect. Posting the sourcestats output after chrony has
>been running for at least 15 minutes should give us enough
>information.
PC6: noselect on all servers:
chronyc> sourcestats
210 Number of
On Mon, Sep 12, 2011 at 07:21:32PM +, thomas.sch...@ascom.com wrote:
> Hm, I don't know what "good" or "bad" values are, but here you are:
> PC9: still switching (without the application running !):
>voluntary_ctxt_switches:64369
>nonvoluntary_ctxt_switches: 3213
> PC6: no
On Mon, Sep 12, 2011 at 06:15:56PM +, thomas.sch...@ascom.com wrote:
> Hi Miroslav,
> >Please send them to me privately. If I see anything interesting I'll
> >post it here.
> Thank you. I am sending you the archive of PC18, which in my view
> shows the most interesting behaviour:
>
> PC18:
>From the older measurements log it seems that peer delay is stable at ms
>level. If the problem was that chrony is often preempted, I'd expect
>the peer delay to be much worse.
>Maybe this would show that it's not the case:
>$ grep ctxt /proc/`pidof chronyd`/status
>voluntary_ctxt_switches:
Hi Bill,
> First the diagnosis, then the cure.
>There are two separate problems in your system that have been noticed. The
>first is that your system hops from one server to other, and sometimes refuses
>to use either, because of the discrepancy in the times delivered by the
>servers. The second
On Sat, Sep 10, 2011 at 10:45:55AM -0700, Bill Unruh wrote:
> There are two separate problems in your system that have been noticed. The
> first is that your system hops from one server to other, and sometimes refuses
> to use either, because of the discrepancy in the times delivered by the
>
On Mon, Sep 12, 2011 at 08:31:13AM +, thomas.sch...@ascom.com wrote:
> Hi all,
> > First the diagnosis, then the cure.
> OK, the measurements:
> I see that each log archive is quite big (200k...500k) so is it OK if I post
> them all or partly to this ML ?
Please send them to me privately.
Hi all,
>>> The only (relatively) special thing: We have a multi-threaded user space
>>> application running
>>> with a lot of threads (~70): About 6...10 of them are running using the
>>> (almost) realtime
>>> scheduler the standard Linux kernel provides (no RT-patches applied), and
>>> 4..6
On Fri, 9 Sep 2011, thomas.sch...@ascom.com wrote:
Hi Bill,
Overlap
A says that the time offset is 3ms plus or minus 1 ms. Ie, it says the time is
between 2 and 4 ms out. B saus that the offset is -6ms plus or minus 2 ms, ie
from -8 to -4 ms out. Which of the two is the system to use?
Is the
14 matches
Mail list logo
