LWN: Comments on "Quote of the week"

Quote of the week

jd — Thu, 06 Sep 2007 18:17:52 +0000

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

nix — Thu, 30 Aug 2007 23:45:18 +0000

Yeah, but even then, if something regresses you can still use the old
version, or both in parallel. That's often sort of difficult with real
Windows. :)

Quote of the week

xav — Thu, 30 Aug 2007 19:34:15 +0000

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

AJWM — Thu, 30 Aug 2007 19:29:05 +0000

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

BenHutchings — Thu, 30 Aug 2007 19:14:58 +0000

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

BenHutchings — Thu, 30 Aug 2007 19:00:30 +0000

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

xav — Thu, 30 Aug 2007 18:12:56 +0000

> 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

lysse — Thu, 30 Aug 2007 17:47:56 +0000

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

AJWM — Thu, 30 Aug 2007 16:40:50 +0000

> 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.

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

amikins — Thu, 30 Aug 2007 15:02:44 +0000

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

nix — Thu, 30 Aug 2007 14:43:59 +0000

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

lysse — Thu, 30 Aug 2007 12:41:58 +0000

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

smitty_one_each — Thu, 30 Aug 2007 11:51:33 +0000

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

gouyou — Thu, 30 Aug 2007 11:29:09 +0000

I was also wondering if it had something to do with their protected media path, where apparently most of the internal communication gets encrypted ...

Quote of the week

intgr — Thu, 30 Aug 2007 09:59:25 +0000

> 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
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
> machine.
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
the ridicule.

Quote of the week

tialaramex — Thu, 30 Aug 2007 09:46:30 +0000

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

jengelh — Thu, 30 Aug 2007 09:44:18 +0000

In fact, this should get a place on, say, www.DoingItWrong.com.

Quote of the week

jospoortvliet — Thu, 30 Aug 2007 09:08:14 +0000

Yeah, it's pretty weird to read this. I thought the MS Win kernel wasn't
that bad, but this sounds just horrible...

Quote of the week

ekj — Thu, 30 Aug 2007 08:44:06 +0000

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

flewellyn — Thu, 30 Aug 2007 04:03:02 +0000

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

sayler — Thu, 30 Aug 2007 01:37:28 +0000

"IP is HARD! Let's go hacking!"