算清真正需要传输的内容
做两份清单：一份是开始工作前需要发送的内容，一份是结束时需要取回的内容。源文件、软件所需的资源以及最终保留的结果，体积未必相同。还要把那些能在租用前就准备好的文件，和只有在计算之后才会产生的文件区分开来。
当工具提供文件数量和总字节数时，请记录下来。要区分数据大小与磁盘占用空间。如果你准备的是压缩包，请用它的实际大小来传输该压缩包。打包和解压需要时间，也可能占用额外空间：请分别核实，不要想当然地认为一定能压缩变小。
确认作用后，删除多余的副本。可重新获取的公共缓存，其重要性与独一无二的原始文件或项目设置并不总是相同。哪些内容应保留的整理方法详见备份指南。
把容量和速率换算成相同的单位
在本指南中，一个字节等于八位。十进制前缀下，1 MB = 1 000 000 字节，1 GB = 1 000 000 000 字节。二进制前缀下，1 MiB = 1 048 576 字节，1 GiB = 1 073 741 824 字节。对应的英文写法是 MB、GB、MiB 和 GiB；NIST 对这些区别有相关文档说明。
因此 Mbit/s 和 MB/s 表示的量并不相同。80 Mbit/s 的速率按算术计算相当于 10 MB/s。这一换算并不保证应用程序真的每秒复制十个兆字节的文件。请始终留意所显示的单位，尤其要区分位和字节。
| 起始值 | 计算时有用的换算 |
|---|---|
| 6 GB | 6 000 MB，即 6 000 000 000 字节 |
| 6 GiB | 6 442 450 944 字节，约合 6.44 GB |
| 8 MB/s | 64 Mbit/s |
| 8 MiB/s | 8 388 608 字节/秒，约合 8.39 MB/s |
传输大文件夹前先做一次小规模往返测试
一旦你的环境和传输方法准备就绪，就发送一个允许传输的小文件，在别处把它取回并打开这份副本。这一次检查可验证传输路径、访问权限和目标位置。它还不足以恰当地衡量一个大型文件夹所需的时间。
接着选择一个有代表性的分组，其规模要足以观察传输在启动之后的表现。使用相同的工具、相同的目标位置，并采用与真实文件夹接近的构成。如果你有很多小文件，请测试一组这样的小文件，而不只是一个大视频。记录实际复制的容量，以及到传输结束所经过的时间，其中包含枚举和停顿。
用容量除以时间来算出平均值。如果结果波动很大，换个时间再测一次，并保留两次观察结果。上传和下载要分别测量：一个方向的观察不能当作另一个方向的测量。针对其他目标的网络测速也并不等同于你的文件传输。ESnet 区分了网络吞吐量测试与它对实际传输所给出的上限。
算出一个时长，再核实它涵盖了哪些环节
在单位一致的情况下，时长（秒）= 容量（字节）÷ 速率（字节/秒）。对于以十进制 GB 表示的容量和以 MB/s 表示的速率，则变为时长（秒）= GB × 1 000 ÷ MB/s。再除以 60 即得分钟数。速率必须严格大于零；如果没有可用的测量值，就把时长视为未知。
例如，800 MB 的分组用 100 秒复制完成，平均为 8 MB/s。这个数字只描述这一次观察。如果你的计时已经包含了停顿和启动时间，就不要再为这些相同的环节额外加一个随意的补量。不妨为未测量的操作单独列出：准备压缩包、打开副本，或重做一部分传输。
保守的方案可以采用多个有代表性平均值中最低的那个。记录采用了哪些平均值及其条件。选择较低的值是一种规划假设，并不保证速率会保持在其之上。
示例演算：上传 6 GB 并取回 1.2 GB
假设有一个项目，总计 6 GB 文件需要上传，随后有 1.2 GB 结果需要取回。在这个完全假设的例子中，上传测试得到 8 MB/s，下载测试得到 3 MB/s。所有容量均为十进制。这些数值并非来自某次 BriefGPU 租用上的实际测试。
发送需要 6000 ÷ 8 = 750 秒，即 12 分 30 秒。取回需要 1200 ÷ 3 = 400 秒，即 6 分 40 秒。如果所采用的平均速率保持不变，两次传输共需 19 分 10 秒。表格还纳入了为该项目确定的核对与预留假设。
| 本示例的步骤 | 输入或计算 | 预计时间 |
|---|---|---|
| 发送 | 6000 MB ÷ 8 MB/s | 12 分 30 秒 |
| 取回 | 1200 MB ÷ 3 MB/s | 6 分 40 秒 |
| 副本核对 | 单独的人力假设 | 20 分钟 |
| 意外情况预留 | 单独的日程假设 | 30 分钟 |
| 这些步骤的预留总计 | 750 + 400 + 1200 + 1800 秒 | 1 小时 9 分 10 秒 |
试试另一种假设的影响
如果示例中的取回速率降到 1.5 MB/s，1200 MB 就需要 800 秒，即 13 分 20 秒。这一步的时间翻倍。在其他假设不变的情况下，总计变为 1 小时 15 分 50 秒。这样你就能看出，计划中哪部分取决于网络，哪部分取决于你自己的核对工作。
如果标称容量是 6 GiB 而不是 6 GB，以 8 MB/s 发送大约需要 805 秒，即 13 分 25 秒。这里的差异来自单位，网络并没有变化。要精确计算，请以字节数为准，而不是文件管理器显示的取整数值。
最后，如果实际文件夹的构成与样本不同，就重新测量一次。简单的乘法无法弥补一次不能代表你复制方式的测试。
把传输记在日程的正确位置
在资源就绪之后进行的发送算作租用期间的准备工作。取回和最终校验属于导出。此前在你电脑上完成的准备工作另行计算。如果一次传输和另一项操作同时进行，不要重复计算同一段时间。
示例的总计不包括安装、计算或等待客户回复。在比较 3 天、7 天和 30 天套餐之前，请把这些项目加进你的完整日程。该方法不对服务器的交付时间、存储容量或网络特性作任何承诺。
不要把取回拖到最后一刻。做一次中间复制，并从目标位置打开第一个文件，能及早发现问题。传输结束的提示并不能代替对预期文件的核对。