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
On Fri, 13 Oct 2006, Open Source wrote:
> 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???
Try using usbmon to get a detailed record of events with high-precision
timestamps. Maybe also add similar logging to your program. This may
suggest some ideas about where the slowdown originates.
It's possible that some process you're unaware of is using the CPU, and
the reduced clock rate increases the latency for your process to continue
running.
Alan Stern
On 10/13/06, Open Source <[email protected]> wrote:
> 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.
Why all the cloak and dagger? You could at least make up a real name.
Bob