Weekly Edition
Return to the Kernel page
| |||||||||||||
|
| |||||||||||||
Quote of the week
In other words, consuming half of your processor is (surprise!)
detrimental to multimedia playback performance. At this point, it
becomes clear that the process scheduler folks and the networking
folks are bitter enemies and do not converse.
-- Robert
Love (not talking about Linux)(Log in to post comments)
Quote of the week Posted Aug 30, 2007 1:37 UTC (Thu) by sayler (subscriber, #3164) [Link] "IP is HARD! Let's go hacking!"
Quote of the week Posted Aug 30, 2007 4:03 UTC (Thu) by flewellyn (subscriber, #5047) [Link] Wow...throttling the networking code in order to give priority to multimedia playback? Don't they realize how that's going to absolutely KILL streaming media? This should be in the dictionary under "crock".
Quote of the week Posted Aug 30, 2007 9:44 UTC (Thu) by jengelh (subscriber, #33263) [Link] In fact, this should get a place on, say, www.DoingItWrong.com.
Quote of the week Posted Aug 30, 2007 8:44 UTC (Thu) by ekj (subscriber, #1524) [Link] I never got that either. How on earth can you manage to spend 40% or thereabout of your CPU for doing something as trivial as streaming 100Mbit/s of ip-packets ? That is complete nonsense. We're talking a modern multi-ghz multi-core cpu here.
Also, decoding and playing an mp3-file is a 1% cpu task on a similar machine.
So, how exactly do two processes, each of which should eat 1% or thereabouts of the CPU manage to step on eachothers toes to the degree that one of them experience a slowdown by a factor of 2-5 (depending on POM it seems) ?
The "fix" is even more laughable.
Quote of the week Posted Aug 30, 2007 9:08 UTC (Thu) by jospoortvliet (subscriber, #33164) [Link] Yeah, it's pretty weird to read this. I thought the MS Win kernel wasn'tthat bad, but this sounds just horrible...
Quote of the week Posted Aug 30, 2007 11:51 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link] The comment is more telling in terms of organizational behavior than any technical argument.I suspect that Vista is Redmond's last OS gasp. Years behind, a trail of dropped features in its wake, and hints of a "urinary struggle" (pissing contest) are this clealry visible to the user? Smacks of a leadership vacuum where an HFMIC like a Torvalds or a de Raadt is supposed to go.
Quote of the week Posted Aug 30, 2007 9:59 UTC (Thu) by intgr (subscriber, #39733) [Link] > How on earth can you manage to spend 40% or thereabout of your CPU for> doing something as trivial as streaming 100Mbit/s of ip-packets To be fair, as far as I can tell these tests were conducted with a gigabit Ethernet card; the limit of 10000 packets per second implies transmission speeds over 100 Mbit/s even with a quite low MTU.
Linux was doing the same thing before the NAPI network driver API came
> Also, decoding and playing an mp3-file is a 1% cpu task on a similar
But the hack they wrote to work around this issue certainly deserves all
Quote of the week Posted Aug 30, 2007 16:40 UTC (Thu) by AJWM (guest, #15888) [Link] > To be fair, as far as I can tell these tests were conducted with a gigabitEthernet card; the limit of 10000 packets per second implies transmission speeds over 100 Mbit/s even with a quite low MTU.
Yes, but that 100 Mbits/s is only 10% of that gigabit Ethernet you've paid for -- which is what people were complaining about.
(Myself, I have no problems playing Ogg files on my desktop coming over the 100 Mbit LAN from the NFS server in my basement -- and it doesn't seem to impact the rest of the network, or my desktop, one whit -- but then there's no microsoftware in that path.)
Quote of the week Posted Aug 30, 2007 19:14 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] CPU usage is quite dependent on the driver and on hardware acceleration features. For example, if hardware checksum generation and checking for TCP/IP is unavailable or disabled this will substantially increase CPU usage. There are several companies selling 10 gigabit Ethernet controllers or NICs and demonstrating throughput fairly close to line rate using Windows drivers. Most of them are using TOEs to do this, though my employer, Solarflare, has not found this to be necessary. This report by Broadband-Testing shows a few comparisons between Windows and Linux drivers on one of our reference NICs on pages 11-13.
Quote of the week Posted Sep 6, 2007 18:17 UTC (Thu) by jd (guest, #26381) [Link] TOE is good. Hardware multicast support is good. Onboard encryption engines would have potential, RVNICs would be good if there was anything that really used them, on-board ECN and traffic control might be neat. For that matter, I have to wonder how efficient the PCI transactions are, as well - there are all kinds of tweaks one could use, but do any of the manufacturers use them?As I see it, there are many places where things could be done faster, better, cheaper and/or easier than with generic off-the-shelf cards. It's merely a case of who does which set of features and when (if ever) will anybody pack in the full set?
Quote of the week Posted Aug 30, 2007 18:12 UTC (Thu) by xav (subscriber, #18536) [Link] > Linux was doing the same thing before the NAPI network driver API came along
Exactely ! That's why fixed ABI, even fixed API suck big time, and that's why the Linux kernel is superior: its driver API is always evolving and getting better. In contrast Win32/Win64 are set is stone and a design mistake is there for life.
Quote of the week Posted Aug 30, 2007 19:00 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] The Windows driver APIs & ABIs are not part of Win32. They do have to remain static for a major release of the OS, but can be changed between releases. Also the kernel can support multiple versions of a driver API. For example, Windows Vista & Server 2008 can use NDIS 5 drivers written for XP & Server 2003, but will work better with NDIS 6 drivers. NDIS 6 allows for various improvements in network performance, particularly through offloading.
Quote of the week Posted Aug 30, 2007 19:34 UTC (Thu) by xav (subscriber, #18536) [Link] I didn't know they deprecated interfaces. I've always been able to install old drivers under Win2K/WinXP, so I assumed they keep backward compatibility at maximum, like for applications.Still, using 40% CPU with the new network stack doesn't look like a real improvement...
Quote of the week Posted Aug 30, 2007 12:41 UTC (Thu) by lysse (guest, #3190) [Link] Yep - whichever way this is looked at, it's a total mess... and to be honest, I would question whether such a disastrous slowdown can actually be fixed at all without fundamentally rebuilding the whole thing.
Which has been done once already.
Of course, the solution which would be adopted in the Free Software world would be a "oh bugger, don't use the latest one whilst we fix it, the last one works just fine", but in MS-world, the last one was Windows XP, and they've very publicly made it clear that they no longer consider it worthwhile - to take all of that back would mortally wound Vista, compromise the future of the Windows platform as a whole, pretty much freeze their sales, and kill the company. So they have no choice but to continue pushing a lemon and hope that nobody notices behind all the shiny...
But as this demonstrates, people *do* notice. Shiny is good for selling stuff, but it doesn't keep people using that stuff - for that you have to provide substance; and Microsoft, by all accounts, have completely (and to be honest, unprecedentedly; sure, they've screwed up before, and nobody likes their business practices much, but this is the first time they've bet the company on a three-legged mare) dropped the ball on that. Lesser mistakes have finished greater companies.
Couldn't have come at a worse time, either. WINE is getting *really* good these days, to the point where you don't need Windows to run Office; kqemu provides virtualisation for free, for anyone, at a respectable speed; the Mac has moved (nigh seamlessly) to x86, and Parallels demonstrates the far-sightedness of that move; Ubuntu is winning lots of friends, including a company we never expected to see...
Quote of the week Posted Aug 30, 2007 14:43 UTC (Thu) by nix (subscriber, #2304) [Link] Of course *installing* stuff under Wine is still harder. I've been trying for some time to install an app that includes QuickTime Pro 7.30 (I think it is). No joy so far.
Of course the nice thing about Wine is that it doesn't matter how long it takes to make this work: the old app will *never* stop working :))) emulators rock.
Quote of the week Posted Aug 30, 2007 15:02 UTC (Thu) by amikins (guest, #451) [Link] Oh, were it true..
I've personally felt the bite of Wine regressions on numerous occasions. They try to keep them to a minimum, but sometimes fixing an implementation error causes something previously working to fail dramatically.
It's still a young technology, and has quite a way to go before it can be relied upon for consistent behavior between releases.
That said, if you SHOW them your regression, they usually track it down right fast. :)
Quote of the week Posted Aug 30, 2007 17:47 UTC (Thu) by lysse (guest, #3190) [Link] I think part of the problem is that the platform it's seeking to emulate is basically two decades' worth of hack upon bug upon special case... it's hard to avoid regressions when reimplementing such a chronic mess.
...As Microsoft might just be reflecting at the moment, come to think of it.
Quote of the week Posted Aug 30, 2007 19:29 UTC (Thu) by AJWM (guest, #15888) [Link] Precisely. The history of Windows development is (from what I've read, no personal knowledge thank ghu) littered with special case hacks to accommodate applications that took advantage of some incidental and undocumented behaviour of previous releases.
It wasn't even necessarily to accommodate the authors/vendors of those badly coded apps either, but rather the trade journalists who would wail long and loud about the next Windows release breaking their apps (never mind that the apps were already broken) if they didn't.
(Of course much of that app breakage wouldn't have happened if the Windows APIs had been properly documented and corresponded to said documentation in the first place.)
Quote of the week Posted Aug 30, 2007 23:45 UTC (Thu) by nix (subscriber, #2304) [Link] Yeah, but even then, if something regresses you can still use the oldversion, or both in parallel. That's often sort of difficult with real Windows. :)
Quote of the week Posted Aug 30, 2007 9:46 UTC (Thu) by tialaramex (subscriber, #21167) [Link] I wondered whether the Vista results were copying with a secure protocol (ie there's crypographic overhead for every packet) and the Microsoft engineers made the mistake of pushing some of that work into the kernel, or a high priority thread, rather than leaving it in userspace where it would lose out to the multimedia software and just slow down your data transfer when it ran short of CPU ?
Certainly the figures shown seem outrageous for just streaming TCP/IP data, but if I compare them to using SFTP here then they seem fairly ordinary. However the SFTP on this Fedora machine doesn't pre-empt realtime audio processes so none of the crazy workarounds from Vista would be necessary.
Quote of the week Posted Aug 30, 2007 11:29 UTC (Thu) by gouyou (subscriber, #30290) [Link] I was also wondering if it had something to do with their protected media path, where apparently most of the internal communication gets encrypted ...
|
|
||||||||||||