Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for June 20, 2013
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Quote of the week
Posted Aug 30, 2007 1:37 UTC (Thu) by sayler (guest, #3164)
Posted Aug 30, 2007 4:03 UTC (Thu) by flewellyn (subscriber, #5047)
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".
Posted Aug 30, 2007 9:44 UTC (Thu) by jengelh (subscriber, #33263)
Posted Aug 30, 2007 8:44 UTC (Thu) by ekj (guest, #1524)
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.
Posted Aug 30, 2007 9:08 UTC (Thu) by jospoortvliet (subscriber, #33164)
Posted Aug 30, 2007 11:51 UTC (Thu) by smitty_one_each (subscriber, #28989)
Posted Aug 30, 2007 9:59 UTC (Thu) by intgr (subscriber, #39733)
Linux was doing the same thing before the NAPI network driver API came
along -- new 3GHz servers were maxing out their CPU way below the Gbit/s
capacity, because handling tens of thousands interrupts per second meant
that there was little time left for processing _anything_. Instead,
Linux now switches to a polling mode and decides for itself when it's
convenient to receive packets.
> Also, decoding and playing an mp3-file is a 1% cpu task on a similar
The packet throttling code is activated regardless of what kind of media is
actually playing which obviously a stupid idea. Apparently they had
problems when decoding some kind of video, which is understandable if
there is no hardware acceleration for the codec.
But the hack they wrote to work around this issue certainly deserves all
Posted Aug 30, 2007 16:40 UTC (Thu) by AJWM (guest, #15888)
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.)
Posted Aug 30, 2007 19:14 UTC (Thu) by BenHutchings (subscriber, #37955)
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.
Posted Sep 6, 2007 18:17 UTC (Thu) by jd (guest, #26381)
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?
Posted Aug 30, 2007 18:12 UTC (Thu) by xav (guest, #18536)
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.
Posted Aug 30, 2007 19:00 UTC (Thu) by BenHutchings (subscriber, #37955)
Posted Aug 30, 2007 19:34 UTC (Thu) by xav (guest, #18536)
Posted Aug 30, 2007 12:41 UTC (Thu) by lysse (guest, #3190)
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...
Posted Aug 30, 2007 14:43 UTC (Thu) by nix (subscriber, #2304)
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.
Posted Aug 30, 2007 15:02 UTC (Thu) by amikins (guest, #451)
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. :)
Posted Aug 30, 2007 17:47 UTC (Thu) by lysse (guest, #3190)
...As Microsoft might just be reflecting at the moment, come to think of it.
Posted Aug 30, 2007 19:29 UTC (Thu) by AJWM (guest, #15888)
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.)
Posted Aug 30, 2007 23:45 UTC (Thu) by nix (subscriber, #2304)
Posted Aug 30, 2007 9:46 UTC (Thu) by tialaramex (subscriber, #21167)
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.
Posted Aug 30, 2007 11:29 UTC (Thu) by gouyou (subscriber, #30290)
Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds