Linked by Thom Holwerda on Wed 29th Aug 2007 00:28 UTC, submitted by diegocg
Permalink for comment 266618
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
More News »
Sponsored Links



Member since:
2005-12-31
This reminds me of a Microsoft paper called:
"The Problems You're Having May Not Be the Problems You Think You're Having"
It was written in 1998 and was a study of the problems with handling low latency audio, video etc tasks on NT kernel based operating systems.
It has an interesting paragraph:
"Another commonly held view is that Ethernet input packet processing is a problem. Yet we tested many of the most popular 10/100 Ethernet cards receiving full rate 100Mbit point-to-point TCP traffic up to user space. The cards we tested were the Intel EtherExpress Pro 100b, the SMC EtherPower II 10/100, the Compaq Netelligent 10/100 Tx, and the DEC dc21x4 Fast 10/100 Ethernet. The longest observed individual DPC execution we observed was only 600 µs, and the longest cumulative delay of user-space threads was approximately 2ms. Ethernet receive processing may have been a problem for dumb ISA cards on 386/20s, but it's no longer a problem for modern cards and machines."
So why did Microsoft need to fix something that was not broken?