MSDN - Speed of MSDN Subscriber Downloads?

Author

Speed of MSDN Subscriber Downloads?

nospam

2005-03-04, 8:55 pm

I'm curious as to the typical speeds of downloads people are getting
from the MSDN Subscriber Downloads site. I can't seem to get more than
about 100 to 150 KB/s, according to the MS File Transfer Manager
display. This has been observed many times over the last several months
(and with different client computers too). Downloads from other
Microsoft sites are much faster (300 KB/s or more). This includes
downloads from BetaPlace, which also uses MS File Transfer Manager to do
the downloads, yet is much faster than MSDN Subscriber Downloads.

The download server (for a download I'm doing right now) has an IP
address of 207.46.51.29 and a hostname (according to DNS) of
"dsglobalnona.one.microsoft.com.akadns.net" and an alias of
"dsglobal.one.microsoft.com". Perhaps it's just this server (or pool of
servers if it's load-balanced) that's slow? I've read of other posts
where people were getting 300 to 400 KB/s.

Andy Boyd [MS]

2005-03-08, 3:56 pm

There are generally a few reasons for having a different performance from
the MSDN Subscriber Downloads site versus the rest of Microsoft. The main
reason is that Subscriber Downloads uses an entirely different download
infrastructure from, for instance, Microsoft public downloads. MSCOM
downloads uses an edge routing infrastructure, so that popular downloads
tend to be replicated out quite close to the user. Because of the
requrirements for providing secure and robust downloads for very large
files, MSDN Subscriber Downloads uses a client/server system (FTM) which
requires us to actually own and manage each download server. We have
servers in 4 worldwide datacenters, as opposed to the public Microsoft
download infrastructure which could use thousands. Another contributing
factor is that the FTM download system does hash checks of each 64KB packet
transferred, plus encryption. This adds about 10% overhead to the transfer,
as I recall.

--
Andy Boyd
Program Manager
MSDN & technet Subscription Online
http://www.boydtech.com/blog

"nospam" <nospam@example.com> wrote in message
news:OkxPdvPIFHA.3108@tk2msftngp13.phx.gbl...
> I'm curious as to the typical speeds of downloads people are getting from
> the MSDN Subscriber Downloads site. I can't seem to get more than about
> 100 to 150 KB/s, according to the MS File Transfer Manager display. This
> has been observed many times over the last several months (and with
> different client computers too). Downloads from other Microsoft sites are
> much faster (300 KB/s or more). This includes downloads from BetaPlace,
> which also uses MS File Transfer Manager to do the downloads, yet is much
> faster than MSDN Subscriber Downloads.
>
> The download server (for a download I'm doing right now) has an IP address
> of 207.46.51.29 and a hostname (according to DNS) of
> "dsglobalnona.one.microsoft.com.akadns.net" and an alias of
> "dsglobal.one.microsoft.com". Perhaps it's just this server (or pool of
> servers if it's load-balanced) that's slow? I've read of other posts
> where people were getting 300 to 400 KB/s.

Jerry Dearbeck

2005-03-25, 3:55 am

That's good, but why only transmit 576 bytes at a time to the FTM
clients?

<looking for some obscure registry setting for FTM to change... :) >

On Tue, 8 Mar 2005 08:42:35 -0800, "Andy Boyd [MS]"
<andboyd@nospam.microsoft.com> wrote:

>There are generally a few reasons for having a different performance from
>the MSDN Subscriber Downloads site versus the rest of Microsoft. The main
>reason is that Subscriber Downloads uses an entirely different download
>infrastructure from, for instance, Microsoft public downloads. MSCOM
>downloads uses an edge routing infrastructure, so that popular downloads
>tend to be replicated out quite close to the user. Because of the
>requrirements for providing secure and robust downloads for very large
>files, MSDN Subscriber Downloads uses a client/server system (FTM) which
>requires us to actually own and manage each download server. We have
>servers in 4 worldwide datacenters, as opposed to the public Microsoft
>download infrastructure which could use thousands. Another contributing
>factor is that the FTM download system does hash checks of each 64KB packet
>transferred, plus encryption. This adds about 10% overhead to the transfer,
>as I recall.

Andy Boyd [MS]

2005-03-28, 8:55 pm

I'm not sure, I'll ask.

--
Andy Boyd
Program Manager
MSDN & technet Subscription Online
http://www.boydtech.com/blog

"Jerry Dearbeck" <nospamerhere@msdn.noneya.com> wrote in message
news:sr674198ae3nam9tncvo8apq12pbln37fe@
4ax.com...
> That's good, but why only transmit 576 bytes at a time to the FTM
> clients?
>
> <looking for some obscure registry setting for FTM to change... :) >
>
> On Tue, 8 Mar 2005 08:42:35 -0800, "Andy Boyd [MS]"
> <andboyd@nospam.microsoft.com> wrote:
>
>

Andy Boyd [MS]

2005-03-28, 8:55 pm

I sent this off to the team that manages the download servers for MSDN, and
they've started looking at this based on another thread (not sure if it's
this same one). Anyway, they're sending it to the Tier2 team for analysis,
if this is something that we can adjust within the context of our download
platform then we'll try to do so.

--
Andy Boyd
Program Manager
MSDN & technet Subscription Online
http://www.boydtech.com/blog

"Andy Boyd [MS]" <andboyd@nospam.microsoft.com> wrote in message
news:OXcmHR%23MFHA.2576@TK2MSFTNGP10.phx.gbl...
> I'm not sure, I'll ask.
>
> --
> Andy Boyd
> Program Manager
> MSDN & technet Subscription Online
> http://www.boydtech.com/blog
>
>
> "Jerry Dearbeck" <nospamerhere@msdn.noneya.com> wrote in message
> news:sr674198ae3nam9tncvo8apq12pbln37fe@
4ax.com...
>
>

Robert Schlabbach

2005-03-30, 3:56 pm

Andy, you could tell them to get in contact with Doug Anderson from the
Windows team. I've just sent Doug detailed explanations about why the MSDN
subscriber downloads servers are slow, after investigating their behavior
using network monitor, and suggested possible fixes.

Basically, the File Transfer Manager (FTM) is flawed, as it sends of the
data in 16KB blocks and waits for each to be acknowledged until it sends
the next one. For connections with a high bandwidth*delay product, which is
true for most broadband connections these days, this means the FTM server
will spend more time sitting idle than sending data.

The situation is slightly better when forcing FTM to use HTTPS transfers
(in the options of the FTM client), as that will make the FTM server send
several 16KB blocks overlapped, but the number of overlapped blocks is
still not high enough to keep up with the speed of most broadband
connections.

I'm not sure if it's in the hands of the MSDN infrastructure team to get
the FTM server and client software fixed, but at least they should be able
to fix the 536 bytes packet payload size, which is _not_ within the
responsibility of the FTM, but rather a (mis)configuration of the MSDN
servers.

Also, Service Pack 1 for Windows Server 2003 supposedly fixes the
non-overlapped sending of HTTP transfers, so deploying SP1 ASAP (it
supposedly was RTM yesterday) could also help the situation.

Still, it would be desirable if Microsoft got started on rewriting a
properly through File Transfer Manager server and client software, with the
bandwidth*delay product of modern broadband connections in mind. If it
can't keep up, say, 10Mbps over a 250ms RTT (round-trip-time), it's just
not good enough.

Regards,«
--
Dipl.-Ing. Robert Schlabbach
e-mail: robert_s@gmx.net
Berlin, Germany

"Andy Boyd [MS]" <andboyd@nospam.microsoft.com> wrote in message news:uuZWPg#MFHA.3228@TK2MSFTNGP12.phx.gbl...
> I sent this off to the team that manages the download servers for MSDN, and
> they've started looking at
this based on another thread (not sure if it's
> this same one). Anyway, they're sending it to the Tier2 team for
analysis,
> if this is something that we can adjust within the context of our
download[color=darkred]
> platform then we'll try to do so.
>
> --
> Andy Boyd
> Program Manager
> MSDN & technet Subscription Online
> http://www.boydtech.com/blog
>
> "Andy Boyd [MS]" <andboyd@nospam.microsoft.com> wrote in message
> news:OXcmHR%23MFHA.2576@TK2MSFTNGP10.phx.gbl...
from[color=darkred]
download[color=darkred]
downloads[color=darkred]
which[color=darkred]
contributing[color=darkred]

Andy Boyd [MS]

2005-03-30, 8:55 pm

Thanks for the info - I've sent this to the download platform team.

--
Andy Boyd
Program Manager
MSDN & technet Subscription Online
http://www.boydtech.com/blog

"Robert Schlabbach" <robert_s@gmx.net> wrote in message
news:d2efb5$3sn$05$1@news.t-online.com...
> Andy, you could tell them to get in contact with Doug Anderson from the
> Windows team. I've just sent Doug detailed explanations about why the MSDN
> subscriber downloads servers are slow, after investigating their behavior
> using network monitor, and suggested possible fixes.
>
> Basically, the File Transfer Manager (FTM) is flawed, as it sends of the
> data in 16KB blocks and waits for each to be acknowledged until it sends
> the next one. For connections with a high bandwidth*delay product, which
> is
> true for most broadband connections these days, this means the FTM server
> will spend more time sitting idle than sending data.
>
> The situation is slightly better when forcing FTM to use HTTPS transfers
> (in the options of the FTM client), as that will make the FTM server send
> several 16KB blocks overlapped, but the number of overlapped blocks is
> still not high enough to keep up with the speed of most broadband
> connections.
>
> I'm not sure if it's in the hands of the MSDN infrastructure team to get
> the FTM server and client software fixed, but at least they should be able
> to fix the 536 bytes packet payload size, which is _not_ within the
> responsibility of the FTM, but rather a (mis)configuration of the MSDN
> servers.
>
> Also, Service Pack 1 for Windows Server 2003 supposedly fixes the
> non-overlapped sending of HTTP transfers, so deploying SP1 ASAP (it
> supposedly was RTM yesterday) could also help the situation.
>
> Still, it would be desirable if Microsoft got started on rewriting a
> properly through File Transfer Manager server and client software, with
> the
> bandwidth*delay product of modern broadband connections in mind. If it
> can't keep up, say, 10Mbps over a 250ms RTT (round-trip-time), it's just
> not good enough.
>
> Regards,«
> --
> Dipl.-Ing. Robert Schlabbach
> e-mail: robert_s@gmx.net
> Berlin, Germany
>
> "Andy Boyd [MS]" <andboyd@nospam.microsoft.com> wrote in message
> news:uuZWPg#MFHA.3228@TK2MSFTNGP12.phx.gbl...
> this based on another thread (not sure if it's
> analysis,
> download
> from
> download
> downloads
> which
> contributing
>
>

Chris Courtright

2005-05-03, 3:56 pm

Any update on improving the speed of the downloads or alternative methods
besides FTM? It is taking 3 days for a download of the beta 2 at my corporate
site where I am getting a whopping 12K/sec. Switching to https helped but
still, this performance issue needs to be addressed.

"Andy Boyd [MS]" wrote:

> Thanks for the info - I've sent this to the download platform team.
>
> --
> Andy Boyd
> Program Manager
> MSDN & technet Subscription Online
> http://www.boydtech.com/blog
>
>
> "Robert Schlabbach" <robert_s@gmx.net> wrote in message
> news:d2efb5$3sn$05$1@news.t-online.com...
>
>
>

Andy Boyd [MS]

2005-05-03, 3:56 pm

If you're getting 12 KB, go to Subscriber Downloads and send an issue to
Contact Us. This will route to the server teams who can help troubleshoot
this, you should be going faster than that to a corporate connection.

--
Andy Boyd
Program Manager
MSDN & technet Subscription Online
http://www.boydtech.com/blog

"Chris Courtright" <Chris Courtright@discussions.microsoft.com> wrote in
message news:F18583BF-5837-47F6-9589-A8D01BE31D81@microsoft.com...[color=darkred]
> Any update on improving the speed of the downloads or alternative methods
> besides FTM? It is taking 3 days for a download of the beta 2 at my
> corporate
> site where I am getting a whopping 12K/sec. Switching to https helped but
> still, this performance issue needs to be addressed.
>
> "Andy Boyd [MS]" wrote:
>

Sponsored Links