Re: Question regarding CDC NCM and VNC performance issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Dec 7, 2023 at 12:07 PM Oliver Neukum <oneukum@xxxxxxxx> wrote:
> On 07.12.23 11:03, Francesco Dolcini wrote:
> > Hello Oliver and Maciej
> >
> > On Thu, Dec 07, 2023 at 10:41:51AM +0100, Oliver Neukum wrote:
>
> >> OK, you are using Linux on _both_ sides. Interesting, far from obvious, though.
> >> (Putting Maciej into CC)
> >
> > One more data point. If the USB host side is Windows and not Linux it
> > works fine.
>
> That suggests, but does not prove that the issue is on the host side.
> Could you post the result of "ethtool -S" after a test run? We should
> get statistics on the reasons for transmissions that way.

An every 1s (the default) ping is too rare to be of help I'd assume...
Try ping with various intervals (-i).  All the way down to a flood ping (-f).
Most likely -i 0.01 would be enough to make things work better...

Also which specific versions of the kernel are involved on both sides
of the connection.

There was a pretty recent fix related to packet aggregation recently
that could be either the fix or the cause.
  "usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call"
Though I doubt it - I believe that was specific to how windows packs things.

Also Krishna Kurapati has a (afaik still not merged) patch "usb:
gadget: ncm: Add support to configure wMaxSegmentSize"
that could be of use - though again, doubt it.

Another thing that comes to mind, is that perhaps the device in
question does not have sufficiently high res timers?
There might be something in the kernel boot log / dmesg about hrtimer
resolution...
Maybe this just needs to be configurable...  Or pick a smaller value
with broken hrtimer (if that's the issue),
or just disable aggregation if lowres hrtimers... etc...

#define TX_TIMEOUT_NSECS 300000
300 us is too small to be noticeable by VNC imho, so I think something
*must* be misbehaving.
Perhaps timer resolution is bad and this 300us ends up being much larger...???

I wonder if the hrtimer_init() call should be with CLOCK_BOOTTIME
instead of CLOCK_MONOTONIC.
There could potentially be an issue with suspend, though I really doubt it.

Another idea would be to add a gadget setting to disable tx
aggregation entirely...
(note that reducing from 8000 to 2000 doesn't actually turn off aggregation...)

Have you tried reducing from 8000 to 4000 or 3500 or 3000?
Maybe there's some funkiness with page sizes??





[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux