search

ataradov / usb-sniffer

Low-cost LS/FS/HS USB sniffer with Wireshark interface
BSD 3-Clause "New" or "Revised" License
838 stars 102 forks source link

USB high speed capture lost some packets #28

Open genknife opened 9 months ago

genknife commented 9 months ago

Hi, I captured a device like usb printer with high speed. If I print one page with simple content, it is OK. But if I print one page with complex content，some packet lost, And some syslog message said "Hardware buffer overflow". I have also done a transfer rate test, result is about 48MB/s. USB 2.0 high speed can mostly reach 60MB/s, but README recommend transfer rate 40~50MB/s. If printer usb high speed transfer rate reach 60MB/s, I will always lost some packets?

ataradov commented 9 months ago

Maximum theoretical USB HS transfer rate is ~53 MB/s after physical protocol overhead. But with the way practical host schedule transfers, you get 48-49 MB/s as a maximum practical transfer rate. So, the printer is also not going to be faster than 48 MB/s. But the sniffer is adding its own overhead with timestamp information and other information about the packets, so it will always be slower.

Some lost frames are normal. It is impossible to capture a lot of traffic on one interface going at full speed. This is a debugging tool, it is not meant to capture absolutely everything at once.

That being said, there are a couple things you can check:

  1. Do a speed test while printer is printing. See if the speed drops. It may drop depending on the root hub port mapping. You may be able to get better results by using different set of USB ports.
  2. This may be a slowness of Wireshark and the pipe interface (it is known to be slow on Windows). You can capture directly to the file from the command line and then open the final captured file in Wireshark. This way you will not be limited by the Wireshark UI trying to display all those frames in run-time.
tencyrat commented 9 months ago

Maximum theoretical USB HS transfer rate is ~53 MB/s after physical protocol overhead. But with the way practical host schedule transfers, you get 48-49 MB/s as a maximum practical transfer rate. So, the printer is also not going to be faster than 48 MB/s. But the sniffer is adding its own overhead with timestamp information and other information about the packets, so it will always be slower.

Some lost frames are normal. It is impossible to capture a lot of traffic on one interface going at full speed. This is a debugging tool, it is not meant to capture absolutely everything at once.

That being said, there are a couple things you can check:

  1. Do a speed test while printer is printing. See if the speed drops. It may drop depending on the root hub port mapping. You may be able to get better results by using different set of USB ports.
  2. This may be a slowness of Wireshark and the pipe interface (it is known to be slow on Windows). You can capture directly to the file from the command line and then open the final captured file in Wireshark. This way you will not be limited by the Wireshark UI trying to display all those frames in run-time.

same issues,i replace it with LCMXO2-2000HC-6TG100C,could you offer me 6TG100C jed files?thanks!

ataradov commented 9 months ago

Replacing with a different FPGA will not do anything for lost packets. The same JED file will work for all speed grades.

In the deleted comments you mention your ID CODE is 0x012ba043. This ID CODE belongs to LCMXO2-1200HC. This will not work, you need 2000HC device.

tencyrat commented 9 months ago

First of all, thanks for your reply. I may have bought a fake chip. The silk of the chip is LCMXO2-2000HC-6TG100C.but the ID CODE is 0x012ba043.

ataradov commented 9 months ago

This is a strange thing to fake, since it will be discovered right away. Those devices have different bit-stream size, so programming would not work even if you change the ID.

Can you show pictures of the device? I have never seen them faked, so I wonder how it compares to the real device.

Also, where did you buy it? I'm sure other will be thankful to know what source to not avoid.

tencyrat commented 9 months ago

This is a strange thing to fake, since it will be discovered right away. Those devices have different bit-stream size, so programming would not work even if you change the ID.

Can you show pictures of the device? I have never seen them faked, so I wonder how it compares to the real device.

Also, where did you buy it? I'm sure other will be thankful to know what source to not avoid.

when i patch the id code,fpga burning pass,but it does not work,speed test is 0MB/s. i use microscope to take photo.5TG is Genuine,6TG is fake.

6TG 5TG

i purchase it from taobao.com so avoid it!