Debugging Microsoft.com 511
teslatug writes "Channel 9 has an interesting video interview with Chris St.Amand and Jeff Stucky who test and debug Microsoft.com. They reveal some of the big problems they used to face such as recycling processes every 5 minutes due to memory leaks and 32 bit limitations, and being unable to push more than 10 Mbits of data to their datacenters due to Windows' networking stack limitations."
Missing info... (Score:5, Informative)
Easy. (Score:4, Informative)
2. xine [xinehq.de]
Not that tough, really, now is it?
Not just Windows stack limitations (Score:4, Informative)
The new TCP stack in Vista effectively implements TCP is such a way that it removes these limitations while preserving compatibility with old stack implementations.
Re:Missing info... (Score:5, Informative)
Compound TCP (Score:3, Informative)
http://research.microsoft.com/research/pubs/view.
Re:Not just Windows stack limitations (Score:4, Informative)
Re:Missing info... (Score:4, Informative)
All that chimney does is provide a standard way for windows to offload the tcp-stack to a seperate processor running on the NIC.
From the white paper: "TCP Chimney offloads the TCP protocol stack to a Network Interface Card (NIC) "This has been available for high-end systems for a decade or more.
A quick google search for "linux tcp/ip accelerated" will find numerous examples of Linux cards that offload the stack.
Re:Not just Windows stack limitations (Score:4, Informative)
Regardless, that has little to do with the problem Microsoft encountered in connecting two datacenters that where phsyiscally seperated by a long distance but connected with a high bandwidth pipe. See this research paper [microsoft.com].
Re:Hmm.... (Score:1, Informative)
I know you're making a joke, but the "Windows uses the BSD stack" FUD has got to stop.
Windows NT 3.1 and 3.5 included a port of the BSD stack.
Windows NT 3.51 (and all subsequent versions) included a completely new written-from-scratch stack. There are still bits of BSD fluff around (for example, the uber-lame FTP client) but the TCP/IP stack is not the BSD stack.
The TCP/IP stacks shipped with Windows for Workgroups 3.1, Windows 95, Windows 98, and Windows ME were based on the NT 3.51 stack. In fact, the NT 3.51, WfW 3.11, and Win95 stacks were developed more-or-less concurrently using the same source base.
In other words, no version of Windows shipped in the past 10 years has used any derivative of the BSD TCP/IP stack.
Re:Missing info... (Score:3, Informative)
Read this [microsoft.com] instead.
Re:10Mbits/s? really? (Score:1, Informative)
No, he's not.
Just because you can push 480Mb/s doesn't mean you're getting 480Mb/s throughput on any given connection.
Yes it does - it means that he's getting 480Mb/s to the outside world. Whether that is to one client on the same local link, or split between 1000 clients across the globe, it's still 480Mb/s.
Suppose you had 1Gb/s on two connections seperated by 5000 miles. You really think you're going got get 1Gb/s?
Yes. By definition. That's what 1Gb/s means. Latency and bandwidth are orthogonal.
The inherant latency delays in the protocol make it impossible to get anywhere near optimum bandwidth.
Latency and bandwith are orthogonal. If you could get 1Gb/s to Mars, it's *still* 1Gb/s, even though the latency would be measured in seconds (or possibly minutes.)
As they say, never underestimate the bandwith of a station wagon full of backup tapes hurtling down the highway.
Re:Not just Windows stack limitations (Score:3, Informative)
I agree that no modern OS runs a 30 year old stack... but most modern OS's today still have major issues with high latency connections even when those pipes have plenty of bandwidth. There is nothing we can do about a 100ms latency when the connection is 5000 miles long, but there is a lot we can do to improve the TCP protocol to optimize for those long distance/high bandwidth connections that are becoming more and more common.
Re:10Mbits/s? really? (Score:3, Informative)
Take a truck. A huge one. Fill it up with recorded DVD's and send it over a hundred miles distance.
You'll have huge bandwidth.
But wait, somehow a DVD got lost in transit. What now ?
You have to phone back and have a taxi to pick it up and deliver the missing DVD.
As you need the last DVD, you'll have to wait. Your bandwidth decreases.
It's pretty much costly for you to do so if you miss a DVD.
So you decide to take only a hundred DVD's per truck and using multiple smaller trucks. But somehow none is missing this time, so you spent a lot of money for the extra trucks.
This issue is somehow similiar to Heisenberg's Uncertainty Principle [wikipedia.org]. You cannot get maximum bandwidth and minimum latency.
Linux can respond faster if it has to. OS/X doesn't do that because it does not want to.
It can also respond slower:
$ cat
250
Tune it as you wish.
Yes, I had some beers today, and what?
Think you misread (Score:5, Informative)
-everphilski-
Re:Remember Hotmail? (Score:3, Informative)
It still can't stand up to the weight. Have you tried using Hotmail in the middle of the day and get those SERVER TOO BUSY errors? If it even responds!
Re:The Desk (Score:5, Informative)
You see, Microsoft started the great thing a few years back where every floor was stocked with 2 giant refrigerators of free soda. The rest of the local software companies quickly moved to copy this ingenious move, so you can't program and not be in contact will all the free soda you can drink. This sounds pretty cool until you've done it for about 2 years. At that time, assuming you are not a natural soda addict, the last thing on earth you want to drink is any kind of beverage with sugar in it, because you are so unbelievably sugared out. In come Talking Rain. Talking Rain is a simple carbonated spring water, with just a hint of fruit oil added, and no sugar. Green Talking Rain adds lime oil, and Red Talking Rain adds Rasberry, I think, although being a Greener myself, I never really paid attention. The fact that only senior programmers have completed this Talking Rain pupation, allows you to easily glance at someone's trash can in their office and peg them for a Senior or Junior level developer. You will almost never see a Junior level developer drinking Talking Rain, and almost never see a Senior level NOT drink it. Kind of a free soda pecking order.
Of course I may be reading to much into this, but my Greener roots run deep
Re:10Mbits/s? really? (Score:5, Informative)
A quick web search says round trip times to mars are between 10-50 minutes. Say 60 minutes * 60 seconds = 360 gigabits of window space to achieve full line rate. Now consider some minor packet loss and even with SACK you're buffering an unreasonable amount of data.
Annoying that the parent got modded up with bad information and this post will likely be passed over.
Re:Missing info... (Score:4, Informative)
The
Nonetheless, Microsoft does have extraordinary bandwidth. On the day that Visual Studio was released to the MSDN, amid great fanfar, I downloaded that night at 650KB/second (the cap on my cable modem) for the entirity of the download.
Re:10Mbits/s? really? (Score:2, Informative)
The round trip time to Mars varies between about 10 and 40 minutes, depending on the relative positions of the Earth and Mars.
Re:Sounds like a lot of crap... (Score:3, Informative)
Even Microsoft acknowledged that BSD was superior to Windows http://www.csse.monash.edu.au/~lloyd/tildeMisc/200 1/2001-MS-BSD.html [monash.edu.au]
So, while Microsoft has been adding "improvements", BSD hasn't stood still. Its STILL better than anything Microsoft has.
I worked for an ISP that was hosting a M$ site ... (Score:5, Informative)
Re:10Mbits/s? really? (Score:3, Informative)
Each end of a TCP connection allocates a receive buffer. The available empty space in this buffer is mentioned as part of the header on every packet. A TCP implementation allowed to continue sending packets to the other machine as long as there is space in the buffer. If machine A says it has an 8 KB buffer, then machine B can send 8 KB without worrying. If machine B receives an ACK packet saying that there is free buffer space from machine A before it sends 8 KB, then it can keep on sending data. However, if 8 KB is sent before machine B hears anything from machine A, machine B is required to completely stop sending data until it receives an ACK indicating free buffer space.
The buffer size specified in the TCP header is a 16 byte number. This worked fine on slower networks, but according to the article it peaks around 10Mb/s. It becomes an issue of latency. Once you receive a packet, you need to be able to get an acknowledgement packet to the other machine before it can send out 64KB of data (counting the packet you just received). If you can't, the other machine stops sending data until it hears from you.
Sometime in the 90's when the problem first became an issue, a solution was developed. A new TCP option was created that indicated the buffer size in the TCP header was to be multiplied by a number specified during the initialization of the connection to get the true buffer size. Apparently MS only implemented this recently.
Re:10Mbits/s? really? (Score:2, Informative)
Re:Easy. (Score:3, Informative)
32-bit DLLs work fine on 64-bit x86 Linux. You have to compile MPlayer as a 32-bit program, of course, but you're still running it on a 64-bit processor, and a 64-bit Linux OS.
Re:Struggling beyond 10Mbit/s? (Score:3, Informative)
#2: -10 points for using "synergy" in technical info (linked ms.com article)
Re:Not just Windows stack limitations (Score:3, Informative)
1,073,741,824 bits per 200ms (100ms RTT)... and thats with the receiver just ACK'ing after the transfer of each 1 gig chunk, not providing intermittant ACKs throughout the transfer.
Re:Missing info... (Score:4, Informative)
To think that you can slashdot Microsofts site because of a puny WMV-file is naive.
It's really naive when you consider the that Microsoft don't host their own website. Akamai does.
Re:What the... (Score:3, Informative)
MOD PARENT DOWN (Score:1, Informative)
The search at rpm.pbone.net in the parent post returns "Your search MPlayer-w32codecs-1.0pre7try2-15.sparc.rpm did not match any entry in database.". Further searches at rpm.pbone.net and Google do not return any hits for this rpm.