For AI agents: The documentation index is at https://docs.digitalocean.com/llms.txt. Markdown versions of pages use the same URL with index.html.md in place of the HTML page (for example, append index.html.md to the directory path instead of opening the HTML document).

Public internet speed tests often show slower speeds than your bare metal GPU can actually reach. These tools are designed for residential and business internet connections, not for data center environments.

Public test servers may sit far from your server, share bandwidth with many users, or limit throughput. Traffic to those servers may also cross external networks or congested internet exchanges. Because of this, public speed tests do not reliably measure your server’s network performance.

Why Public Speed Tests Show Lower Speeds

Several things can cause lower results:

• Suboptimal route: Traffic may travel over external networks outside of our control.
• The test server is overloaded or rate-limited. Many public speed test servers limit throughput or are built for lower-bandwidth consumer connections.
• The test does not run long enough. Small file transfers or short tests may not sustain traffic long enough to reflect actual throughput.
• The tool uses only one connection. Single-threaded tools such as scp, or basic curl and wget tests, often cannot fully use a high-bandwidth network link.

Because of these limits, public speed tests are not a reliable way to measure NIC performance or overall network capacity.

Better Ways to Measure Network Performance

Use testing methods that better match your actual workload:

• Check the destination’s capacity. Transfer speeds depend on both ends of the connection. The destination may limit throughput.
• Use a tool such as iperf. iperf supports parallel streams and gives a more accurate view of available throughput.
• Test the endpoints you actually use. If your workload transfers data to services such as AWS S3, Google Cloud Storage, Spaces, or another server, test those destinations directly.
• Use large files or longer transfers. Larger and sustained transfers usually give more accurate results than short tests.

Test within DigitalOcean First

If you transfer data between your DigitalOcean resources, test within the same region first. For example, test between your bare metal GPU and another Droplet, bare metal GPU, or Spaces bucket in the same region. This helps show whether the bottleneck is inside or outside of DigitalOcean’s network.

When to Contact Support

If you still see slow or inconsistent speeds, contact support.

To help us investigate, include:

1. A file transfer test from your bare metal GPU to the destination you expect to use.
2. The file size, transfer method (wget, curl, rsync, scp, and so on), and observed speeds.
3. Results from a second test to another endpoint.
4. Any relevant logs, command output, or other observations.

This information helps us identify whether the issue comes from your configuration, the testing method, the destination, or the network path.

We can help investigate performance issues within DigitalOcean’s network, but we may not be able to troubleshoot bottlenecks caused by public speed test services or third-party endpoints.

Related Topics

Can I make BIOS-level changes to bare metal GPUs?

Request BIOS-level changes to bare metal GPUs through a support ticket. Some changes require reprovisioning.

How do I fix a "system not initialized" error on multi-GPU Droplets?

Make sure NVIDIA Fabric Manager is running and has the same version number as the GPU drivers.

How do I schedule automatic reindexing for my knowledge bases?

Create a scheduled function to automatically reindex a knowledge base.