From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3CE133BA8E for ; Sat, 2 Jun 2018 13:08:44 -0400 (EDT) Received: by mail-qt0-x234.google.com with SMTP id e8-v6so36043347qth.0 for ; Sat, 02 Jun 2018 10:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JtpCdcT5j7MaeTVaZ07BGSsS7v+0r/6QKP6Yuhmr+Iw=; b=LmefeVN6udc+CTzLAYGz2sAT5Qp2/kRH+vNd0F0VrhfSfeFTuoMfs616Vt5Nt1YDe3 4YSJ2gSE68Zxjs20kwPsKGD2+3YOV88EDFsIQa6xg1V5xW59h73sy1M+QzI7MOYOQEGA vMzUKwQpN1VBTp3a1PZ041AT5D/3Wr5ZNtlVD9BSHNYRyFN6vtjJ0OxCL+gJElgTHCcc qg/MlMIBXgAgrKVHhFYyCE9PkyyrUcmn2SNDsopJrg38yjkTrBNcUPyxJ1ZSUVF7vjeZ OSqpzKnhrAIjDvsv4ZmNstj++bWfEp1aE11ksaF5KDE2rFIGdOnszvxFh0bAEu8YQNm+ 9O9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JtpCdcT5j7MaeTVaZ07BGSsS7v+0r/6QKP6Yuhmr+Iw=; b=PrAlR21BWKLf5S2blTgEj5QuKxWFYysyTk0N/vCmIB/NBikmoNxpV371X8/ovKP+eo Kkzr2t21sHLpe3fOU1gHs+ZPS6Ix4gXTAOUEHLrzkeYyWJYsoiXS68+cFcqvrvuv7FSP 4TTDXktqE8vGaGwG5oHxOxZ8euGH2Fv12GRr0Od3l5LSfGQ7VyJozLBNsC2/TAoxJYxT 5PuVWNaU7AGLJOT4+Vim1OeMhRALS1cJjS8ffwLNnjjhgFpFUk5rHdmGAoScvkFp05vj QTkSCATc4Bpa9eppC40AvURs4hmSmoiyh4z78flqMJaKnL1sV6MVHUu5fs/ZJMgJybJq z8hA== X-Gm-Message-State: APt69E2tnRipd4v/ZpdUOebssN7HdXv3yuKv/JqGQIr+M1clmi0W8V6N PasKbb8H1YTjopop4aHFNQFfU/JYdmXwt+wYNiM= X-Google-Smtp-Source: ADUXVKI844m2IQx2gbU87Kim5lOTQN6LCS4JGmod54t2vjSDhb4RAt0oPio70Q+IEeP9WNYvX/8Joo7P35xXzlb/HNg= X-Received: by 2002:aed:24fb:: with SMTP id u56-v6mr4196510qtc.203.1527959323803; Sat, 02 Jun 2018 10:08:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:24f0:0:0:0:0:0 with HTTP; Sat, 2 Jun 2018 10:08:43 -0700 (PDT) In-Reply-To: <871sdqmg8l.fsf@toke.dk> References: <87muwe9z7j.fsf@toke.dk> <87k1ri9yve.fsf@toke.dk> <877enimhuh.fsf@toke.dk> <9A273CA6-FDF6-485D-B466-8B01D4573BD9@gmail.com> <871sdqmg8l.fsf@toke.dk> From: Dave Taht Date: Sat, 2 Jun 2018 10:08:43 -0700 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Jonathan Morton , Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] Lockup at high speeds X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2018 17:08:44 -0000 How on earth are you getting these speeds? I'm stuck at a pathetic *4* gbit here on the admittedly ancient 12 core boxes I'd got. (I'll go rework my veth topology) rcu stuff makes me nervous, what happens if that nat stuff is disabled enti= rely. What if you made q.len and sparse/bullk flow counts atomic ops? I tend to lean towards an overflow post 40gbit also. On Fri, Jun 1, 2018 at 12:58 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Jonathan Morton writes: > >>> On 1 Jun, 2018, at 10:23 pm, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>> >>> Happens in unlimited mode and when the shaper is set to 60gbps, but not= when it is set to 40gbps. >> >> Observations: >> >> - The shaper converts a rate in B/s into a time-per-byte value stored >> in floating-point - cake_set_rate(). It is plausible that such a >> conversion becomes faulty when exposed to especially large values. > > Yeah. When changing the rate to a 64-bit value I changed the shifts in > cake_set_rate() to the maximum possible to try to mitigate this... > >> - 40Gbps is 5.0 GB/s, 0.2000 ns/B. 60Gbps is 7.5 GB/s, 0.1333 ns/B. >> No obvious power-of-two threshold is crossed; both are between 0.25 >> and 0.125 ns/B, require 40 bits to store as bps and 33 as B/s. >> >> - In unlimited mode, the time-per-byte should be zero and the shaper >> should therefore always pass traffic without advancing, but >> time_next_packet will be continually reset to the latest delivery >> time. > > Right. I was wondering if there was some way we could end up looping > through cake_dequeue() forever if the shaper is not limiting things; > there is both a while(1) and a couple of 'goto begin's in there. I guess > if the sparse/bulk flow counts or sch->q.len accounting got messed up we > might? But that shouldn't happen, should it? > >> What happens if a watchdog timer is set for a time that has already >> elapsed? > > As far as I can tell from tracing through those functions, that just > ends up inserting a timer value into an rbtree. So I don't think that in > itself can cause bad things to happen... > > -Toke > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619