In message <[EMAIL PROTECTED]>,Joshua Johnson writes: >I don't currently see an RX mailing list or an RX project for OpenAFS, >should there be one?
probably not. openafs-devel doesnt seem to have too much traffic. >I have wondered about TCP for RX and what the implications of it could mean. while tcp for rx might be useful i believe you would wind up making the same changes needed to 'fix' udp. >Where does IPV6 fit into this? ipv6 should eliminate nats. i believe the rx header already reserved enough space for ipv6 addresses. >How involved is the current RX in the raw IO performance gap (AFS vs. NFS, >FTP et. all) people bring up? i believe rx is the problem but more precisely how rx is used the problem. we (nrl) had some work done to put atm into afs. rx datagrams were sent directly over an atm vc. atm pdu's are more like udp than tcp but that's probably not were the gains were seen. the 'segment' size for rx was increased. this created a 'new' type of jumbogram that wasnt a bunch of little rx datagrams packaged together (like 'regular' jumbograms). regular jumbograms are typically handled via scatter/gather which (IMHO) isnt well implemented on many operating systems. i believe (and i wish i had some time to work on this -- really) that if you just junked the current jumbogram scheme and make rx datagrams bigger (and reducing them for congestion control) you could see some pretty substantial performance increases. apparently jumbograms are the way they are because people wanted a form of congestion control on afs (controlling number of rx datagrams in a packet). >Anyway, sorry for my ramblings. Where is the appropriate place to toss >around thoughts/ideas involving RX ? openafs-devel. _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
