Announcement

Collapse
No announcement yet.

Google Fixes A Longstanding, Important TCP Bug In The Linux Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • SystemCrasher
    replied
    Originally posted by droidhacker View Post

    Not just servers, but also portable devices... where it actually has an even GREATER share than servers (over 80%).
    Then, there're some smart TVs, routers, NAS boxes, "compute sticks" and so on... all this accounts for millions of units and if you carefully look around, you can easily find about 5 devices running Linux vs every single Windows PC. Windows just does not fits many tasks at all. Say, winduz sucks really hard in embedded. Pooly customizable OS with moron licensing terms. It could be better than that for sure.

    When it comes to portable devices... winduz only can support qualcomm SoC. All other SoCs "forced" to love Linux, because ... winduz can't work on anything but qualcomm. EPIC FAIL - all these stories about better hardware compatibility are nuff void.
    Last edited by SystemCrasher; 06 October 2015, 08:42 AM.

    Leave a comment:


  • droidhacker
    replied
    Originally posted by FLHerne View Post

    On web servers - where this is actually relevant - that share is more like 70%. More than twice that of Windows.
    Not just servers, but also portable devices... where it actually has an even GREATER share than servers (over 80%).
    I think that windows has something like ZERO percent share in portable devices.

    I actually think that this bug will have more impact on portable devices than servers. Because servers tend to have multiple users, they don't generally have a quiescent period. They stay under load. Portable devices, on the other hand, have the OBJECTIVE of maximizing the quiescent periods in order to improve battery performance. So they'll sit there dormant, until they blast everything all at once. Combine that with a generally SLOWER network, and bad things happen.

    Leave a comment:


  • Ardje
    replied
    Originally posted by Rexilion View Post
    Besides, from the description it seems that the issue goes away once the first congestion is detected and acted upon accordingly.
    Unfortunately no. After "idle" (which is normal in tcp land), it needs to congest again and again, while you actually want to continue the same parameters. Idle might be a 1 second delay or whatever is considered idle. Normal tcp land usually has regular parts of idle. Such as in web browsers, which linger connections for a few seconds.

    Leave a comment:


  • YoungManKlaus
    replied
    Originally posted by FLHerne View Post
    On web servers - where this is actually relevant - that share is more like 70%. More than twice that of Windows.
    You also forgot that teeny tiny thing called Android, so also for consumers Linux market share is more around 50% (wild guess form me) across their major internet devices.

    Leave a comment:


  • SystemCrasher
    replied
    Well, I noticed some strange "oscillations" in TCP traffic, too. And I suspect this could at least partially mitigate it. Though calling it "important" is overrated: it only happens in very specific circumstances and does not affects most of users most of time. So after fix, most people would not see anything changed at all...

    Leave a comment:


  • pal666
    replied
    Originally posted by Master5000 View Post
    If these issues are longstanding bugs in the kernel then I don't think Linux is serious OS. It's probably better that it's at 1%.
    moron, linux has larger installed base than all others combined. its only weak spot is desktop pcs, which are not the largest traffic source

    Leave a comment:


  • thunderbird32
    replied
    Originally posted by vsteel View Post

    Zork> Pick up sword.
    Zork> Kill troll with sword
    The troll is disarmed by a subtle feint past his guard.
    The unarmed troll cannot defend himself: He dies.
    Almost as soon as the troll breathes his last breath, a cloud of sinister black fog envelops him, and when the fog lifts, the carcass has disappeared.
    Your sword is no longer glowing.
    "'Your sword's blowing glue'. Wait let me try that again, 'Your sword's glowing blue'."

    Leave a comment:


  • Remdul
    replied
    Hmm. This bug reminds me of another (inherent?) flaw in the typical Berkeley socket implementation. When you close the socket, all pending outgoing data is immediately destroyed, and nothing is send (the expected behavior appears undocumented). This requires the client application to wait for the network stack (networking hardware mostly?) to finish up, wasting lots of CPU cycles. My guess is that Google & co have custom socket implementations or hardware that have this fixed (or worked around), but for your typical client application (read: everything not in a datacenter), you have to wait until it burps. An enormous amount of energy must be wasted worldwide on those pointless CPU cycles.

    What I learned is that the technology that powers the internet is extremely fragile, outdated, and quite frankly, in very very poor state. OpenSSL/Heartbleed was just the tip of the iceberg. IMO, it's a miracle that things just work at all.
    Last edited by Remdul; 28 September 2015, 09:48 AM.

    Leave a comment:


  • Delgarde
    replied
    Originally posted by asdfblah View Post
    BTW, why are you people feeding the troll?
    Boredom, I assume. Arguing with trolls isn't very productive, but it can be a fun way to waste some downtime...

    Leave a comment:


  • milkylainen
    replied
    Reading the title you would indeed think this was high profile. A longstanding TCP bug...
    Yeah.. In the cubic congestion control module.
    That's why congestion control is modular to begin with.
    Because congestion control is a behavior ridden booby trap field.

    Leave a comment:

Working...
X