From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bobcat.rjmcmahon.com (bobcat.rjmcmahon.com [45.33.58.123]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5E7EA3B2A4 for ; Sun, 19 Feb 2023 18:37:52 -0500 (EST) Received: from mail.rjmcmahon.com (bobcat.rjmcmahon.com [45.33.58.123]) by bobcat.rjmcmahon.com (Postfix) with ESMTPA id 7D71C1B258; Sun, 19 Feb 2023 15:37:51 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 bobcat.rjmcmahon.com 7D71C1B258 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjmcmahon.com; s=bobcat; t=1676849871; bh=6pDRCP9Ebvurd184WjkATB28zd2lf/dPAmpRfpVTnXU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=cGEDtOmix7JryApF8N/+j+3qDJboRL4WpWTV5IaDsUORIZnsUhyK1yiYAYOYtH+Pn 1D1I1XMGVwWgsf0gDuzUK6UIosTtrTzkod2oB6hYR4TBf3KmlTIqyNyEhTMLeer2Y6 +al8XlO3Qoz6MIcApQh4gYVsNngSdYFsaLWMJIUw= MIME-Version: 1.0 Date: Sun, 19 Feb 2023 15:37:51 -0800 From: rjmcmahon To: rjmcmahon Cc: Dave Taht , Rpm In-Reply-To: <26ac4e4e00b1d0f20c816630fafb7e58@rjmcmahon.com> References: <26ac4e4e00b1d0f20c816630fafb7e58@rjmcmahon.com> Message-ID: <1209c1b2fb917edc8bf33a73782823bd@rjmcmahon.com> X-Sender: rjmcmahon@rjmcmahon.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Rpm] Almost had a dialog going with juniper... X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2023 23:37:52 -0000 A bit off topic, but the AP/client power asymmetry is another design flaw similar to bloat. Not sure why nobody is talking about that. https://www.youtube.com/watch?v=Ey5jVUXSJn4 Bob > Their post isn't really about bloat. It's about the discrepancy in i/o > bw of memory off-chip and on-chip. > > My opinion is that the off-chip memory or hybrid approach is a design > flaw for a serious router mfg. The flaw is thinking the links' rates > and the chip memory i/o rates aren't connected when obviously they > are. Just go fast as possible and let some other device buffer, e.g. > the end host or the server in the cloud. > > Bob >> https://blog.cerowrt.org/post/juniper/ >> >> But they deleted the comment thread. It is interesting, I suppose, to >> see how they frame the buffering problems to themselves in their post: >> https://www.linkedin.com/pulse/sizing-router-buffers-small-new-big-sharada-yeluri/ > _______________________________________________ > Rpm mailing list > Rpm@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/rpm