On Mon, Sep 04, 2006 at 05:42:45PM -0700, Eric Anderson wrote: > Oddly making this change significantly increases the amount of user > time; haven't investigated why as the tradeoff for reduced wall clock > time is a win. Best guess is that because the client is running > faster, it makes more recv calls for less data.
Likely, and the likely wall clock side of the tradeoff comes from those reads sending window updates to the remote side that will allow it to send more data sooner and keep tcp streaming. Watching a pull with tcptrace shows some pretty bursty behaviour and windows closing right down for long periods. If we're waiting for disk here, ok, but anything we can do to overlap disk and network waits by getting the sender going at the same time is a win, that's likely what's happening here. On the localhost sync, the RTT latencies are much less significant, even if they are serialised with disk latencies. -- Dan.
pgpUwiWtOEYYs.pgp
Description: PGP signature
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
