**** BEGIN LOGGING AT Sun May 17 02:59:57 2020 May 17 15:06:51 zmatt: I actually found an old kernel module that implements pps for the dmtimer, though it isn't hugely valuable if you don't supply the timer with a higher clock May 17 15:07:35 I mean, having 1/(24 MHz) inaccuracy is better than having (random irq latency) inaccuracy May 17 15:07:39 the suggestion was to supply an external 24MHz clock and then use this timer as the clocksource May 17 15:07:49 system clocksource May 17 15:08:38 I'm confused, why would you need an external 24 MHz clock? May 17 15:10:24 hm, indeed May 17 15:10:30 I wouldn't want to use a clocksource that doesn't derive from the main oscillator, since that would make it impossible to relate to any other timer (like the one used by hardware timestamping of ethernet packets) May 17 15:11:49 (that's also why I created an eCAP clocksource driver, since when using a 24 MHz counter as system clock, linux will use a fixed-point approximation of "1000/24" to convert timer ticks into nanoseconds, causing slow drift compared to what you'd expect) May 17 15:21:31 zmatt: https://github.com/ddrown/pps-gmtimer May 17 15:24:15 yeah I'm not sure why you'd ever want to use an external clock source here May 17 15:25:04 you will want to make the timer you're using the system timer, hence I think using an eCAP would be better than using a dmtimer May 17 15:25:18 the general principle should be similar either way May 17 15:29:04 how is pps used anyway? I've never worked with the subsystem May 17 15:29:50 is it just a standardized API to deliver timestamps of the 1Hz signal (from e.g. a GPS receiver) to a userspace ntpd ? May 17 17:33:09 it seems so May 17 17:33:18 I have just started giving it a look May 17 17:34:55 the gpsdo I'm working on should double as a timesource, so I'm making myself familiar with how ntpd and chrony interface with e.g. gpsd May 17 17:40:46 hmm sounds like a reasonable idea, as GPS has fairly high time accuracy. May 17 18:08:44 it's funny, my dad had a gps navigation system which... didn't know the time, you have to set it manually May 17 18:08:50 it's hard to imagine a more epic failure May 17 21:05:49 really that's pretty strange since the clock is built in to the protocol.. May 17 21:06:59 that's exactly why it's an epic failure... it's impossible for a gps receiver to not know the time May 17 21:08:28 it could be it wasn't in the specification so it may not be the implementors fault. Knowing how things go "are you sure you don't want me to acquire the time too? if it takes any longer it's too long!" May 17 21:09:29 I'm pretty sure the receiver itself *has* to know the time as an integral part of the process of acquiring a fix May 17 21:09:47 but it may be an interface/API thing May 17 21:09:53 dunno, it's still dumb as shit May 17 21:10:20 right... having worked with a GPS that's exactly it. Qualcom has a lot of patents on the GPS stuff. May 17 21:11:21 you receive the time when you connect so yeah it doesn't make sense but seldom do products actually make sense May 17 21:14:14 Hey! May 17 21:14:21 Speaking of not making sense... May 17 21:14:36 I got cherrypy up and running today w/ some source! May 17 21:14:43 * GenTooMan hands set a pile of pennies. May 17 21:14:51 Their library is enormous. May 17 21:16:03 I am going to follow along in this book, "Python3 Web Developement," and try out cherrypy and jquery. May 17 21:17:34 I just finally made the starter script to the book work. May 17 21:48:05 good to hear May 17 21:52:21 Yea. They have all sorts of neat stuff you can do w/ python, jquery, .js, and css/html. **** ENDING LOGGING AT Mon May 18 02:59:57 2020