Quote:
Originally Posted by raymor
We'd definitely have a look at it if we were doing regular hosting, but 99% of our internet traffic is inbound. With speeds getting faster and faster, the higher bandwidth delay product is a problem for Reno and Tahoe based algorithms, so if we were sending data out we'd evaluate for stability. Aside from our internet traffic, we have our SAN and over the short, fast segments cubic works fine for our needs.
For non-geeks, what I just said is that Brad's FAST TCP is good for web sites.  |
This is the same tech that won the supercomputing bandwidth challenge and transferred the library of congress in like 15 minutes. It's not Reno or Tahoe based, read the white papers.. its FastTCP, the fastest stack on the market - patented and with stability that the others don't have. Since conception, nothing has been faster. Anyways, I know most of your data is inbound. That was kind of my point, its ideal for the sending end. Further, would reduce the total time on full restores dramatically. For that matter, the initial data copy time on multi-TB volumes would be cut to fractions helping you to go live faster and possibly the client for not changing their 95th. Even more interesting, in the event your cloned clients actually fail over their live traffic, now your server is more effectively serving the traffic because it has replaced TCP/IP with FastTCP. Anyways, happy to take the conversation offline. Cheers
Brad