Date: Thu, 9 Jul 1998 18:10:30 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bf20761@binghamton.edu Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Multi-threaded and TCP/IP window size Message-ID: <199807091810.LAA19691@usr04.primenet.com> In-Reply-To: <Pine.SOL.L3.93.980709094537.16513A-100000@bingsun1> from "zhihuizhang" at Jul 9, 98 10:06:17 am
next in thread | previous in thread | raw e-mail | index | archive | help
> (1) I know for sure that FreeBSD does not supported multi-threaded. I am > considering the possibility of constructing a clustered file system using > a good NIC. I am just wondering if the fact that FreeBSD does not support > multi-threaded programming will affect the performance or implementation > of a clustered file system and how. FreeBSD supports multithreading. It does not support kernel threading without patches. If you need contexts within the kernel, it is possible to get them three ways: A) The way init, update/syncd, and the page daemon get them, by creating process contexts in the kernel. Since I was the person who generalized this mechanism in init_main.c, I know that you can start arbitrary processes using the same method by providing a "thread" entrypoint. B) The way nfsiod, et. al. do it, which is to create a process in user space, and make a call to kernel space that never returns to user space. This effectively creates the same situation, with the difference that you get a choice as to how many process contexts you provide the kernel. C) Contact Elvind and get a copy of John Dyson's patches in support of kernel threading. There is also primitive support for important things like SMP CPU affinity. > (2) A friend has a special application requirement in which two machines > are communicating with each other with TCP/IP. If the receiver send a > packet with window size of *zero*, it expects the sender to send one byte > a time immediately. He tested other Unix systems (Linux, SunOS, AIX) and > found that in these Unix systems, the sender keeps sending a lot of data > *for a while* before sending one byte a time (kind of probing). What he > wants is an instantanous response form the sender. Later when the receiver > sends a packet saying the window size is now, say, 3000 bytes, the sender > should be able to come to data rate *immediately*. Can this be (or > already have been) done by FreeBSD? You may want to contact Julian Elisher, julian@freebsd.org; he has done work in dynamic window size adjustment. I believe that the advertised window size would have to be one byte (not zero) for this to work, and if you dynamically adjusted it, then you would still have a short period until it took effect. One possible approach would be to synchronize by sending bytes of a particular value back and forth, and changing value when the one byte level has been reached. This would require a correlation delay, but the resulting channel will be one byte. Because TCP is reliable stream delivery, both ends will know when this situation has occurred, and can start up whatever protocol on top of this that they need. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807091810.LAA19691>