[OpenAFS] Re: WAN speed

[Jeffrey Altman]

The lacks large window sizes is unlikely the issue in this case.  The use ca=
se is reading large numbers of small files which require a separate RPC for e=
ach 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 mat=
ters.

Jeffrey Altman


On Mar 22, 2012, at 11:28 AM, Simon Wilkinson <simonxwilkinson@gmail.com> wr=
ote:

>=20
> On 22 Mar 2012, at 15:23, Andrew Deason wrote:
>=20
>> On Thu, 22 Mar 2012 15:20:20 +0000
>> Simon Wilkinson <simonxwilkinson@gmail.com> wrote:
>>=20
>>> 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.
>>>=20
>>> 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.
>>=20
>> 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.
>=20
> Yeah, that's a bigger problem. We can't extend the window beyond 255, beca=
use that's the maximum size of the RX ACK packet.
>=20
> 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 f=
ull window for Store or Read Data if you are writing enough data in single c=
all that you can grow the window quickly enough.
>=20
> Ultimately, we either need rx/tcp, or a bigger revamp of rx/udp than anyon=
e is currently considering.
>=20
> S.
>=20
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info