The CH340 USB-to-serial converter is encountering substantial delays in data visualization.

[blueoce]

The screenshot above shows data being sent by a serial port assistant. Although there is data, it is displayed very slowly and requires a long wait. Sometimes, it is even impossible to wait for the data to be displayed.

My question is that the delay in displaying the data is too large. Can the USB protocol filtering be placed on an FPGA for processing? This way, the display speed will be much faster and there will be no lagging.

[ataradov]

Please don't send the same request in multiple places at the same time.

I'm not sure I understand the issue. CH340 is a full speed device. There should not be any lag in capturing the data. If you see lag, there may be something wrong with your setup. May be the PC is too slow to run Wireshark or something like that.

In general, anything is possible if you spend enough time working on it. It is not possible with the current sniffer architecture, since it just passes the data to the host.

[blueoce]

Test Method:

Reopen the capture for CH340.

Utilize a serial port assistant to send 5 packets of data.

Halt the capture on CH340.

Employ the search function to look for data "DATA," but no instances of any of the sent packets are detected.

Issue: The data has indeed been transmitted, yet no data is visible within Wireshark's capture interface. Strangely, if I wait for an extended period, these 5 packets eventually appear. I'm unsure where the data is getting stuck and need guidance on how to proceed with further troubleshooting.

测试方法： 1 重新打开捕捉CH340. 2 用串口助手，发送5包数据。 3 暂停捕捉CH340. 4 用搜索功能，查找数据DATA，没有发现任何一包数据。 问题：数据已经上传了，但是在Wireshark的捕捉数据界面没有发现任何数据。 但是如果等很久，这个5包数据还是会上传的，我不知道数据到底卡在哪里了，如何进行下一步的排查呢？

285524959 @.***

 

------------------ 原始邮件 ------------------ 发件人: "ataradov/usb-sniffer" @.>; 发送时间: 2024年6月18日(星期二) 凌晨0:00 @.>; @.**@.>; 主题: Re: [ataradov/usb-sniffer] The CH340 USB-to-serial converter is encountering substantial delays in data visualization. (Issue #37)

Please don't send the same request in multiple places at the same time.

I'm not sure I understand the issue. CH340 is a full speed device. There should not be any lag in capturing the data. If you see lag, there may be something wrong with your setup. May be the PC is too slow to run Wireshark or something like that.

In general, anything is possible if you spend enough time working on it. It is not possible with the current sniffer architecture, since it just passes the data to the host.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[ataradov]

There are multiple buffers present in the system, but they all are designed to be flushed reasonably fast. There should be no significant delays, nothing more than a couple seconds.

I don't really know what is going on. It is hard to tell without more information.

Do a simple test - start the capture, connect the device, open a COM port in a terminal program, send one byte. Do you observe this byte immediately or with the delay? Do you observe the delay in the other frames (getting the descriptors)?

[blueoce]

Test Method:

Reopen the capture for CH340.

Utilize a serial port assistant to send 5 packets of data.

Halt the capture on CH340.

Employ the search function to look for data "DATA," but no instances of any of the sent packets are detected.

When the CH340 is initially plugged in, the data capture is very quick, with no discernible delay. 开始插入CH340时候，数据捕捉是非常快的。感觉不到延迟。

 However, as the number of data packets increases, a substantial delay occurs, and in some cases, data is not received at all.但是当分组数据多了以后，就会出现大量的延时，甚至收不到数据。

Issue: The data has indeed been transmitted, yet no data is visible within Wireshark's capture interface. Strangely, if I wait for an extended period, these 5 packets eventually appear. I'm unsure where the data is getting stuck and need guidance on how to proceed with further troubleshooting.

285524959 @.***

 

------------------ 原始邮件 ------------------ 发件人: "ataradov/usb-sniffer" @.>; 发送时间: 2024年6月18日(星期二) 凌晨1:12 @.>; @.**@.>; 主题: Re: [ataradov/usb-sniffer] The CH340 USB-to-serial converter is encountering substantial delays in data visualization. (Issue #37)

There are multiple buffers present in the system, but they all are designed to be flushed reasonably fast. There should be no significant delays, nothing more than a couple seconds.

I don't really know what is going on. It is hard to tell without more information.

Do a simple test - start the capture, connect the device, open a COM port in a terminal program, send one byte. Do you observe this byte immediately or with the delay? Do you observe the delay in the other frames (getting the descriptors)?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[ataradov]

Please respond on GitHub directly. Those email responses are impossible to read.

How long do you need to wait until the delays occur? Even when no actual data is sent, USB generates a lot of packets like SOFs and other polling. Eventually you will run out of RAM on your PC.

[blueoce]

After approximately 30 seconds, the CH340 starts to experience noticeable lag, to the point where it feels like data might be getting lost. 30秒之后，就会CH340就会出现卡顿，甚至感觉卡到丢失数据。

When testing with a mouse device, similar lag issues do not arise; neither do they occur with USB drive devices.

测试鼠标设备，不会出现类似卡顿的问题，U盘设备也不会卡顿。

[blueoce]

The screenshot above shows the test results for a USB mouse device. Regardless of how long the test runs, data upload remains swift and experiences no lag. 上图是测试USB鼠标设备的截图，不论测试多久，数据上传都很快。不会卡顿。

[ataradov]

This is strange. There is no real difference between the mouse and the CH340.

One thing I can suggest is enable folding of the empty frames in the sniffer settings. All those IN/NAK pairs will be condensed a lot.

[blueoce]

USB flash drive devices also respond very quickly. U盘设备响应也非常快。

[blueoce]

The issue has been resolved. The response is now very fast.

[ataradov]

Resolved how? By enabling folding? It is strange because the other devices would have generated similar number of frames.

[blueoce]

For the CH340 device, it is necessary to enable the feature of folding empty data packets in the packet capture software; otherwise, it encounters lag or even becomes unresponsive. In contrast, the mouse device operates normally without requiring this adjustment, experiencing no lag or freezing issues.

[ataradov]

I guess the polling is much slower on the mouse.

But yes, for long running captures, enabling the folding helps a lot. Note that this folding happens in the software on the PC side, but before it gets to the Wireshark. The hardware still sends all the frames.

So, the overall slowness is due to Wireshark itself. It gets slow trying to parse all those empty IN/NAK pairs.

[blueoce]

By filtering out empty packets in Wireshark, a substantial amount of PC RAM is saved, which in turn enhances the computer's responsiveness.