On 22 Mar 2012, at 15:23, Andrew Deason wrote: > On Thu, 22 Mar 2012 15:20:20 +0000 > Simon Wilkinson <simonxwilkin...@gmail.com> 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 OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
