Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When “idle” isn't idle: how a Linux kernel optimization became a QUIC bug

blog.cloudflare.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: When “idle” isn't idle: how a Linux kernel optimization became a QUIC bug

#31

Post by mrguyorama »

philipwhiuk wrote: post #9
yuye wrote: post #6

Earlier quoted context omitted.

The first half wasn't too bad, but the AI tells get strong in the second half.

The tell I always spot is it's propensity to bold random words frankly.

The heading content and structure is the biggest tell IMO. Even shitty highschool kids don't write like that.

I don't understand where or how AI picked up that habit, because it's self evidently terrible. It makes it clear how low signal AI based writing is. The writing is like the music in shitty blockbusters; engineered to make you feel, rather than to actually structure the content or provide meaningful sections.

Compare this writeup to the Pixter writeup, where sections feel natural and not "scripted" like this.

Re: When “idle” isn't idle: how a Linux kernel optimization became a QUIC bug

#32

Post by twoodfin »

bonzini wrote: post #28
twoodfin wrote: post #19

Earlier quoted context omitted.

I don’t get it. Unlike a lot of the technical article slop that is posted here, this obviously had a lot of human thought and effort put into the prompt. The LLM pass (unsurprisingly) made it worse. For example: The results were conclusive: 100% pass rate, showing Reno recovered cleanly after the loss phase, and revealing that this is a CUBIC-related bug. Look, I’m reading a description of a Linux kernel network cong…

Yeah, you aren't selling anything. "Reno has a 100% pass rate for recovering cleanly after the loss phase, so the bug is almost certainly related to CUBIC" is a perfectly fine technical text.

Also, the same event both “showing” and “revealing” two different things is just bad writing.

Re: When “idle” isn't idle: how a Linux kernel optimization became a QUIC bug

#33

Post by phreack »

twoodfin wrote: post #32
bonzini wrote: post #28

Earlier quoted context omitted.

Yeah, you aren't selling anything. "Reno has a 100% pass rate for recovering cleanly after the loss phase, so the bug is almost certainly related to CUBIC" is a perfectly fine technical text.

Also, the same event both “showing” and “revealing” two different things is just bad writing.

Another LLM tell is that they penalize repetition so they'll use as many synonyms as possible. You may end up recognizing the same concept being rehashed with synonyms constantly. You can look up examples of thie as "elegant variation"

Re: When “idle” isn't idle: how a Linux kernel optimization became a QUIC bug

#34

Post by Worf »

phreack wrote: post #33
twoodfin wrote: post #32

Earlier quoted context omitted.

Also, the same event both “showing” and “revealing” two different things is just bad writing.

Another LLM tell is that they penalize repetition so they'll use as many synonyms as possible. You may end up recognizing the same concept being rehashed with synonyms constantly. You can look up examples of thie as "elegant variation"

In one of the languages I read, journalists do this when quoting someone and it pisses me off. Instead of "said", they'll cycle through the same 6-7 synonyms. Instead of just quoting everything together, they break it up.

So instead of:

> President Jackson said "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.".

They'll do something like:

> President Jackson noted that "Lorem ipsum dolor sit amet". The head of state also remarked that "consectetur adipiscing elit" while emphasizing that "sed do eiusmod tempor incididunt ut labore et dolore magna aliqua".

> "Ut enim ad minim veniam, quis nostrud exercitation", categorically proclaimed the former business tycoon. He concluded that "ullamco laboris nisi ut aliquip ex ea commodo consequat".

I've seen this way before LLMs and how much it's used varies a bit from language to language. But it's so formulaic, I can't help but imagine some brain-dead moron sitting in front of the keyboard, trying to make 5 paragraphs from 2 sentences someone said without adding anything else.

Re: When “idle” isn't idle: how a Linux kernel optimization became a QUIC bug

#35

Post by hack1312 »

OptionOfT wrote: post #25

I tried to read the article, and had to go back and forth between reading about terms and etc, because I'm not _that_ familiar in the space. But previously I could understand Cloudflare's blog posts. This one just feels... off. The buildup just doesn't feel right. The fact that there is an Em Dash (sorry...) in the code tells me that it's at least AI assisted, which explains the vibe the article emanates. And once I…

The vast majority of the marketing team was laid off. Prince said he only needs people to build and people to sell, fuck everyone else.

Re: When “idle” isn't idle: how a Linux kernel optimization became a QUIC bug

#36

Post by johng »

I _believe_ i've been having some connectivity issues related to this. Where the site acts like it's down but you refresh the page and it works. The solution is to disable the HTTP-3/QUIC toggle in Cloudflare. Some discussion here: https://xenforo.com/community/threads/page-could-not-be-load...

May not be related, but it might. It only recently started happening to me/our sites in the past couple of days.

Re: When “idle” isn't idle: how a Linux kernel optimization became a QUIC bug

#37

Post by insumanth »

The line that stuck with me: "Recovery after congestion collapse is an uncommon regime, but it is exactly the regime a congestion controller exists to handle." This generalizes well beyond congestion control.

Most control loops have the same property. The path the system follows 99% of the time gets well-exercised; the path it falls into when things go wrong is the path you actually need to be correct on. There's usually no way to discover the bug until you deliberately drive the system into the bad regime and watch it try to climb out.

Re: When “idle” isn't idle: how a Linux kernel optimization became a QUIC bug

#38

Post by happyPersonR »

otterley wrote: post #21
vasilvv wrote: post #15

Earlier quoted context omitted.

> though going the in-house approach would warrant keeping an eye on the relevant kernel commits like a hawk to avoid missing bug fixes like these. These in-house implementations tend to have less eyeballs than the kernel. This is somewhat funny to read because this specific issue in CUBIC (sudden CWND jump upon existing quiescence) was originally discovered in Google's QUIC library and then later reported to the tea…

Would formal validation of these algorithms (e.g. with TLA+) help avoid such bugs?

I thought there was in the past and some of the flaws found were addressed in facebooks version of this

https://doi.org/10.1145/3452296.3472912

Toward formally verifying congestion control behavior | Proceedings of the 2021 ACM SIGCOMM 2021 Conference

Re: When “idle” isn't idle: how a Linux kernel optimization became a QUIC bug

#39

Post by yencabulator »

lproven wrote: post #11

The article uses the term "CCAs" without ever defining it. I followed the links, and googled it, with no useful result. What is a CCA in this context?

Not sure if it got edited, but the first use of the term is

> Before we dive into the core problem, a quick refresher on Congestion Control Algorithms (CCAs) may help to set the stage.

Post reply on HN