Hi all,
I just tested using CONFIG_HZ_1000=y and
CONFIG_HZ=1000 and as expected, this change
improves the throughput. Thank you Lee for pointing
that out so quickly.
Alan -- yes, I understand the ability to increase throughput
by transfering more bytes and I am definitely able to see
better overall throughput when increasing the number
of bytes per transaction. However, I needs to still have
good transaction-level timing because I cannot always
queue the transactions up. Recall that each transaction
is a WRITE followed by a READ. The results of the
READ determine the outgoing bytes for the following
transaction's WRITE.
Not to sound like a broken record, but there is something
seriously wrong here. This has to be a bug somewhere.
It could be very well just be something as simple as
issuing the right incantation with libusb, devio, etc. But,
I've been using libusb for years now and am at a loss
on what might have changed to require this.
Any ideas???
Best regards.
p.s. My apologies about the word wrap. I'm using
a different mail client than my usual one and didn't
realize it was not wrapping automatically.
----- Original Message ----
From: Alan Stern <[email protected]>
To: Open Source <[email protected]>
Cc: [email protected]; [email protected]
Sent: Friday, October 13, 2006 6:56:31 AM
Subject: Re: [linux-usb-devel] USB performance bug since kernel 2.6.13 (CRITICAL???)
[FYI, it would make things easier for the rest of us if you can convince
your email client to wrap lines before 80 columns.]
I'll be interested to here if changing HZ back to 1000 makes any
difference. As others have already stated, it shouldn't matter but maybe
it does somehow.
Even if it does, there are things you might be able to do with HZ=250 to
improve throughput. You could transfer more than 512/1024 bytes per URB.
You could queue multiple URBs before waiting for the first one to
complete. Provided you can keep the endpoint queues filled, you should be
able to achieve the maximum throughput of the hardware.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
