From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <f.ebner@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id A4752924CD
 for <pve-devel@lists.proxmox.com>; Tue, 21 Mar 2023 13:33:49 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id 8C73518F96
 for <pve-devel@lists.proxmox.com>; Tue, 21 Mar 2023 13:33:49 +0100 (CET)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
 [94.136.29.106])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with ESMTPS
 for <pve-devel@lists.proxmox.com>; Tue, 21 Mar 2023 13:33:48 +0100 (CET)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
 by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 8CDDF45D03
 for <pve-devel@lists.proxmox.com>; Tue, 21 Mar 2023 13:33:48 +0100 (CET)
From: Fiona Ebner <f.ebner@proxmox.com>
To: pve-devel@lists.proxmox.com
Date: Tue, 21 Mar 2023 13:33:42 +0100
Message-Id: <20230321123345.128141-2-f.ebner@proxmox.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20230321123345.128141-1-f.ebner@proxmox.com>
References: <20230321123345.128141-1-f.ebner@proxmox.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL -0.002 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
Subject: [pve-devel] [PATCH proxmox-resource-scheduling 1/2] pve ha: fix
 scoring issue when a node is overcommitted compared to others
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2023 12:33:49 -0000

When nodes have different stats, the sum of percentage values will be
different for different alternatives, so the linear average is enough.
But when nodes have the same stats, this is not the case, the sum will
be the same, thus the average won't influence the scoring. If there is
an already overcommitted node, all alternatives besides the already
overcommitted node would be scored the same.

To fix it, use the squares of percentages instead, where more evenly
distributed usage across nodes will lead to a smaller value and thus
better scoring.

It's not really necessary to divide by length or take the sqrt, but it
seemed nicer to have something that would give 1.0 if all inputs are
1.0.

Reported-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
---

Sorry about the stupid mistake :(

 src/pve_static.rs | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/pve_static.rs b/src/pve_static.rs
index 345c0a2..6663b70 100644
--- a/src/pve_static.rs
+++ b/src/pve_static.rs
@@ -79,11 +79,11 @@ pub fn score_nodes_to_start_service(
         .iter()
         .enumerate()
         .map(|(target_index, _)| {
-            // all of these are as percentages to be comparable across nodes
+            // Base values on percentages to allow comparing nodes with different stats.
             let mut highest_cpu = 0.0;
-            let mut sum_cpu = 0.0;
+            let mut squares_cpu = 0.0;
             let mut highest_mem = 0.0;
-            let mut sum_mem = 0.0;
+            let mut squares_mem = 0.0;
 
             for (index, node) in nodes.iter().enumerate() {
                 let new_cpu = if index == target_index {
@@ -92,7 +92,7 @@ pub fn score_nodes_to_start_service(
                     node.cpu
                 } / (node.maxcpu as f64);
                 highest_cpu = f64::max(highest_cpu, new_cpu);
-                sum_cpu += new_cpu;
+                squares_cpu += new_cpu.powi(2);
 
                 let new_mem = if index == target_index {
                     node.mem + service.maxmem
@@ -101,13 +101,13 @@ pub fn score_nodes_to_start_service(
                 } as f64
                     / node.maxmem as f64;
                 highest_mem = f64::max(highest_mem, new_mem);
-                sum_mem += new_mem;
+                squares_mem += new_mem.powi(2);
             }
 
             PveTopsisAlternative {
-                average_cpu: sum_cpu / len as f64,
+                average_cpu: (squares_cpu / len as f64).sqrt(),
                 highest_cpu,
-                average_memory: sum_mem / len as f64,
+                average_memory: (squares_mem / len as f64).sqrt(),
                 highest_memory: highest_mem,
             }
             .into()
-- 
2.30.2