From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D2C3A3B2A4 for ; Fri, 7 Feb 2020 06:11:32 -0500 (EST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1581073891; bh=luDqx8bwH36sTRFLs5dZGzxfCkXdn+GnCHZ3C0b009I=; h=From:To:Subject:In-Reply-To:References:Date:From; b=wfGQKQABpYTSoj2iOAX6z+/t2cVl8t/Kc2IERMnJLsTWfFg7qXR/grfVr8EINcSuU W2WrfChilelpILrblse3vTPThFi8GB966eu+e+PwnAq0i+k5Zqmc/5du305MXrxdQX VUb/Tgs0Ly+YSyf/d+f7+LOkuo/d+xb605/qxr8qqeHxmmHoFaUfprYVZDaf3GBTm0 Aa3J1H7VNR6OC2ZoSXX7WiE6IpZ+p05USaJLvtnDmW59Enflst3/KAu2A5uPORPiZf bq07hDVpr2vuflE1InW8zmf8KKuiiT+rmp2S7BSBjtcfIm0j6ovYVpz+1XmasWoVrB abZOjgUcH/TMQ== To: Rich Brown , bloat@lists.bufferbloat.net In-Reply-To: <073CE9AB-FE12-402E-BFE3-179DF7BF2093@gmail.com> References: <073CE9AB-FE12-402E-BFE3-179DF7BF2093@gmail.com> Date: Fri, 07 Feb 2020 12:11:30 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87ftfmbqjh.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Bloat] Can't Run Tests Against netperf.bufferbloat.net X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 11:11:33 -0000 Rich Brown writes: >> On Feb 6, 2020, at 12:00 PM, Matt Taggart wrote: >> >> This smells like a munin or smokeping plugin (or some other sort of >> monitoring) gathering data for graphing. > > Yup. That is a real possibility. The question is what we do about it. > > If I understood, we left it at: > > 1) Toke was going to look into some way to spread the > 'netperf.bufferbloat.net' load across several of our netperf servers. > > 2) Can someone give me advice about iptables/tc/? to identify IP > addresses that make "too many" connections and either shut them off or > dial their bandwidth back to a 3 or 5 kbps? Not sure if it's possible to do with iptables, but it should be fairly straight-forward to write an eBPF filtering program that will lock out an IP after it has used a certain amount of bandwidth. That was the reason for my question about your kernel version; need to figure out what types of BPF support you have available :) -Toke