The lacks large window sizes is unlikely the issue in this case. The use case is reading large numbers of small files which require a separate RPC for each object. An 8MB window size won't help when the file sizes are small and the number of files is large. The RPC latency * number of RPCs is what matters.
Jeffrey Altman On Mar 22, 2012, at 11:28 AM, Simon Wilkinson <[email protected]> wrote: > > On 22 Mar 2012, at 15:23, Andrew Deason wrote: > >> On Thu, 22 Mar 2012 15:20:20 +0000 >> Simon Wilkinson <[email protected]> wrote: >> >>> That limit is imposed because it is the point at which the current RX >>> implementation loses the queue efficiency/throughput tradeoff. You can >>> run with a larger window size, but it will actually make things go >>> slower. >>> >>> It was naively increasing the maximum window size to 255 that caused >>> the huge performance problems in the 1.5.x series that Andrei >>> highlighted at the 2010 European AFS workshop. >> >> Yes, I know, that's what I'm talking about. Even if we didn't have that >> problem, a window size of 255 is still prohibitively small for many >> uses. > > Yeah, that's a bigger problem. We can't extend the window beyond 255, because > that's the maximum size of the RX ACK packet. > > Large windows only help up to a point, though. We go back in to slow start > with every new call, (this is similar to TCP, which re-enters slow start if > RTT has passed since the last packet was sent). So, you will only use the > full window for Store or Read Data if you are writing enough data in single > call that you can grow the window quickly enough. > > Ultimately, we either need rx/tcp, or a bigger revamp of rx/udp than anyone > is currently considering. > > S. > > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
