Hi Oleg, I suggest you to increase this to at least 1500 bytes. I don't remember all the configs, but I think inside boards/ you will find some examples.
BR, Alan On 8/10/22, Oleg <ev.m...@gmail.com> wrote: > Hi all again, > > Thanks all for feedbacks. I got back from COVID and can continue to debug > this issue. > > Alan, could you please clarify what things you suggested to tune? I don't > see many options, especially about net buffers. > NET_ETH_PKTSIZE is the default one without IPv6: 590. Length of mavlink FTP > data packets according to wireshark are 308 bytes long. > > Petro, I have tried with and without CONFIG_NET_UDP_WRITE_BUFFERS, it > didn't help. > Also as I see this config option is related to ongoing UDP/IP packets that > are from board to PC, but in my case the udp packets from PC to board get > lost. > > Gregory, yes, I fully understand packet loss is normal UDP behavior and > mavlink FTP in px4 is indeed designed to handle packet loss, but I agree > with Petro that the probability of losing a UDP packet in the wire is > pretty low and I'm quite sure that this is not the case in my current > simplest environment. > > I've enabled NET_STATISTICS and NETDEV_STATISTICS (thanks for advice!) and > not on the first try but reproduce the issue. Packets get lost due to a > wrong checksum. I set a breakpoint on increasing drop statistics and found > out that part of data in such packet is not the same as sent: there are 32 > bytes wrong bytes and I found them in the same place but in the received > packet ten times ago. And this ten count is repeatable, only the offset of > 32 byte could be different in different tests (but also multiple of 32: > 0x60, 0x80 etc.) > [image: изображение.png] > > > So it looks like the problem is related to dcache. This issue reminds me > very much of the previous random FAT files system failures I'm asked about > some time ago. That time they were fixed in > https://github.com/apache/incubator-nuttx/pull/4872 (and also probably > related https://github.com/apache/incubator-nuttx/pull/5062). > > I'm not very familiar with dcache, but will try to investigate further. > Will be much appreciated for suggestions on how to debug dcache. > > --- > With best regards, Oleg. > > > чт, 4 авг. 2022 г. в 16:46, Gregory Nutt <spudan...@gmail.com>: > >> On 8/4/2022 7:40 AM, Petro Karashchenko wrote: >> > Hi, >> > >> > Yes, the packet lost on UDP is a normal situation, but... If the board >> > is >> > directly connected to the PC, then from my experience the probability >> > to >> > lose a UDP packet in the wire is pretty low. So only loss may be done >> > in >> > the stack and statistics should identify this easily. >> > >> > Best regards, >> > Petro >> It is good to debug in both environments. The simplest environment is >> best for initial testing, but an application must also be tested in a >> full up busy network environment and must survive significant packet >> loss. Packet loss should effect only efficiency and should not bring >> the application down. >> >
