Re: Advice on deriving accurate time values from the kernel?
:Hi, : :I am in the process of developing a device driver for the purpose of :stepper motor control. The timing of each pulse is determined by :external timing hardware on an I/O board, which will fire an interrupt :after the time requested. Using this method, I am able to generate :streams of pulses at approximately 5000Hz on a Pentium II 400MHz system. : :Everything seems to be working well, but I'd really like to gather some :accurate timing data in order to derive some statistics to from the :system. Intuition tells me I'll need a clock with a tick rate of at :least 2 Hz to derive this. : :So, is such a thing available in the kernel? I've searched through :various mailing list archives and have found reference to the "HZ" :option to the kernel, which works to a point. However, it is not ideal :as setting HZ to high values generates far too much kernel overhead. :Also being considered is additional external timing hardware, but this :is something I'd rather avoid for many reasons. : :What I am after is not a "timer" as such - all I need to do is derive a :time value at an initial time, and a subsequent value at a later time. :I've used "getmicrouptime", but this appears dependent on the "Hz" :option, and as such is of limited use. : :I've just had some input from a colleauge who has suggested using the :Pentium profiling registers, which we are currently investigating... : :Any advice gratefully received, : :-- :Jennifer Clark Hmm. FreeBSD does not guarentee interrupt timing. If the system is busy doing other things your interrupts can be significantly delays (by microseconds, even milliseconds). I would definitely not try to control a stepper motor from an interrupt! What I recommend instead is that you put a microcontroller on the I/O board and have it do all the sensitive stepper motor timing, then write a device driver that does supervisory management of the microcontroller. For example, a small 68HC11F1 or an 8xC51 type of microcontrollor would work well. I prefer the 68HC11F1 myself because it has automatically timed output registers that make it easy to generate perfect waveforms. In regards to your question on accumulating statistics... that's a hard one. An external interrupt pulse is probably the easiest way to do it even though you do not like the idea. It may also be sufficient to call getmicrouptime from the interrupt you are already getting from the I/O board. Another possibility would be to write a user-level process with access to the I/O space (via /dev/mem or /dev/io) to poll in a tight loop and collect statistics that way. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Advice on deriving accurate time values from the kernel?
I've done some work on measuring things like interrupt response times and the interval between two interesting events or steps in processing. A cheap way to do this is to use the TSC register in the CPU, though you then need to calibrate the frequency that the CPU really runs at. If you're willing to spend some money, you can get hardware to plug into a PCI slot that can return timestamps in 100ns units, as well as generating interrupt at some time in the future, etc. See http://www.bancomm.com/cbc637PCI.htm for one example of such hardware. I have a device driver for FreeBSD for this board which even allows user processes to get precise timing by mmap()'ing the device registers into user space for easy access. The driver will be contributed to the FreeBSD project "soon." I was pretty close to doing so just prior to the newbus conversion and now need to update the driver for a more recent -current. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Advice on deriving accurate time values from the kernel?
:Hi, : :I am in the process of developing a device driver for the purpose of :stepper motor control. The timing of each pulse is determined by :external timing hardware on an I/O board, which will fire an interrupt :after the time requested. Using this method, I am able to generate :streams of pulses at approximately 5000Hz on a Pentium II 400MHz system. : :Everything seems to be working well, but I'd really like to gather some :accurate timing data in order to derive some statistics to from the :system. Intuition tells me I'll need a clock with a tick rate of at :least 2 Hz to derive this. : :So, is such a thing available in the kernel? I've searched through :various mailing list archives and have found reference to the HZ :option to the kernel, which works to a point. However, it is not ideal :as setting HZ to high values generates far too much kernel overhead. :Also being considered is additional external timing hardware, but this :is something I'd rather avoid for many reasons. : :What I am after is not a timer as such - all I need to do is derive a :time value at an initial time, and a subsequent value at a later time. :I've used getmicrouptime, but this appears dependent on the Hz :option, and as such is of limited use. : :I've just had some input from a colleauge who has suggested using the :Pentium profiling registers, which we are currently investigating... : :Any advice gratefully received, : :-- :Jennifer Clark Hmm. FreeBSD does not guarentee interrupt timing. If the system is busy doing other things your interrupts can be significantly delays (by microseconds, even milliseconds). I would definitely not try to control a stepper motor from an interrupt! What I recommend instead is that you put a microcontroller on the I/O board and have it do all the sensitive stepper motor timing, then write a device driver that does supervisory management of the microcontroller. For example, a small 68HC11F1 or an 8xC51 type of microcontrollor would work well. I prefer the 68HC11F1 myself because it has automatically timed output registers that make it easy to generate perfect waveforms. In regards to your question on accumulating statistics... that's a hard one. An external interrupt pulse is probably the easiest way to do it even though you do not like the idea. It may also be sufficient to call getmicrouptime from the interrupt you are already getting from the I/O board. Another possibility would be to write a user-level process with access to the I/O space (via /dev/mem or /dev/io) to poll in a tight loop and collect statistics that way. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Advice on deriving accurate time values from the kernel?
If you only want to timestamp events and not generate the event, you can use microtime() or nanotime(). On a 400MHz PII non-SMP you should get 2.5 ns resolution with nanotime(). On a normal kernel with kern.timecounter.method at the default of 0, the get... versions give you time at the last tick or even worse, so they are no good for that. John -- John Hay -- john@mikom.csir.co.za Hi, I am in the process of developing a device driver for the purpose of stepper motor control. The timing of each pulse is determined by external timing hardware on an I/O board, which will fire an interrupt after the time requested. Using this method, I am able to generate streams of pulses at approximately 5000Hz on a Pentium II 400MHz system. Everything seems to be working well, but I'd really like to gather some accurate timing data in order to derive some statistics to from the system. Intuition tells me I'll need a clock with a tick rate of at least 2 Hz to derive this. So, is such a thing available in the kernel? I've searched through various mailing list archives and have found reference to the HZ option to the kernel, which works to a point. However, it is not ideal as setting HZ to high values generates far too much kernel overhead. Also being considered is additional external timing hardware, but this is something I'd rather avoid for many reasons. What I am after is not a timer as such - all I need to do is derive a time value at an initial time, and a subsequent value at a later time. I've used getmicrouptime, but this appears dependent on the Hz option, and as such is of limited use. I've just had some input from a colleauge who has suggested using the Pentium profiling registers, which we are currently investigating... Any advice gratefully received, -- Jennifer Clark http://telepresence.dmem.strath.ac.uk http://www.crmjewellery.co.uk http://www.furniturenet.co.uk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Advice on deriving accurate time values from the kernel?
I've done some work on measuring things like interrupt response times and the interval between two interesting events or steps in processing. A cheap way to do this is to use the TSC register in the CPU, though you then need to calibrate the frequency that the CPU really runs at. If you're willing to spend some money, you can get hardware to plug into a PCI slot that can return timestamps in 100ns units, as well as generating interrupt at some time in the future, etc. See http://www.bancomm.com/cbc637PCI.htm for one example of such hardware. I have a device driver for FreeBSD for this board which even allows user processes to get precise timing by mmap()'ing the device registers into user space for easy access. The driver will be contributed to the FreeBSD project soon. I was pretty close to doing so just prior to the newbus conversion and now need to update the driver for a more recent -current. louie To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
