Oh but I'm fascinated by the discussion of Starlink's network performance.! 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_bufferbloat_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. That > is one implemented for trading at 10+ GB/sec, implemented in Verilog, and > now apparently in production use at one of the largest NY trading > intermediaries. > > 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 > networking 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" < > cerowrt-devel@lists.bufferbloat.net>, "Scott Manley" < > scottmanley1972@gmail.com> > > Cc: "bloat" , "cerowrt-devel" < > cerowrt-devel@lists.bufferbloat.net>, "Scott Manley" < > scottmanley1972@gmail.com> > > Subject: [Cerowrt-devel] my thx to spacex (and kerbal space program) > forcheering 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=wjur0RG-v-I&feature=youtu.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 >