From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 78963A00C5 for ; Wed, 2 Feb 2022 15:51:46 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 524E440688; Wed, 2 Feb 2022 15:51:46 +0100 (CET) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) by mails.dpdk.org (Postfix) with ESMTP id 15B7B40141 for ; Wed, 2 Feb 2022 15:51:46 +0100 (CET) Received: by mail-io1-f44.google.com with SMTP id 9so25802084iou.2 for ; Wed, 02 Feb 2022 06:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V23BQaFqQafFFSuJOU1X568hQdFcRJ71TMCB9QoF3C0=; b=h1E2DEfzvjQvmPXRSD66Xk6uapoprw1d7j9DRKsYWoab+Qd2F2czIGicIhhR1OVsap 2X4m5+4pq17lX61R1WnE944+mdZCSamT+k4wiHwLTBKrzaw4Oope7UQ9KFxMAOfE/wow HQuyRd2igjnLv9QScG61axaqdjsPOLkaAOM1c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V23BQaFqQafFFSuJOU1X568hQdFcRJ71TMCB9QoF3C0=; b=xtHe1tpNIV7lN/sCsLP+f87Ru0KaauCRJ8JukDcxqdrFKQFIciXcNEe35gd7H+qKs2 oVca6WJ64MQUEVDyrEM/ZlYREal/7uXeuJxCsPesEM6eFi4aO8uF5C7pgl1znk8XNdTy ZmlkPvtuODyTiqg5qdPVQgr3fUdE4sGVZ8k4pLGhTnilXBUYSVdWGCLCPXkum7j9ikiV VC6uaKZQotN9Js5HITf77c0nwkb80TEPDFLrLEfKxOP2QRHha93UwiUgsC/GYImmfFP6 RgvuQnALNTc6CJ5IJiRjJ9C2AP9fwByLtBKw8btGVYbFyJABHtp7j0Eg34ek3OKNyBOu Ez9w== X-Gm-Message-State: AOAM5327LPKM9PU7bZkN7brJ1/ffSgqpOhOAnUzlx2RTS6wmglMNp52G CplAtu2lAIiCbe5X4s5GCkbqXSd+EwpAHzk6uosSMQ== X-Google-Smtp-Source: ABdhPJyIIhtSeajmz4k6WNlq2QM6+T8ntZV8SlRcaVqn6RbYWNBr1rTuJDxVNyH75AQ7SjOwxcYXIGQIo/J0J7ukNJ0= X-Received: by 2002:a6b:5a05:: with SMTP id o5mr16395038iob.19.1643813505388; Wed, 02 Feb 2022 06:51:45 -0800 (PST) MIME-Version: 1.0 References: <1928246.j4tpOohVRJ@thomas> In-Reply-To: From: Brandon Lo Date: Wed, 2 Feb 2022 09:51:09 -0500 Message-ID: Subject: Re: [dpdk-dev] [Bug 826] red_autotest random failures To: "Danilewicz, MarcinX" , Lincoln Lavoie Cc: "Dumitrescu, Cristian" , "Ajmera, Megha" , "Singh, Jasvinder" , "Zegota, AnnaX" , "Yigit, Ferruh" , "thomas@monjalon.net" , "david.marchand@redhat.com" , "ci@dpdk.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-bounces@dpdk.org > On Mon, Jan 31, 2022 at 2:27 PM Danilewicz, MarcinX wrote: >> After some time I did some testing. As you may guess, with real hardware I could not reproduce error. >> >> From what I see, the problem was here: >> >> FT2 >> RED config, avg queue size, min threshold, max threshold, drop prob %, drop rate %, diff %, tolerance % , >> 5 127 32 128 1.6493 0.9900 0.0000 50.0000 >> 6 127 32 128 1.4137 0.8500 0.0000 50.0000 >> 7 127 32 128 1.2370 0.7300 0.0000 50.0000 >> 8 127 32 128 1.0995 0.6200 0.0000 50.0000 >> 9 127 32 128 0.9896 0.6300 0.0000 50.0000 >> ------------------------------------------------------------------------ >> >> Drop_rate in line 8 should not be greater than in line 9. However by looking at other results, drop_rate value in line 9 is about 0.1% greater than expected. Line 8 results are fine to me. >> >> How often any can see this issue? Is there a chance I could use existing docker container for testing? Hi Marcin, Attached is an Ubuntu 20.04 Dockerfile that we use in the lab for unit testing. I don't think we run into the red_autotest failure too often, so it is hard to debug. My guess is that the test will randomly fail when there are a lot of processes running on the system, especially since we run multiple tests per system in the lab. In a typical worst-case scenario, we can see a machine performing 2 to 3 total compile/ABI tests along with a single unit test. We do allocate a specific amount of resources (4GB RAM, 2 cores) to each container, so that can be another factor that affects the frequency of these failures. If this issue seems too dependent on the current system load and other situational factors, it might be good to think about running the red_autotest separate from other tests in the lab so it does not have to compete for resources. Any thoughts on this? Thanks, Brandon -- Brandon Lo UNH InterOperability Laboratory 21 Madbury Rd, Suite 100, Durham, NH 03824 blo@iol.unh.edu www.iol.unh.edu