On 09/17/13 17:38, Harald Schmalzbauer wrote:
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
Hi,
I think the adapters use very small buffers. You can try adding
".interval = 4" to the other USB configs, above the one you patched, and
see what happens. I cannot tell if you will loose characters or not.
--HPS
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
