Skip to content
DoctorDODemo data
Signed in as Alex Morgan, alex.morgan@contosoai.example, Admin.

Demo data: ContosoAI (fictitious). Nothing here is a real company, device or person.

Estate · demo data

Connectivity

Every check in the connectivity matrix across 46,000 devices: what passes, what fails, and where devices that should agree do not. A check a device did not run is shown as not collected, never as a pass.

Checks failing
6 of 35
on at least one device
Inconsistent
6
checks where one site disagrees with itself
Devices with a failure
24,481
53% of 46,000
Never collected
2
checks no device could run

Where devices disagree

Devices in one site that pass and fail the same check almost always point to a firewall or proxy difference between their subnets: a sharper finding than either the passes or the failures alone.

Network findings

Recommendations
What the endpoint tests found, and how many devices raise each. The evidence, the change and the Microsoft page are under Recommendations.

  1. critical

    DO-NET-007

    Connected Cache host unreachable

    6,577 devices · Bengaluru 1,592, Seattle 854, Hyderabad 850 and 7 more

    Evidence and fix in Recommendations

  2. critical

    DO-NET-010

    Port 7680 inbound blocked

    1,863 devices · Frankfurt 519, Boston 356, Chicago 347 and 4 more

    Evidence and fix in Recommendations

  3. warning

    DO-CFG-011

    The device has less RAM than Delivery Optimization needs to peer

    142 devices · Dublin HQ 20, San Francisco 10, London 7 and 35 more

    Evidence and fix in Recommendations

  4. warning

    DO-CFG-012

    The cache drive is smaller than Delivery Optimization needs to peer

    112 devices · Dublin HQ 17, London 10, San Francisco 7 and 27 more

    Evidence and fix in Recommendations

Endpoint health

Each endpoint Microsoft documents for Delivery Optimization and Windows Update, as 43,394 devices tested it: name resolution, connection, certificate, an HTTP answer and a one-byte range request. A wildcard is tested on a host the device used or one Microsoft names, never a guessed one.

Showing 1 to 10 of 24

Byte ranges are requested only for a file the device itself downloaded, so “Not run” there is expected where it downloaded nothing from that endpoint. Probes run through the proxy Delivery Optimization would use in the background, and results are cached on the device for up to six hours.

Check matrix

  • Pass
  • Warning
  • Fail
  • Not applicable
  • Not collected
46,000 devices · n of N counts the devices each check applies to

Cloud service

Without the DO cloud service no peering is possible at all; a failure here makes most other findings moot.

Content & metadata

Where payloads and update metadata come from when no peer or cache has them.

Peer-to-peer

TCP 7680 in both directions, the firewall rules that open it, and NAT traversal for Group mode.

Connected Cache

Only where a cache host is configured or discovered; not-applicable everywhere else.

Proxy

The richest source of silent failure: inspection, rewritten source addresses and per-user configuration.

Local prerequisites

The service, the download mode and the device’s own eligibility to peer.

Content sources across sites

How fast each Microsoft host and Connected Cache server delivered content at each site, compared with the same host at the other sites. A rate is a job's bytes over its whole download time, waits and Delivery Optimization's own throttling included (Microsoft LearnDownloadDuration (opens in a new tab)), so it is a lower bound, compared like for like.

43,394 of 46,000 devices reported content sources, 43,394 with at least one timed download, 2026-09-12 to 2026-10-11.

  • 1d.tlu.dl.delivery.mp.microsoft.com is slow from BengaluruWarning · low confidence · DO-SRC-001Devices at Bengaluru got content from 1d.tlu.dl.delivery.mp.microsoft.com at a median 815 KB/s, 12% of the 6.7 MB/s it runs at from 41 other sites.
    Here
    2,547 devices, 49,111 timed jobs: median 815 KB/s
    Elsewhere
    The median of 41 other sites' medians: 6.7 MB/s
    Other hosts here
    The other HTTP hosts measured here run at a median 40% of their rate elsewhere
    Configured waits
    Devices here are configured to wait up to 600 s (median) for peers or a cache before HTTP, against 120 s elsewhere: a job that falls back after that wait carries it in its DownloadDuration

    DoctorDO’s readingthe same host is fast from other sites and the other hosts are not slowed as much here, so the path between this site and this host is the likely cause (the site's egress or route, a proxy or inspection rule for it, or the CDN edge its traffic reaches), not the host as a whole. A host name is not an edge or a place: devices at different sites can be answered with different addresses for it. The rate is each job's bytes from this source over its whole DownloadDuration (waits for peers and Delivery Optimization's own throttling included), so it is a lower bound on what the path carries, and it is compared like for like: the same host, at other sites. Devices here are configured to wait longer before HTTP than elsewhere, and that wait is part of each job's time, so the slower rate may be the configured wait, not the path.

    NextCompare this site with a fast one: resolve 1d.tlu.dl.delivery.mp.microsoft.com from both and note the addresses it answers with, check the proxy and inspection rules that apply to it here, and time one download from it at each. It is a Microsoft host: when the path checks out, the evidence export lists it for a support case.

  • 1d.tlu.dl.delivery.mp.microsoft.com is slow from HyderabadWarning · low confidence · DO-SRC-001Devices at Hyderabad got content from 1d.tlu.dl.delivery.mp.microsoft.com at a median 807 KB/s, 12% of the 6.7 MB/s it runs at from 41 other sites.
    Here
    1,333 devices, 23,508 timed jobs: median 807 KB/s
    Elsewhere
    The median of 41 other sites' medians: 6.7 MB/s
    Other hosts here
    The other HTTP hosts measured here run at a median 39% of their rate elsewhere
    Configured waits
    Devices here are configured to wait up to 600 s (median) for peers or a cache before HTTP, against 120 s elsewhere: a job that falls back after that wait carries it in its DownloadDuration

    DoctorDO’s readingthe same host is fast from other sites and the other hosts are not slowed as much here, so the path between this site and this host is the likely cause (the site's egress or route, a proxy or inspection rule for it, or the CDN edge its traffic reaches), not the host as a whole. A host name is not an edge or a place: devices at different sites can be answered with different addresses for it. The rate is each job's bytes from this source over its whole DownloadDuration (waits for peers and Delivery Optimization's own throttling included), so it is a lower bound on what the path carries, and it is compared like for like: the same host, at other sites. Devices here are configured to wait longer before HTTP than elsewhere, and that wait is part of each job's time, so the slower rate may be the configured wait, not the path.

    NextCompare this site with a fast one: resolve 1d.tlu.dl.delivery.mp.microsoft.com from both and note the addresses it answers with, check the proxy and inspection rules that apply to it here, and time one download from it at each. It is a Microsoft host: when the path checks out, the evidence export lists it for a support case.

  • 1d.tlu.dl.delivery.mp.microsoft.com is slow from MelbourneWarning · low confidence · DO-SRC-001Devices at Melbourne got content from 1d.tlu.dl.delivery.mp.microsoft.com at a median 1.5 MB/s, 23% of the 6.7 MB/s it runs at from 41 other sites.
    Here
    562 devices, 10,528 timed jobs: median 1.5 MB/s
    Elsewhere
    The median of 41 other sites' medians: 6.7 MB/s
    Other hosts here
    The other HTTP hosts measured here run at a median 79% of their rate elsewhere
    Bandwidth limits
    562 of the 562 devices measured here have a download bandwidth limit configured: a lower rate there is the limit at work, not the path

    DoctorDO’s readingthe same host is fast from other sites and the other hosts are not slowed as much here, so the path between this site and this host is the likely cause (the site's egress or route, a proxy or inspection rule for it, or the CDN edge its traffic reaches), not the host as a whole. A host name is not an edge or a place: devices at different sites can be answered with different addresses for it. The rate is each job's bytes from this source over its whole DownloadDuration (waits for peers and Delivery Optimization's own throttling included), so it is a lower bound on what the path carries, and it is compared like for like: the same host, at other sites. Most devices measured here have a bandwidth limit configured, so this may be the limit at work.

    NextCompare this site with a fast one: resolve 1d.tlu.dl.delivery.mp.microsoft.com from both and note the addresses it answers with, check the proxy and inspection rules that apply to it here, and time one download from it at each. It is a Microsoft host: when the path checks out, the evidence export lists it for a support case.

  • 1d.tlu.dl.delivery.mp.microsoft.com is slow from OsakaWarning · low confidence · DO-SRC-001Devices at Osaka got content from 1d.tlu.dl.delivery.mp.microsoft.com at a median 1.7 MB/s, 26% of the 6.7 MB/s it runs at from 41 other sites.
    Here
    396 devices, 12,020 timed jobs: median 1.7 MB/s
    Elsewhere
    The median of 41 other sites' medians: 6.7 MB/s
    Other hosts here
    The other HTTP hosts measured here run at a median 75% of their rate elsewhere
    Bandwidth limits
    396 of the 396 devices measured here have a download bandwidth limit configured: a lower rate there is the limit at work, not the path

    DoctorDO’s readingthe same host is fast from other sites and the other hosts are not slowed as much here, so the path between this site and this host is the likely cause (the site's egress or route, a proxy or inspection rule for it, or the CDN edge its traffic reaches), not the host as a whole. A host name is not an edge or a place: devices at different sites can be answered with different addresses for it. The rate is each job's bytes from this source over its whole DownloadDuration (waits for peers and Delivery Optimization's own throttling included), so it is a lower bound on what the path carries, and it is compared like for like: the same host, at other sites. Most devices measured here have a bandwidth limit configured, so this may be the limit at work.

    NextCompare this site with a fast one: resolve 1d.tlu.dl.delivery.mp.microsoft.com from both and note the addresses it answers with, check the proxy and inspection rules that apply to it here, and time one download from it at each. It is a Microsoft host: when the path checks out, the evidence export lists it for a support case.

  • 1d.tlu.dl.delivery.mp.microsoft.com is slow from PuneWarning · low confidence · DO-SRC-001Devices at Pune got content from 1d.tlu.dl.delivery.mp.microsoft.com at a median 2.0 MB/s, 30% of the 6.7 MB/s it runs at from 41 other sites.
    Here
    423 devices, 7,908 timed jobs: median 2.0 MB/s
    Elsewhere
    The median of 41 other sites' medians: 6.7 MB/s
    Other hosts here
    The other HTTP hosts measured here run at a median 82% of their rate elsewhere
    Bandwidth limits
    423 of the 423 devices measured here have a download bandwidth limit configured: a lower rate there is the limit at work, not the path

    DoctorDO’s readingthe same host is fast from other sites and the other hosts are not slowed as much here, so the path between this site and this host is the likely cause (the site's egress or route, a proxy or inspection rule for it, or the CDN edge its traffic reaches), not the host as a whole. A host name is not an edge or a place: devices at different sites can be answered with different addresses for it. The rate is each job's bytes from this source over its whole DownloadDuration (waits for peers and Delivery Optimization's own throttling included), so it is a lower bound on what the path carries, and it is compared like for like: the same host, at other sites. Most devices measured here have a bandwidth limit configured, so this may be the limit at work.

    NextCompare this site with a fast one: resolve 1d.tlu.dl.delivery.mp.microsoft.com from both and note the addresses it answers with, check the proxy and inspection rules that apply to it here, and time one download from it at each. It is a Microsoft host: when the path checks out, the evidence export lists it for a support case.

  • 1d.tlu.dl.delivery.mp.microsoft.com is slow from SingaporeWarning · medium confidence · DO-SRC-001Devices at Singapore got content from 1d.tlu.dl.delivery.mp.microsoft.com at a median 1.9 MB/s, 29% of the 6.7 MB/s it runs at from 41 other sites.
    Here
    1,233 devices, 8,667 timed jobs: median 1.9 MB/s
    Elsewhere
    The median of 41 other sites' medians: 6.7 MB/s
    Other hosts here
    The other HTTP hosts measured here run at a median 95% of their rate elsewhere

    DoctorDO’s readingthe same host is fast from other sites and the other hosts are not slowed as much here, so the path between this site and this host is the likely cause (the site's egress or route, a proxy or inspection rule for it, or the CDN edge its traffic reaches), not the host as a whole. A host name is not an edge or a place: devices at different sites can be answered with different addresses for it. The rate is each job's bytes from this source over its whole DownloadDuration (waits for peers and Delivery Optimization's own throttling included), so it is a lower bound on what the path carries, and it is compared like for like: the same host, at other sites.

    NextCompare this site with a fast one: resolve 1d.tlu.dl.delivery.mp.microsoft.com from both and note the addresses it answers with, check the proxy and inspection rules that apply to it here, and time one download from it at each. It is a Microsoft host: when the path checks out, the evidence export lists it for a support case.

  • 1d.tlu.dl.delivery.mp.microsoft.com is slow from SydneyWarning · low confidence · DO-SRC-001Devices at Sydney got content from 1d.tlu.dl.delivery.mp.microsoft.com at a median 657 KB/s, 10% of the 6.7 MB/s it runs at from 41 other sites.
    Here
    957 devices, 16,258 timed jobs: median 657 KB/s
    Elsewhere
    The median of 41 other sites' medians: 6.7 MB/s
    Other hosts here
    The other HTTP hosts measured here run at a median 32% of their rate elsewhere
    Configured waits
    Devices here are configured to wait up to 900 s (median) for peers or a cache before HTTP, against 120 s elsewhere: a job that falls back after that wait carries it in its DownloadDuration

    DoctorDO’s readingthe same host is fast from other sites and the other hosts are not slowed as much here, so the path between this site and this host is the likely cause (the site's egress or route, a proxy or inspection rule for it, or the CDN edge its traffic reaches), not the host as a whole. A host name is not an edge or a place: devices at different sites can be answered with different addresses for it. The rate is each job's bytes from this source over its whole DownloadDuration (waits for peers and Delivery Optimization's own throttling included), so it is a lower bound on what the path carries, and it is compared like for like: the same host, at other sites. Devices here are configured to wait longer before HTTP than elsewhere, and that wait is part of each job's time, so the slower rate may be the configured wait, not the path.

    NextCompare this site with a fast one: resolve 1d.tlu.dl.delivery.mp.microsoft.com from both and note the addresses it answers with, check the proxy and inspection rules that apply to it here, and time one download from it at each. It is a Microsoft host: when the path checks out, the evidence export lists it for a support case.

  • 1d.tlu.dl.delivery.mp.microsoft.com is slow from TokyoWarning · medium confidence · DO-SRC-001Devices at Tokyo got content from 1d.tlu.dl.delivery.mp.microsoft.com at a median 1.7 MB/s, 26% of the 6.7 MB/s it runs at from 41 other sites.
    Here
    1,140 devices, 7,885 timed jobs: median 1.7 MB/s
    Elsewhere
    The median of 41 other sites' medians: 6.7 MB/s
    Other hosts here
    The other HTTP hosts measured here run at a median 85% of their rate elsewhere

    DoctorDO’s readingthe same host is fast from other sites and the other hosts are not slowed as much here, so the path between this site and this host is the likely cause (the site's egress or route, a proxy or inspection rule for it, or the CDN edge its traffic reaches), not the host as a whole. A host name is not an edge or a place: devices at different sites can be answered with different addresses for it. The rate is each job's bytes from this source over its whole DownloadDuration (waits for peers and Delivery Optimization's own throttling included), so it is a lower bound on what the path carries, and it is compared like for like: the same host, at other sites.

    NextCompare this site with a fast one: resolve 1d.tlu.dl.delivery.mp.microsoft.com from both and note the addresses it answers with, check the proxy and inspection rules that apply to it here, and time one download from it at each. It is a Microsoft host: when the path checks out, the evidence export lists it for a support case.

  • Atlanta: every content source is slowWarning · low confidence · DO-SRC-002The 5 HTTP hosts measured at Atlanta run at a median 9% of their rate at other sites.
    swda01-mscdn.manage.microsoft.com
    608 KB/s here, 8.2 MB/s elsewhere (7%), 89 devices
    msedge.b.tlu.dl.delivery.mp.microsoft.com
    623 KB/s here, 7.4 MB/s elsewhere (8%), 89 devices
    1d.tlu.dl.delivery.mp.microsoft.com
    632 KB/s here, 6.7 MB/s elsewhere (9%), 89 devices
    f.c2r.ts.cdn.office.net
    622 KB/s here, 5.2 MB/s elsewhere (12%), 89 devices
    au.download.windowsupdate.com
    614 KB/s here, 4.6 MB/s elsewhere (13%), 89 devices
    Microsoft CDN here
    median 620 KB/s per device
    Bandwidth limits
    89 of the 89 devices measured here have a download bandwidth limit configured: a lower rate there is the limit at work, not the path

    DoctorDO’s readingevery host is slower here by a similar factor, so the site's own connection (its link, its route to the internet, a proxy in the path) is the likely cause, not one host or CDN. Low confidence: most devices measured here have a download bandwidth limit configured, so the lower rate is, at least in part, the limit doing its job. The rate is each job's bytes from this source over its whole DownloadDuration (waits for peers and Delivery Optimization's own throttling included), so it is a lower bound on what the path carries, and it is compared like for like: the same host, at other sites.

    NextCheck the site's link and its way to the internet during the window: utilisation, the WAN route to the breakout, and any proxy in the path. A Connected Cache server at the site, or more peering, takes this traffic off that path.

  • Belfast: every content source is slowWarning · low confidence · DO-SRC-002The 5 HTTP hosts measured at Belfast run at a median 19% of their rate at other sites.
    swda01-mscdn.manage.microsoft.com
    1.2 MB/s here, 8.2 MB/s elsewhere (15%), 170 devices
    msedge.b.tlu.dl.delivery.mp.microsoft.com
    1.2 MB/s here, 7.4 MB/s elsewhere (17%), 170 devices
    1d.tlu.dl.delivery.mp.microsoft.com
    1.3 MB/s here, 6.7 MB/s elsewhere (19%), 170 devices
    f.c2r.ts.cdn.office.net
    1.3 MB/s here, 5.2 MB/s elsewhere (24%), 170 devices
    au.download.windowsupdate.com
    1.3 MB/s here, 4.6 MB/s elsewhere (27%), 170 devices
    Microsoft CDN here
    median 1.2 MB/s per device
    Bandwidth limits
    170 of the 170 devices measured here have a download bandwidth limit configured: a lower rate there is the limit at work, not the path

    DoctorDO’s readingevery host is slower here by a similar factor, so the site's own connection (its link, its route to the internet, a proxy in the path) is the likely cause, not one host or CDN. Low confidence: most devices measured here have a download bandwidth limit configured, so the lower rate is, at least in part, the limit doing its job. The rate is each job's bytes from this source over its whole DownloadDuration (waits for peers and Delivery Optimization's own throttling included), so it is a lower bound on what the path carries, and it is compared like for like: the same host, at other sites.

    NextCheck the site's link and its way to the internet during the window: utilisation, the WAN route to the breakout, and any proxy in the path. A Connected Cache server at the site, or more peering, takes this traffic off that path.

Showing 1 to 10 of 20

Connected Cache faster than the CDN at 23 sites
  • Devices at Amsterdam got content from the Connected Cache server dp01.ams.contosoai.example at a median 54.6 MB/s, against 7.8 MB/s from Microsoft's CDN hosts.
  • Devices at Austin got content from the Connected Cache server dp01.aus.contosoai.example at a median 24.9 MB/s, against 6.2 MB/s from Microsoft's CDN hosts.
  • Devices at Bengaluru got content from the Connected Cache server dp01.blr.contosoai.example at a median 25.1 MB/s, against 1.2 MB/s from Microsoft's CDN hosts.
  • Devices at Berlin got content from the Connected Cache server dp01.ber.contosoai.example at a median 24.5 MB/s, against 2.9 MB/s from Microsoft's CDN hosts.
  • Devices at Copenhagen got content from the Connected Cache server dp01.cph.contosoai.example at a median 85.2 MB/s, against 7.6 MB/s from Microsoft's CDN hosts.
  • Devices at Cork got content from the Connected Cache server dp01.ork.contosoai.example at a median 54.7 MB/s, against 8.0 MB/s from Microsoft's CDN hosts.
  • Devices at Dublin HQ got content from the Connected Cache server dp01.dub.contosoai.example at a median 55.0 MB/s, against 8.1 MB/s from Microsoft's CDN hosts.
  • Devices at Helsinki got content from the Connected Cache server dp01.hel.contosoai.example at a median 85.7 MB/s, against 7.4 MB/s from Microsoft's CDN hosts.
  • Devices at Hyderabad got content from the Connected Cache server dp01.hyd.contosoai.example at a median 24.6 MB/s, against 1.2 MB/s from Microsoft's CDN hosts.
  • Devices at London got content from the Connected Cache server dp01.lon.contosoai.example at a median 55.2 MB/s, against 7.8 MB/s from Microsoft's CDN hosts.
  • Devices at Lyon got content from the Connected Cache server dp01.lys.contosoai.example at a median 24.7 MB/s, against 7.6 MB/s from Microsoft's CDN hosts.
  • Devices at Manchester got content from the Connected Cache server dp01.man.contosoai.example at a median 25.0 MB/s, against 7.9 MB/s from Microsoft's CDN hosts.
  • Devices at Munich got content from the Connected Cache server dp01.muc.contosoai.example at a median 55.0 MB/s, against 7.6 MB/s from Microsoft's CDN hosts.
  • Devices at New York got content from the Connected Cache server dp01.nyc.contosoai.example at a median 54.8 MB/s, against 6.8 MB/s from Microsoft's CDN hosts.
  • Devices at Oslo got content from the Connected Cache server dp01.osl.contosoai.example at a median 85.5 MB/s, against 7.5 MB/s from Microsoft's CDN hosts.
  • Devices at Paris got content from the Connected Cache server dp01.par.contosoai.example at a median 55.4 MB/s, against 7.7 MB/s from Microsoft's CDN hosts.
  • Devices at San Francisco got content from the Connected Cache server dp01.sfo.contosoai.example at a median 55.2 MB/s, against 6.0 MB/s from Microsoft's CDN hosts.
  • Devices at Seattle got content from the Connected Cache server dp01.sea.contosoai.example at a median 24.9 MB/s, against 2.2 MB/s from Microsoft's CDN hosts.
  • Devices at Singapore got content from the Connected Cache server dp01.sin.contosoai.example at a median 55.1 MB/s, against 3.2 MB/s from Microsoft's CDN hosts.
  • Devices at Stockholm got content from the Connected Cache server dp01.sto.contosoai.example at a median 85.4 MB/s, against 7.5 MB/s from Microsoft's CDN hosts.
  • Devices at Sydney got content from the Connected Cache server dp01.syd.contosoai.example at a median 25.1 MB/s, against 1,022 KB/s from Microsoft's CDN hosts.
  • Devices at Tokyo got content from the Connected Cache server dp01.tyo.contosoai.example at a median 55.0 MB/s, against 2.8 MB/s from Microsoft's CDN hosts.
  • Devices at Toronto got content from the Connected Cache server dp01.yyz.contosoai.example at a median 25.0 MB/s, against 6.6 MB/s from Microsoft's CDN hosts.
What these rates can and cannot say
  • A host name is not an edge server or a location. Devices resolve it to addresses that Microsoft says may differ over time for load balancing, so devices at different sites, or at one site on different days, can reach different servers for the same host. The job list does not say which server served a download.
  • DownloadDuration is the whole job's time ("Total download time in seconds"), including any wait for peers before HTTP and Delivery Optimization's own bandwidth throttling, which by default targets no more than 45% of the available bandwidth for a background download. Rates are therefore effective job rates, a lower bound on what the path can carry.
  • A job's time is counted only for the source that delivered at least 90% of its bytes, and only when that was at least 4 MiB. Each device contributes one rate per host (its timed bytes over its timed time); sites are compared on the median of their devices.
  • A site and host is judged only with at least 3 devices and 10 timed jobs, and compared with the same host elsewhere only when at least 2 other sites have that much evidence. Sites where most measured devices have a download bandwidth limit configured, or where devices are configured to wait clearly longer before HTTP than elsewhere (DODelay settings, whose wait is inside each job's time), are left out of the slow sites.
  • The path between a site and a host includes the organisation's own network: its link, its internet breakout, proxies and inspection. Check those before treating a slow host as Microsoft's.

Sources: Microsoft LearnMonitor Delivery Optimization (opens in a new tab), Microsoft LearnDelivery Optimization FAQ (opens in a new tab), Microsoft LearnWindows Update security (opens in a new tab). The thresholds (3 devices, 10 timed jobs, half the rate elsewhere) are DoctorDO's.

One host, site by site

The median rate per device at each site, with the median of the other sites marked. Sites with fewer than 3 devices or 10 timed jobs are listed, not judged.

126 TB from 43,394 devices at 42 sites; estate median 7.5 MB/s over 537,157 timed jobs.

Median hereMedian of the other sites

  1. FukuokaSlower (4%)264 KB/s
  2. PerthSlower (7%)498 KB/s
  3. ChennaiSlower (7%)509 KB/s
  4. ToulouseSlower (7%)510 KB/s
  5. AtlantaSlower (9%)632 KB/s
  6. SydneySlower (10%)657 KB/s
  7. DenverSlower (11%)753 KB/s
  8. HyderabadSlower (12%)807 KB/s
  9. BengaluruSlower (12%)815 KB/s
  10. HamburgSlower (19%)1.2 MB/s

Showing 1 to 10 of 42

Sites: the CDN and the cache

The median rate per device from Microsoft’s CDN hosts and from Connected Cache at each site. 'Hosts against elsewhere' is the median, over the HTTP hosts measured at the site, of each one’s rate here as a share of its rate at the other sites.
Rates from the CDN and from Connected Cache per site
SiteReportingFrom the CDNCDN rateFrom the cacheCache rateCache against CDNHosts against elsewhere
Amsterdam1,230 of 1,3005.6 TB7.8 MB/s10.6 TB54.6 MB/s7.0 times132%
Atlanta89 of 1051.1 TB620 KB/s0 B—n/a9%
Austin1,048 of 1,10010.0 TB6.2 MB/s2.7 TB24.9 MB/s4.0 times106%
Belfast170 of 1901.8 TB1.2 MB/s0 B—n/a19%
Bengaluru2,547 of 2,70027.1 TB1.2 MB/s4.7 TB25.1 MB/s20 times40%
Berlin1,048 of 1,1009.7 TB2.9 MB/s2.5 TB24.5 MB/s8.4 times52%
Boston718 of 76010.5 TB6.8 MB/s0 B—n/a116%
Chennai92 of 1051.2 TB505 KB/s0 B—n/a7%
Chicago650 of 6909.9 TB6.5 MB/s0 B—n/a110%
Copenhagen955 of 1,0002.6 TB7.6 MB/s7.9 TB85.2 MB/s11 times127%

Showing 1 to 10 of 42