Re: Preliminary sys/netinet style patch
Xin LI [EMAIL PROTECTED] writes: I have a patchset to remove tailing spaces, convert leading spaces to tabs, and removes spaces before tabs. As a rule, we never do this except in conjunction with other changes. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
closefrom (was Re: Article on Sun's DTrace)
Hi; The article suggests we should learn from Solaris and implement closefrom(3C): http://www.freebsd.org/cgi/man.cgi?query=closefromapropos=0sektion=0manpath=SunOS+5.9format=html And make sure we use it in sendmail (and Javac). cheers, Pedro. Yahoo! Companion - Scarica gratis la toolbar di Ricerca di Yahoo! http://companion.yahoo.it ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
concurrent scp transfers (and a testing methodology ?)
I have read several documents on the number of concurrent https sessions a FreeBSD system is capable of. However, I wonder how well this relates to how many ssh sessions (scp file transfers, specifically) that a FreeBSD server can handle. Can anyone throw out some basic numbers for this ? Assuming a 1ghz p3 and 2gigs of RAM, and assuming that everyone is transferring a totally different file. (so there is no amount of cache hits - everything comes straight off the drives) I would think the major bottleneck would be disk - you would start chugging the disks far before you used up all the CPU on a 1ghz p3 ... but what is the second bottleneck ? Is it cpu, or is it ram (or mbufs, etc.) Would it be a reasonable test to just start up scp sessions from the machine to itself and then divide the number of sessions you can acceptably create by the number 2 ? Or is this somehow a flawed test ? Any additional comments (kernel tunes, settings, war stories) are greatly appreciated. (like, does SMP help a lot here, or just a little ?) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ZEROCOPY between kernel and userland
Hello everybody, i'm writing a netgraph module to get some stats about the network traffic. Actually i have to pass all the data gathered all in one piece, to the process which asks me for it. The client should work like this in userland: int * pointer; ioctl(dev, MY_COMMAND, pointer); after this pointer points to the right memory area. The array to pass is about 500Kb, so copying with copyout() would be too expensive, moving the array from kernel's addrespace to process's address space would be fast. The question is: what's the actual API to do that, if there's any, in freebsd 5? TIA -- Claudio thefly Martella [EMAIL PROTECTED] GNU/PG keyid: 0x8EA95625 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ZEROCOPY between kernel and userland
From: thefly [mailto:[EMAIL PROTECTED] Hello everybody, i'm writing a netgraph module to get some stats about the network traffic. Actually i have to pass all the data gathered all in one piece, to the process which asks me for it. The client should work like this in userland: int * pointer; ioctl(dev, MY_COMMAND, pointer); after this pointer points to the right memory area. The array to pass is about 500Kb, so copying with copyout() would be too expensive, moving the array from kernel's addrespace to process's address space would be fast. The question is: what's the actual API to do that, if there's any, in freebsd 5? We did a device, and 'mmap' some shared memory between the two. The user space has read-only access. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZEROCOPY between kernel and userland
could you point me pls to some code of that? To me read-only access is ok, userspace doesn't need to write anything on it, kernelspace does. But what about locking issues between userspace read access and kernelspace write access? On Tue, Jul 06, 2004 at 09:22:39AM -0400, Don Bowman wrote: From: thefly [mailto:[EMAIL PROTECTED] Hello everybody, i'm writing a netgraph module to get some stats about the network traffic. Actually i have to pass all the data gathered all in one piece, to the process which asks me for it. The client should work like this in userland: int * pointer; ioctl(dev, MY_COMMAND, pointer); after this pointer points to the right memory area. The array to pass is about 500Kb, so copying with copyout() would be too expensive, moving the array from kernel's addrespace to process's address space would be fast. The question is: what's the actual API to do that, if there's any, in freebsd 5? We did a device, and 'mmap' some shared memory between the two. The user space has read-only access. -- Claudio thefly Martella [EMAIL PROTECTED] GNU/PG keyid: 0x8EA95625 signature.asc Description: Digital signature
Re: concurrent scp transfers (and a testing methodology ?)
I have read several documents on the number of concurrent https sessions a FreeBSD system is capable of. However, I wonder how well this relates to how many ssh sessions (scp file transfers, specifically) that a FreeBSD server can handle. Can anyone throw out some basic numbers for this ? Assuming a 1ghz p3 and 2gigs of RAM, and assuming that everyone is transferring a totally different file. (so there is no amount of cache hits - everything comes straight off the drives) I would think the major bottleneck would be disk - you would start chugging the disks far before you used up all the CPU on a 1ghz p3 ... but what is the second bottleneck ? Is it cpu, or is it ram (or mbufs, etc.) Would it be a reasonable test to just start up scp sessions from the machine to itself and then divide the number of sessions you can acceptably create by the number 2 ? Or is this somehow a flawed test ? Any additional comments (kernel tunes, settings, war stories) are greatly appreciated. (like, does SMP help a lot here, or just a little ?) What crypto algorithm are you using for your ssh/scp session? AES, DES, 3DES, arcfour? Any hardware assist for doing the crypto? Are you having the underlying SSH session try to compress the data? louie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Article on Sun's DTrace
In a nutshell, here is what DTrace is about: - It has no impact on the system when it is not used. So you can leave it in all the time, instead of having a debug kernel and a production kernel. [I don't know how they achieve the no impact but they claim that they really mean no, not just negligible.] - It allows you to analyze pretty much any aspect of the kernel that you like, and it has hooks into userland as well. So if you have strange behaviors happening due to a badly-written process, you can track down what that process is doing. They demonstrate some nice examples of this. - The D language is what you use to specify how the trace info is filtered/processed/presented to you. D is not a complete programming language. It is highly constrained (i.e. no loops, no recursion, etc) in order to make sure that every path through a D program completes in finite time (otherwise, a bug in your D program might effectively hang the kernel, which is a no-no). So, you could think of it as a million debugging printf's magically inserted into the kernel for you along with a tool to analyze the output, but it's really much more sophisticated than that. It looks very nice. I wish I'd had it during my forays into the FreeBSD kernel. Is it hopelessly solaris-specific? Well, I was at the presentation that Bryan Cantrill gave at USENIX, where he was asked about the possibility of porting DTrace to linux. His response was something like well, we're really trying to encourage people to use the *best* possible operating system, so no. (Of course, one might argue that this means that a FreeBSD port is imminent, but I don't think that's what he meant.) -Dan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
About rules on style changes [Was: Re: Preliminary sys/netinet style patch]
Hi, Dag-Erling, (I have removed freebsd-net@ from cc list and added doc@ as the topic seemed to be more related to doc@) On Tue, Jul 06, 2004 at 01:50:34PM +0200, Dag-Erling Sm?rgrav wrote: Xin LI [EMAIL PROTECTED] writes: I have a patchset to remove tailing spaces, convert leading spaces to tabs, and removes spaces before tabs. As a rule, we never do this except in conjunction with other changes. Hmm... Seems that I have misunderstood the committers' guide, section 10.3, which said: Do not mix style fixes with new functionality. A style fix is any change which does not modify the functionality of the code. Mixing the changes obfuscates the functionality change when using cvs diff, which can hide any new bugs. I thought that this is not a strict discourage of style fixes. Shall we add something to clarify the rule, like this: In order to prevent difficulties other committers will encounter when making changes or merging changes from third party, it is discouraged to do style changes when there is no functional changes over a subsystem, and please follow style(9) when committing new code, as a consistent style will ease others' work when merging your changes. Thanks. Cheers, -- Xin LI delphij frontfree net http://www.delphij.net/ See complete headers for GPG key and other information. pgpRFHsBH3c7G.pgp Description: PGP signature
Re: About rules on style changes
Xin LI [EMAIL PROTECTED] writes: Hmm... Seems that I have misunderstood the committers' guide, section 10.3, which said: Do not mix style fixes with new functionality. A style fix is any change which does not modify the functionality of the code. Mixing the changes obfuscates the functionality change when using cvs diff, which can hide any new bugs. That just means you have to do it in a separate commit. We do not generally make style changes for their own sake; instead, we commit style fixes shortly before or after a functional change. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: About rules on style changes
Thanks for the clarification :-) On Tue, Jul 06, 2004 at 04:46:52PM +0200, Dag-Erling Sm?rgrav wrote: [snip] That just means you have to do it in a separate commit. We do not generally make style changes for their own sake; instead, we commit style fixes shortly before or after a functional change. Cheers, -- Xin LI delphij frontfree net http://www.delphij.net/ See complete headers for GPG key and other information. pgpQ1eD4pt1WR.pgp Description: PGP signature
Re: concurrent scp transfers (and a testing methodology ?)
I think the divide by two methodology would be flawed because packets would circulate on local loopback which is must faster than Ethernet. More transferts would be possible in a long period of time because of that. Joe Schmoe said: I have read several documents on the number of concurrent https sessions a FreeBSD system is capable of. However, I wonder how well this relates to how many ssh sessions (scp file transfers, specifically) that a FreeBSD server can handle. Can anyone throw out some basic numbers for this ? Assuming a 1ghz p3 and 2gigs of RAM, and assuming that everyone is transferring a totally different file. (so there is no amount of cache hits - everything comes straight off the drives) I would think the major bottleneck would be disk - you would start chugging the disks far before you used up all the CPU on a 1ghz p3 ... but what is the second bottleneck ? Is it cpu, or is it ram (or mbufs, etc.) Would it be a reasonable test to just start up scp sessions from the machine to itself and then divide the number of sessions you can acceptably create by the number 2 ? Or is this somehow a flawed test ? Any additional comments (kernel tunes, settings, war stories) are greatly appreciated. (like, does SMP help a lot here, or just a little ?) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Nicolas Bérard Nault ([EMAIL PROTECTED]) http://www.quebecbsd.org http://www.xeatech.net http://staff.xeatech.net/nicobn Je ne sais pas avec quelles armes se combattra la troisième guerre mondiale mais je peux vous assurer que la quatrième se combattra avec des pierres et des bâtons. -- Albert Einstein. -- Nicolas Bérard Nault ([EMAIL PROTECTED]) http://www.quebecbsd.org http://www.xeatech.net http://staff.xeatech.net/nicobn Je ne sais pas avec quelles armes se combattra la troisième guerre mondiale mais je peux vous assurer que la quatrième se combattra avec des pierres et des bâtons. -- Albert Einstein. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: concurrent scp transfers (and a testing methodology ?)
Joe Schmoe [EMAIL PROTECTED] wrote: However, I wonder how well this relates to how many ssh sessions (scp file transfers, specifically) that a FreeBSD server can handle. Can anyone throw out some basic numbers for this ? Assuming a 1ghz p3 and 2gigs of RAM, and assuming that everyone is transferring a totally different file. In LAN environments, scp is conspicuously CPU limited. A P3/1GHz will be able to push out a file at about 6MB/s. Divide by desired number of files. Just what transfer rates did you have in mind? I would think the major bottleneck would be disk I don't think so. If you have many concurrent transfers of different files spread out wildly over the disk, you might get the disk to thrash, but it isn't clear that it will still matter at this point. Check some random reads benchmarks for your vintage of disk. (like, does SMP help a lot here, or just a little ?) A lot, as far as SMP goes. Alternatively, a lowly VIA C3 Nehemiah with its on-core AES engine should happily beat your usual high-end P4/Athlon/etc at this task. (I don't know whether FreeBSD integrates the AES engine in userland. OpenBSD does.) -- Christian naddy Weisgerber [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZEROCOPY between kernel and userland
[Please don't top-post, it tends to lose context.] On Tue, Jul 06, 2004 at 03:36:40PM +0200, thefly wrote: could you point me pls to some code of that? To me read-only access is ok, userspace doesn't need to write anything on it, kernelspace does. But what about locking issues between userspace read access and kernelspace write access? First, be aware that mmap is not necessicairly faster then copyout on modern CPUs. The cycles required to copy a few K of bytes aren't worth much of anything on a modern CPU compared to a page-fault. Second, if you still want to do things this way, take a look at the geom statistics mechanism. IIRC, it works by using a generation number at the top and bottom of the stats structure. The user copies the entire struct and then verified that the copies of the generation number at the top and bottom of the struct are the same. If so, it uses the copy it got. If not, it tries again. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpb5Mk7vrPds.pgp Description: PGP signature
