From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8413CA00BE; Tue, 29 Oct 2019 15:05:27 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2BE451BEB5; Tue, 29 Oct 2019 15:05:26 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 7E5AB1BEB4 for ; Tue, 29 Oct 2019 15:05:24 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Oct 2019 07:05:23 -0700 X-IronPort-AV: E=Sophos;i="5.68,244,1569308400"; d="scan'208";a="193614679" Received: from dhunt5-mobl4.ger.corp.intel.com (HELO [10.237.221.4]) ([10.237.221.4]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/AES256-SHA; 29 Oct 2019 07:05:21 -0700 To: Thomas Monjalon , "Burakov, Anatoly" Cc: dev@dpdk.org References: <20190724131803.30066-1-david.hunt@intel.com> <5316435.KtOK4V2HBz@xps> <1655765.anAStuQWUM@xps> From: "Hunt, David" Message-ID: <0c0b07e4-ef84-056f-bffa-06a402fa99f6@intel.com> Date: Tue, 29 Oct 2019 14:05:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <1655765.anAStuQWUM@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH v1] examples/power: fix oob frequency oscillations X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 27/10/2019 18:35, Thomas Monjalon wrote: > 06/08/2019 13:18, Thomas Monjalon: >> 26/07/2019 12:15, Burakov, Anatoly: >>> So it's biased towards scaling up quickly, but it's doing that over a >>> period. Please correct me if i'm wrong as i'm not really familiar with >>> this codebase, but, assuming the window size is long enough, you could >>> be missing opportunities to scale down? For example, if you get a short >>> burst of 1's followed by a long burst of zeroes, you're not scaling down >>> until you go through the entire buffer and overwrite all of the values. >>> I guess that's the point of oscillation prevention, but maybe you could >>> improve the "scale-up" part by only checking a few recent values, rather >>> than the entire buffer? >> This patch is deferred to 19.11. > Any news for this patch? > The algorithm was intended to be biased (strongly) towards the scale-up, for performance reasons. If there is a single "scale-up" in the entire array, then we stay up until the entire array agrees that we can scale down. If the user wants to relax this, then simply reduce the size of the array, which will have the same affect. But I had tested it with an array size of 32, and that gave the best results for my use cases.