工具/软件:TI-RTOS
在五年前发布的"DM648具有 NDK 2.0并支持快速重传丢弃的数据包"中、TCP 快速重传被列为 NDK 的候选对象。 它是否已实施?
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
工具/软件:TI-RTOS
在五年前发布的"DM648具有 NDK 2.0并支持快速重传丢弃的数据包"中、TCP 快速重传被列为 NDK 的候选对象。 它是否已实施?
您好 Todd:
我有一个应用、它在以太网上将样本流输出到 TM4C129X。 TM4C129X 设置数据速率、因此它必须能够 控制传输。 与许多流应用程序一样、此应用程序可能会对偶尔的数据丢失不敏感。 我希望以太网错误率小于10**-9,因此数据丢失不会是什么大问题。 我开始使用 UDP 对应用程序进行编码、但为了允许连接限制、我发现自己开始实施类似 TCP 的确认。 因此、我决定我宁愿依赖 TCP 来进行限制。
但是、TCP 将在数据包丢失时重试、而不是仅忽略丢失。 这意味着、当发生罕见的数据包丢失时、将会出现不必要的延迟。 我决定容忍这种延迟、并假设有足够的额外连接带宽来在发生延迟时赶上。 但是、我想尽量减少它。 TCP 不带快速重新传输、可作为重新传输的额外延迟源。 这就是我为什么要问它。 设置 tcp_SACKPERMITTED 似乎会获得快速重新传输的大部分好处。 此外、我将邮件大小调整为长度小于1500字节、因此可能 甚至不会出现快速重新发送地址所产生的多段确认问题。
我尝试推送100 Mbit/s、因为数据速率是必须最大程度地提高的关键设计参数。 这会产生另一个问题、我刚刚遇到过这个问题。 您可以 向任意方向通过 TM4C129X 以太网将多少 TCP 或 UDP 数据推送到 Linux 服务器等大型空载主机? 您似乎已经对 TI-RTOS 进行了全面的基准测试、因此如果您有这些 NDK 数据、我不会感到意外。
我提出这一问题主要是出于好奇,目的是尽量减少风险。 我是否需要该功能? 从上述考虑来看、我可能不会这样做。 但是、如果您实施它、我肯定会为我的套接字连接打开它!
感谢您的回答。
此致、
Leo Bredehoft