[参考译文] PROCESSOR-SDK-J784S4：FreeRTOS Enet 示例 enet_loopback_test 5ms 每2500万个发送帧冻结一次

您好！

如果描述符不可用、您在此期间是否能看到任何丢弃数据包、将不会接收数据包。

我只知道在此冻结期间系统不调用 FreeRTOS 空闲函数

我可以知道在此冻结时间内程序计数器指向的位置吗？

此致、
Sudheer

您好！

我没有看到 任何丢失的帧。

幸运的是、我不知道 Programmm 计数器此时在哪里以及内核实际执行的操作。

此致

Daniel

您好！

并且我很幸运地不知道此时程序计数器的位置以及内核实际执行的操作。

您可以添加打印件和跟踪、并将其添加到目标位置。

我没有看到 任何丢失的帧。

如果 TDA4是发送方、则可能是由于 UDMA 上没有可用的缓冲器来传输帧。  
传输完成后、将释放描述符并重新填充新的帧信息。

您如何识别几毫秒的冻结？

此致、
Sudheer

您好！

对不起,我认为 程序计数器的位置很复杂 ,我的应用程序在 EnetDma_submitTxPktQ()之后的循环中

(但对于调度程序或中断而言、距离很远。) 因此、 EnetDma_submitTxPktQ 始终已成功完成。

我使用 CCNT 计数器来测量时间、 Wireshark 记录中有5ms 的间隔。

此致

Daniel

您好！

对不起,我认为 程序计数器的位置很复杂 ,我的应用程序在 EnetDma_submitTxPktQ()之后的循环中

(但对于调度程序或中断而言、距离很远。) 因此、 EnetDma_submitTxPktQ 始终已成功完成。

我不知道您是如何根据需要修改回送示例的。

默认 SDK 有信标并等待它发送数据包、信标在中断中发布。
此外、我们会检查是否有任何描述符可用、如果没有等待一段时间、然后填充队列/描述符。

在收到如此多的数据包后、硬件可能处于繁忙状态、因此您可以观察数据包中的延迟。

在调用跟踪之前、很难找到它被击中的位置。

此致、
Sudheer

您好！

您可以查看我附加的文件吗？

此致

Daniel

您好！

您能看一下我随附的文件吗？

如果正在 执行"WFI"、ARM 计数器将不会递增。  

我会发现您使用 ARM 计数器并执行一些计算、如上所述、如果 执行"WFI"、将影响您的计算。
另外、我认为计数器是32位计数器。 如果超过32位计数器值、请检查您的计算是否考虑了溢出。

请 在循环中添加打印件并检查打印件的位置。

此致、
Sudheer

您好！

现在我来谈谈 CCNT 问题。

我将 WFI 替换为 NOP、计数器溢出在代码中进行处理。

如果要发送至少1000万帧、则无法打印。

我测量了不同发送步骤中的平均和最大时间值。

""

时间3168s、帧10000000
次数超过；100us 9999100；1000us 1；1500us 0；5000us 2；
全部在我们:最小值: 0010,平均值: 0316,最大值5771
prepare1 in us：最小值：0002、平均值：0002、最大值：0205
prepare2 in us：最小值：0000、平均值：0000、最大值：0034
发送给我们：最小值：0003、平均值：0005、最大值0805
信标量：最小值：0010、平均值：0306、最大值：5761

时间6336秒、帧20000000
次数超过；100us 9999100；1000us 1；1500us 0；5000us 2；
全部在我们:最小值: 0010,平均值: 0317,最大值5783
prepare1 in us：最小值：0002、平均值：0002、最大值：0171
prepare2 in us：最小值：0000、平均值：0000、最大值：0033
发送给我们：最小值：0003、平均值：0005、最大值：0742
信标在我们：最小值：0010、平均值：0307、最大值5771

时间9505秒、帧30000000
次数超过；100us 9999099；1000us 1；1500us 0；5000us 3；
全部在我们：最小值：0010、平均值：0316、最大值：5796
prepare1 in us：最小值：0002、平均值：0002、最大值：0166
prepare2 in us：最小值：0000、平均值：0000、最大值：0046
发送给我们：最小值：0003、平均值：0005、最大值：0730
我们的信标：最小值：0010、平均值：0306、最大值：5785
收到5002个数据包

时间12673秒、帧40000000
次数超过；100us 9999100；1000us 1；1500us 0；5000us 2；
所有在我们:最小值: 0010,平均值: 0316,最大值5779
prepare1 in us：最小值：0002、平均值：0002、最大值：0171
prepare2 in us：最小值：0000、平均值：0000、最大值：0033
发送给我们：最小值：0003、平均值：0005、最大值：0752
我们的信标：最小值：0010、平均值：0306、最大值：5768

时间15842秒、帧50000000
次数超过；100us 9999099；1000us 1；1500us 0；5000us 3；
全部在我们:最小值: 0010,平均值: 0316,最大值5778
prepare1 in us：最小值：0002、平均值：0002、最大值：0168
prepare2 in us：最小值：0000、平均值：0000、最大值：0034
发送给我们：最小值：0003、平均值：0005、最大值：0732
我们的信标：最小值：0010、平均值：0306、最大值：5769

发送了500000个数据包

""

在  EnetDma_submitTxPktQ 之后的循环中(并且仅在该循环中)我得到5、2ms 的延迟

                qwTickPoint3 = OsMeasGetCounterTicks();
#if 0
     /* can send frames even faster but it looks like there is sometimes an addtional delay */
                SemaphoreP_pend(gEnetLpbk.hTxSem, SemaphoreP_WAIT_FOREVER);
#elif 0
    /* too slow */
                EnetAppUtils_wait(1);
#else
                for (int i =0; i < dwTicks1u * 60; i++) /* about 250us */
                    __asm__ volatile ("nop");
#endif
                qwTickPoint4 = OsMeasGetCounterTicks();

如果我使用 EnetAppUtils_wait (1)；而不是循环也会发生同样的情况。

此致

Daniel

抱歉、信标是此块的名称

信标 美国：最小值：0010、平均值：0306、最大值：5761

您好！

我现在谈 CCNT 问题。

我想知道您在使用 ARM 计数器时观察到的问题是什么。

延迟是否与提交数据包后观测器的延迟相同？ 即、对于获取传输完成。

此致、
Sudheer

您好！

抱歉、这是一个拼写错误"知道"而不是"现在"

现在没有问题了、我相信我的时间测量。

我在  EnetDma_submitTxPktQ ()之后的等待循环中得到这种延迟,特别是在我的应用程序中,我可以证明延迟是真实的。

此致

Daniel

您好！

我在  EnetDma_submitTxPktQ()之后的等待循环中得到了这种延迟、特别是在我的应用程序中、我可以证明延迟是真的。

如上所述、如果缓冲区不可用且 H/W 正忙于传输所提交的帧、您将等待。
请参阅 SDK 示例中的注释。

此致、
Sudheer

您好！

我想你的意思是在  EnetDma_submitTxPktQ ()内  

我在块中确定它

发送给我们：最小值：0003、平均值：0005、最大值：0730

最大偏差。

当  EnetDma_submitTxPktQ() 成功完成时、我的延迟将出现在下一个块中。
我们的信标：最小值：0010、平均值：0306、最大值：5785

此致

Daniel

您好！

我认为延迟是在  enetDma_submitTxPktQ () [/报价]

我在 loopback.c 文件中找不到 subitTxPktQ。 我不确定上述股票是否最新。

从 Tx 任务中、我可以理解你填充了队列、但不需要检查 Tx 是否完成、通常是通过 TI SDK 中的信标来检查。

如果使用了所有队列元素、则不会有任何空队列来提交 Tx 数据包。 如果 H/W 正忙于发送之前提交的数据、而未释放/清空队列、则无法推送更多数据。

请检查时间延迟是否由于此队列元素不可用？ 因为您没有使用 DMA 通知来指示 Tx 完成。

此致、
Sudheer

您好！

请搜索  EnetDma_submitTxPktQ (不带括号)。

在 Linux 驱动程序代码中、信标属于发送中断、我认为这也用于检索函数的清理。

我的测试不到 cpsw 发送功能的1%(低于100Mbit 的10%、可能为1Gbit)。 因此硬件不能很忙。

此致

Daniel

您好！

 您似乎修改了传输序列。

与 TI SDK 相比、我们会检查所有填充在队列中的数据包并将所有数据包提交给 DMA、但在您的应用程序中、您不会循环所有填充的队列元素并提交给 DMA。

在查看分步调试或调试日志之前、 很难确认延迟是从哪里开始？

请为整个 Tx 过程添加一些调试点(归档具有数据的队列、获取并提交到 DMA、如果未获取检查队列是否可用于下一个数据包队列、则获取完成状态)

此致、
Sudheer

尊敬的 Sudheer：

我用 Beckhoff ET2000进行了测试。

直至帧 N 一切正常、所有帧也成功发送 N .  

在 我的 asm ("NOP")循环中的帧 n 之后、系统冻结超过5ms、然后继续发送。

通过这个结果(以及我 没有在那里做任何更改的事实)、可以假设获取缓冲区和发送没有问题。

但是, 如果尝试发送帧 n ,可能是 Tx 清理环的状态或 EnetLpbk_retraceFreeTxPkts()函数后面的其他一些东西的状态是坏的

我应收集哪些国家信息？

或者,我应该在 Sematphore 和 EnetLpbk_retraceFreeTxPkts()周围做些什么,以使其安全但仍然快速?

此致

Daniel

您好！

但 如果尝试发送帧 n、可能是 Tx 清理环的状态或 EnetLpbk_retretraceFreeTxPkts()函数后的某些其他事情的状态是坏的。

您是否可以通过"EnetLpbk_retraceFreeTxPkts" API 检查是否存在延迟添加？ 查看前后的时间来了解相关信息。

此致、
Sudheer

您好！

何时意味着在冻结循环中但在冻结之后、在冻结之前或之后的循环中？

平均值为7µs (all -  prepare1 - prepare2  -  send -  semaphore)

此致

Daniel

您好！

您的意思是在冻结周期中但在冻结周期之后、在冻结之前或之后的周期中？

我的意思是、检查冻结是否由于"EnetLpbk_retraceFreeTxPkts"调用？

此致、
Sudheer

尊敬的 Sudheer：

我进行了新的测量。

EnetLpbk_retraceFreeTxPkts()获取的时间永远不会超过67µs、 测量是从 Point4到结尾

冻结始终在我的 nop-loop 期间进行。

时间2679s、帧10000000
次数超过；100us 9999115；1000us 0；1500us 1；5000us 2；
全部在我们:最小值: 0010,平均值: 0267 ,最大值5835
prepare1 in us：最小值：0002、平均值：0003、最大值：0224
prepare2 in us：最小值：0000、平均值：0000、最大值：0053
发送给我们：最小值：0005、平均值：0007、最大值：1063
Smphr/Wait in us：最小值：0010、平均值：0253、最大值：5820
检索在我们:最小值: 0001,平均值: 0002,最大值0065

时间5349秒、帧20000000
次数超过；100us 9999117；1000us 1；1500us 0；5000us 2；
全部在我们:最小值: 0010,平均值: 0267 ,最大值5822
preparare1 in us：最小值：0002、平均值：0003、最大值：0176
prepare2 in us：最小值：0000、平均值：0000、最大值：0052
发送给我们：最小值：0004、平均值：0008、最大值：0942
Smphr/Wait in us：最小值：0010、平均值：0253、最大值：5808
取回在我们:最小值: 0001,平均值: 0002,最大值0062

时间8025秒、帧30000000
次数超过；100us 9999115；1000us 1；1500us 0；5000us 3；
全部在我们:最小值: 0010,平均值: 0267 ,最大值5818
prepare1 in us：最小值：0002、平均值：0003、最大值：0187
prepare2 in us：最小值：0000、平均值：0000、最大值：0054
发送给我们：最小值：0005、平均值：0007、最大值：0929
smphr/Wait in us：最小值：0010、平均值：0253、最大值为5802
检索在我们:最小值: 0001,平均值: 0002,最大值0067

此致

Daniel

尊敬的 Sudheer：

我打开了原始检索循环。 并使用我的 nop-wait-loop 对其进行测试。

仍然是发送后第一个250µs 的冻结状态、每400万帧后冻结一次。

            //while (0U != EnetQueue_getQCount(&txSubmitQ))
            if (0U != EnetQueue_getQCount(&txSubmitQ))
            {
                uint32_t txCnt = EnetQueue_getQCount(&txSubmitQ);
                status = EnetDma_submitTxPktQ(gEnetLpbk.hTxCh,
                                                   &txSubmitQ);
                qwTickPoint3 = OsMeasGetCounterTicks();

                for (int i =0; i < dwTicks1u * 60; i++) /* about 250us */
                    __asm__ volatile ("nop");
                qwTickPoint4 = OsMeasGetCounterTicks();

                SemaphoreP_pend(gEnetLpbk.hTxSem, SemaphoreP_WAIT_FOREVER);

                /* Retrieve TX free packets */
                if (status == ENET_SOK)
                {
                    txCnt            = txCnt - EnetQueue_getQCount(&txSubmitQ);
                    txRetrievePktCnt = 0U;
                    while (txRetrievePktCnt != txCnt)
                    {
                        /* This is not failure as HW is busy sending packets, we
                         * need to wait and again call retrieve packets */
                        EnetAppUtils_wait(1);
                        txRetrievePktCnt += EnetLpbk_retrieveFreeTxPkts();
                    }
                }
                //else
                //{
                //    break;
                //}
            }

时间10939秒、帧10000000
次数大于；100us 0；1000US 9998998；1500us 1；5000us 9；
全部在我们:最小值: 0010,平均值: 1094,最大值6571
prepare1 in us：最小值：0002、平均值：0003、最大值：0222
prepare2 in us：最小值：0000、平均值：0000、最大值：0017
发送给我们：最小值：0005、平均值：0009、最大值：1131
等待时间：最小值：0010、平均值：0252、最大值：5864
smphr/检索在我们:最小值: 0010,平均值: 0828,最大值5315

此致

Daniel

您好！

仍然是发送后第一个250µs 的冻结状态、每400万帧后冻结一次。

由于您的 NOP 等待循环、电流为250us。

for (int i =0; i < dwTicks1u * 60; i++) /* about 250us */
    __asm__ volatile ("nop");

您好！

但我不希望它在 SemaphoreP_pend 中发生、

我需要冷静下来。

我想这表明,发送可以留下时间延迟炸弹。

 此致

Daniel

您好！

我认为这表明发送可以留下延时炸弹。

你需要处理队列(描述符)的释放并在传输成功后发回。

在 SDK 中、它基于 ISR、而基于信标的处理也是如此。

但我不希望它在 SemaphoreP_pend 中发生、

我需要冷静下来。

可能是创建一个任务并尝试释放所有已完成的队列、然后在其他线程中填充描述符并提交数据包。

即使在上述情况下、如果未释放队列、发送将冻结一段时间、直到找到空队列。

上述情况中、没有其他可能在没有信标/中断的情况下处理发送。

此致、
Sudheer

尊敬的 Sudheer：

我确保了每个周期仅发送一个帧、

我添加了一个具有更高优先级的线程、该线程 运行 SemaphoreP_pend 和 EnetLpbk_retraceFreeTxPkts。

在发送 I sleep 1ms 后、我会检查是否检索到了封装。

static void EnetLpbk_txTaskCleanup(void* a0,
                            void* a1)
{
    uint32_t txRetrievePktCnt = 0;

    uint32_t *pdwTxRetrieveTotal = (uint32_t *)a1;
    MutexP_Handle mutexHandle = (MutexP_Handle)a0;

    while (1)
    {
        SemaphoreP_pend(gEnetLpbk.hTxSem, SemaphoreP_WAIT_FOREVER);

        /* Retrieve TX free packets */
        txRetrievePktCnt = EnetLpbk_retrieveFreeTxPkts();

        MutexP_lock(mutexHandle, MutexP_WAIT_FOREVER);
        *pdwTxRetrieveTotal = *pdwTxRetrieveTotal + txRetrievePktCnt;
        MutexP_unlock(mutexHandle);
    }
}

所以队列中没有剩余任何内容、但仍然存在相同的冻结、每450万帧。

Time 11098 s, Frames 10000000
times more than; 100us 2; 1000us 9999996; 1500us 0; 5000us 2;
dwCntTxRetrieveDelayed 0; dwTxRetrieveTotal 10000000; pktCnt 10000000;
all        in us: avg: 1109, max 5728
prepare1   in us: avg: 0003, max 0080
prepare2   in us: avg: 0000, max 0017
send       in us: avg: 0010, max 0113
wait       in us: avg: 1095, max 5713

Time 22197 s, Frames 20000000
times more than; 100us 2; 1000us 9999996; 1500us 0; 5000us 2;
dwCntTxRetrieveDelayed 0; dwTxRetrieveTotal 10000000; pktCnt 10000000;
all        in us: avg: 1109, max 5707
prepare1   in us: avg: 0003, max 0021
prepare2   in us: avg: 0000, max 0017
send       in us: avg: 0010, max 0031
wait       in us: avg: 1094, max 5693

Time 33297 s, Frames 30000000
times more than; 100us 3; 1000us 9999994; 1500us 0; 5000us 3;
dwCntTxRetrieveDelayed 0; dwTxRetrieveTotal 10000000; pktCnt 10000000;
all        in us: avg: 1109, max 5698
prepare1   in us: avg: 0003, max 0021
prepare2   in us: avg: 0000, max 0017
send       in us: avg: 0011, max 0031
wait       in us: avg: 1094, max 5681

Time 44396 s, Frames 40000000
times more than; 100us 2; 1000us 9999996; 1500us 0; 5000us 2;
dwCntTxRetrieveDelayed 0; dwTxRetrieveTotal 10000000; pktCnt 10000000;
all        in us: avg: 1109, max 5698
prepare1   in us: avg: 0003, max 0021
prepare2   in us: avg: 0000, max 0017
send       in us: avg: 0010, max 0031
wait       in us: avg: 1094, max 5684

 此致

Daniel

e2e.ti.com/.../enet_5F00_loopback.c

您好！

让我们在下周查看 TI SDK 并给您带来最新消息。
请等待回复。

此致、
Sudheer

您好！

请检查以下 E2E Thread 的更新。 下面是与该主题相关的信息。
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1416294/processor-sdk-j784s4-processor-sdk-j784s4-freertos-enet-examples-enet_loopback_test-5ms-freeze-every-2-5-million-send-frames

如有任何疑问、请跟进上面的 E2E。 将关闭该主题。

此致。
Sudheer

尊敬的 Sudheer：

感谢您重新打开该主题。

它还没有解决,而另一个线程只是尝试继续。

好的、但是在接下来的步骤中(在这种情况下)、您有什么建议。

此致

Daniel

你(们)好  

我已经在下面的主题中发布了其他检查点。  

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1416294/processor-sdk-j784s4-processor-sdk-j784s4-freertos-enet-examples-enet_loopback_test-5ms-freeze-every-2-5-million-send-frames

此致、  

Sudheer

尊敬的 Sudheer：

我将每个环路减少到一帧、但这并不会影响我的问题。

从问题成功发送前的最后一帧开始、发送所需的所有队列似乎都正常。

µSecond 在发送后发生几 μ s (在250µs 内、但有时在 SemaphoreP_pend (gEnetLpbk.hTxSem ...)之后发生、因此它可能与发送后的发送帧相关。

此致

Daniel

您好！

因为您的吞吐量要求非常低、所以您可以修改应用程序、提交所有数据包、释放队列并使用新数据发回。

您是否确认延迟来自代码？ 在连续传输数据包时测量计时来实现。

此致、
Sudheer

您好！

每次在 EnetLpbk_txTask 中使用所有可用描述符时、我都要再次发送、

或者您是关于 EnetLpbk_retraceFreeTxPkts 的吗？

在我上传的代码中、冻结 是在等待 EnetAppUtils_wait (1)时执行的；但是无论发送后执行何种操作、都是如此。

此致

Daniel

您好！

我需要有关您如何控制传输速率的信息、因为您提到您使用的带宽较少。
根据 我的理解、您将不断向 S/W 的硬件提交数据包

在我上传的代码中、冻结 是在等待 EnetAppUtils_wait (1)时发生的；但不管发送后做了什么、我都会发生这种冻结。

您是否可以移除上述等待、因为它会使任务保持睡眠状态、而是持续检查空闲缓冲区。 此外、确保软件没有延迟。

如果线路/链路速率低于推送到硬件的 s/w、则硬件无法更快地释放缓冲区、这会导致出现 s/w 延迟来提交数据包(因为 H/W 会将缓冲区空情况通知 s/w、s/w 应处理下一个数据包、结果会少微秒延迟)

此致、
Sudheer

尊敬的 Sudheer：

非常感谢。

在  cpsw_stats.c 中禁用 CPSW 统计信息可以解决我的问题。

-经常调用 ENET_STATS_IOCTL_RESET_HOSTPORT_STATS 和 ENET_STATS_IOCTL_RESET_MACPORT_STATS。

并在我的应用程序的 STAT_PORT_EN_REG 中写入零  

磁珠也有帮助

此致

Daniel

您好！

感谢您的更新。

将关闭该主题。

此致、
Sudheer