From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 3CA083B29E; Sun, 3 Jan 2021 00:48:30 -0500 (EST) Received: by mail-il1-x12a.google.com with SMTP id n9so22381914ili.0; Sat, 02 Jan 2021 21:48:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=B8sSipeoj0I/1F822RCcItPKJr0WzTRKJxZ2hG582gU=; b=UesuVeaG/np3KlKkW1ibaNE4hGJ/ikEFbvBGB8KD1YB8Vgnwfr8Nvx9K4rqyv0Nw3m Lu2s6nDNcNd+hrgaQZ6z0UMxhZSnko8TH7B6LIMeBDUZRW2pqHmDSKozi4Mln3wL7jC4 k+9VR0aBg+xYfhLJxLI3eLX/Av+0TvwtXq2crwReBtjC/hzYGFw5Zpsva0MZD3DRR8UN nljjfME0+yi3OEoXl6B6hvV6caSDpstMYaZVKdJnbeWe2f++uZxKcPNFIrP0ks9N+yKG SfHNx2sipwmVLTMuxQUCeK6HgjHQQBtJYgwepBdiXeh2j0SomrCftAlzfKyAisCJh16z p3Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=B8sSipeoj0I/1F822RCcItPKJr0WzTRKJxZ2hG582gU=; b=edpKFztud8rJaP+iHeXHEWyRBJzTscPclWvdHLYsck+8DtXkeyAzlD47bJDyYycv3r 7ibiqiV0zPLgbTtni78esAAZwUJh0PYmOuee8mCSTmt4I9WVp8aKrOmi//+8NFSonybM x9+/FRvI6WLh5p2saK+zuY+2ppBjY1oux7W5VEj5S5Vzl1Ebm/hbaQh2tTXEdWExocrK QgUZD4HDXXwvY1GdRdSazXblY4nc5UvYUbmuwiMRmJRgDsOZqPWP/sQVoWPBv0BsLqzA PXWqgDcHSbyJ2p/yehOVHZe0OhJjEjN36m/Uuwrlc63PurepD3mpsqE2qGls98bX4Fj1 winQ== X-Gm-Message-State: AOAM530uhwC+O1rNiwAcsC+ratGQu7ppq2jGPoss013wmD0FFolwX7nk 3gel65rQHSeZQ0dp/DSiLAUKNqtd8YVT9Dosq24= X-Google-Smtp-Source: ABdhPJyKGahBSpcaVVk2ZgKDEjFqjkHclWcme9Fuqo5C4oGeMnP5Yb/l5YNEyxwMI5Ah0ZnQ7CkvoUGyPhT7++CYgXQ= X-Received: by 2002:a05:6e02:ecc:: with SMTP id i12mr63306806ilk.0.1609652909563; Sat, 02 Jan 2021 21:48:29 -0800 (PST) MIME-Version: 1.0 References: <1609543872.082620517@apps.rackspace.com> In-Reply-To: From: Dave Taht Date: Sat, 2 Jan 2021 21:48:18 -0800 Message-ID: To: Scott Manley Cc: "David P. Reed" , bloat , cerowrt-devel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Cerowrt-devel] my thx to spacex (and kerbal space program) forcheering me up all year X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2021 05:48:30 -0000 On Sat, Jan 2, 2021 at 1:39 PM Scott Manley wro= te: > > Oh but I'm fascinated by the discussion of Starlink's network performance= .! I HAD figured that everyone at starlink has read about how NOT to build a space-born packet switched network. If you haven't read it, "Eccentric Orbits: The Iridium Story" is a great read. I have had quite the hobby trying to grok what starlink is up to, I can go into it here if you like. I can't remember how much of the bufferbloat problem I'd discussed with you at the last hackers conference. PS (can you pleeeeeze record you singing over your part in that song? :) ) > > On Sat, Jan 2, 2021 at 9:17 AM Dave Taht wrote: >> >> Taking scott manley off the cc. As much as I would like him to sit in >> on that song, I don't think he cares about bufferbloat as much as Id >> like him to.... I do wish I knew someone that could just magically get >> the bufferbloat issue raised within >> starlink effectively.... >> >> On Fri, Jan 1, 2021 at 3:31 PM David P. Reed wrote= : >> > >> > It has bufferbloat? >> >> Yep. See links below. >> >> > Why am I not surprised? >> >> I was surprised given the length of the talk I'd had with their VP, >> eng, but I do figure that getting the thing working at all >> was a greater challenge than tackling our issue. I've long worried of >> course, that the mac layer on this thing was going to be very weird, >> and since they were working with qca they'd end up buring everything >> in the network offload processors, even though at present speeds the >> cpu they are using is *loafing*, Im not as optimistic as jon is as to >> how easy the port of cake or fq_codel would be to their hardware as it >> is variable bandwidth and thus needs bql-like backpressure. >> >> >> Since there doesn't seem to be a gpl drop yet we don't know a lot, >> however there was a teardown of the hw and jim's posting and a start >> at testing on reddit - the dslreports test was flawed in that ping did >> not work at all.... >> >> https://www.reddit.com/r/Starlink/comments/k0dwon/starlink_and_bufferblo= at_testing/ >> >> rate limiting with sqm works: >> >> https://www.reddit.com/r/Starlink/comments/jxkef9/ahat_is_your_starlinks= _bufferbloat_score/ >> >> and the starlink teardown was good: >> https://www.reddit.com/r/hardware/comments/kchxl8/starlink_teardown_and_= analysis/ >> >> We think that this hardware actually has fq_codel AND hw rate limiting >> in it. But that's not the right thing for a starlink up or downlink >> which is variable rate. >> >> any I know at least 5 people on the beta list and maybe we can get >> better testing done in the next month or two. >> >> It would of course be great if somehow we could get loud enough for >> musk to tweet back or hire one of us to help 'em get it right.... I >> had a friend of mine send him a suitably inscribed copy of toke's >> "bufferbloat and beyond" via interoffice mail... but finding someone >> up there more focused on the terminal software itself would be better. >> I mean low latency should be their bread and butter and while Im sad >> that the early tests are dismal, I am pretty confident that ultimately >> they will get it right. >> >> > I can share that one stack hasn't had it from the start, by design. Th= at is one implemented for trading at 10+ GB/sec, implemented in Verilog, an= d now apparently in production use at one of the largest NY trading interme= diaries. >> >> Yea! >> >> > >> > Why? Simply two reasons: >> > >> > 1. People who design parallel hardware systems are trained to focus on= closing timing constraints. Which means never using FIFOs that are longer = than absolute minimum. The designer is a VLSI designer by trade, not a netw= orking guy. >> > >> > 2. Trading is all about managing delay. In this case, 100 msec packet = delay is worst allowable case end to end. >> > >> > Yet it is full TCP in hardware. >> > >> > Can't share more, because I don't know more, it being all proprietary = to the bank in question. >> > >> > Now, one wonders: why can't Starlink get it right first time? >> > >> > It's not like bufferbloat is hard on a single bent pipe hop, which is = all Starlink does today. >> > >> > -----Original Message----- >> > From: "Dave Taht" >> > Sent: Thu, Dec 31, 2020 at 1:37 pm >> > To: "bloat" , "cerowrt-devel" , "Scott Manley" >> > Cc: "bloat" , "cerowrt-devel" , "Scott Manley" >> > Subject: [Cerowrt-devel] my thx to spacex (and kerbal space program) f= orcheering me up all year >> > >> > If it wasn't for such a long list of wonderful accomplishments in >> > space, it would have been a sadder year. i just re-recorded my song >> > "one first landing" out on my dinghy: >> > >> > https://www.youtube.com/watch?v=3Dwjur0RG-v-I&feature=3Dyoutu.be >> > >> > Maybe someday I'll get scott manley to do his verse on this. Try as I >> > might over the past few years, I still can't cop his accent. >> > >> > Now if we can only fix starlink's bufferbloat! It looks to me like the >> > firmware is QCA's openwrt derivative... >> > >> > -- >> > "For a successful technology, reality must take precedence over public >> > relations, for Mother Nature cannot be fooled" - Richard Feynman >> > >> > dave@taht.net CTO, TekLibre, LLC Tel: 1-831-435-0729 >> > _______________________________________________ >> > Cerowrt-devel mailing list >> > Cerowrt-devel@lists.bufferbloat.net >> > https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > >> > >> >> >> -- >> "For a successful technology, reality must take precedence over public >> relations, for Mother Nature cannot be fooled" - Richard Feynman >> >> dave@taht.net CTO, TekLibre, LLC Tel: 1-831-435-0729 --=20 "For a successful technology, reality must take precedence over public relations, for Mother Nature cannot be fooled" - Richard Feynman dave@taht.net CTO, TekLibre, LLC Tel: 1-831-435-0729