Pete Zaitcev <[EMAIL PROTECTED]> writes:
> On Thu, Nov 20, 2003 at 09:16:39AM -0500, chas williams wrote:
>> >Possible problems with this approach are:
>> >- TCP may cause worse performance than UDP.
>> >- Can multiple users behind the same NAT be handled?
>> >- For large servers, the number of TCP connections may become too great
>>
>> you might want to take a look at the 'rx performance' threads
>> back in june 2003. in particular, this comment about tcp
>> makes me skeptical about tcp:
>>
>> https://lists.openafs.org/pipermail/openafs-devel/2003-June/004424.html):
>
> I'm truly shocked that Derek in particular would bring up
> this old strawman. He's one of elders, saw the migration
> of NFS from UDP to TCP, saw everything, cheesh...
Um, no, I'm not an elder. You're confusing me with Derrick (who is an
elder). Me, I'm just a plain old AFS Developer, the Red Hat package
maintainer, and the original creator of Linux-AFS. However I still
stand by my statement that TCP doesn't scale to large numbers of
concurrant, long-lasting sessions.
> The case of 20,000 simultaneous long lived TCP connections
> is not unheard of, it's routine on IRC servers. It's all
> down to the hashing quality.
Most machines, out of the box, cannot handle this directly. Most
machines are configured to limit the number of open file descriptors
to about 1024, maybe 4096. The limit in the kernel may be 100k
fds, but that doesn't mean a single process can handle that many.
Note also that this is getting better over time, but the libc
interfaces are still rather limited. Show me a system with an fd_set
that can handle 32k fds out of the box! Show me one that can handle
8k! The max that I've seen is 4k, and even that required recompiling
certain core pieces of the OS, because 1k was the default.
> -- Pete
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[EMAIL PROTECTED] PGP key available
_______________________________________________
OpenAFS-devel mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-devel
