Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
On Wed, Dec 04, 2002 at 11:34:30AM -0800, Terry Lambert wrote: Stijn Hoop wrote: On Wed, Dec 04, 2002 at 10:06:16AM -0800, Terry Lambert wrote: Actually, for the case you are talking about, your emulator should be using aggregate instead of discrete timeouts, and you would not be having a problem. It's not useful to do 100 1ms timeouts to achieve a 100ms timeout, when you can ask for a single 100ms timeout. I would count this as a bug in your emulator. Yes, I would count it as a bug in any application in fact. But these benchmarks are used to determine which of the various _sleep functions would be appropriate to use in the idle loop of the emulator while not dropping too many frames. Sleeping for a minimum of 10 ms is a lot if you want to achieve a steady 60 frames / second. It's a flawed benchmark. I'd argue it isn't flawed for the measuring it is supposed to do - namely the overhead for the various _sleep functions. Care to tell me why it is flawed according to you? I would argue that that application was special purpose, as well. Yes it most certainly is. The hardclock rate gets boosted in the kernel under certain usage conditions, among them being using the PC speaker driver. I believe there is an interface available that you could abuse to raise it the same way. Far be it for sotware to know about the hardware it's running on, though... 8-). That sounds gross... :) --Stijn -- Help Wanted: Telepath. You know where to apply. msg38498/pgp0.pgp Description: PGP signature
Automount from a Solaris NIS/NFS server?
Hello-- I'm running FreeBSD 4.7-STABLE and have managed (after some difficulty), to get it to bind to a Solaris NIS server we have here. All NIS users can log on now, but I can't figure out how to get home directories automounted when users do log in. I tried a couple of things on the web, an awk script to transform the Solaris auto.home, to amd syntax, and it seems to work fine, except that no home directories are mounted when NIS users log in. I'm hoping for a silver bullet solution! Here are some relevant bits: # cat /etc/amd.conf [ global ] auto_dir = /net log_file = /var/log/amd log_options = all search_path = /etc/amdmaps [/net] map_type = nis map_name = amd.nis From the amd.nis map /defaults opts:=rw,grpid,intr,rsize=8192,wsize=8192,resvport;type:=nfs username host==nlattp6sfs1;type:=link;fs:=/volumes/home/toostenburg host!=nlattp6sfs1;os!=netbsd1;type:=nfs;rhost:=nlattp6sfs1;rfs:=/volumes/home/toostenburg host!=nlattp6sfs1;os==netbsd1;type:=nfs;opts:=rw,grpid,intr,resvport,proto=udp,vers=2;rhost:=nlattp6sfs1 It seems that amd is not picking up NIS logons. Any ideas? Cheers Tiarnan __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: strange netstat output inside 4.x jails...
In message [EMAIL PROTECTED], Josh Brooks writes: I run netstat -i fxp0 while _innside_ a jail: and then, I transfer a large file from the jail to some external host. The file I transferred out was 4.3 megabytes. Opkts only increased by 1733 ... which means 2481 bytes per packet ... but ifconfig tells us: How long did you wait after the transfer completed before checking netstat? I think the packet counts for fxp interfaces are only updated about once a second, as the driver periodically polls them from the hardware (the byte counts are updated immediately though). Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
Stijn Hoop wrote: It's a flawed benchmark. I'd argue it isn't flawed for the measuring it is supposed to do - namely the overhead for the various _sleep functions. Care to tell me why it is flawed according to you? Because it measures the API one way, but the code uses it another. The results you get are not predictive of the code that you are going to be running. The hardclock rate gets boosted in the kernel under certain usage conditions, among them being using the PC speaker driver. I believe there is an interface available that you could abuse to raise it the same way. Far be it for sotware to know about the hardware it's running on, though... 8-). That sounds gross... :) Well, really, something that requires RT performance should be in the kernel. That's why we put interrupt handlers there. 8-). Probably the place to do this is in the POSIX RT scheduling; if the RT scheduling is active (meaning a process has called it, and that process is still running), it's probably a reasonable thing to crank up the Hz. This would make it self-adjusting, and also self-healing, so that you could safely degrade the overall system performance by intentionally running your application, but not otherwise. Note that if this were implemented, it would mean your benchmark is still broken, because it doesn't call the necessary interfaces. Another alternative would be a nanosleep call with an argument below a certain value. I would hesitate to do it that way, though, since I think that it ought to take a priviledged program to do the evil deed, given the impact on the rest of the system. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
On Thu, Dec 05, 2002 at 01:58:24AM -0800, Terry Lambert wrote: Stijn Hoop wrote: I'd argue it isn't flawed for the measuring it is supposed to do - namely the overhead for the various _sleep functions. Care to tell me why it is flawed according to you? Because it measures the API one way, but the code uses it another. The results you get are not predictive of the code that you are going to be running. But the code is going to use the _sleep functions as used in the benchmark -- to sleep for less than 10 ms (which evidently makes no sense on a default FreeBSD system, as pointed out by the results). Well, really, something that requires RT performance should be in the kernel. That's why we put interrupt handlers there. 8-). /me ponders having an option XMAME in the kernel nah, lets not go there :) Probably the place to do this is in the POSIX RT scheduling; if the RT scheduling is active (meaning a process has called it, and that process is still running), it's probably a reasonable thing to crank up the Hz. This would make it self-adjusting, and also self-healing, so that you could safely degrade the overall system performance by intentionally running your application, but not otherwise. That's a good suggestion, but how many OSs implement those? Where can I learn more about them? Any open standards? Note that if this were implemented, it would mean your benchmark is still broken, because it doesn't call the necessary interfaces. ? I don't get this. Another alternative would be a nanosleep call with an argument below a certain value. I would hesitate to do it that way, though, since I think that it ought to take a priviledged program to do the evil deed, given the impact on the rest of the system. And that would sleep less than 10ms on average? --Stijn -- SIGSIG -- signature too long (core dumped) msg38502/pgp0.pgp Description: PGP signature
Re: maxusers and random system freezes
On Wed, 4 Dec 2002, Terry Lambert wrote: grep -B 7 KVA_ /sys/i386/conf/LINT -- Terry Thanks a lot Terry, and will you please correct me if I'm wrong, so I don't mess anything up on a production server? The kernel option in question is KVA_PAGES, correct? Because it's not defined in the custom server's kernel then it's value default to 256 (FreeBSD 4.5-STABLE), which makes the KVA space to occupy 1G. Then if I make KVA_PAGES=512 (KVA space 2G), will it solve the problem for this particular server having 4G of phisical memory, or must KVA_PAGES be 768 (KVA space 3G)? Have some other options to be tuned besides KVA_PAGES? Thanks again Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: maxusers and random system freezes
Varshavchick Alexander wrote: On Wed, 4 Dec 2002, Terry Lambert wrote: grep -B 7 KVA_ /sys/i386/conf/LINT Thanks a lot Terry, and will you please correct me if I'm wrong, so I don't mess anything up on a production server? The kernel option in question is KVA_PAGES, correct? Yes. Because it's not defined in the custom server's kernel then it's value default to 256 (FreeBSD 4.5-STABLE), which makes the KVA space to occupy 1G. Then if I make KVA_PAGES=512 (KVA space 2G), will it solve the problem for this particular server having 4G of phisical memory, or must KVA_PAGES be 768 (KVA space 3G)? Have some other options to be tuned besides KVA_PAGES? IMO, KVA need to be more than half of physical memory. But I tend to use a lot of mbufs and mbuf clusters in products I work on lately (mostly networking stuff). If you don't tune kernel memory usage up, then you may be able to get away with 2G. So: 2G might be OK, 3G would be more certain, given you are cranking some things up, in the config you posted, that make me think you will be eating more physical memory. If you follow the 1.5 rule, then you will have 6G of swap when you have 4G of physical RAM, and will definitely need to go for 3G of KVA space. Note, though: all space you add to KVA is subtracted from the process address space, so if you need big processes, sometimes you are better off with less physical RAM, and a larger user virtual address space. For other tuning information, see also man tuning. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
Stijn Hoop wrote: Because it measures the API one way, but the code uses it another. The results you get are not predictive of the code that you are going to be running. But the code is going to use the _sleep functions as used in the benchmark -- to sleep for less than 10 ms (which evidently makes no sense on a default FreeBSD system, as pointed out by the results). Actually, the way it was stated, it's my impression that it's dealing with frame rate, and only sleeping to add intentional delays. This matches closely what I did with the select timeout in my own games. In practice, unless the player was doing nothing, then the timer did not have an opportunity to fire, since the player provided input before the timer ended up firing, which made the select come true. Well, really, something that requires RT performance should be in the kernel. That's why we put interrupt handlers there. 8-). /me ponders having an option XMAME in the kernel nah, lets not go there :) In terms of the video driver requirements, when the video driver is used in certain modes. Also in terms of display rate for queued frames to a video driver: the driver ould be set to display at a steady 10 FPS, for example, and would do so, from queued data from user space, come hell or high water. Probably the place to do this is in the POSIX RT scheduling; if the RT scheduling is active (meaning a process has called it, and that process is still running), it's probably a reasonable thing to crank up the Hz. This would make it self-adjusting, and also self-healing, so that you could safely degrade the overall system performance by intentionally running your application, but not otherwise. That's a good suggestion, but how many OSs implement those? Where can I learn more about them? Any open standards? Most modern OS's implement them. In FreeBSD, there's rtprio, and there's a kernel module to implement POSIX RT Scheduling (it was discussed just the other day on the -current mailing list, when someone was getting an ENOSYS because they had not loaded the module). You can also man -k scheduling. You are looking for system scope scheduling priority. Note that if this were implemented, it would mean your benchmark is still broken, because it doesn't call the necessary interfaces. ? I don't get this. Does your benchmark make the call to the POSIX RT scheduling? If it doesn't, then the Hz would not magically bump itself up for the duration of the program. Another alternative would be a nanosleep call with an argument below a certain value. I would hesitate to do it that way, though, since I think that it ought to take a priviledged program to do the evil deed, given the impact on the rest of the system. And that would sleep less than 10ms on average? Either way you implemented it, it would dynamically adjust the Hz. If you are serious about implementing this, you will have to go through the kernel, and everywhere times are stored in ticks, multiply the stored value by the new multiplier divided by the old multiplier. That would be a lot of work. If you do this, my suggestion would be to implement two new types for this type of data: tick_t For a fixed tick rate at boot Hz hardtick_t For an adjusted Hz tick rate ...and then convert all tick fields to use one of these types, preferrably tick_t (or clock values instead of ticks, if possible), and only use hardtick_t where absolutely necessary. You would also ensure that the adjusted Hz was some integer multiple of the boot Hz. Then every adjusted_Hz/ boot_Hz ticks of the adjusted clock, you make a soft tick to handle tick_t's. You still get the interrupt overhead, including the softintr overhead (which can be considerable), but you only end up paying the price when you absolutely have to do it. The conversion of tick fields to a tick_t type (at the very least) is long, long overdue. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: maxusers and random system freezes
On Thu, 5 Dec 2002, Terry Lambert wrote: ... Because it's not defined in the custom server's kernel then it's value default to 256 (FreeBSD 4.5-STABLE), which makes the KVA space to occupy 1G. Then if I make KVA_PAGES=512 (KVA space 2G), will it solve the problem for this particular server having 4G of phisical memory, or must KVA_PAGES be 768 (KVA space 3G)? Have some other options to be tuned besides KVA_PAGES? IMO, KVA need to be more than half of physical memory. But I tend to use a lot of mbufs and mbuf clusters in products I work on lately (mostly networking stuff). If you don't tune kernel memory usage up, then you may be able to get away with 2G. So: 2G might be OK, 3G would be more certain, given you are cranking some things up, in the config you posted, that make me think you will be eating more physical memory. Are you talking primarily about SHMMAXPGS=262144 option here? Then may be it'll be oevrall better to reduce it and make KVA space 2G, to leave more room for user address space? You see, there cannot be any much possibility to make experiments with this server, so I very much relay on your advices, thank you again. If you follow the 1.5 rule, then you will have 6G of swap when you have 4G of physical RAM, and will definitely need to go for 3G of KVA space. No, the swap is very slightly used on this server, and the total swap size is 2G. Note, though: all space you add to KVA is subtracted from the process address space, so if you need big processes, sometimes you are better off with less physical RAM, and a larger user virtual address space. For other tuning information, see also man tuning. Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: maxusers and random system freezes
Varshavchick Alexander wrote: So: 2G might be OK, 3G would be more certain, given you are cranking some things up, in the config you posted, that make me think you will be eating more physical memory. Are you talking primarily about SHMMAXPGS=262144 option here? Then may be it'll be oevrall better to reduce it and make KVA space 2G, to leave more room for user address space? That's the one I was referring to, yes, but you didn't post your whole config (please do *NOT* post it; I can't spend the time on going over it line by line). Tuning is a skill; it can be plotted out as a cookbook recipe, but it takes a lot of work to do that, and no one has volunteered. Basically, to write out a cookbook, you have to know where every byte of memory is going in the kernel, and what tunables impact each other, and how they are related. Once you know that, you could easily write a program to kick out a configuration file for various usages, or even modify the code to auto-tune itself (everything by KVA space, which impacts the base address that the kernel gets linked to... unless you compile the entire kernel PIC, which I do not recommend). But knowing the information is hard. I know it for 4.3 and 4.4. You see, there cannot be any much possibility to make experiments with this server, so I very much relay on your advices, thank you again. If you are having system freeses at random, and you want to fix them instead of living with them, some experimentation is going to be inevitable. I don't know enough about your installation to be able to give you a kernel config file to use that will magically fix all your current issues for you, and prevent future issues from coming up. That's going to have to be up to you. If you follow the 1.5 rule, then you will have 6G of swap when you have 4G of physical RAM, and will definitely need to go for 3G of KVA space. No, the swap is very slightly used on this server, and the total swap size is 2G. It doesn't matter. The amount of swap the kernel allocates page tables for is based on the amount of physical RAM in the machine. You pay for the page tables whether you use them or not, for swap, for the kernel, and for any memory which you permit to be allocated at interrupt time, plus any allocations that occur after you are up and running, until you run out of physical RAM. This is one of those things you just have to know about how the kernel uses virtual memory, if you are going to be a skilled kernel tuner. As a rule, swap should be at least physical memory size + 64K on any system that you need to be able to get a system dump from, since it needs to dump physical RAM. If you are not worried about the machine falling over, then you can ignore that. Note that man tuning suggests 2* physical RAM for swap. PS: I am going to be out of touch (able to download, but not send email) for the next couple of days... up to a week. If you have more questions, and they can't wait, you will need to ask someone else. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: maxusers and random system freezes
Thus spake Terry Lambert [EMAIL PROTECTED]: As a rule, swap should be at least physical memory size + 64K on any system that you need to be able to get a system dump from, since it needs to dump physical RAM. If you are not worried about the machine falling over, then you can ignore that. IIRC, the extra 64K are not required anymore for core dumps. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: maxusers and random system freezes
On Thu, 5 Dec 2002, Terry Lambert wrote: IMO, KVA need to be more than half of physical memory. But I tend to use a lot of mbufs and mbuf clusters in products I work on lately (mostly networking stuff). If you don't tune kernel memory usage up, then you may be able to get away with 2G. A question arises. The value 256 (1G KVA space) acts as a default for any system installation, not depending of real phisical memory size. So for any server with RAM less than 2G (which is a majority I presume) the KVA space occupies more than half of physical memory. It can even be more than TOTAL phisical memory for servers with RAM less than 1G. Isn't it bad for a system? It seems that it is not. Then why cannot the KVA space always be made as some big value? If it is important for servers with large RAM, why it is not or a smaller servers? Can anybody besides Terry which seems to be unavailable now help? Regards Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: maxusers and random system freezes
Thus spake Varshavchick Alexander [EMAIL PROTECTED]: A question arises. The value 256 (1G KVA space) acts as a default for any system installation, not depending of real phisical memory size. So for any server with RAM less than 2G (which is a majority I presume) the KVA space occupies more than half of physical memory. It can even be more than TOTAL phisical memory for servers with RAM less than 1G. Isn't it bad for a system? It seems that it is not. Then why cannot the KVA space always be made as some big value? If it is important for servers with large RAM, why it is not or a smaller servers? In FreeBSD, each process has a unique 4G virtual address space associated with it. Not every virtual page in every address space has to be associated with real memory. Most pages can be pushed out to disk when there isn't enough free RAM, and unallocated parts of the virtual address space aren't backed by anything. (Referencing an unmapped page that the system doesn't know about generally causes the program or OS to crash. You've probably seen these as ``segmentation faults'' and ``page fault in kernel mode'' panics.) To simplify things, the kernel is mapped into a fixed location in every address space. The KVA parameter controls how big a chunk the kernel gets; the remainder goes to user processes. However, only the part of the KVA reservation that the kernel actually uses is wired to physical memory. For example, if you have a 1 GB KVA reservation and the kernel allocates only 20 MB of RAM, then only 20 MB of RAM is needed (plus some epsilon if you want to be picky), but in theory, the kernel could allocate and manage up to 1 GB of data. You don't lose extra physical memory for increasing KVA, but a large KVA size does constrain the virtual address space available to user processes. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: maxusers and random system freezes
On Thu, 5 Dec 2002, Varshavchick Alexander wrote: On Thu, 5 Dec 2002, Terry Lambert wrote: IMO, KVA need to be more than half of physical memory. But I tend to use a lot of mbufs and mbuf clusters in products I work on lately (mostly networking stuff). If you don't tune kernel memory usage up, then you may be able to get away with 2G. A question arises. The value 256 (1G KVA space) acts as a default for any system installation, not depending of real phisical memory size. So for any server with RAM less than 2G (which is a majority I presume) the KVA space occupies more than half of physical memory. It can even be more than TOTAL phisical memory for servers with RAM less than 1G. Isn't it bad for a system? It seems that it is not. Then why cannot the KVA space always be made as some big value? If it is important for servers with large RAM, why it is not or a smaller servers? Can anybody besides Terry which seems to be unavailable now help? It controls the split between virtual address space, not allocation of physical memory. If KVA is turned up to 3GB (say) then userland virtual address space for all processes is limited to 1GB (each). For Terry's stuff (networking, mostly, and probably mostly in the kernel anyway) this is beneficial. For (to pick an example at random) anyone running java* or other large userland processes, having only 1GB of elbow-space (physical or virtual) is often not sufficient. jan * You've plenty of resources and an infinite number of threads are bound to make fair progress seem to be a summation of the java way :-) -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ Work #90: As many pseudo-intellectual sycophants as necessary to make one inarticulate scotsman think he's a genius in command of The Profound. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: maxusers and random system freezes
On Thu, 5 Dec 2002, David Schultz wrote: In FreeBSD, each process has a unique 4G virtual address space associated with it. Not every virtual page in every address space has to be associated with real memory. Most pages can be pushed out to disk when there isn't enough free RAM, and unallocated parts of the virtual address space aren't backed by anything. (Referencing an unmapped page that the system doesn't know about generally causes the program or OS to crash. You've probably seen these as ``segmentation faults'' and ``page fault in kernel mode'' panics.) To simplify things, the kernel is mapped into a fixed location in every address space. The KVA parameter controls how big a chunk the kernel gets; the remainder goes to user processes. However, only the part of the KVA reservation that the kernel actually uses is wired to physical memory. For example, if you have a 1 GB KVA reservation and the kernel allocates only 20 MB of RAM, then only 20 MB of RAM is needed (plus some epsilon if you want to be picky), but in theory, the kernel could allocate and manage up to 1 GB of data. You don't lose extra physical memory for increasing KVA, but a large KVA size does constrain the virtual address space available to user processes. Thank you David for such an excellent explanation. So if sysctl reports vm.zone_kmem_pages: 5413 vm.zone_kmem_kvaspace: 218808320 vm.kvm_size: 1065353216 vm.kvm_free: 58720256 does it mean that total KVA reservation is 1065353216 bytes (1G) and almost all of it is really mapped to physical memory because only 58720256 (56M) is free, and the server is balancing on the edge of crashing with KVA going out? Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
nvclock0.6 port
Hi, I'm working on porting nvclock (the nvidia video card overclocking util), and I've got it working now. However, I don't have it clean enough to submit a port yet, but I wanted people to test the binaries I have (for -STABLE, the gtk binary requires gtk2 and both binaries require libgnugetopt). I'm putting the binaries up at http://wam.umd.edu/~culverk/nvclockbins.tar.gz Thanks... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Automount from a Solaris NIS/NFS server?
Tiarnan O'Corrain wrote: I'm running FreeBSD 4.7-STABLE and have managed (after some difficulty), to get it to bind to a Solaris NIS server we have here. All NIS users can log on now, but I can't figure out how to get home directories automounted when users do log in. I tried a couple of things on the web, an awk script to transform the Solaris auto.home, to amd syntax, and it seems to work fine, except that no home directories are mounted when NIS users log in. We use the script approach at ISI (http://www.isi.edu/larse/etc/rc.d/isiconfig), and it works fine. Hoperfully the script will give you some ideas that'll apply to your configuration. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: maxusers and random system freezes
--- Terry Lambert [EMAIL PROTECTED] wrote: Marc Recht wrote: Every now and this I hear people saying (mostly you :)) that some problems are KVA related or that the KVA must be increased. This makes me a bit curious, since I've never seen problems like that on Linux. It sounds for me, the not kernel hacker, a bit like something which should be set at boot time (or via sysctl). Have you got some pointers which explain FreeBSD's KVA ? As far as I know, Linux maps all the memory in the machine into the kernel address space, so there is never a problem of it running out while there is free memory (if you run out of it, there isn't any at all left in the machine). It also permits the kernel to directly modify processes' address spaces??? I have written documentation for FreeBSD 4.3/4.4. Unfortunately, everyone keeps substituting activity for action, and hacking away at the code, so it doesn't sit still long enough to match any useful documentation; otherwise, I would have published what I wrote in Pentad Embedded Systems Journal already (example: the KVA_PAGES stuff came in after FreeBSD 4.3/4.4, and blew out two paragraphs on what to modify where, and how to calculate the values to use). The best documentation is probably Matt Dillon's article in Daemon News, the FreeBSD Developer's handbook, or the German guy's article in English (sorry for not remembering your name), depending on what part of things you are interested in. If you could get people to leave the damn code alone for a while, I'd be willing to update my article to FreeBSD RELENG_4 (-STABLE), and publish it. One of the major problems with undocumented code is that weenies are unwilling to sit down and understand it, so they rewrite it to understand it, instead, and then you are still without documentation. Documentation that's almost right is unbelievably worse than no documentation at all. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message __ Post your free ad now! http://personals.yahoo.ca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tcp_usrreq bug ??
On Tue, 3 Dec 2002, Aniruddha Bohra wrote: Hello The following code snippet is from netinet/tcp_usrreq.c As in the comment (and presumably correct behaviour) a RST should be sent on close if the connection is embryonic. However, if (tp-t_state TCPS_ESTABLISHED) tp = tcp_close(tp); does not do it. One can imagine a scenario when a client would just do a connect() and close() and an overloaded server would have its listen queue crowded by connections that were not synchronized but closed. I have seen this happen in my lab test, where I use httperf to measure Apache webserver throughput. There are several listen queue overflows and resets. The interesting part is that the client _NEVER_ has more than 3200 open descriptors yet a queue of 4096 on the server gets filled up. Is there a reason for not sending a RST or is it a bug? Please help. Thanks Aniruddha I took a quick look, and I agree that the comment doesn't seem to match reality. Looking back, it appears that the code/comment have been exactly the same since FreeBSD 2, back in 1994. Note that I haven't actually doublechecked this with tcpdump, so my comments are based off of what you stated... There are two sides to examine this problem from: The server side, and the client side. Server side: Getting flooded with SYN packets is an unfortunate reality that all OSes must deal with these days. Even if you're using a pre-syncache version of FreeBSD, you shouldn't be seeing too many problems due to listen queue overflows. If performance is terrible, you may consider moving to FreeBSD 4.7, or doing further examination to determine if listen queue overflows are really hurting you. Client side: #1 - Why is your benchmark program terminating connections before they finish connecting? #2 - I've been thinking about how FreBSD should handle the situation where a connection is closed before it has become established, and I think that silently dropping the connection is best. Here's why: Normal usage, single connection closed like this: Client receives syn-ack packet, responds with reset. Had a reset been preemptively sent, it would have crossed with the syn-ack on the wire, and two syn-acks would be sent. Either way, the connection gets reset. Flooded server, single connection closed: Same as above; preemptive reset wastes bandwidth. Client used to perform a synflood: Again, same as above. If a reset was sent, you'd double the PPS the server was flooded with. That being said, I don't think that a connect/close pair would be used for a synflood. Such a flood would be easily blockable and tracable with extreme ease. Note that FreeBSD's rst rate limiting would limit the number of connections / second that would be reset, but the server's built-in anti-syn flood countermeasures should do fine. Hence, I'm not sure that we can do anything better than what we are doing now. Once the 5.0 codefreeze is over, I'll go in and take out the misleading comment. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Automount from a Solaris NIS/NFS server?
Tiarnan O'Corrain wrote:
I'm running FreeBSD 4.7-STABLE and have managed
(after some difficulty), to get it to bind to a Solaris
NIS server we have here. All NIS users can log on
now, but I can't figure out how to get home
directories automounted when users do log in.
I tried a couple of things on the web, an awk
script to transform the Solaris auto.home, to
amd syntax, and it seems to work fine, except that
no home directories are mounted when NIS users
log in.
We use the script approach at ISI
(http://www.isi.edu/larse/etc/rc.d/isiconfig), and it works fine.
Hoperfully the script will give you some ideas that'll apply to your
configuration.
Lars
--
Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute.
My docs on doing this (dont abuse my awk!! - it only has to run once a day!):
The BSD automounter AMD can use NIS tables.
However the table format is different from the more commonly used automounter autofs.
My example below is to automount home directories as per auto_home with autofs.
The example assumes the server svr is a NIS+ server in NIS compatibility.
In order to use AMD for this purpose, translation of auto_home into the AMD format
is required.
To do this translation:
1) Create a new NIS+ table on the NIS+ server with format as follows:
svr: {1017} niscat -o amd_home.org_dir
Object Name : amd_home
Directory : org_dir.unix.dsto.
Owner : svr.unix.dsto.
Group : admin.unix.dsto.
Access Rights : r---rmcdrmcdr---
Time to Live : 12:0:0
Creation Time : Thu Sep 26 14:32:32 2002
Mod. Time : Thu Sep 26 14:32:32 2002
Object Type : TABLE
Table Type : key-value
Number of Columns : 2
Character Separator :
Search Path :
Columns :
[0] Name : key
Attributes: (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE)
Access Rights :
[1] Name : value
Attributes: (TEXTUAL DATA)
Access Rights :
2) Create a translation script on the NIS+ server with content as follows (in this
example the script is /export/data/cis/nisplus/server-setup/generate_amd_home.sh:
#!/bin/sh
temp_file=/tmp/temp_file$$
/usr/bin/niscat auto_home.org_dir | awk '{split($2,a,:); str=; x=1; while
(x=length(a[2])) {y=substr(a[2],x,1); if(y==) {str=str $1} else {str=str y};
x=x+1}; print $1,host==a[1];type:=link;fs:=str ||
rhost:=a[1];type:=nfs;rfs:=str;sublink:=.}' $temp_file
/usr/lib/nis/nisaddent -r -f $temp_file -t amd_home.org_dir.unix.dsto. key-value
rm $temp_file
3) Ensure the translation script runs once a day by creating a root cron job as
follows:
# Generate amd_home.org_dir from auto_home.org_dir for users of AMD
15 4 * * * [ -x /export/data/cis/nisplus/server-setup/generate_amd_home.sh ]
/export/data/cis/nisplus/server-setup/generate_amd_home.sh
A 'more correct' approach would be to use the script feature of Solstice so that when
new users are added the amd_home table gets updated.
With the above approach, new users cannot log onto AMD utilising clients until after
4:15am the next day.
Configuration for AMD on the client machines is as follows (this example for a
FreeBSD client):
1) Start with the commandline:
amd -F /etc/amd.conf(This is the default location of the config file so just amd
will do)
2) Create /etc/amd.conf with content as follows:
[global]
map_options = opts:=intr,rsize=8192,wsize=8192
mount_type = nfs
auto_dir = /.tmp_mnt
cache_duration = 300
log_file = syslog
restart_mounts = yes
unmount_on_exit = no
[/net]
map_name = /etc/amd.map
[/home]
map_name = amd.home
map_type = nis
3) Create /etc/amd.map with content as follows:
/defaults type:=host;fs:=${autodir}/${rhost}/host;rhost:=${key}
* opts:=rw,grpid,resvport,vers=3,proto=udp,nosuid,nodev
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: maxusers and random system freezes
Thus spake Gary Thorpe [EMAIL PROTECTED]: As far as I know, Linux maps all the memory in the machine into the kernel address space, so there is never a problem of it running out while there is free memory (if you run out of it, there isn't any at all left in the machine). It also permits the kernel to directly modify processes' address spaces??? Linux used to do that, but AFAIK it doesn't anymore. Mapping all of physical memory into KVA simplifies copyin() and copyout(), but it restricts the amount of usable physical memory to well under 4GB. They couldn't possibly have kept doing things this way when they added support for all of the bank switching crap on i386. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
One GNU ASM syntax problem
Hi,everybody, I have one question about GNU ASM syntax. As I know: __asm __volatile( instructions :output :input :exception); In Linux, the restriction of output are =m,=a, etc. But I found in FreeBSD, there are =m and +m. I do not know the difference between + and =. why? Thank you! Best Regards Ouyang Kai _ ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: One GNU ASM syntax problem
I do not know the difference between + and =. why? Thank you, I got it from 'info gcc'. It is the reason that Extended asm supports input-output or read-write operands. Use the constraint character `+' to indicate such an operand and list it with the output operands.. Best Regards Ouyang Kai _ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: One GNU ASM syntax problem
kai ouyang wrote: I do not know the difference between + and =. why? Thank you, I got it from 'info gcc'. It is the reason that Extended asm supports input-output or read-write operands. Use the constraint character `+' to indicate such an operand and list it with the output operands.. Also be aware that different versions of gcc treat this differently. We use gcc-2.95 on FreeBSD 4.x and gcc-3.2.1 on FreeBSD 5.x. Those versions are much more sensitive and have stricter requirements than gcc-2.8 and earlier. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: maxusers and random system freezes
On Thu, 5 Dec 2002, David Schultz wrote: Linux used to do that, but AFAIK it doesn't anymore. Linux puts kvm at 0xc000, kernel at physical 0x10, etc. There was a time when you could address all of physical memory just by direct-mapping the PTEs, since base of 0xc000 means KVM space of 0x4000. Those days are gone. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: maxusers and random system freezes
Ronald G. Minnich wrote: On Thu, 5 Dec 2002, David Schultz wrote: Linux used to do that, but AFAIK it doesn't anymore. Linux puts kvm at 0xc000, kernel at physical 0x10, etc. There was a time when you could address all of physical memory just by direct-mapping the PTEs, since base of 0xc000 means KVM space of 0x4000. Those days are gone. Sort-of. They now use a milti-tiered memory pool system. The first block is direct mapped in using 4MB pages. That works out to something like 930MB or so. The balance (they have a 1GB KVA space too) is pageable to allow the kernel to access memory outside of the first 930MB (or whatever the exact amount is). What linux does that I find interesting is that they agressively *move* user pages in order to get best use of that 930MB pool. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
One Filesystem vnode operations declare problem.
Hi, everybody, I have some questions about FS vnode operations. I found the filesystems always declare vnode operations by VNODEOP_SET more than once. For example: In DEVFS: VNODEOP_SET(devfs_vnodeop_opv_desc); VNODEOP_SET(devfs_specop_opv_desc); In FFS: VNODEOP_SET(ffs_vnodeop_opv_desc); VNODEOP_SET(ffs_specop_opv_desc); VNODEOP_SET(ffs_fifoop_opv_desc); Why? Why can not the kerenel use only devfs_vnodeop_opv_desc or ffs_vnodeop_opv_desc? Another words, I want to know the difference among those VNODEOP_SET in one filesystem. Thank you! Best Regards Ouyang Kai _ Ãâ·ÑÏÂÔØ MSN Explorer: http://explorer.msn.com/lccn/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: One Filesystem vnode operations declare problem.
kai ouyang wrote: Hi, everybody, I have some questions about FS vnode operations. I found the filesystems always declare vnode operations by VNODEOP_SET more than once. For example: In DEVFS: VNODEOP_SET(devfs_vnodeop_opv_desc); VNODEOP_SET(devfs_specop_opv_desc); In FFS: VNODEOP_SET(ffs_vnodeop_opv_desc); VNODEOP_SET(ffs_specop_opv_desc); VNODEOP_SET(ffs_fifoop_opv_desc); Why? Why can not the kerenel use only devfs_vnodeop_opv_desc or ffs_vnodeop_opv_desc? Another words, I want to know the difference among those VNODEOP_SET in one filesystem. The name of the macro is a little strange, that is more of a historical relic where we used to declare these things in something called a 'linker set'. These days it is handled by a SYSINIT() function that registers the vnode ops. Our vnode op system is fully dynamic. We can create new VOP_xxx() functions on the fly. But for this to work, they need to be registered and assigned an index number in the system vectors. The act of referencing a foo vector in the xxx_opv_desc table adds support for a VOP_FOO(). For example, suppose we have some remote file system loadable module that supports remote file copies. That filesystem could introduce VOP_COPYFILE() that would cause the file to be copied on the server, rather than the source file being read by the client and then copied back to the new file. We could then load another module that adds a copyfile(2) syscall that calls VOP_COPYFILE(). And because of the vnode stacking system and the VOP_DEFAULT() vectors, we could even mount union fs's over the top of this hypothetical file system, even though at the time that unionfs was compiled there was no VOP_COPYFILE operation to pass down the stack. Quite a while ago, the kernel used to have a static list of supported VOP_* calls. This has not been the case for quite some time now. Any file system can create any VOP_* that it likes. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: maxusers and random system freezes
On Wed, 4 Dec 2002, Terry Lambert wrote: Marc Recht wrote: Every now and this I hear people saying (mostly you :)) that some problems are KVA related or that the KVA must be increased. This makes me a bit curious, since I've never seen problems like that on Linux. It sounds for me, the not kernel hacker, a bit like something which should be set at boot time (or via sysctl). Have you got some pointers which explain FreeBSD's KVA ? I have written documentation for FreeBSD 4.3/4.4. Unfortunately, everyone keeps substituting activity for action, and hacking away at the code, so it doesn't sit still long enough to match any useful documentation; otherwise, I would have published what I wrote in Pentad Embedded Systems Journal already (example: the ^^^ I appreciate some of the info you give. But every time you reference a proper noun (person, journal, etc.), Google only gives results of you talking about it in FreeBSD list archives! See also freebsd mitre netbeui What kind of conclusion is one to draw from that? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Financial freedom in 24 days or less
Hello, Would you like to make $100,000 a year online? If so, then this is your magical email to the kingdom of financial freedom. Think about how life would be WITHOUT an alarm clock waking you up every morning. Or sitting in traffic all morning. Are you frustrated that you belong to the corporate world? IMAGINE your daily commute taking 20 seconds as you walk to your computer! Is this just a dream? Many people think so but they are ABSOLUTELY WRONG. Financial freedom is given to people who jump at the opportunity, not to those who hesitate. 2 years ago I was just like you, I was making $12 an hour working my butt off struggling to pay my bills. One day, a friend of mine introduced me to the GREATEST business ever created online. Within 6 months of working just an hour a day, I was able to quit my full time job and leave the corporate world FOREVER. Now I would like to share this opportunity with you. It is MY DUTY to help you get to the places you dream about, and I'm about to do just that. Normally, there is a $29.99 charge associated with joining this business. But for the next 48 hours, you can sign up, ABSOLUTELY FREE. Even if this isn't the opportunity of a lifetime, how can you afford to pass up this chance? You have nothing to lose! No credit card required, Nothing! All you have to do is click on the link below to learn more about this AMAZING business. http://www.product-galore.com/affiliate.htm Thank you and have a great day! Dan Meadows Jr. 0863al5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
