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
-
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]
