[OpenAFS-devel] RX Performance

chas williams chas@cmf.nrl.navy.mil
Thu, 19 Jun 2003 11:00:20 -0400


In message <200306191438.h5JEcRsG027181@ginger.cmf.nrl.navy.mil>,Ken Hornstein 
writes:
>The problem with this that I see is that all of the serious thinking about
>how to make a good-performing stream protocol in the last 10 years has been
>done with TCP, and _not_ done with RX.  So we could duplicate that in
>RX, which would be hard, or just use TCP, which would be easy.

nfs (over udp) doesnt really do anything fancy and see fairly good
performance.  better than afs typically (for uncached files).  rx
(after its rewrite) has assorted tcp features.  i dont believe any
of these features are fundamentally broken.  they are just hampered
by the jumbogram mechanism.  it seems like there would be more gain from
making the smallish number of changes to rx jumbograms instead of adding
(and debugging) a tcp implementation.

>I had this discussion with Love in the AFS Workshop; he pointed out that
>most modern OS's have solved the problem with select()ing on large numbers
>of descriptors (Solaris has /dev/poll, the BSDs have kqueue, and Linux
>has something which I forget right now).  That seems to be the big one.

while most is good, afs does run on quite a few platforms not listed.
i have no idea how aix, hpux (despite its bsd lineage), dux, and nt handle 
this.  tcp connections also consume more resources than a single udp socket.

i might also add that tuning tcp is not really a simple matter either :)