Date: Mon, 28 Jul 1997 01:30:01 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs Subject: Re: kern/4112: Re: PPSCLOCK kernel diffs Message-ID: <199707280830.BAA17961@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/4112; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: FreeBSD-gnats-submit@FreeBSD.ORG, leres@ee.lbl.gov Cc: Subject: Re: kern/4112: Re: PPSCLOCK kernel diffs Date: Mon, 28 Jul 1997 18:18:29 +1000 > Appended are context diffs to the 2.2.2-RELEASE kernel that > add the PPSCLOCK option. Although the system already has > the ability to capture DCD timestamps, the existing code > suffers from several problems. First, the timestamp is not > taken as soon as possible; measurements show that 2-3 > microseconds are lost on a really fast system like a 200 > MHz pentium pro. The latency is presumably because serial i/o or just checking for it takes some time, and DCD is checked after input. This time doesn't depend much on the CPU - the (lack of) speed of i/o instructions depends more on the bus than on the CPU. I don't think it is reasonable to attempy to support a latency of 2-3 microseconds in a general purpose driver or system. While the "fast interrupt handler" interface used by the sio driver gives it a chance of reaching such a latency, there is no chance of reaching it consistently unless there is only one active device with a fast interrupt handler in the whole system. Another active 16550A device (even on the same interrupt) would give up to about 75 usec of jitter, because it takes up to about 60 i/o instructions to handle one interrupt (more for the COM_MULTIPORT configuration), and each i/o instruction takes up to about 1.25 usec. The jitter can be reduced to about 10 usec per extra active 16550A device by not using the FIFO. I have some improvements to the interrupt handler that would get in the way of polling the modem status first. They depend on the UART actually working, so that the modem status doesn't need to be polled unless it has changed. The UART doesn't tell you that the modem status register should be read until you have processed what the UART considers to be higher priority events. > 2nd, the lack of a event serial number > makes it impossible to detect extra or missing pulses. OK. > The current layout has a new include file, sys/ppsclock.h. > It might be a better idea to move the contents of this file > into sys/ttycom.h and rename the two new ioctls so they > fit in with the other TIO* ioctls. Do you want the whole LBL copyright on the merged version? >+ #ifdef PPSCLOCK >+ /* >+ * Check the modem status now so we get a better >+ * timestamp (On a 200 MHZ Pentium Pro this makes >+ * a difference of about 2 or 3 microseconds...) >+ * >+ * If data carrier detect changed and it was the >+ * one we are waiting for (either leading or trailing >+ * edge) then grab the timestamp. >+ */ >+ modem_status = inb(com->modem_status_port); >+ if (com->do_pps_timestamp && >+ ((modem_status ^ com->last_modem_status) & MSR_DCD) != 0 && >+ com->pps_tet ^ ((modem_status & MSR_DCD) != 0)) { >+ microtime(&com->ppsclock.tv); >+ ++com->ppsclock.serial; >+ } >+ #endif This inherits a bug from the old code. I somehow convinced myself that it's OK to call microtime() from here. It's not. microtime() can only be called from ordinary interrupt handlers. Calling it from fast interrupt handlers may fail because of the following problems: 1. If microtime() uses the i8254 counter and not the "i586" TSC, then a clock overflow heuristic is used. The heuristic is fine-tuned to work at an i8254 clock interrupt period of 62.5 usec, and won't work if clock interrupts have been disabled for more than about TIMER0_LATCH_COUNT = 20 i8254 cycles (17 usec). Fast interrupt handlers often break this by keeping all interrupts disabled for 100 usec or so. 2. `time' is not valid in fast interrupt handlers, since the fast interrupt handler may have interrupted hardclock(). Therefore, the accesses to `time' in microtime() are invalid if microtime() is called from a fast interrupt handler. Note that the feature of fast interrupt handlers that causes this problem - that they can interrupt any normal interrupt handler - is the same feature that gives you a chance of getting very accurate timestamps. Also, the complications for the kernel PLL and PPSCLOCK in hardclock() make this nontrivial to fix - for a simple adjustment to `time' it would only be necessary to disable fast interrupts while doing the adjustment and to somehow keep track of the before and after states so that microtime() knows which one to use. In fact, the simple adjustment to `time' is already handled correctly for the TSC case in cpu_clockupdate(). Perhaps this case already works, because other adjustments are smaller than interrupt jitter. John Hay tried calling hardpps() from siointr1(). I don't like this, because hardpps() is probably too slow on slow machines. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707280830.BAA17961>