Linked by Thom Holwerda on Mon 27th Aug 2007 22:21 UTC
Windows A curious network performance reduction noticed by many Windows Vista users of the 2CPU forum that became the talk of Slashdot last week has been identified as having been caused not by DRM, as Slashdot users expected, but by a curious prioritization 'feature' of Vista that's intentionally biased toward Media Player at the expense of network and system resources.
Thread beginning with comment 266183
To read all comments associated with this story, please click here.
abraxas
Member since:
2005-07-07

Russinovich's characterization of the throttling trigger as "hard-coded" may be an indication that the company's fix may involve giving the user a choice of which services should be pared down when crunch time comes, system services or multimedia. But with the sheer number of system services Vista now runs, crunch time may be coming too often anyway.

I don't think Micsosoft is going to allow customers to choose which services are alloted more processor time. I think they are more likely going to alter the trigger from being hard-coded to a variable based on detection of network speeds.

It seems that the people that replied to this thread have said nothing about the real issue which is the hard-coding of network speeds to 100Mbit. This is bound to cause problems on networks that don't operate at 100Mbit. It was a stupid move but one that shouldn't take much effort to fix.

Reply Score: 5

butters Member since:
2005-07-08

Hmmm, it seems like we have a proc neutrality debate on our hands! Microsoft wants to throttle certain types of tasks (moving content) in favor of others (consuming content). But they don't own our processors, and we don't (typically) share them with other Microsoft customers. Even if people find this tradeoff acceptable (which I don't doubt), we should be able to disable or adjust this throttling to fit our needs.

As for the hard-coded throttling, this is just ridiculous. The very least Microsoft can do is base the throttling on a hardware calibration loop to compensate for differences in network and processor performance. In other words, figure out the average processor time per second required on your system to process packets at your network speeds. They can build it into their upgrade treadmill index thingy (forget the name).

But even better, they should dynamically adjust the relative timeslice ratios of realtime tasks at runtime. If we drop excessive packets because the network driver is starving, give a bit more to the network. If we drop a sample/frame because the media player is starving, pump it up. A steady-state equilibrium should be established very quickly as network usage and/or media workload changes.

Reply Parent Score: 3