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
signature.asc
Description: OpenPGP digital signature
