[参考译文] 66AK2E05：升级 K2E SDK 后、使用 SCP 和 SFTP 的文件传输速度非常慢

尊敬的 Wyman Yuan：

您是否在 SCP 期间检查了 CPU 使用情况？ 可以共享两个 OpenSSL 版本吗？ 检查 AES 加密是否具有硬件加速功能？

SATA SSD 上使用的是哪种文件系统类型？

为了帮助确定此问题是否与小文件开销有关、您能否尝试使用 SCP 传输大文件并检查是否仍然存在性能下降？

此致、

Betsy Varughese.

您好 Betsy、

升级系统后、我使用了 TI 提供的服务器文件系统、新旧系统都使用 dropbear 而不是 openssl。 没有硬件更改、降级后、传输速度恢复正常。 在 SCP 传输的三分钟内,CPU 使用率仍然非常低,带宽使用率也很好,这正是我的难题。 如果按照 TI 的说明执行升级、那么这个问题很普遍。

我试图转移一个 5 MB 压缩文件,它仍然需要 1 秒,这也似乎是非常不合理的。 我安装了一个目录作为 tmpfs 来排除来自 SSD 的干扰,然后通过 SCP 传输,速度仅从 300 秒提高到 280 秒,这也是非常不合理的。

dropbear v2018.76

您好、Wyman：

您能在这两种情况下共享内核版本吗？ 请 对 SDK 版本和共享运行 scp -v。 这是为了确认默认密码在 SDK 升级后是否发生了更改。

此致、

Betsy Varughese.

您好 Betsy、

K2E 上的 scp 似乎不支持查询版本。

root@k2e-evm:~# scp -v
usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]
           [-l limit] [-P port] [-S program]
           [[user@]host1:]file1 [...] [[user@]host2:]file2

您好、Wyman：

明白。 您是否知道 SCP 连接使用哪种密码？

此致、

Betsy Varughese.

在 dropbear 中、似乎找不到正在使用的默认密码。 您认为它是由密码引起的吗？ 但是、CPU 负载非常低。

您好、Wyman：

您认为这是由密码引起的吗？ 但是、CPU 负载非常低

不完全、根据提供的观察结果、 我怀疑此问题可能与 SSH 会话开销有关。  

此致、

Betsy Varughese.

您好 Betsy、

是的,因为我尝试了其他方法来安装 Samba 服务和 Samba 的文件传输速度是正常的,这表明网络本身是好的。 不过、由于 SCP 经常在工程中使用、我们仍然希望解决 SCP 速度太慢的问题。

您好、Wyman：

您是否检查了 SDK V6.03 的内核配置？

发行说明链接： https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/linux/Release_Specific_ Release_Notes．html？

此致、

Betsy Varughese.

您好、Wyman：

此致、

Betsy Varughese.