Bez├╝glich Hans Petter Selasky's Nachricht vom 17.09.2013 11:24
(localtime):
> On 09/17/13 11:06, Harald Schmalzbauer wrote:
>> ...
>> Shall we switch to non-list-comm?
>
> Hi,
>
> That's OK.
>
>> Hmm, in my case, this 4-port-serial-USB-hub will be used as console
>> concentrator. So most time it's doing nothing, just feeding tmux with
>> consoles output. What latency are we talking about? Less than a some
>> milliseconds should be fine.
>> What I'm curious about is why my prolific USB-serial converter doesn't
>> generate these high irqs.
>
> Try this patch and see what happens:
>
> ==================================================================
> --- umcs.c    (revision 255492)
> +++ umcs.c    (local)
> @@ -230,6 +230,7 @@
>          .bufsize = 0,        /* use wMaxPacketSize */
>          .callback = &umcs7840_intr_callback,
>          .if_index = 0,
> +        .interval = 20, /* ms */
>      },
>  };
>
>
> BTW: I see that the umcs driver shouldn't do synchronous control
> transfers from the USB interrupt transfer callback. This should be
> postponed into some worker thread, for example the USB explore thread.
> See USB audio driver for an example.
>
> --HPS

I tried your patch and it works as expected: IRQs decreased to ~64/s
when idle/disconnected.

One interesting thing I never measured before:
Console connection with 115k2 via umcs and 'while ( 2>1 ) echo "---..."
end' results in 8000 irqs/s :-( But that's also true for the prolific
(uplcom). The latter just goes down to 0.0 irqs/s when idle.

Doing the same with uart0 results in 1444irqs/s.
Is it by design/unavoidable that transfering the same via USB multiplies
by factor 5-6?

Thanks,

-Harry

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to