On 12/1/19 2:44 AM, Achim Gratz via devel wrote:
> Richard Laager via devel writes:
>> The issue persists when removing "nts" from "server" lines (i.e.
>> disabling NTS client behavior).
>>
>> The problem goes away when disabling NTS server behavior.
To clarify: If I run as an NTS client but not N
Richard Laager via devel writes:
> The issue persists when removing "nts" from "server" lines (i.e.
> disabling NTS client behavior).
>
> The problem goes away when disabling NTS server behavior.
I don't serve NTS from the two test machines, so that would be an
additional code path to consider.
Richard Laager via devel writes:
> That was the case for me _at startup_, but not after that. (See the
> attached logs.)
I think the culprit is somewhere in the NTS client code.
>>> This would also explain why a server
>>> that has many clients would see many more such errors.
>
> Why's that? Wh
On 12/1/19 2:17 AM, Richard Laager via devel wrote:
> On 11/30/19 6:17 AM, ASSI via devel wrote:
>> ASSI via devel writes:
>>> is… intriguing. If you follow the code through the function, ts_min in
>>> the log should always be ts_prev+sys_fuzz; these two values can't be
>>> identical or differ by
On 11/30/19 6:17 AM, ASSI via devel wrote:
> ASSI via devel writes:
>> is… intriguing. If you follow the code through the function, ts_min in
>> the log should always be ts_prev+sys_fuzz; these two values can't be
>> identical or differ by any other value, ts_min must strictly be greater
>> than t
ASSI via devel writes:
> is… intriguing. If you follow the code through the function, ts_min in
> the log should always be ts_prev+sys_fuzz; these two values can't be
> identical or differ by any other value, ts_min must strictly be greater
> than ts_prev by sys_fuzz. I notice that there is alway
