Re: VM: dynamic swap remapping (patch)
: Second, application not always grows to 1G, most of the time it keeps : as small as 500M ;). Why should we precommit 1G for 500M data? Doing : multi-mmap memory management is additional pain. Why not? Disk space is cheap. For a problem like this I would simply throw in two 30G+ hard drives and partition them with 16G of swap each, giving me 32G of swap for the machine. If you needed to do it cheaply you could even use IDE, though personally I would use SCSI for reliability. Depending on the amount of real memory in the machine you might have to tweek a few kernel options (like matching NSWAP to the actual number of swap devices), but basically it should just work. Even using file-backed memory is fairly trivial. You don't need to do multi-mmap memory management or do any kernel tweaking. Just reserve 1G and use a single mmap() and file per process. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
ehlo. > My suggestion, (but not my final say, i'm still open to ideas): > >Implement a memory status signal to notify processes of changes >in the relative amount of system memory. > >When memory reaches a low or high watermark, the signal is >broadcast to all running processes. > >The default disposition will be to ignore the signal. > >The signal will be named SIGMEMINFO. (SIGXfoo means >'process has exceeded resource foo') Agreed. As for SIG_IGN, can anyone tell me -- can I force existing application to use my signal handler? For example, by preallocating some shared library? If so, there are no contras for ignoring signal by default. >The signal will pass via the siginfo struct information >such that the process can determine if the system has >just exceeded the low watermark (danger) or has reclaimed >down to the high watermark (enough free memory). Passing more info is always better. Agreed. > a) over allocate swap a bit and set the low watermark carefully. > b) do the following enhancement: > > Provide a system whereby you can swap to the filesystem without > additional upcalls/syscalls from userspace, basically, provide > some means of paging to the filesystem automatically. > > then, set your lowwater mark to the size of your swap partition, > now your system will alert your processes and automatically swap > _anyone_ to the filesystem. > > I really think that this would be more flexible and still allow > you to achieve what you want... What do you think? I can't say anything until I'll got detail. Sorry, English is neither my native nor used often, so I may easely miss important details, but here is my random comments: Initally, I was trying the same (I think) approach, but there was some problems. Some kernel function refused to work with VM objects of processes differing from curproc. I.e., it could be hard to work with bigproc inside swap daemon; and swap daemon is the only place where we can detect OOM condition; that's why I used signal to transfer control to user space, and then back into kernel -- already in another process. Another reason to do it -- to make all limits and quota work automatically. Also, I did not wanted to make swap daemon busy too long. Also, what means "over allocate swap a bit"? How to compute the value of that bit? At what moment should we preallocate? Should we repeat preallocation after getting SIGMEMINFO (himark)? Also, you cannot set low mark to size of swap partition. To create file-based swap you need some memory (file operations requires it). So, low mark should be a bit lower (that's why I raised value of nswap_lowat). Finally, if you want to over allocate swap for every process in system, the whole swap can wind up consisting of only preallocations. Resource management is the role of kernel. Any hard reservation interfere with that. -- dozen @ home To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
* Matt Dillon <[EMAIL PROTECTED]> [010930 02:53] wrote: > > : Second, application not always grows to 1G, most of the time it keeps > : as small as 500M ;). Why should we precommit 1G for 500M data? Doing > : multi-mmap memory management is additional pain. > > Why not? Disk space is cheap. For a problem like this I would simply > throw in two 30G+ hard drives and partition them with 16G of swap each, > giving me 32G of swap for the machine. If you needed to do it cheaply > you could even use IDE, though personally I would use SCSI for > reliability. Depending on the amount of real memory in the machine > you might have to tweek a few kernel options (like matching NSWAP to > the actual number of swap devices), but basically it should just work. > > Even using file-backed memory is fairly trivial. You don't need to > do multi-mmap memory management or do any kernel tweaking. Just > reserve 1G and use a single mmap() and file per process. What he needs is a system to inform him that things aren't looking so good, check my email for what I think is a pretty good solution. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
uvcx ¥ß§YÀ°±zºô¸ô¶}©±Àç·~!! lxlu
Title: ¥ß§YÀ°±zºô¸ô¶}©±Àç·~°µ¥Í·N!! dnjymxjjocxnu ¥ß§YÀ°±zºô¸ô¶}©±Àç·~°µ¥Í·N!! 2¤p®É§Ö³tºô¶»s§@¤Îקï!! ºô¶»s§@¶W§C»ù¥unNT800¤¸. §K¶Oºô§}!!ºô¯¸¤º®e¥i¤À:¤½¥q²¤¶. ²£«~¤¶²Ð. ²£«~¬Û¤ù. «È¤á¯d¨¥ªO. ©wÁʪí³æ. ±m¦â°Êµeµ¥µ¥¦³·NªÌÅwªï¬¢½Í!! ¥»³B´£¨Ñ°Ó®a¹ê¨Ò§@«~®i¥Ü: ½Ð¨Ómail¯Á¨ú!! §¹¦¨ºô¶»s§@. ¥ß§Yª¾·|±zªº§K¶Oºô§}. ¦p http://98.to/±zªº©R¦W(¤¤^¤Î¼Æ¦r¬Ò¥i) ¡@ºô¶»s§@©Îקï¯d¨¥ Ápµ¸©m¦W Ápµ¸¹q¸Ü ¤½¥q¦WºÙ ¹q¤l«H½c ¹w¦ôºô¶¼Æ¶q 5¶¥H¤U 5¶-10¶ 10¶¥H¤W ¤£ª¾¹D ¥Ø«eºô§}µL ¦³ ·PÁ±zªº¯d¨¥!!§ÚÌ·|¾¨§Ö»P±zÁpµ¸!! kyehnbecoxqnc
Re: VM: dynamic swap remapping (patch)
In message <[EMAIL PROTECTED]>, Matt Dillon writes: >: Second, application not always grows to 1G, most of the time it keeps >: as small as 500M ;). Why should we precommit 1G for 500M data? Doing >: multi-mmap memory management is additional pain. > >Even using file-backed memory is fairly trivial. You don't need to >do multi-mmap memory management or do any kernel tweaking. Just >reserve 1G and use a single mmap() and file per process. I once had a patch to phkmalloc() which backed all malloc'ed VM with hidden files in the users homedir. It was written to put the VM usage under QUOTA control, but it had many useful side effects as well. I can't seem to find it right now, but it is trivial to do: just replace the sbrk(2) with mmap(). Only downside is the needed filedescriptor which some shells don't like. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
* Vladimir Dozen <[EMAIL PROTECTED]> [010930 03:02] wrote: > ehlo. > > > My suggestion, (but not my final say, i'm still open to ideas): > > > >Implement a memory status signal to notify processes of changes > >in the relative amount of system memory. > > > >When memory reaches a low or high watermark, the signal is > >broadcast to all running processes. > > > >The default disposition will be to ignore the signal. > > > >The signal will be named SIGMEMINFO. (SIGXfoo means > >'process has exceeded resource foo') > > Agreed. As for SIG_IGN, can anyone tell me -- can I force > existing application to use my signal handler? For example, > by preallocating some shared library? If so, there are no > contras for ignoring signal by default. Yes, it's kind of evil, but you need to do this: make a .c file that has your signal handler and a function called _init that enables it. You also might want to export if we're in the low watermark via sysctl variable so that at startup you can set a variable to do things like make a malloc wrapper fail... compile it like so: gcc -shared -fpic -fPIC -o t2.So -c t2.c ; ld t2.So -shared -o t2.so then install it someplace, then set this in the environment: LD_PRELOAD=/path/to/where/you/put/it/t2.so All non-setuid and non-setgid programs will respect this. Now just because I told you that, doesn't mean you should run off now and use your solution, I hope you take the time to consider what I've got to say here. :) > >The signal will pass via the siginfo struct information > >such that the process can determine if the system has > >just exceeded the low watermark (danger) or has reclaimed > >down to the high watermark (enough free memory). > > Passing more info is always better. Agreed. It's just a trick so you only need one signal instead of a signal for both SIGMEMLOW (signal memory low) and SIGMEMOK (signal memory is ok, or enough is free). > > a) over allocate swap a bit and set the low watermark carefully. > > b) do the following enhancement: > > > > Provide a system whereby you can swap to the filesystem without > > additional upcalls/syscalls from userspace, basically, provide > > some means of paging to the filesystem automatically. > > > > then, set your lowwater mark to the size of your swap partition, > > now your system will alert your processes and automatically swap > > _anyone_ to the filesystem. > > > > I really think that this would be more flexible and still allow > > you to achieve what you want... What do you think? > > I can't say anything until I'll got detail. Sorry, English is neither > my native nor used often, so I may easely miss important details, but > here is my random comments: > > Initally, I was trying the same (I think) approach, but there was > some problems. Some kernel function refused to work with VM objects > of processes differing from curproc. I.e., it could be hard to work > with bigproc inside swap daemon; and swap daemon is the only place > where we can detect OOM condition; that's why I used signal to transfer > control to user space, and then back into kernel -- already in another > process. Another reason to do it -- to make all limits and quota work > automatically. Also, I did not wanted to make swap daemon busy too long. Well you can simply grab curproc to do this and steal the context, most likely you'll be in the context of a process that has faulted, the only trick you need to do is to write the file instead of directly to the device. The idea is to cause the next fault by any program to give you a 'curproc' to do filesystem operations. You could also wakeup() the swapper and set a flag to tell it to allocate some filesystem space, the problem (as you've stated) is that you can tie swapper up too long doing this. > Also, what means "over allocate swap a bit"? How to compute the value > of that bit? At what moment should we preallocate? Should we repeat > preallocation after getting SIGMEMINFO (himark)? You're still thinking of the combined solution, just think of a system where all you have right now is the signals I mentioned. Now remeber, your solution depends on spare space in the filesystem... Your spare space is most likely not known. Instead of depending on possibly non-existant spare space, just make your swap a little bigger and set your low watermark a bit lower. Now you have more time to do something when memory is low. > Also, you cannot set low mark to size of swap partition. To create > file-based swap you need some memory (file operations requires it). > So, low mark should be a bit lower (that's why I raised value of > nswap_lowat). Yes, you're right, I didn't consider this. You can start swapping to the filesystem at an earlier point then. > Finally, if you want to over allocate swap for every process in > system, the whole swap can wind up consisting of onl
Re: VM: dynamic swap remapping (patch)
On Sat, 29 Sep 2001, Alfred Perlstein wrote: > * Vladimir Dozen <[EMAIL PROTECTED]> [010929 14:38] wrote: > > > P.S. Anyway, I do NOT insist my solution is better, and even that it > > is good for anything at all. It was fun for me to hack in BSD kernel, > > and it was interesting challenge, and I feel need to share results > > with others. At worst, I will recommend our customer to setup > > processing farm under FreeBSD with applied patch. > > I'm really impressed with the work you put into this, but it seems > that you've tried to tackle two problems at the same time, Indeed, the whole idea of swapping tasks to the filesystem in nice, but having the task do this all by itself isn't a good option for many people... > My suggestion, (but not my final say, i'm still open to ideas): > >Implement a memory status signal to notify processes of changes >in the relative amount of system memory. > >When memory reaches a low or high watermark, the signal is >broadcast to all running processes. > >The default disposition will be to ignore the signal. > >The signal will be named SIGMEMINFO. (SIGXfoo means >'process has exceeded resource foo') That'd be SIGDANGER, right ? > b) do the following enhancement: > > Provide a system whereby you can swap to the filesystem without > additional upcalls/syscalls from userspace, basically, provide > some means of paging to the filesystem automatically. Sounds like a winner, when swap runs out a process gets suspended onto the filesystem automatically and SIGDANGER is sent out to give others a chance to clean themselves up. If enough space is freed, the suspended process can get back into the system. This should also preserve leaky applications while at the same time leaving the system intact... regards, Rik -- IA64: a worthy successor to i860. http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
ehlo. > : Second, application not always grows to 1G, most of the time it keeps > : as small as 500M ;). Why should we precommit 1G for 500M data? Doing > : multi-mmap memory management is additional pain. > > Why not? Disk space is cheap. Developer time is expensive. Someone already wrote good allocation routines, and they are inside libc. Reinventing bycicle in every new large-scale application doesn't sounds good for me. > For a problem like this I would simply > throw in two 30G+ hard drives and partition them with 16G of swap each, > giving me 32G of swap for the machine. As it was said here before, there are actually two problems: notification (avoiding silently kills) and getting more paging space. The second can be solved by adding swap space. The first -- cannot. As developer, I'm more interested in first. Current solution with killproc() is not acceptable. Just imagine any OS documentation which say: "the OS may terminate process at any point with no warning or notification". Would you like to use it? But this is exactly what FreeBSD does at OOM. > Even using file-backed memory is fairly trivial. You don't need to > do multi-mmap memory management or do any kernel tweaking. Just > reserve 1G and use a single mmap() and file per process. As I already said, it is not trivial. It involves writing/adopting some allocation stuff. It means time & human resources -> money. -- dozen @ home To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
* Rik van Riel <[EMAIL PROTECTED]> [010930 04:12] wrote: > On Sat, 29 Sep 2001, Alfred Perlstein wrote: > > * Vladimir Dozen <[EMAIL PROTECTED]> [010929 14:38] wrote: > > > > > P.S. Anyway, I do NOT insist my solution is better, and even that it > > > is good for anything at all. It was fun for me to hack in BSD kernel, > > > and it was interesting challenge, and I feel need to share results > > > with others. At worst, I will recommend our customer to setup > > > processing farm under FreeBSD with applied patch. > > > > I'm really impressed with the work you put into this, but it seems > > that you've tried to tackle two problems at the same time, > > Indeed, the whole idea of swapping tasks to the filesystem > in nice, but having the task do this all by itself isn't a > good option for many people... > > > My suggestion, (but not my final say, i'm still open to ideas): > > > >Implement a memory status signal to notify processes of changes > >in the relative amount of system memory. > > > >When memory reaches a low or high watermark, the signal is > >broadcast to all running processes. > > > >The default disposition will be to ignore the signal. > > > >The signal will be named SIGMEMINFO. (SIGXfoo means > >'process has exceeded resource foo') > > That'd be SIGDANGER, right ? Sort of. > > > b) do the following enhancement: > > > > Provide a system whereby you can swap to the filesystem without > > additional upcalls/syscalls from userspace, basically, provide > > some means of paging to the filesystem automatically. > > Sounds like a winner, when swap runs out a process gets > suspended onto the filesystem automatically and SIGDANGER > is sent out to give others a chance to clean themselves > up. Well, no, the idea is to have a low and high watermark so that flip-flopping on the boundry doesn't generate a lot of signals. SIGDANGER is ok for a name, but slightly misleading because I wanted to piggyback some info in the siginfo to tell processes when the danger has passed. Well ok, the name is ok, but I do want an upcall when the situation is alleviated. Let me also state that it may be wise to add huristics to the system to not SIGDANGER anything that is completely swapped out or hasn't run in a long time, this would avoid a spike in thrashing at the time of the broadcast. > If enough space is freed, the suspended process can get > back into the system. > > This should also preserve leaky applications while at the > same time leaving the system intact... Hopefully, also having a SIGDANGER handler may be an indication to the kernel to give you a second chance before shooting at you, I know it could be used to subvert behavior to have another niave program killed, however that could be a tunable to give those trying to do the right thing a second chance. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
ehlo. > You're still thinking of the combined solution, just think of a > system where all you have right now is the signals I mentioned. Yah, now I think I got it. Well, actually, signal(s) is all I need. The remapping was just a bonus. To be more precise, I need the only signal -- at low mark passed. Some other application might be interested in second -- hi mark -- signal, but my doesn't. SIGDANGER is the signal from Irix, AFAIR? So, how about to accept this name (just to not increase entropy of the Universe) and send it to all processes when nswap_lowat reached? The only point -- I prefer to have ability to set nswap_lowat via sysctl since I cannot predict what amount of memory can be consumed while freeing memory ;) (e.g., throwing exception in C++ may eat memory due to creating exception object; logging may eat memory also). > Just think what happens if your filesystems are full and you run > out of swap... The same that happens today -- killproc() will kill me. The situation doesn't becomes worse with remapping, it just ... mmm... prolonges. -- dozen @ home To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
* Vladimir Dozen <[EMAIL PROTECTED]> [010930 04:41] wrote: > ehlo. > > > You're still thinking of the combined solution, just think of a > > system where all you have right now is the signals I mentioned. > > Yah, now I think I got it. Well, actually, signal(s) is all > I need. The remapping was just a bonus. To be more precise, > I need the only signal -- at low mark passed. Some other > application might be interested in second -- hi mark -- > signal, but my doesn't. > > SIGDANGER is the signal from Irix, AFAIR? > > So, how about to accept this name (just to not increase entropy > of the Universe) and send it to all processes when nswap_lowat > reached? > > The only point -- I prefer to have ability to set nswap_lowat > via sysctl since I cannot predict what amount of memory can > be consumed while freeing memory ;) (e.g., throwing exception > in C++ may eat memory due to creating exception object; logging > may eat memory also). You want to submit a patch? If not I can take a look at it, but it's been a bit since I've looked at the vm system. > > > Just think what happens if your filesystems are full and you run > > out of swap... > > The same that happens today -- killproc() will kill me. > The situation doesn't becomes worse with remapping, it just > ... mmm... prolonges. > > -- > dozen @ home -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
ehlo.
> You want to submit a patch? If not I can take a look at it,
> but it's been a bit since I've looked at the vm system.
except for sysctl, the patch is quite simple due to the fact
that histeresis is already implemented in swap_pager.c, something
like:
diff vm/swap_pager.c vm.new/swap_pager.c
217a218,219
> struct proc* p;
>
218a221,225
> /* warn all processes */
> for( p = allproc.lh_first; p != 0; p = p->p_list.le_next )
> {
> psignal(p,SIGDANGER);
> }
diff sys/signal.h sys.new/signal.h
105a106,109
> #ifndef _POSIX_SOURCE
> #define SIGDANGER 32 /* close to out-of-memory */
> #endif
>
diff kern/kern_sig.c kern.new/kern_sig.c
165a166
> SA_IGNORE /* SIGDANGER */
--
dozen @ home
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
ehlo.
>
> diff vm/swap_pager.c vm.new/swap_pager.c
> 217a218,219
> > struct proc* p;
> >
> 218a221,225
> > /* warn all processes */
> > for( p = allproc.lh_first; p != 0; p = p->p_list.le_next )
> > {
> > psignal(p,SIGDANGER);
> > }
>
Oops, it doesn't work. All processes died. Why?
Something should be changed in libc?
--
dozen @ home
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
* Vladimir Dozen <[EMAIL PROTECTED]> [010930 06:16] wrote:
> ehlo.
>
> >
> > diff vm/swap_pager.c vm.new/swap_pager.c
> > 217a218,219
> > > struct proc* p;
> > >
> > 218a221,225
> > > /* warn all processes */
> > > for( p = allproc.lh_first; p != 0; p = p->p_list.le_next )
> > > {
> > > psignal(p,SIGDANGER);
> > > }
> >
>
> Oops, it doesn't work. All processes died. Why?
> Something should be changed in libc?
I'll take a look at implementing it sometime this week.
I want to do the siginfo thing if possible.
--
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
sio modification
Hello, I'm wondering about a seemingly simple sio.c modification. The problem stems from me wanting to use this dang remote control receiver, which manipulates the CD line of the serial port it plugs into. Afaik, the UART itself is capable of generating an interrupt whenever CD changes. The problem is, sio.c doesn't support this feature. I'm stuck with polling the status register to find out the state of CD. Not a very good solution for a daemon that's supposed to run in the background all the time, especially since the CD line will be toggled at about 40kHz (I think that's the remote control frequency standard). Perhaps I'm wrong about the 40kHz figure. Anyways, who is in charge of sio.c? Any change I make to it would result in the interface to sio changing, so I think I should collaborate with someone who knows what they're talking about when it comes to sio. --Bart To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
precise timing
On a totally unrelated subject to my sio.c message, I have a second problem. I've built a computer-controlled drill, that is controlled via the parallel port. This drill uses stepper motors, at 1/2 step. My driver software implements a maximum-acceleration control algorithm that ensures that at any point in time, any axis will not experience more than X m/s/s of acceleration. This keeps the drill from self-destructing. :) Unfortunately, it means I need access to a very precise timing source to issue the step instructions to the motor control board. Right now, I use for() as a timing loop. I calibrate it on program start and can then get very precise timing. There are, of course, the intermittent interruptions of the multitasker. So this solution is not ideal by any means. In fact, the for() loop approach is really meant for the DOS port of this software. I'm wondering if there is any way I can access a more precise interrupt-driven (or blocking) timing source. I know I can do a select() with supposedly microsecond accuracy, but I doubt that it is in fact that accurate in practice (doesn't the kernel only use a 100Hz clock or something?). Is there any way to get at the system timers on the motherboard? Those can provide precise timing, no? --Bart To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sio modification
In message <200109301003.06903@EO>, Bart Kus writes: > Hello, I'm wondering about a seemingly simple sio.c modification. The >problem stems from me wanting to use this dang remote control receiver, which >manipulates the CD line of the serial port it plugs into. Afaik, the UART >itself is capable of generating an interrupt whenever CD changes. The >problem is, sio.c doesn't support this feature. I'm stuck with polling the >status register to find out the state of CD. Not a very good solution for a >daemon that's supposed to run in the background all the time, especially >since the CD line will be toggled at about 40kHz (I think that's the remote >control frequency standard). Perhaps I'm wrong about the 40kHz figure. Your machine will not work too well if it is 40kHz. The PPS-API allows you to timestamp edges on DCD, if the frequency is more reasonable, that would work for you. Find RFC27xx for more info about PPS-API. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
On Sun, Sep 30, 2001 at 10:18:01AM -0500, Bart Kus wrote: > On a totally unrelated subject to my sio.c message, I have a second problem. > I've built a computer-controlled drill, that is controlled via the parallel > port. This drill uses stepper motors, at 1/2 step. My driver software > implements a maximum-acceleration control algorithm that ensures that at any > point in time, any axis will not experience more than X m/s/s of > acceleration. This keeps the drill from self-destructing. :) Unfortunately, > it means I need access to a very precise timing source to issue the step > instructions to the motor control board. > > Right now, I use for() as a timing loop. I calibrate it on program start > and can then get very precise timing. There are, of course, the intermittent > interruptions of the multitasker. So this solution is not ideal by any > means. In fact, the for() loop approach is really meant for the DOS port of > this software. I'm wondering if there is any way I can access a more precise > interrupt-driven (or blocking) timing source. I know I can do a select() > with supposedly microsecond accuracy, but I doubt that it is in fact that > accurate in practice (doesn't the kernel only use a 100Hz clock or > something?). Is there any way to get at the system timers on the > motherboard? Those can provide precise timing, no? Controlling steppers via lpt is what I explained and showed last tuesday on the cosmo-project meeting. We used nanosleep() which worked fine for the demonstration and playing. As long as you don't have troubles with longer than requested periods this would fit your needs. Nevertheless in my opinion it's a job for a dedicated CPU/controller. Think about using an 68HC11 or something like that. If you can enshure not only minimum but also maximum step times you can even get the motor faster - well not with lowered drill of course. You can shorten the steps while the motor is rotating which you can't do at once. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
> On a totally unrelated subject to my sio.c message, I have a second problem. > I've built a computer-controlled drill, that is controlled via the parallel > port. This drill uses stepper motors, at 1/2 step. My driver software > implements a maximum-acceleration control algorithm that ensures that at any > point in time, any axis will not experience more than X m/s/s of > acceleration. This keeps the drill from self-destructing. :) Unfortunately, > it means I need access to a very precise timing source to issue the step > instructions to the motor control board. Are you controlling the rotation speed of the drill or the x,y,z position? I'd guess the latter. Don't you also need guaranteed real time response (which FreeBSD won't provide you)? I suppose if you are controlling the position (and not the velocity) RT response won't be too critical. At any rate you are better off writing a device driver which can run timing critical code while blocking out all other interrupts. Or else between the time you measure time and supply the next pulse a higher prio interrupt handler else may sneak in. As was suggested you may want to consider a dedicated cpu based controller. Thre are a number of solutions for hobbyists (such as the handyboard, see www.handyboard.com). Is this a totally homebrew drill or something from a kit? I'd be interested in details (probably better offline since the interection of freebsd s/w hackers & h/w hackers is tiny). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
In message <200109301010.07784@EO>, Bart Kus cleopede: > On a totally unrelated subject to my sio.c message, I have a second problem. > I've built a computer-controlled drill, that is controlled via the parallel >port. This drill uses stepper motors, at 1/2 step. My driver software >implements a maximum-acceleration control algorithm that ensures that at any >point in time, any axis will not experience more than X m/s/s of >acceleration. This keeps the drill from self-destructing. :) Unfortunately, >it means I need access to a very precise timing source to issue the step >instructions to the motor control board. > > Right now, I use for() as a timing loop. I calibrate it on program start >and can then get very precise timing. There are, of course, the intermittent >interruptions of the multitasker. So this solution is not ideal by any >means. In fact, the for() loop approach is really meant for the DOS port of >this software. I'm wondering if there is any way I can access a more precise >interrupt-driven (or blocking) timing source. I know I can do a select() >with supposedly microsecond accuracy, but I doubt that it is in fact that >accurate in practice (doesn't the kernel only use a 100Hz clock or >something?). Well, setitimer has a maximum rate of 100 Hz, with a slop factor sometimes much greater than 10 ms. This was the result of some recent testing on a lightly-loaded standard 4.3 system. >Is there any way to get at the system timers on the >motherboard? Those can provide precise timing, no? But not necessarily realtime response if you are generating the stepper pulses yourself. How many stepper motors are you driving? If it's only one at a time, then maybe the speaker port on the motherboard (a programmable counter-timer) would be more reliable. Another idea is to use a fifo'ed UART's data out line and fiddle with the baud rate to vary the speed of the pulses. And one final idea is to use a (possibly port-powered) MCU as an independent timer generator. Greg Shenaut To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
On Sun, Sep 30, 2001 at 01:44:37PM +, Vladimir Dozen wrote: > SIGDANGER is the signal from Irix, AFAIR? AIX has SIGDANGER. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sio modification
In message <200109301226.0779@EO>, Bart Kus writes: >On Sunday 30 September 2001 10:38, you wrote: >> Your machine will not work too well if it is 40kHz. >> >> The PPS-API allows you to timestamp edges on DCD, if the frequency is >> more reasonable, that would work for you. Find RFC27xx for more info >> about PPS-API. > > Oh really. I was actually reading pps.c, and it looked like it was for the >parallel port interrupt pin only. I'd rather avoid cutting up this connector >if I can. Is the DCD edge timestamp (which would be PERFECT) already >implemented, or is this a spec for me to write for when modifying sio.c? It's in sio.c already. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Looking for testers for PR ports/30821
Rexx-IMC doesn't build on -CURRENT at the moment (so says Bento). This PR contains a patch, but I'm -CURRENT-less. Could someone build things and let me know? In addition to the sample scripts in the examples directory tree (which have all been modified to run from a commandline just like any other script), doing: rexx -s 'say sqrt(2)' will verify that the math extensions work. Thanks. -- jmc MacroHard -- the perfection of form over substance, marketing over performance, and greed over design . . . To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
On Sunday 30 September 2001 11:03, Bernd Walter wrote: > Controlling steppers via lpt is what I explained and showed last > tuesday on the cosmo-project meeting. > We used nanosleep() which worked fine for the demonstration and > playing. > As long as you don't have troubles with longer than requested periods > this would fit your needs. Is there a record of your explanation somewhere? As for the longer-than-requested timing periods, yes that is a problem. If maximum velocity of the drill is 30cm/s, a sudden stop would not be good. I can of course change the MAX_V, but I'm still hoping for a non-kludgy solution. > Nevertheless in my opinion it's a job for a dedicated CPU/controller. > Think about using an 68HC11 or something like that. > If you can enshure not only minimum but also maximum step times you > can even get the motor faster - well not with lowered drill of course. I agree. This does need a dedicated MCU. However, I only had 1 PCB layer to work with, so simplicity was key here. > You can shorten the steps while the motor is rotating which you can't > do at once. What do you mean here? I already do use variable timing for the steps BTW. Remember, the motors perform constant-acceleration operations...it means they slowly approach MAX_V. It's pretty neat to listen to. :) --Bart To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
On Sunday 30 September 2001 12:47, Greg Shenaut wrote: > Well, setitimer has a maximum rate of 100 Hz, with a slop factor > sometimes much greater than 10 ms. This was the result of some > recent testing on a lightly-loaded standard 4.3 system. That's not good enough. :/ > How many stepper motors are you driving? If it's only one at a time, then > maybe the speaker port on the motherboard (a programmable counter-timer) > would be more reliable. I like the speaker port idea. Can one program the speaker port to generate an int/signal/un-block using bsd's kernel API? > Another idea is to use a fifo'ed UART's data out > line and fiddle with the baud rate to vary the speed of the pulses. I don't think this will provide the "smoothness" I want. Going from 2400->4800 steps/sec for example would be a huge jerk. Need SMOOTH transition (constant-acceleration). But the speaker port idea sounds great. --Bart To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sio modification
On Sunday 30 September 2001 10:38, you wrote: > Your machine will not work too well if it is 40kHz. > > The PPS-API allows you to timestamp edges on DCD, if the frequency is > more reasonable, that would work for you. Find RFC27xx for more info > about PPS-API. Oh really. I was actually reading pps.c, and it looked like it was for the parallel port interrupt pin only. I'd rather avoid cutting up this connector if I can. Is the DCD edge timestamp (which would be PERFECT) already implemented, or is this a spec for me to write for when modifying sio.c? If I do have to write something, for my work to be included anywhere, I should be writing for the -CURRENT kernel, right? I presently run -STABLE, so that would obviously be the more comfortable kernel to write for...but it is *STABLE* after all. --Bart PS: That's RFC2783 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
On Sun, Sep 30, 2001 at 01:10:35PM -0500, Bart Kus wrote: > On Sunday 30 September 2001 11:03, Bernd Walter wrote: > > Controlling steppers via lpt is what I explained and showed last > > tuesday on the cosmo-project meeting. > > We used nanosleep() which worked fine for the demonstration and > > playing. > > As long as you don't have troubles with longer than requested periods > > this would fit your needs. > > Is there a record of your explanation somewhere? As for the > longer-than-requested timing periods, yes that is a problem. If maximum > velocity of the drill is 30cm/s, a sudden stop would not be good. I can of > course change the MAX_V, but I'm still hoping for a non-kludgy solution. > > > Nevertheless in my opinion it's a job for a dedicated CPU/controller. > > Think about using an 68HC11 or something like that. > > If you can enshure not only minimum but also maximum step times you > > can even get the motor faster - well not with lowered drill of course. > > I agree. This does need a dedicated MCU. However, I only had 1 PCB layer > to work with, so simplicity was key here. It's possible to build a single layer PCB with an MCU. Well it can be tricky sometimes. > > You can shorten the steps while the motor is rotating which you can't > > do at once. > > What do you mean here? I already do use variable timing for the steps BTW. > Remember, the motors perform constant-acceleration operations...it means they > slowly approach MAX_V. It's pretty neat to listen to. :) Yes - that's want I mean and that's what gets you in trouble with the longer-than-requested thing so you are stuck with the initial speed. The problem here is that nanosleep returns no earlier than the given time unless a signal is received, in which case the exceeded time is returned and you can recall with the remaining. So you can garantie a minimal time. But with a multitasking OS you can't enshure that you will have the CPU at a special given time - other tasks including ints may have priority. At worst your process may need to wait for a disk... You might be able to do in the kernel (ab)using the clock interrupts, so you realy know when you own the CPU. See hardclock() function in src/sys/kern/kern_clock.c Don't forget that the rate can be modified via sysctl. With an MCU you would also use a timer interrupt. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
* Jos Backus <[EMAIL PROTECTED]> [010930 12:55] wrote: > On Sun, Sep 30, 2001 at 01:44:37PM +, Vladimir Dozen wrote: > > SIGDANGER is the signal from Irix, AFAIR? > > AIX has SIGDANGER. Anyone care to tell me how it works in AIX? If the interface is nice, cloning it would be kind of cool. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sio modification
Bart Kus <[EMAIL PROTECTED]> types: > manipulates the CD line of the serial port it plugs into. Afaik, the UART > itself is capable of generating an interrupt whenever CD changes. The > problem is, sio.c doesn't support this feature. I'm stuck with polling the > status register to find out the state of CD. Not a very good solution for a > daemon that's supposed to run in the background all the time, especially > since the CD line will be toggled at about 40kHz (I think that's the remote > control frequency standard). Perhaps I'm wrong about the 40kHz figure. It looks like you've already got a solution to this problem, and this won't be very useful if the 40kHz figure is right, but I figured I might mention it anyway. Have you thought about using the feature of the callin device of the "open" call blocking until it gets CD? You should then get a SIGHUP when CD drops. http://www.mired.org/home/mwm/ Q: How do you make the gods laugh? A: Tell them your plans. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
On Sun, Sep 30, 2001 at 02:23:26PM -0500, Alfred Perlstein wrote: > * Jos Backus <[EMAIL PROTECTED]> [010930 12:55] wrote: > > AIX has SIGDANGER. > > Anyone care to tell me how it works in AIX? If the interface is > nice, cloning it would be kind of cool. I don't currently have access to an AIX system, but http://as400bks.rochester.ibm.com/doc_link/en_US/a_doc_lib/aixbman/admnconc/pag_space_under.htm has some (useful) info. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
* Jos Backus <[EMAIL PROTECTED]> [010930 14:35] wrote: > On Sun, Sep 30, 2001 at 02:23:26PM -0500, Alfred Perlstein wrote: > > * Jos Backus <[EMAIL PROTECTED]> [010930 12:55] wrote: > > > AIX has SIGDANGER. > > > > Anyone care to tell me how it works in AIX? If the interface is > > nice, cloning it would be kind of cool. > > I don't currently have access to an AIX system, but > > >http://as400bks.rochester.ibm.com/doc_link/en_US/a_doc_lib/aixbman/admnconc/pag_space_under.htm > > has some (useful) info. It sure does! I think I'm going to make a proposal on -arch about this, to be perfectly honest, AIX has a good implementation, I haven't read it all yet, but it doesn't look like it gives the applications a notification when the danger is gone, we'll have to figure that out, or I'll have to read more into this. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
: :In message <[EMAIL PROTECTED]>, Matt Dillon writes: :>: Second, application not always grows to 1G, most of the time it keeps :>: as small as 500M ;). Why should we precommit 1G for 500M data? Doing :>: multi-mmap memory management is additional pain. :> :>Even using file-backed memory is fairly trivial. You don't need to :>do multi-mmap memory management or do any kernel tweaking. Just :>reserve 1G and use a single mmap() and file per process. : :I once had a patch to phkmalloc() which backed all malloc'ed VM with :hidden files in the users homedir. It was written to put the VM :usage under QUOTA control, but it had many useful side effects as well. : :I can't seem to find it right now, but it is trivial to do: just :replace the sbrk(2) with mmap(). Only downside is the needed :filedescriptor which some shells don't like. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :[EMAIL PROTECTED] | TCP/IP since RFC 956 I think the file descriptor problem can be solved easily... simply open the file, mmap() the entire 1G segment for this special application, and then close() the file. Then have sbrk() just eats out of the mapped segment. Alternatively sbrk() could open/mmap/close in large 1MB or 4MB segments, again leaving no file descriptors dangling. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
* Matt Dillon <[EMAIL PROTECTED]> [010930 14:59] wrote: > > : > :In message <[EMAIL PROTECTED]>, Matt Dillon writes: > :>: Second, application not always grows to 1G, most of the time it keeps > :>: as small as 500M ;). Why should we precommit 1G for 500M data? Doing > :>: multi-mmap memory management is additional pain. > :> > :>Even using file-backed memory is fairly trivial. You don't need to > :>do multi-mmap memory management or do any kernel tweaking. Just > :>reserve 1G and use a single mmap() and file per process. > : > :I once had a patch to phkmalloc() which backed all malloc'ed VM with > :hidden files in the users homedir. It was written to put the VM > :usage under QUOTA control, but it had many useful side effects as well. > : > :I can't seem to find it right now, but it is trivial to do: just > :replace the sbrk(2) with mmap(). Only downside is the needed > :filedescriptor which some shells don't like. > : > :-- > :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > :[EMAIL PROTECTED] | TCP/IP since RFC 956 > > I think the file descriptor problem can be solved easily... simply > open the file, mmap() the entire 1G segment for this special application, > and then close() the file. Then have sbrk() just eats out of the mapped > segment. Alternatively sbrk() could open/mmap/close in large 1MB or 4MB > segments, again leaving no file descriptors dangling. Won't that cause fragmentation? You're forgettng the need to ftruncate or pre-zero the file unless that's been fixed. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Looking for testers for PR ports/30821
Le (On) Sun, Sep 30, 2001 at 11:22:24AM -0700, John Merryweather Cooper ecrivit (wrote): > Rexx-IMC doesn't build on -CURRENT at the moment (so says Bento). This > PR contains a patch, but I'm -CURRENT-less. Could someone build things > and let me know? It builds now. But your patch did not work well for the Make.new date change. Maybe because you patched a patch ? ;) Or maybe because I copy-pasted it from Netscape. > In addition to the sample scripts in the examples directory tree (which > have all been modified to run from a commandline just like any other > script), doing: > > rexx -s 'say sqrt(2)' > > will verify that the math extensions work. 1.41421356 looks like a reasonable value ;) Cheers, -- Sameh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
You definite need to use a microcontroller. Something like the 68HC11F1 is a good single-chip solution (though the F1 only has 512 bytes of E^2). I'm sure Motorola has newer chips with more on-board E^2.Stepper motors can be manipulated from a PC parallel port but you will never get smooth output and you can forget about momentum accelleration. There are also a huge number of Intel-derivative microcontrollers that are as self contained and in much smaller packages then typical motorola parts. I'm most familiar with the Motorola's... For a stepper or waveform output I've always liked the motorola MCUs because they have timer output compare registers that will automatically flip a bit for you on an output port, giving you timer resolution down to crystal / 4 and accuracy that is at the crystal accuracy. But the Intel derivatives are going to be much, much cheaper... $2 or $3 for an MCU that does what you want and extremely easy to program. Look at the MCS51 and MCS96 series. Note that there are dozens of manfacturers of Intel-style controllers. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
:> :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :> :[EMAIL PROTECTED] | TCP/IP since RFC 956 :> :> I think the file descriptor problem can be solved easily... simply :> open the file, mmap() the entire 1G segment for this special application, :> and then close() the file. Then have sbrk() just eats out of the mapped :> segment. Alternatively sbrk() could open/mmap/close in large 1MB or 4MB :> segments, again leaving no file descriptors dangling. : :Won't that cause fragmentation? You're forgettng the need to :ftruncate or pre-zero the file unless that's been fixed. : :-- :-Alfred Perlstein [[EMAIL PROTECTED]] You have to pre-zero the file. You can do it in reasonably-sized chunks (like 4M) without causing fragmentation. You *CANNOT* use ftruncate() to extend the file - that will virtually guarentee massive fragmentation. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
[...] > > was suggested you may want to consider a dedicated cpu based > > controller. Thre are a number of solutions for hobbyists > > (such as the handyboard, see www.handyboard.com). > > Unfortunately, money is a big factor. So that's not an option. :/ > Atmel AVR microcontrollers are < $10 from distributors like Digikey (and Digikey usually has high prices). They're very slick and VERY FAST. You can do 12 MIPS with one of their chips. Of course you'd need to spend some time learning their instruction sets/learning how to code in C for them. There is a C compiler in the ports named avr-gcc to do just that. As for programmers, you can program these chips with a simple homebrew cable that plugs into your parallel port. Please see: http://www.bsdhome.com/avrprog Is that cheap enough? -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
On Sunday 30 September 2001 12:30, Bakul Shah wrote: > Are you controlling the rotation speed of the drill or the > x,y,z position? I'd guess the latter. Don't you also need I am controlling XYZ. > guaranteed real time response (which FreeBSD won't provide > you)? I suppose if you are controlling the position (and not > the velocity) RT response won't be too critical. At any rate Hrm, I was planning on investigating the RT capabilities of fbsd after I got myself a decent timer mechanism. I was hoping they would be enough to get close to RT. I have an SMP system I can use, so 1 CPU can be dedicated to the task. > you are better off writing a device driver which can run > timing critical code while blocking out all other interrupts. Not an option. It would stall the whole system during the (possibly 20 minute) drilling operation. Maybe it'll be possible with SMPng, but not now. > Or else between the time you measure time and supply the next > pulse a higher prio interrupt handler else may sneak in. As I'm hoping higher-priority interrupts will be quick about their work. A few microseconds or 10s or possibly 100s hopefully won't upset the drill too much. > was suggested you may want to consider a dedicated cpu based > controller. Thre are a number of solutions for hobbyists > (such as the handyboard, see www.handyboard.com). Unfortunately, money is a big factor. So that's not an option. :/ > Is this a totally homebrew drill or something from a kit? > I'd be interested in details (probably better offline since > the interection of freebsd s/w hackers & h/w hackers is > tiny). It's home brew, I'll forward you more details in personal email. --Bart To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sio modification
On Sunday 30 September 2001 13:18, you wrote: > It's in sio.c already. Sorry to bug you again, but it seems that the PPS driver for sio doesn't support PPS_CANWAIT. Am I correct in that assessment? Without blocking, I don't see any other mechanism for event-driven execution. The RFC seems to hint towards sampling at the Nyquist frequency in the case of a missing PPS_CANWAIT. Establishing an 80kHz loop is pretty much impossible given the 100Hz resolution of nanosleep() and friends. --Bart To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sio modification
In message <200109301600.21610@EO>, Bart Kus writes: >On Sunday 30 September 2001 13:18, you wrote: >> It's in sio.c already. > > Sorry to bug you again, but it seems that the PPS driver for sio doesn't >support PPS_CANWAIT. Am I correct in that assessment? Without blocking, I >don't see any other mechanism for event-driven execution. The RFC seems to Yes, you'll have to poll, sorry... >hint towards sampling at the Nyquist frequency in the case of a missing >PPS_CANWAIT. Establishing an 80kHz loop is pretty much impossible given the >100Hz resolution of nanosleep() and friends. > > --Bart > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem(s) With FreeBSD-Current
On Sat, Sep 29, 2001 at 05:48:37PM -0700, Luigi Rizzo wrote: > > Hello, > > > > I have tried to compile FreeBSD Current (several times) over the last > > couple of days and get the following message when trying to run XFree86 > > and a number of other applications: > > > >/user/lib/libpam.so.1 : Undefined symbol "__stdoutp"... > > > > Does anyone else have the same problem ?? > > same here (though cross-compilig CURRENT on 4.3), > for me the fix was to revert the sep.20 change on src/include/stdio.h > > @@ -198,7 +198,7 @@ __END_DECLS > #endif > > /* To be removed by 5.0-RELEASE */ > -#if (defined(__i386__) || defined(__alpha__)) && !defined(_FIXED_STDIO) > +#if (defined(__i386__) || defined(__alpha__)) && defined(_OLD_STDIO) > #definestdin (&__sF[0]) > #definestdout (&__sF[1]) > #definestderr (&__sF[2]) > > Maybe it is the wrong fix, but it did work. Yes, it's the wrong fix. If you actually go and read your -current mailbox, you'll find it very hard to avoid tripping over an email containing the correct fix. Kris PGP signature
Problems with Davicom network chip under load.
Hi, I was just attempting to move an iso image between two 4.3-Release machines, the server being a PPro180 with i82559 and the client being a P3-933 with a Davicom network chip. FTP'ing an image from server to client resulted in the client aparrently losing the plot at layer 3 - a ping running simultaneously stops responding at the same time. This proved to be extremely repeatable. Doing ifconfig dc0 down, then up again fixes the problem temporarily. There is nothing in either dmesg nor /var/log/messages about this, and netstat -m shows nothing abnormal. Is this a known problem? RTFM'ing a little I see a recent CVS commit (http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sys/pci/if_dc.c), version 1.54 "Deal with the condition where we lose link in the middle of transmitting a bunch of frames."? Is this therefore fixed under 4.4? BTW, as a short term fix, the same machine has a realtek chipset so I swopped the configuration over and all is good. Must do the 4.4 upgrade (sigh). Cheers, Dave ---FYI, Configuration-- (a snipped dmesg) FreeBSD 4.3-RELEASE #4: Fri Sep 21 16:08:35 NZST 2001 CPU: Pentium III/Pentium III Xeon/Celeron (930.96-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 real memory = 134135808 (130992K bytes) avail memory = 127950848 (124952K bytes) Preloaded elf kernel "kernel" at 0xc02a4000. Preloaded elf module "agp.ko" at 0xc02a409c. Pentium Pro MTRR support enabled agp0: mem 0xe000-0xe7ff at device 0.0 on pci0pcib2: at device 1.0 on pci0 pci1: on pcib2 pci1: at 0.0 irq 11 rl0: port 0xa800-0xa8ff mem 0xdb80-0xdb8000ff irq 5 at device 10.0 on pci0 rl0: Ethernet address: 00:50:bf:25:54:ce miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: port 0xa400-0xa4ff mem 0xdb00-0xdbff irq 10 at device 11.0 on pci0 dc0: Ethernet address: 00:80:ad:72:b6:cc miibus1: on dc0 ukphy0: on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: power supplies
Dan wrote: > > I had the stangest situation today where a new nic card was put into a > machine and then the machine did not start up. Placed the old nic card > back in the box and it still did not start up. Switched power supplies > with an exactly equal box and both machine booted up fine. This has > happened twice since we started replacing nic cards today with ones with > more buffer space available on them out of about 8 machines now. > > Does this make any sense to anyone? I had almost exactly the same experience with a Tyan motherboard, excapt that it was not a network but video card in my case. Unplugging the power cord from the machine between removing one card and inserting another (or possibly the same) one has helped. Though I don't know why it happens. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Looking for testers for PR ports/30821
On 2001.09.30 13:16 Sameh Ghane wrote: > Le (On) Sun, Sep 30, 2001 at 11:22:24AM -0700, John Merryweather > Cooper ecrivit (wrote): > > Rexx-IMC doesn't build on -CURRENT at the moment (so says Bento). > This > > PR contains a patch, but I'm -CURRENT-less. Could someone build > things > > and let me know? > > It builds now. But your patch did not work well for the Make.new date > change. > Maybe because you patched a patch ? ;) Or maybe because I copy-pasted > it from > Netscape. > Probably the latter . . . :) Most browsers hose tab/space alignment, etc. > > In addition to the sample scripts in the examples directory tree > (which > > have all been modified to run from a commandline just like any other > > script), doing: > > > > rexx -s 'say sqrt(2)' > > > > will verify that the math extensions work. > > 1.41421356 looks like a reasonable value ;) > > Cheers, > > -- > Sameh > Excellent! Thanks for taking the time to check things out for me. Rexx-IMC 1.7 (the previous version) wouldn't even give you an answer--the math libraries were hosed. -- jmc MacroHard -- the perfection of form over substance, marketing over performance, and greed over design . . . To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KSE next steps...
Glenn Gombert wrote: > > A couple of questions come to mind after reading what has been done > so far and what ( think has been committed into the the Free BSD Current > tree)and reading throught the present KSE write up.. > > How much of the KSE code is dependant upon the SMP support being fully > functional?? The new system call(s) sa_new(cpy_id), sa_pressmpt)...etc > seem to depend upon the new SMP support being functional in the 'Current' > tree...is this the case or call's like "sa_new(cpu_id) will just create > one KSE per avaiable CPU (one on a single cpu machine).. A single CPU machine will hav only one KSE (per kseg) but it will still have completely asynchronous syscalls, so it will still be able to schedule many threads at once without the fear that one will block and block all the others.. So it's still very useful for UP machines. > > > > Should they be allocated from a zone allocator similar to that > > currently used for process structures? > > Should the vm object associated with threads structures be allocated > > and 'left' as it presently is (type stable storage)? > > Should the thread structure that comes with the proc structure be used > > as one of > > the > > threads for KSE operation, or should it be left untouched until > > KSE mode is stopped (or exit)? If we use the thread pre-packed with > > the proc > > there are some problems.. > > > > For example: it is intimatly associated with one process, but thread > > structs in > > KSE > > mode are transient, and might be given to a different process should > > it be > > needed > > there. (kernel thread structures are only 'used' when the thread enters > > the > > kernel > > due to a trap of some sort (e.g. syscall) until it returns back to > > user land). > > It provides the stack and storage for the thread to transfer from user > > to kernel > > and is 'empty' while the thread is running in user space. > > > > Another option might be to ALWAYS allocate them separatly.. That makes > > the first > > one > > just another thread struct... but it may be more 'expensive' to allocate > > tehm > > that way. > > (though thay could be cached...) > > Are all of the API's in section 3.3 of the KSE white paper implemeted > with SMP support (like thread_new(), thread_preempt()... etc ?? they (or similar ones) will be. We're still working out the API. > > > 2/ When processes have a single state, (e.g. SLEEP, RUN etc.) it becomes > > possible > > for a process to simultaneously have threads in multiple states.. What > > do we do > > in all the places that current code assumes a single monolithic state, > > and how do we report the stat of such a process in /proc or ps? > > > > - My guess is that a single state 'KSE' for a process should indicate > > that no > > finer > > state information is available for that process until we add code to > > 'ps' to > > support it.. We can alter ps and friends to simply give up if they > > see that > > state.. > > > > Has the Kenrnel Scheduler been changed to support the creation of KSE's > or is that planned fir this next phase ?.. that will be this next phase... > > > 3/ similar for reporting wmesg information.. > > > > 4/ What does a process with 4 threads do if you send it a SIGTSTP and > > it has a > > number of threads (maybe on a different processor) presently suspended > > in > > syscalls > > or, maybe running in syscalls. > > > > (other questions later when I think of them..) > > > > The next steps: > > a) add allocators/destructors for threads, kses and ksegrps > > b) use them, and add code to fork() (and friends) to use them > > c) define the user interface so that uerland code can start to be planned. > > (I may just do that first.) > > d) add the syscalls to switch modes etc. > > e) make a single test syscall that exercises some of this...(no locking.. > > What sort of mechanism has been used todate to test the functionality > that has been added to the kernel code in the 'Current' branch so far?? SO far the main aim was "No new functionality, and keep working" :-) > > I am just coming up to speed on some of this and have been waiding > through the way the 4.x kernel functions now and how it is envisioned > to function under 5.0 did you look at the 5.0 kernel? > > > just > > simple) > > > > > > > > julian > > > > > > > > > > -- > > ++ __ _ __ > > | __--_|\ Julian Elischer | \ U \/ / hard at work > > in > > | / \ [EMAIL PROTECTED] +-->x USA\ a very strange > > | ( OZ)\___ ___ | country ! > > +- X_.---._/presently in San Francisco \_/ \\ > > v > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-arch" in the body of the message > > > > __ > FREE voicemail, email, and fax...all in one place. > Sign Up Now! http://www.onebox.com -- +--
Re: precise timing
In message <200109301318.44290@EO>, Bart Kus cleopede: >On Sunday 30 September 2001 12:47, Greg Shenaut wrote: >> Well, setitimer has a maximum rate of 100 Hz, with a slop factor >> sometimes much greater than 10 ms. This was the result of some >> recent testing on a lightly-loaded standard 4.3 system. > > That's not good enough. :/ > >> How many stepper motors are you driving? If it's only one at a time, then >> maybe the speaker port on the motherboard (a programmable counter-timer) >> would be more reliable. > > I like the speaker port idea. Can one program the speaker port to generate >an int/signal/un-block using bsd's kernel API? I do not think that there is hardware support for interrupts from the speaker port, but it seems to me that since it just sits there putting out a square wave at whatever frequency was most recently programmed into it, all one of the (relatively infrequent) less-than 10 ms timing glitches would do is to slow down the ramp sometimes, which would never harm the stepper motor (but would slow down the process a little bit). >> Another idea is to use a fifo'ed UART's data out >> line and fiddle with the baud rate to vary the speed of the pulses. > > I don't think this will provide the "smoothness" I want. Going from >2400->4800 steps/sec for example would be a huge jerk. Need SMOOTH >transition (constant-acceleration). I was thinking in terms of changing the baud rate in smaller increments than that--the timing hardware inside the standard PC UART is just a 16-bit programmable divider. But a MCU is still probably your best bet. (I remember writing a stepper-motor driver on a TI 9900 back in the 70's.) Greg Shenaut To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sio modification
On Sunday 30 September 2001 16:18, Poul-Henning Kamp wrote: > Yes, you'll have to poll, sorry... Ick. How hard would it be to pull off one of the following: 1) Give time_pps_fetch() the ability to become a blocking call 2) Modify the PPS API slightly, by allowing time_pps_fetch() to return a list of events, rather than just 1 event (would need facility to set max # of events for kernel to record - max backlog) I can't think of any other way of dealing with the problem of remote controls under freebsd, other than out-right writing something new tailored for the problem. I assume #1 is hard, since it's not implemented, and is proposed in the PPS API. #2 would be an a-ok solution too, since I could poll time_pps_fetch() 10 times/sec or something and still give fairly real-time response to remote control button presses. --Bart To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
On Sunday 30 September 2001 14:33, Devin Butterfield wrote: > Atmel AVR microcontrollers are < $10 from distributors like Digikey (and > Digikey usually has high prices). They're very slick and VERY FAST. You can > do 12 MIPS with one of their chips. > > Of course you'd need to spend some time learning their instruction > sets/learning how to code in C for them. There is a C compiler in the ports > named avr-gcc to do just that. > > As for programmers, you can program these chips with a simple homebrew > cable that plugs into your parallel port. > > Please see: > > http://www.bsdhome.com/avrprog > > Is that cheap enough? Oh, very nice! Definate contender for "version 2" of this controller. I'd still like to get version 1 working though. Thanks for the info! --Bart To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
> Hrm, I was planning on investigating the RT capabilities of fbsd after I got > myself a decent timer mechanism. I was hoping they would be enough to get > close to RT. I have an SMP system I can use, so 1 CPU can be dedicated to > the task. I doubt even an SMP system would help. > > you are better off writing a device driver which can run > > timing critical code while blocking out all other interrupts. > Not an option. It would stall the whole system during the (possibly 20 > minute) drilling operation. Maybe it'll be possible with SMPng, but not now. I meant blocking other interrupts only during critical periods. For instance, when your s/w gets control, you find out the current time and figure out what speed you want to set. Then you set timout for the next time you want to do this and return. Basically you are approximating a curve and while doing this at regular interval is easier, you can also approximate with an irregular interval (use Bresenham). But this is just a generic suggestion; I do not know enought details to do more than that. One other thing you can do is to increase clock tick rate to 1000 Hz from the default 100 Hz. > > was suggested you may want to consider a dedicated cpu based > > controller. Thre are a number of solutions for hobbyists > > (such as the handyboard, see www.handyboard.com). > > Unfortunately, money is a big factor. So that's not an option. :/ IIRC you can buy a kit (including a two sided PCB) for under $100. A few years ago I built the precursor to the Handy Board (called Miniboard) from a kit for a lot less. It had a 68hc11E2 (with a 2k EEPROM) + you can control upto 4 motors + a bunch of sensors and digitial output control pins. Someone may still be selling it. What I was thinking of was not a completely dedicated controller. You interface to something like the miniboard via a serial port and do all the fancy computation on your freebsd system and let the controller do the PWM by feeding it precomputed parameters (at time t0 velocity v0, at time t1 set it to v1 and so on). > It's home brew, I'll forward you more details in personal email. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: precise timing
On 30-Sep-2001 Bart Kus wrote: > Right now, I use for() as a timing loop. I calibrate it on program start > and can then get very precise timing. There are, of course, the > intermittent > interruptions of the multitasker. So this solution is not ideal by any > means. In fact, the for() loop approach is really meant for the DOS port of > this software. I'm wondering if there is any way I can access a more > precise > interrupt-driven (or blocking) timing source. I know I can do a select() > with supposedly microsecond accuracy, but I doubt that it is in fact that > accurate in practice (doesn't the kernel only use a 100Hz clock or > something?). Is there any way to get at the system timers on the > motherboard? Those can provide precise timing, no? I suspect the only way you could achieve this in FreeBSD at the moment is to write a kernel driver. That way you can disable interrupts while you frob your board.. (And get quick access when you need it). --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sio modification
On Sunday 30 September 2001 14:30, Mike Meyer wrote:
> It looks like you've already got a solution to this problem, and this
> won't be very useful if the 40kHz figure is right, but I figured I
> might mention it anyway. Have you thought about using the feature of
> the callin device of the "open" call blocking until it gets CD? You
> should then get a SIGHUP when CD drops.
This sounded like a really good idea when I first read it, so I wrote a
test. The first thing I noticed is that SIGHUP was *NOT* being generated
(any idea why?) on CD transition to low. I then realized that I could use
write() and it would fail when CD==low. So I used that technique for
detecting CD==low, and after setting "dtrwait" to 0 using comcontrol, things
seemed to be going well. However, I pressed the same button on the remote
multiple times and I noticed a very high variance in the time-deltas between
high/low states. In fact, sometimes 7 transitions are reported, sometimes 9.
The variance for some time-deltas is sometimes as high as a factor of 10
(note: I'm not using the statistical definition of variance - I simply mean
that a +edge -> -edge time can be 100us and then 1000us on the next press of
the same button). Sadly, this seemingly good mechanism doesn't perform well
enough to produce the kind of data I'd need for pattern matching.
Perhaps actually managing to generate a SIGHUP would cut down on this
variance?
I've attached the source for the test program for your reading enjoyment. :)
Don't feel obligated to open it.
--Bart
/* Cow & Chicken rule!
*
* IRBaboon Copyright (C) Bart Kus, 2001.
*/
/* NOTE:
* Be SURE to do a: comcontrol /dev/irbaboon dtrwait 0
* Prior to running this program!
*/
#include
#include
#include
#include
#include
#include
#include
#include
int i;
unsigned int dt[256];
void handler_sighup(int data) {
printf("Got SIGHUP\n");
return;
}
void handler_sigint(int data) {
int i2;
for(i2=0; i2 < i; i2++)
printf("DT: %010dus\n", dt[i2]);
return;
}
int main(int argc, char **argv)
{
int fd;
struct termios t;
struct timeval high, low;
/* Configure our CD->low SIGHUP handler */
signal(SIGHUP, handler_sighup);
signal(SIGINT, handler_sigint);
/* Configure the port */
cfsetspeed(&t, B115200);
t.c_iflag = 0;
t.c_oflag = 0;
t.c_cflag = CSIZE|CS6|CREAD|HUPCL;
t.c_lflag = 0;
for(i=0; i < NCCS; i++)
t.c_cc[i] = '\0';
i=0;
while(1) {
/* Open callin device - blocks until CD->high */
fd = open("/dev/irbaboon", O_RDWR, 0);
gettimeofday(&high, NULL);
if(tcsetattr(fd, TCSANOW, &t)) {
perror("tcsetattr()");
exit(1);
}
while(write(fd, "X", 1) != -1);
gettimeofday(&low, NULL);
close(fd);
/* printf("HIGH: %09d.%09ds\n", high.tv_sec, high.tv_usec);
printf(" LOW: %09d.%09ds\n", low.tv_sec, low.tv_usec);
printf(" DT: %010dus\n", (low.tv_sec-high.tv_sec)*100 + (low.tv_usec - high.tv_usec));*/
dt[i++] = (low.tv_sec-high.tv_sec)*100 + (low.tv_usec - high.tv_usec);
}
return 0;
}
Re: setjmp/longjmp
[Format recovered--see http://www.lemis.com/email/email-format.html] On Friday, 28 September 2001 at 10:12:14 -0700, Julian Elischer wrote: > On Fri, 28 Sep 2001, Gersh wrote: >> On Fri, 28 Sep 2001, Bernd Walter wrote: >>> On Fri, Sep 28, 2001 at 07:03:51PM +0530, Anjali Kulkarni wrote: Does anyone know whether it is advisable or not to use setjmp/longjmp within kernel code? I could not see any setjmp/longjmp in kernel source code. Is there a good reason for this or can it be used? >>> >>> You need to look again, it's used in several places in the kernel. >> >> Look at sys/i386/i386/db_interface.c > > Yeah but it would probably be a pretty bad idea to use it without > very careful thought. Especialy with the kernel becoming > pre-emptable in the future.. Can you think of a scenario where it wouldn't work? Preemption doesn't tear stacks apart, right? Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: power supplies
On Sun, 30 Sep 2001 [EMAIL PROTECTED] wrote: > I had almost exactly the same experience with a Tyan motherboard, > excapt that it was not a network but video card in my case. > Unplugging the power cord from the machine between removing one > card and inserting another (or possibly the same) one has helped. > Though I don't know why it happens. I've seen similar stuff although have not (yet) fried a PS. I've had chipset lockup that requred unplugging AC for 30+ seconds before it was resolved. A simple power cycle with the power switch was not sufficient. Bear in mind that power supplies are never really "off" any more. There is always power applied to motherboards as long as AC is hot. I expect that sloppy enough design could result in these types of problems. Soft power off is not as perfect. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sio modification
On 01-Oct-2001 Bart Kus wrote: > The variance for some time-deltas is sometimes as high as a factor of 10 > (note: I'm not using the statistical definition of variance - I simply mean > that a +edge -> -edge time can be 100us and then 1000us on the next press of > the same button). Sadly, this seemingly good mechanism doesn't perform well > enough to produce the kind of data I'd need for pattern matching. > > Perhaps actually managing to generate a SIGHUP would cut down on this > variance? > > I've attached the source for the test program for your reading enjoyment. > :) > Don't feel obligated to open it. If you're making an IR rx/tx device I suggest you visit.. http://www.lirc.org/ They have 'dumb' recievers which is probably what you're using, but there is also a link for 'smart' one which uses a PIC chip to do the polling... http://www.geocities.com/SiliconValley/Sector/3863/uir/index.html You could probably fit the whole thing inside a D9 backshell. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: power supplies
On 01-Oct-2001 Ronald G Minnich wrote: > I've seen similar stuff although have not (yet) fried a PS. I've had > chipset lockup that requred unplugging AC for 30+ seconds before it was > resolved. A simple power cycle with the power switch was not sufficient. We found this problem at work due to an interface card (of custom design) that didn't have any isolation. Power was flowing back from the controlled device and tricking the PSU into thinking it was still on. > Soft power off is not as perfect. No, but it's pretty neat :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
In message <[EMAIL PROTECTED]> Vladimir Dozen writes: : SIGDANGER is the signal from Irix, AFAIR? AIX. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
In message <200109301010.07784@EO> Bart Kus writes: : Right now, I use for() as a timing loop. I calibrate it on program start : and can then get very precise timing. There are, of course, the intermittent : interruptions of the multitasker. So this solution is not ideal by any : means. In fact, the for() loop approach is really meant for the DOS port of : this software. I'm wondering if there is any way I can access a more precise : interrupt-driven (or blocking) timing source. I know I can do a select() : with supposedly microsecond accuracy, but I doubt that it is in fact that : accurate in practice (doesn't the kernel only use a 100Hz clock or : something?). Is there any way to get at the system timers on the : motherboard? Those can provide precise timing, no? you are likely better off implementing this as a device driver, likely with the parallel port bus stuff. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM Corruption - stumped, anyone have any ideas?
On Sat, 29 Sep 2001 20:38:51 + (UTC), in sentex.lists.freebsd.hackers you wrote: >Hi! > >On Mon, 24 Sep 2001, Matt Dillon wrote: > >> A number of people have been seeing these on STABLE: >> >> panic: vm_page_remove(): page not found in hash >> >There was rummors that lowering "maxusers" from 512 to 128 worksaround >this problem on a machine with 3Gb of memory... Hi, This machine has maxusers set to 192 with 512MB of RAM. ---Mike Mike Tancsa ([EMAIL PROTECTED]) Sentex Communications Corp, Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers could setup a national IP network." (KDW2) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
On Sunday, 30 September 2001 at 14:55:58 -0500, Alfred Perlstein wrote: > * Jos Backus <[EMAIL PROTECTED]> [010930 14:35] wrote: >> On Sun, Sep 30, 2001 at 02:23:26PM -0500, Alfred Perlstein wrote: >>> * Jos Backus <[EMAIL PROTECTED]> [010930 12:55] wrote: AIX has SIGDANGER. >>> >>> Anyone care to tell me how it works in AIX? If the interface is >>> nice, cloning it would be kind of cool. >> >> I don't currently have access to an AIX system, but >> >> >http://as400bks.rochester.ibm.com/doc_link/en_US/a_doc_lib/aixbman/admnconc/pag_space_under.htm >> >> has some (useful) info. > > It sure does! > > I think I'm going to make a proposal on -arch about this, to be > perfectly honest, AIX has a good implementation, I haven't read it > all yet, but it doesn't look like it gives the applications a > notification when the danger is gone, we'll have to figure that out, > or I'll have to read more into this. If it's any help, I have an AIX box here. It belongs to IBM, so I have to respect security issues, but I'll do what I can. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
* Greg Lehey <[EMAIL PROTECTED]> [010930 22:49] wrote: > On Sunday, 30 September 2001 at 14:55:58 -0500, Alfred Perlstein wrote: > > * Jos Backus <[EMAIL PROTECTED]> [010930 14:35] wrote: > >> On Sun, Sep 30, 2001 at 02:23:26PM -0500, Alfred Perlstein wrote: > >>> * Jos Backus <[EMAIL PROTECTED]> [010930 12:55] wrote: > AIX has SIGDANGER. > >>> > >>> Anyone care to tell me how it works in AIX? If the interface is > >>> nice, cloning it would be kind of cool. > >> > >> I don't currently have access to an AIX system, but > >> > >> >http://as400bks.rochester.ibm.com/doc_link/en_US/a_doc_lib/aixbman/admnconc/pag_space_under.htm > >> > >> has some (useful) info. > > > > It sure does! > > > > I think I'm going to make a proposal on -arch about this, to be > > perfectly honest, AIX has a good implementation, I haven't read it > > all yet, but it doesn't look like it gives the applications a > > notification when the danger is gone, we'll have to figure that out, > > or I'll have to read more into this. > > If it's any help, I have an AIX box here. It belongs to IBM, so I > have to respect security issues, but I'll do what I can. Well Joe seems to have provided a pretty interesting document on how it works in AIX, but I was wondering if they do anything wrt low/high watermarks like my idea. Basically you'd like to inform processes that the danger has been alliviated so that they can cautiously start accepting more work rather than freaking out and shutting out clients forever... This might lead to a situation where SIGDANGER starts getting sent informing that things are looking bleak, then processes start freeing resources, they get the second SIGDANGER to let them know that things are looking ok so they ramp up again and the cycle repeats, I guess that's not optimal, but I'd like FreeBSD to let processes know that things are looking better so they can go from "scrooge mode" to "thrifty mode". -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sio modification
Bart Kus wrote: > If I do have to write something, for my work to be included anywhere, I > should be writing for the -CURRENT kernel, right? I presently run -STABLE, > so that would obviously be the more comfortable kernel to write for...but it > is *STABLE* after all. Most of us doing commercial developement write for -stable, and give it out to be ported to -current by someone else, if we don't have the time to do both. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
Bakul Shah wrote: > > > Hrm, I was planning on investigating the RT capabilities of fbsd after > > I got > > myself a decent timer mechanism. I was hoping they would be enough to get > > close to RT. I have an SMP system I can use, so 1 CPU can be dedicated to > > the task. > > I doubt even an SMP system would help. Plus this is ASMP -- ASymmetric MultiProcessing -- when you dedicate a CPU to a task. FreeBSD doesn't support this. Linux supports this, with the patches from Ingo. I'm guessing they will become part of the standard Linux distribution. He developes the "Tux" in kernel web server, and he has the entire code path for the thing, including the TCP stack, so it fits in a single CPU instruction cache. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
Devin Butterfield([EMAIL PROTECTED])@2001.09.30 12:33:26 +: > [...] > > > was suggested you may want to consider a dedicated cpu based > > > controller. Thre are a number of solutions for hobbyists > > > (such as the handyboard, see www.handyboard.com). > > > > Unfortunately, money is a big factor. So that's not an option. :/ > > > > Atmel AVR microcontrollers are < $10 from distributors like Digikey (and > Digikey usually has high prices). They're very slick and VERY FAST. You can > do 12 MIPS with one of their chips. i can second that. a good friend of mine is implementing particle accelerator control units on the avr series and is very content with features, performance and overall development/deployment cost. basically they seem to be standard 16bit arm thumb platforms, with memory and interface configurations being the only varying features. > Of course you'd need to spend some time learning their instruction > sets/learning how to code in C for them. There is a C compiler in the ports > named avr-gcc to do just that. what i have seen from the development environment under win32 (yes, yes, i know...) the gcc generates code with a quite good quality and performance, some bugs included but well documented, and the in system programmer frontend 'pony prog' being pretty good as well. i also find it appealing that the avr series has onchip flash/eeprom and can be programmed via the isp bus even if one managed to screw up the boot code completely -- this reduces development costs and time dramatically ;-) /k -- > "Her figure described a set of parabolas that could cause cardiac arrest > in a yak." --Woody Allen KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- [EMAIL PROTECTED] GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 Please do not remove my address from To: and Cc: fields in mailing lists. 10x PGP signature
Re: VM: dynamic swap remapping (patch)
On Sun, Sep 30, 2001 at 11:41:14PM -0500, Alfred Perlstein wrote: > > If it's any help, I have an AIX box here. It belongs to IBM, so I > > have to respect security issues, but I'll do what I can. I seem to remember that one could set a watermark using the no command, but I could be wrong. No AIX to verify this, maybe Greg can. The link below has some info, too: http://nscp.upenn.edu/aix4.3html/aixbman/prftungd/tunableaixparms.htm -- JoS Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM: dynamic swap remapping (patch)
Alfred Perlstein wrote: [ ... SIGDANGER ... ] > Well Joe seems to have provided a pretty interesting document on > how it works in AIX, but I was wondering if they do anything wrt > low/high watermarks like my idea. > > Basically you'd like to inform processes that the danger has been > alliviated so that they can cautiously start accepting more work > rather than freaking out and shutting out clients forever... The process is supposed to return unused memory to the system when it gets the signal, if it can. It's not supposed to shed all load until it gets the "all clear" signal. I don't know if there are any good books on Windows Internals, but the Windows VM system does the same thing: it notifies all kernel subsystems that they need to free up memory, if they can. The VFAT32 IFS will basically return exactly one page out of many thousands it is using for cache, when it gets the request (it is implemented as a callback, which you must provide when you register for VM services). > This might lead to a situation where SIGDANGER starts getting > sent informing that things are looking bleak, then processes > start freeing resources, they get the second SIGDANGER to let > them know that things are looking ok so they ramp up again and > the cycle repeats, I guess that's not optimal, but I'd like FreeBSD > to let processes know that things are looking better so they can > go from "scrooge mode" to "thrifty mode". The idea is just to free resources, if you can, and to mark the processes which are "precious" by whether or not they have a signal handler. A close reading of the other document posted (it seemed to be the admin manual from the URL) will indicate that the followon SIGKILL is not sent to the processes that have a SIGDANGER handler registered. Note that this does not mean that your process won't be killed off as a result of a page not present fault, so abusing the interface is not really tolerated very well by the system. I think signalling an "all clear" is really a bad idea; a soft hysteresis loop is much less prone to pendulum swings than a hard hysteresis loop (lesson #1 in the book "Fuzzy Logic"). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sio modification
In message <[EMAIL PROTECTED]>, Terry Lambert writes: >Bart Kus wrote: >> If I do have to write something, for my work to be included anywhere, I >> should be writing for the -CURRENT kernel, right? I presently run -STABLE, >> so that would obviously be the more comfortable kernel to write for...but it >> is *STABLE* after all. > >Most of us doing commercial developement write for -stable, and >give it out to be ported to -current by someone else, if we don't >have the time to do both. With the amount of code you have had to get integrated in our tree I can truly see how the workload would overwhelm you. Submissions should contain a -current version or they are likely to never make it into the tree... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
