It makes me sick to see ignorant readers trying to be smug with their "+3 funny" remarks. Jim Gray is one of the great minds in computer science, a Turing award recipient and has published some of the seminal works in transactions and serializability theory. Cut out the Microsoft bashing and show some respect.
For the kinds of usage patterns that source code control systems generate, latency is most likely going to make a bigger difference.
mod parent up. what parent is trying to say is related to the way TCP manages its congestion window. If you're facing high latency in the link to your UK office (which is likely, given the distance metric), the RTT will be high and TCP will slice its congestion window in half -- so even if you were to have "sufficient bandwidth" (whatever that means!), TCP wouldnt let you fill the pipe unless the latency issue is simultaneously addressed.
A good rule of thumb is to look at the bandwidth-delay product (BDP), which is an estimate of the maximum window size TCP will reach. That will tell you to what extent TCP is filling the pipe. Then look at the typical workload at your India office (do you use it only for source control, or do your developers download large files such as logs/cores? what is the percentage of datagram traffic? is there any source of bursty traffic?). Put together all the pieces and you should end up with a very rough estimate. pick up any good book on TCP and you may find some more answers.
Netscape opening multiple requests in parallel seemed like a massive abuse of webserver resources
...as opposed to Internet Exploder?
AAMOF this had more to do with the absence of persistent connections in the HTTP 1.0. The server would simply close the socket at its end after servicing a request, so the client had to open a new connection for each new object in the page.
That has changed in HTTP 1.1, among other reasons due to the server maxing out the number of open connections on the host.
This would be a cool idea if the distro supported a sufficiently large number of device drivers. That way you could boot off this USB drive and expect all the hardware on the host to be discovered. Knoppix would be the ideal choice for this sort of a thing. IBM tried something similar [slashdot.org] with Knoppix to allow users to carry the state of their OS around on portable storage.
Those two examples highlight the perfect situation where the bottleneck isn't even close to being the CPU, the disks are simply working at 100% capacity
That argument holds good if you're running *ONLY* a bunch of apps, each requiring high disk I/O. In that case the CPU is going to be left twiddling its thumbs since everyone's waiting for the I/O to complete. But that is not the case in general. You are overlooking the fact that there are several other threads (read processes in the non-Linux world) that are waiting for their share of the CPU. So while your app waits for the disk read to complete, the other threads could benefit from the additional execution core.
Also note that the operating system has a big role to play in how it mitigates the high latency in disk I/O, particularly w.r.t its management of the page cache, writeback policy and disk scheduling.
VMware uses various techniques to get around this, including full simulation and binary re-writing.
VMWare does not do a *full* simulation ala plex86 or bochs, instead it runs the guest OS at PL1 and translates only the sensitive instructions when they trap to PL0. Also note that the move to Vanderpool or Pacifica will benefit VMware as much as it does Xen - of course Xen may always hold the edge in terms of speed. That said, Xen's paravirtualization approach is quite kludgy - one can see how development issues will just go back and forth between OS writers and the virtualization people.
Slashdot Mirror
It makes me sick to see ignorant readers trying to be smug with their "+3 funny" remarks. Jim Gray is one of the great minds in computer science, a Turing award recipient and has published some of the seminal works in transactions and serializability theory. Cut out the Microsoft bashing and show some respect.
For the kinds of usage patterns that source code control systems generate, latency is most likely going to make a bigger difference.
mod parent up. what parent is trying to say is related to the way TCP manages its congestion window. If you're facing high latency in the link to your UK office (which is likely, given the distance metric), the RTT will be high and TCP will slice its congestion window in half -- so even if you were to have "sufficient bandwidth" (whatever that means!), TCP wouldnt let you fill the pipe unless the latency issue is simultaneously addressed.
A good rule of thumb is to look at the bandwidth-delay product (BDP), which is an estimate of the maximum window size TCP will reach. That will tell you to what extent TCP is filling the pipe. Then look at the typical workload at your India office (do you use it only for source control, or do your developers download large files such as logs/cores? what is the percentage of datagram traffic? is there any source of bursty traffic?). Put together all the pieces and you should end up with a very rough estimate. pick up any good book on TCP and you may find some more answers.
Smoking Pot Demo at Linux World Boston
darn. I need to cut down on the caffeine.
why bother? its not like we here at /. RTFA anyway.
Googlefight has Steve Jobs as winner.
Bill G = 35,200,000
Jobs = 142,000,000
Netscape opening multiple requests in parallel seemed like a massive abuse of webserver resources
...as opposed to Internet Exploder?
AAMOF this had more to do with the absence of persistent connections in the HTTP 1.0. The server would simply close the socket at its end after servicing a request, so the client had to open a new connection for each new object in the page.
That has changed in HTTP 1.1, among other reasons due to the server maxing out the number of open connections on the host.
Polaris is really a triple star system
so this why Sun is still excited about PowerPC.
what the %@#$! where's the directions for putting it back together??
Well, that erased my usb floppy disk, and I still don't know much. Next?
huh? who said anything about scsi emulation.
dd if=/dev/zero of=/dev/sda
That'll teach you not to mess with Unix in 24 hours.
This would be a cool idea if the distro supported a sufficiently large number of device drivers. That way you could boot off this USB drive and expect all the hardware on the host to be discovered. Knoppix would be the ideal choice for this sort of a thing. IBM tried something similar [slashdot.org] with Knoppix to allow users to carry the state of their OS around on portable storage.
phew...thank goodness I've downloaded my stash of p0rn
Those two examples highlight the perfect situation where the bottleneck isn't even close to being the CPU, the disks are simply working at 100% capacity
That argument holds good if you're running *ONLY* a bunch of apps, each requiring high disk I/O. In that case the CPU is going to be left twiddling its thumbs since everyone's waiting for the I/O to complete. But that is not the case in general. You are overlooking the fact that there are several other threads (read processes in the non-Linux world) that are waiting for their share of the CPU. So while your app waits for the disk read to complete, the other threads could benefit from the additional execution core. Also note that the operating system has a big role to play in how it mitigates the high latency in disk I/O, particularly w.r.t its management of the page cache, writeback policy and disk scheduling.
VMware uses various techniques to get around this, including full simulation and binary re-writing.
VMWare does not do a *full* simulation ala plex86 or bochs, instead it runs the guest OS at PL1 and translates only the sensitive instructions when they trap to PL0. Also note that the move to Vanderpool or Pacifica will benefit VMware as much as it does Xen - of course Xen may always hold the edge in terms of speed. That said, Xen's paravirtualization approach is quite kludgy - one can see how development issues will just go back and forth between OS writers and the virtualization people.