Slashdot Mirror
Debugging Microsoft.com
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."
The summary is missing the fact that many of their problems went away after upgrading to an early 64 bit version of Vista with its improved networking stack.
Help Brendan pay off his student loans
1. mplayer
2. xine
Not that tough, really, now is it?
The secret to creativity is knowing how to hide your sources. -- Albert Einstein
The limitations discussed in the video of the Windows TCP stack are not limited to Windows. These are limitations imposed by a to-the-spec implementation of TCP. TCP is 30+ years old, and it wasn't designed for the kinds of networks it runs on today.
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.
Slightly off topic, but the new Windows TCP stack will be implementing their new Compound TCP stack, aka, CTCP. More information can be read here:
a spx?type=Technical%20Report&id=940
http://research.microsoft.com/research/pubs/view.
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.
You're confused.
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.
Bandwidth vs Latency.
/proc/sys/net/ipv4/icmp_ratelimit
:)
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. 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?
No, no, no... they can saturate a 10MB/s connection easily. What they had problems with was database connections over a long distance (a problem with TCP, not windows)... which they rectified (using a concept called CTCP), check this paper out: http://research.microsoft.com/research/pubs/view.a spx?type=Technical%20Report&id=940
-everphilski-
Remember the whole Hotmail fiasco in late '97 when Microsoft acquired it? The whole thing was running on UNIX and ran just fine. They tried to replace it with NT servers, and it just couldn't stand up under the weight no matter how much hardware they threw at it.
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!
The one on the left is Coke, the other 3 are Red Talking Rain. Personally, I'm a Green Talking Rain programmer, but I can respect teh other side :) Talking rain (particularly green) is the nectar of the programmers here in Seattle.
:)
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
Latency and bandwidth are not orthogonal when you have flow control. Try looking up 'bandwidth delay product' and tcp windowing. To achieve 1gbp/s to mars you need to buffer all that data in case of packet loss. Available memory will throttle your throughput.
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.
The round trip time to Mars varies between about 10 and 40 minutes, depending on the relative positions of the Earth and Mars.
Even Microsoft acknowledged that BSD was superior to Windows http://www.csse.monash.edu.au/~lloyd/tildeMisc/200 1/2001-MS-BSD.html
So, while Microsoft has been adding "improvements", BSD hasn't stood still. Its STILL better than anything Microsoft has.
It was one of there secondary sites, something like blah.microsoft.com. The ISP was supposed to be hosting it on a colo NT box as part of an outsourced hosting contract. Well the site crashed constantly and the support team got sick of the late night pager calls and moved it over to a BSDI box with Apache and spoofed the server headers to read IIS, never told the M$ guys.
You're totally not understanding where the bottleneck is. The issue isn't if it's possible to push 480Mb/s out of one machine, or if it's possible to push it over a link rated at 480Mb/s. The issue is if it's possible to do it *using the original TCP standard*.
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.
If you watch the system log on an OS X machine that's getting ping flooded, you'll note that it starts printing "Limiting icmp ping response from (large number) to 250 packets per second". It's entirely intentional.
TANSTAAFI: There Ain't No Such Thing As A Free iPod.
#1: tcp window sizes are neat. By changing a couple proc variables, I can push 350mbps with a single tcp flow over a busy I2 link with a single stock fedora core 3 kernel, on a 1ghz P3.
#2: -10 points for using "synergy" in technical info (linked ms.com article)
The VLC features documentation states that VLC is able to read WMV under (Open|Free)BSD
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Who the hell modded this 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.