<div dir="ltr">Oh but I'm fascinated by the discussion of Starlink's network performance.!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 2, 2021 at 9:17 AM Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Taking scott manley off the cc. As much as I would like him to sit in<br>
on that song, I don't think he cares about bufferbloat as much as Id<br>
like him to.... I do wish I knew someone that could just magically get<br>
the bufferbloat issue raised within<br>
starlink effectively....<br>
<br>
On Fri, Jan 1, 2021 at 3:31 PM David P. Reed <<a href="mailto:dpreed@deepplum.com" target="_blank">dpreed@deepplum.com</a>> wrote:<br>
><br>
> It has bufferbloat?<br>
<br>
Yep. See links below.<br>
<br>
> Why am I not surprised?<br>
<br>
I was surprised given the length of the talk I'd had with their VP,<br>
eng, but I do figure that getting the thing working at all<br>
was a greater challenge than tackling our issue. I've long worried of<br>
course, that the mac layer on this thing was going to be very weird,<br>
and since they were working with qca they'd end up buring everything<br>
in the network offload processors, even though at present speeds the<br>
cpu they are using is *loafing*, Im not as optimistic as jon is as to<br>
how easy the port of cake or fq_codel would be to their hardware as it<br>
is variable bandwidth and thus needs bql-like backpressure.<br>
<br>
<br>
Since there doesn't seem to be a gpl drop yet we don't know a lot,<br>
however there was a teardown of the hw and jim's posting and a start<br>
at testing on reddit - the dslreports test was flawed in that ping did<br>
not work at all....<br>
<br>
<a href="https://www.reddit.com/r/Starlink/comments/k0dwon/starlink_and_bufferbloat_testing/" rel="noreferrer" target="_blank">https://www.reddit.com/r/Starlink/comments/k0dwon/starlink_and_bufferbloat_testing/</a><br>
<br>
rate limiting with sqm works:<br>
<br>
<a href="https://www.reddit.com/r/Starlink/comments/jxkef9/ahat_is_your_starlinks_bufferbloat_score/" rel="noreferrer" target="_blank">https://www.reddit.com/r/Starlink/comments/jxkef9/ahat_is_your_starlinks_bufferbloat_score/</a><br>
<br>
and the starlink teardown was good:<br>
<a href="https://www.reddit.com/r/hardware/comments/kchxl8/starlink_teardown_and_analysis/" rel="noreferrer" target="_blank">https://www.reddit.com/r/hardware/comments/kchxl8/starlink_teardown_and_analysis/</a><br>
<br>
We think that this hardware actually has fq_codel AND hw rate limiting<br>
in it. But that's not the right thing for a starlink up or downlink<br>
which is variable rate.<br>
<br>
any I know at least 5 people on the beta list and maybe we can get<br>
better testing done in the next month or two.<br>
<br>
It would of course be great if somehow we could get loud enough for<br>
musk to tweet back or hire one of us to help 'em get it right.... I<br>
had a friend of mine send him a suitably inscribed copy of toke's<br>
"bufferbloat and beyond" via interoffice mail... but finding someone<br>
up there more focused on the terminal software itself would be better.<br>
I mean low latency should be their bread and butter and while Im sad<br>
that the early tests are dismal, I am pretty confident that ultimately<br>
they will get it right.<br>
<br>
> 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.<br>
<br>
Yea!<br>
<br>
><br>
> Why? Simply two reasons:<br>
><br>
> 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.<br>
><br>
> 2. Trading is all about managing delay. In this case, 100 msec packet delay is worst allowable case end to end.<br>
><br>
> Yet it is full TCP in hardware.<br>
><br>
> Can't share more, because I don't know more, it being all proprietary to the bank in question.<br>
><br>
> Now, one wonders: why can't Starlink get it right first time?<br>
><br>
> It's not like bufferbloat is hard on a single bent pipe hop, which is all Starlink does today.<br>
><br>
> -----Original Message-----<br>
> From: "Dave Taht" <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>><br>
> Sent: Thu, Dec 31, 2020 at 1:37 pm<br>
> To: "bloat" <<a href="mailto:bloat@lists.bufferbloat.net" target="_blank">bloat@lists.bufferbloat.net</a>>, "cerowrt-devel" <<a href="mailto:cerowrt-devel@lists.bufferbloat.net" target="_blank">cerowrt-devel@lists.bufferbloat.net</a>>, "Scott Manley" <<a href="mailto:scottmanley1972@gmail.com" target="_blank">scottmanley1972@gmail.com</a>><br>
> Cc: "bloat" <<a href="mailto:bloat@lists.bufferbloat.net" target="_blank">bloat@lists.bufferbloat.net</a>>, "cerowrt-devel" <<a href="mailto:cerowrt-devel@lists.bufferbloat.net" target="_blank">cerowrt-devel@lists.bufferbloat.net</a>>, "Scott Manley" <<a href="mailto:scottmanley1972@gmail.com" target="_blank">scottmanley1972@gmail.com</a>><br>
> Subject: [Cerowrt-devel] my thx to spacex (and kerbal space program) forcheering me up all year<br>
><br>
> If it wasn't for such a long list of wonderful accomplishments in<br>
> space, it would have been a sadder year. i just re-recorded my song<br>
> "one first landing" out on my dinghy:<br>
><br>
> <a href="https://www.youtube.com/watch?v=wjur0RG-v-I&feature=youtu.be" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=wjur0RG-v-I&feature=youtu.be</a><br>
><br>
> Maybe someday I'll get scott manley to do his verse on this. Try as I<br>
> might over the past few years, I still can't cop his accent.<br>
><br>
> Now if we can only fix starlink's bufferbloat! It looks to me like the<br>
> firmware is QCA's openwrt derivative...<br>
><br>
> --<br>
> "For a successful technology, reality must take precedence over public<br>
> relations, for Mother Nature cannot be fooled" - Richard Feynman<br>
><br>
> <a href="mailto:dave@taht.net" target="_blank">dave@taht.net</a> CTO, TekLibre, LLC Tel: 1-831-435-0729<br>
> _______________________________________________<br>
> Cerowrt-devel mailing list<br>
> <a href="mailto:Cerowrt-devel@lists.bufferbloat.net" target="_blank">Cerowrt-devel@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
><br>
><br>
<br>
<br>
--<br>
"For a successful technology, reality must take precedence over public<br>
relations, for Mother Nature cannot be fooled" - Richard Feynman<br>
<br>
<a href="mailto:dave@taht.net" target="_blank">dave@taht.net</a> <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729<br>
</blockquote></div>