From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olegrok@tarantool.org>
Received: from smtp48.i.mail.ru (smtp48.i.mail.ru [94.100.177.108])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id B9633469710
 for <tarantool-patches@dev.tarantool.org>;
 Mon,  4 May 2020 17:26:35 +0300 (MSK)
From: Oleg Babin <olegrok@tarantool.org>
References: <cover.1588292014.git.v.shpilevoy@tarantool.org>
 <badc06d86e3f52b59453184d42f2f1e5d0537e47.1588292014.git.v.shpilevoy@tarantool.org>
 <40b31a98-794a-82f6-4332-37996194ac8b@tarantool.org>
 <77fc8155-27d7-84c3-39ac-444bd773085a@tarantool.org>
Message-ID: <0745d082-78c6-87b1-ec50-6c164fc689c5@tarantool.org>
Date: Mon, 4 May 2020 17:26:29 +0300
MIME-Version: 1.0
In-Reply-To: <77fc8155-27d7-84c3-39ac-444bd773085a@tarantool.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Subject: Re: [Tarantool-patches] [PATCH vshard 3/7] test: disable router
	discovery for some tests
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>, tarantool-patches@dev.tarantool.org

Thanks for explanation. LGTM.

On 02/05/2020 23:09, Vladislav Shpilevoy wrote:
> Thanks for the review!
> 
>>> @@ -49,13 +51,13 @@ util.collect_timeouts(rs1)
>>>        ok: 0
>>>        timeout: 0.5
>>>      - fail: 0
>>> -    ok: 1
>>> +    ok: 0
>>>        timeout: 0.5
>>>    ...
>>>    util.collect_timeouts(rs2)
>>>    ---
>>>    - - fail: 0
>>> -    ok: 1
>>> +    ok: 0
>>>        timeout: 0.5
>>>      - fail: 0
>>>        ok: 0
>>> @@ -74,7 +76,7 @@ util.collect_timeouts(rs1)
>>>        ok: 0
>>>        timeout: 0.5
>>>      - fail: 0
>>> -    ok: 9
>>> +    ok: 8
>>>        timeout: 0.5
>>>    ...
>>>    _ = rs1:callrw('echo')
>>> @@ -86,7 +88,7 @@ util.collect_timeouts(rs1)
>>>        ok: 0
>>>        timeout: 0.5
>>>      - fail: 0
>>> -    ok: 1
>>> +    ok: 9
>>>        timeout: 0.5
>>>    ...
>>
>> Sorry for maybe quite stupid question, but why does it quite significantly increase?
>> ```
>> net_sequential_ok - count of sequential success requests to the replica
>> ```
> 
> This is because the value is truncated to 1, when becomes >= 10. Since
> there is no discovery, this makes number of successful requests decremented.
> Before the patch value was 1. So 1 - 1 = 0, this brings the counter to its
> previous round, where it ended up being 9.
> 
> After 10 the counter is truncated, because the only thing which matters -
> did it manage to make 10 successful requests in a row or not. If it did,
> the timeout is decreased. If it managed, then can start from 1 again.
>