From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id ALhQM64eCGJOywAAgWs5BA (envelope-from ) for ; Sat, 12 Feb 2022 21:55:10 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id yAcOLK4eCGIHnwAAG6o9tA (envelope-from ) for ; Sat, 12 Feb 2022 21:55:10 +0100 Received: from mail.notmuchmail.org (yantan.tethera.net [IPv6:2a01:4f9:c011:7a79::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 4E6202D770 for ; Sat, 12 Feb 2022 21:55:10 +0100 (CET) Received: from yantan.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id 634A85F704; Sat, 12 Feb 2022 20:55:08 +0000 (UTC) Received: from mailproxy02.manitu.net (mailproxy02.manitu.net [217.11.48.66]) by mail.notmuchmail.org (Postfix) with ESMTPS id EA5B55F6C3 for ; Sat, 12 Feb 2022 20:55:05 +0000 (UTC) Received: from mail-oo1-f53.google.com (mail-oo1-f53.google.com [209.85.161.53]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: michael@grubix.eu) by mailproxy02.manitu.net (Postfix) with ESMTPSA id ED83CC00A9 for ; Sat, 12 Feb 2022 21:55:04 +0100 (CET) Received: by mail-oo1-f53.google.com with SMTP id u25-20020a4ad0d9000000b002e8d4370689so14624525oor.12 for ; Sat, 12 Feb 2022 12:55:05 -0800 (PST) X-Gm-Message-State: AOAM532HboB9zCTAnWIbThaEPVrCNH/W5rFPUFMYO5KXgFRKmNrXHn7n Jmfc9O9O0mB3qu4GDZSPYJLl7JGYR9gXPS+G07g= X-Google-Smtp-Source: ABdhPJxwvfexR+umk+mHLeJjKwIQ9MQD1g7+znlD3Nbtv4f35M7uSwOdCSILhorxv2mPBSEiVDQt3+Q+nPtJH/a868k= X-Received: by 2002:a05:6870:f812:: with SMTP id fr18mr1892905oab.129.1644699303947; Sat, 12 Feb 2022 12:55:03 -0800 (PST) MIME-Version: 1.0 References: <164458773197.3086.16103597141743611268.git@grubix.eu> <87k0e1x87f.fsf@tethera.net> <164467277576.6467.13919733764427871872.git@grubix.eu> <874k54xfuw.fsf@tethera.net> In-Reply-To: From: Michael J Gruber Date: Sat, 12 Feb 2022 21:54:52 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Test suite timing issues? To: Tomi Ollila Message-ID-Hash: VM7ZHC4DPH43VO5NLHU7COD3BMBOKXOI X-Message-ID-Hash: VM7ZHC4DPH43VO5NLHU7COD3BMBOKXOI X-MailFrom: git@grubix.eu X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: notmuch@notmuchmail.org X-Mailman-Version: 3.3.3 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: multipart/mixed; boundary="===============2003961231970186959==" X-Migadu-Flow: FLOW_IN X-Migadu-Country: DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1644699310; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=XFf8ilb46R6aefuJ4jvNh5qdmGeTo0eDxPAgbcPBtpc=; b=qMbIpEsPY1HAiUrMIzDSEA6gkXDWsu3YZEucOtArmB93+sSfPNvMfQGeKZPKCieg0utsfu JaFstPgSh6ePxzQ3cqYLRS/B5/yQpV/QMD1Jfp4jlqMlIf2YLF6TOVt7Of1xrHTTMEfjDt i7xqiRqo/s/rFQVpTw9b0znu42opO3dCrIsKOyD5ZTD/e7FB0v6Qt+hXnv7Pp1/7e2bb4x 0XGSD3km/6ffCDfWVlS6EytuuuKBPfr3tCXxN41Rr8inv1/+Dm1sgt3H/QANnRvS+a7IOD DR18DfEBQcAyAfxAVrHsaJ8pu2hgsbPJ7R9+TSwdyWhxEtc3Fse0+LPauu0kmg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1644699310; a=rsa-sha256; cv=none; b=VvSox2I92afBJtWHhHxKJinvN2P7aOuIUf0SSKPbEtWRgelnn1SmrwjOvDKYxa97pbPuyy C254ikACI4ZubHJCBIsdQZgYfqabm/irVoBMTQigsVNW4ShwYKDr+ufXYvDM/+PgSstjRO onsY4G9dt1w9d0eDNryBRhF5jCHzsmdpN2ZieO0kxnTVxn0i0GZn720ZDpSb+jiWbMvaOy iCbrmhnQAaLUfDquKcGT8IKIwSDLGmpamFxE9UVV5qr0lyzE0QxlpIEgJ3J3kdJnA4hfpp R20SFYe6cu/60T8QAU5o9KKGmVG/q+ne5mi4/u23vNJuwxfz8zLR2lT9DcmcoQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 2a01:4f9:c011:7a79::1 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Spam-Score: -1.54 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 2a01:4f9:c011:7a79::1 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Queue-Id: 4E6202D770 X-Spam-Score: -1.54 X-Migadu-Scanner: scn1.migadu.com X-TUID: VCTXAFZhLEfk --===============2003961231970186959== Content-Type: multipart/alternative; boundary="000000000000c6346c05d7d8650b" --000000000000c6346c05d7d8650b Content-Type: text/plain; charset="UTF-8" Am Sa., 12. Feb. 2022 um 21:45 Uhr schrieb Tomi Ollila : > On Sat, Feb 12 2022, David Bremner wrote: > > > Tomi Ollila writes: > > > >> On Sat, Feb 12 2022, Michael J. Gruber wrote: > >> > >> Only thing that came into mind are directory timestamps... if directory > >> (m)time is same as before notmuch will not scan it for files... > >> > >> ... following that if the granularity of directory timestamp were 1 > second, > >> then it could easily happen than first one new message is not seen, and > >> next time there is one extra message to be see... > > > > What do you think about adding --full-scan to the notmuch-new invocation > > in add_message? It doesn't make any tests fail and is about the same > > speed. I need to do a few more trials, but first time through it was > > actually faster (!), maybe because the cache is hot > > Does such a change hide "buggy" functionality ? > > Or do we consider notmuch new buggy if it does not notice all new messages > arrived every time ? > > The timestamping sounds like a perfect explanation of what I've been seeing. Unfortunately, I can't reproduce the issue "reliably" (with a certain probability), and so if everything succeeds with --full-scan 10 times it still does not mean much. As I understand, notmuch new without --full-sync may have issues when the time resolution is too low (or operations too fast) and will pick a message on the next run, so it's not really buggy - it uses a shortcut that may be too quick but does not loose messages in the long run. Michael > > --000000000000c6346c05d7d8650b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Am Sa., 12. Feb. 2022 um 21:45=C2=A0Uhr s= chrieb Tomi Ollila <tomi.ollila@ik= i.fi>:
On= Sat, Feb 12 2022, David Bremner wrote:

> Tomi Ollila <tomi.ollila@iki.fi> writes:
>
>> On Sat, Feb 12 2022, Michael J. Gruber wrote:
>>
>> Only thing that came into mind are directory timestamps... if dire= ctory
>> (m)time is same as before notmuch will not scan it for files... >>
>> ... following that if the granularity of directory timestamp were = 1 second,
>> then it could easily happen than first one new message is not seen= , and
>> next time there is one extra message to be see...
>
> What do you think about adding --full-scan to the notmuch-new invocati= on
> in add_message? It doesn't make any tests fail and is about the sa= me
> speed. I need to do a few more trials, but first time through it was > actually faster (!), maybe because the cache is hot

Does such a change hide "buggy" functionality ?

Or do we consider notmuch new buggy if it does not notice all new messages<= br> arrived every time ?

=C2=A0
The timestamping sounds like a perfe= ct explanation of what I've been seeing. Unfortunately, I can't rep= roduce the issue "reliably" (with a certain probability), and so = if everything succeeds with --full-scan 10 times it still does not mean muc= h.

As I understand, notmuch new without --full-syn= c may have issues when the time resolution is too low (or operations too fa= st) and will pick a message on the next run, so it's not really buggy -= it uses a shortcut that may be too quick but does not loose messages in th= e long run.

Michael=C2=A0

--000000000000c6346c05d7d8650b-- --===============2003961231970186959== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============2003961231970186959==--