Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Tue, Sep 21, 2010 at 04:47:45PM -0400, Kyle Moffett wrote: Well how about something much more straightforward: I am about to post another patch set for discussion, so please comment on it when it appears. Thanks, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
Hi Richard, 1. Character device 2. POSIX clock with dynamic ids Please, just take your pick ;^) Just to reopen this nearly dead but very interesting thread: I'm happy with every solution that has no impact on the accuracy of the PTP clock. If I can choose, I would prefer the POSIX clock with dynamic ids solution. Kind regards and thanks for your effort, Stephan Gatzka smime.p7s Description: S/MIME Cryptographic Signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Fri, Aug 27, 2010 at 03:30:39PM -0700, John Stultz wrote: On Fri, 2010-08-27 at 14:38 +0200, Richard Cochran wrote: We have not introduced new PPS interface. We use existing PPS subsystem. Doesn't the pps subsystem have its own way to control the pps signal interrupt? I'm not totally sure here, but given your point above that having multiple pps events it seems like they should be selectable. It seems something that we'd want to control via the global pps interface, rather then having a pps-enable flag on every random bit of hardware that can support it. The PPS subsystem offers no way to disable PPS interrupts. Same for the timestamps and periodic output (ie: and how do they differ from reading or setting a timer on CLOCK_PTP?) The posix timer calls won't work: I have a PTP hardware clocks with multiple external timestamp channels. Using timer_gettime, how can I specify (or decode) the channel of interest to me? I guess I'm not following you here. Again, I'm not super familiar with the hardware involved. Could you clarify a bit more? What do you mean by external timestamp? Is this what is used on the packet timestamping? No, the packet timestamp occurs in the PHY, MAC, or on the MII bus and is an essential feature to support the PTP. An external timestamp is just a wire going into the clock and is an optional feature to make the clock more useful. The clock can latch the current time value when an edge is dectected on the wire. Using external timestamps, you correlate real world events with the absolute time in the clock. Typically, a clock offers two or more such input channels (wires), but timer_gettime does not offer a way to differentiate between them, and thus is not suitable. The posix clock id interface is frustrating because the flat static enumeration is really limiting. I wonder if a dynamic enumeration for posix clocks would be possibly a way to go? I am perfectly happy with this. In other words, a driver registers a clock with the system, and the system reserves a clock_id for it from the designated available pool and assigns it back. Then userland could query the driver via something like sysfs to get the clockid for the hardware. Would that maybe work? I have now posted a sample implementation of this idea. Do you like it? The sysfs will include one class device for each PTP clock. Each clock has a sysfs attribute with the corresponding clock id. Do you mean the clock_id # in the posix clocks namespace? Yes. I would also be happy with the character device idea already posted. Just pick one of the two, and I'll resubmit the patch set... Personally, with regard to exposing the ptp clock to userland I'm more comfortable via the chardev. However, the posix clocks/timer api is really close to what you need, so I'm not totally set against it. And maybe the dynamic enumeration would resolve my main problems with it? Okay, I have posted a draft of the dynamic idea. Can you support it? That said, with the chardev method, I don't like the idea of duplicating the existing time apis via a systemtime device. Dropping that from your earlier patch would ease the majority of my objections. Well, the clock interface needs to offer basic services: 1. Set time 2. Get time 3. Jump offset 4. Adjust frequency This is similar to what the posix clock and ntp API offer. Using a chardev, should I make the ioctls really different, just for the purpose of being different? To me, it makes more sense to offer a familiar interface. I was perfectly happy with the chardev idea. In fact, that is the way I first implemented it. Now, I have also gone ahead and implemented the dynamic posix clock idea, too. At this point I would just like to go forward with one of the two proposed APIs. I had modelled the character device on the posix clock calls in order to make it immediately familar, and I think it is a viable approach. After the lkml discussion, I think it is even cleaner and nicer to just offer a new clock id. I would like to repeat the sentiment in this last paragraph! I already implemented and would be content with either form for the new clock control API: 1. Character device 2. POSIX clock with dynamic ids Please, just take your pick ;^) Thanks, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
Alan Cox wrote: The master node in a PTP network probably takes its time from a precise external time source, like GPS. The GPS provides a 1 PPS directly to the PTP clock hardware, which latches the PTP hardware clock time on the PPS edge. This provides one sample as input to a clock servo (in the PTPd) that, in turn, regulates the PTP clock hardware. A PTP clock is TAI, Unix time is UTC. Not necessarily. AFAIK, the time distributed by IEEE1588v2 can either be based on the PTP epoch (timePropertiesDS.ptpTimescale=TRUE) and thus represent TAI or be based on an implementation specific arbitrary epoch (timePropertiesDS.ptpTimescale=FALSE) and represent time on some arbitrary time scale. Christian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Thu, Aug 26, 2010 at 06:57:49PM -0700, john stultz wrote: On Wed, 2010-08-25 at 11:40 +0200, Christian Riesch wrote: 2) Master clock: We have one or more network ports. Our system has a really good clock (ovenized quartz crystal, an atomic clock, a GPS timing receiver...) and it distributes this time on the network. In such a case we do not steer our clock based on the (packet) timestamps we get from our timestamping unit. Instead, we directly drive our clock hardware with a very stable frequency that we get from the OCXO or the atomic clock... Ok. Following you here... or we use one of the ancillary features of the PTP clock that Richard mentioned to timestamp not network packets but a 1pps signal and use these timestamps to steer the clock. Wait.. I thought we weren't using PTP to steer the clock? But now we're using the pps signal from it to do so? Do I misunderstand you? Or did you just not mean this? The master node in a PTP network probably takes its time from a precise external time source, like GPS. The GPS provides a 1 PPS directly to the PTP clock hardware, which latches the PTP hardware clock time on the PPS edge. This provides one sample as input to a clock servo (in the PTPd) that, in turn, regulates the PTP clock hardware. Packet time stamping is used to distribute the time to the slaves, but it is not part of the control loop in this case. I assume here you mean PTPd is steering the PTP clock according to the system time (which is NTP/GPS/whatever sourced)? And then the PTP clock distributes that time through the network? Yes, but in this case, system time has nothing to do with the Linux system time. For a PTP master clock, it really doesn't matter whether the Linux time is correct, or not. It doesn't hurt either (but see below about chaining servos). So first of all, thanks for the extra explanation and context here! I really appreciate it, as I'm not familiar with all the hardware details and possible use cases, but I'm trying to learn. So in the two cases you mention, the time flow is something like: #1) [Master Clock on Network1] = [PTP Clock] = [PTPd] = [PTP Clock] = [PTP Clients on Network2] I would only draw the PTP clock once, perhaps like this: +--+ | ^ V | [Master Clock on NW 1]---[HW timestamp]---[PTPd]--adj--[PTP Clock] [Slaves on NW 2,3,...]---[HW timestamp]---[] #2) [GPS] = [NTPd] = [System Time] = [PTPd] = [PTP clock] = [PTP clients on Network] Nope. More like this: +--+ | ^ V | [GPS]--PPS-[Latch timestamp]---[PTPd]--adj--[PTP Clock] [Slaves on NW 1,2,3,...]---[HW pkt timestamp]---[] And the original case: #3) [Master Clock on Network] = [PTP clock] = [PTPd] = [PTP clock] More like: [Master Clock on NW 1]---[HW timestamp]---[PTPd]--adj--[PTP Clock] With a secondary control flow: [PPS signal from PTP clock] = [NTPd] = [System Time] Yes. So, just brainstorming here, I guess the question I'm trying to figure out here, is can the System Time and PTP clock be merged/globbed into a single Time interface from the userspace point of view? This is the core issue and source of misunderstanding, in my view. The fact of the matter is, the current generation of computers has multiple clocks, and these are usually unsynchronized. I think we should not try too hard to cover up or work around this. It is a fact of life. It would be nice if there were only one clock, and that clock could do everything that we need. Indeed, the next generation of SoC computers may all have PTP build in to the main CPU. Well, one can always wish. If we can make it appear that multiple clocks are just one clock, then I agree that we should do it. But I would not want to sacrifice synchronization accuracy or application features just to keep that illusion. In other words, if internal to the kernel, the PTP clock was always synced to the system time, couldn't the flow look something like: #3') [Master clock on network] = [PTP clock] = [PTPd] = [System Time] = [in-kernel sync thread] = [PTP clock] So PTPd sees the offset adjustment from the PTP clock, and then feeds that offset correction right into (a possibly enhanced) adjtimex. The kernel would then immediately steer the PTP clock by the same amount to keep it in sync with system time (along with a periodic offset/freq correction step to deal with crystal drift). Similarly: #2') [GPS] = [NTPd] = [System Time] = [in-kernel sync thread] = [PTP clock] = [PTP clients on Network] and #1') [Master Clock on Network1] = [PTP Clock]
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Mon, Aug 23, 2010 at 01:21:39PM -0700, john stultz wrote: On Thu, 2010-08-19 at 17:38 +0200, Richard Cochran wrote: On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote: My point was that a syscall is better than an ioctl based interface here, which I definitely still think. Given that John knows much more about clocks than I do, we still need to get agreement on the question that he raised, which is whether we actually need to expose this clock to the user or not. If we can find a way to sync system time accurate enough with PTP and PPS, user applications may not need to see two separate clocks at all. At the very least, one user application (the PTPd) needs to see the PTP clock. SYSCALL_DEFINE3(clock_adjtime, const clockid_t, clkid, int, ppb, struct timespec __user *, ts) ppb - desired frequency adjustment in parts per billion ts - desired time step (or jump) in sec,nsec to correct a measured offset Arguably, this syscall might be useful for other clocks, too. This is a mix of adjtime and adjtimex with the addition of the clkid parameter, right? Sort of, but not really. ADJTIME(3) takes an offset and slowly corrects the clock using a servo in the kernel, over hours. For this function, the offset passed in the 'ts' parameter will be immediately corrected, by jumping to the new time. This reflects the way that PTP works. After the first few samples, the PTPd has an estimate of the offset to the master and the rate difference. The PTPd can proceed in one of two ways. 1. If resetting the clock is not desired, then the clock is set to the maximum adjustment (in the right direction) until the clock time is close to the master's time. 2. The estimated offset is added to the current time, resulting in a jump in time. We need clock_adjtime(id, 0, ts) for the second case. Have you considered passing a struct timex instead of ppb and ts? Yes, but the timex is not suitable, IMHO. Could you expand on this? We need to able to specify that the call is for a PTP clock. We could add that to the modes flag, like this: /*timex.h*/ #define ADJ_PTP_0 0x1 #define ADJ_PTP_1 0x2 #define ADJ_PTP_2 0x3 #define ADJ_PTP_3 0x4 I can live with this, if everyone else can, too. Could we not add a adjustment mode ADJ_SETOFFSET or something that would provide the instantaneous offset correction? Yes, but we would also need to add a struct timespec to the struct timex, in order to get nanosecond resolution. I think it would be possible to do in the padding at the end? You're right that the timex is a little crufty. But its legacy that we will support indefinitely. So following the established interface helps maintainability. We can use it for PTP, with the modifications suggested above. Or we can just introduce the clock_adjtime method, instead. So if the clock_adjtime interface is needed, it would seem best for it to be generic enough to support not only PTP, but also the NTP kernel PLL. For the proposed clock_adjime, what else is needed to support clock adjustment in general? I don't mind making the interface generic enough to support any (realistic) conceivable clock adjustment scheme, but beyond the present PTP hardware clocks, I don't know what else might be needed. Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Friday 27 August 2010, Richard Cochran wrote: On Mon, Aug 23, 2010 at 01:21:39PM -0700, john stultz wrote: On Thu, 2010-08-19 at 17:38 +0200, Richard Cochran wrote: On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote: Have you considered passing a struct timex instead of ppb and ts? Yes, but the timex is not suitable, IMHO. Could you expand on this? We need to able to specify that the call is for a PTP clock. We could add that to the modes flag, like this: /*timex.h*/ #define ADJ_PTP_0 0x1 #define ADJ_PTP_1 0x2 #define ADJ_PTP_2 0x3 #define ADJ_PTP_3 0x4 I can live with this, if everyone else can, too. My suggestion was actually to have a new syscall with the existing structure, and pass a clockid_t value to it, similar to your sys_clock_adjtime(), not change the actual sys_adjtime syscall. Could we not add a adjustment mode ADJ_SETOFFSET or something that would provide the instantaneous offset correction? Yes, but we would also need to add a struct timespec to the struct timex, in order to get nanosecond resolution. I think it would be possible to do in the padding at the end? Yes, that's exactly what the padding is for. Instead of timespec, you can probably have a extra values for replacing the existing ppm values with ppb values. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Mon, Aug 23, 2010 at 01:08:45PM -0700, john stultz wrote: On Thu, 2010-08-19 at 07:55 +0200, Richard Cochran wrote: The clockid_t CLOCK_PTP will be arch-neutral. Sure, but are they conceptually neutral? There are other clock synchronization algorithms out there. Will they need their own similar-but-different clock_ids? Look at the other clock ids and what the represent: IMHO, the presently offered clock ids are a mixed bag... CLOCK_REALTIME : Wall time (possibly freq/offset corrected) CLOCK_MONOTONIC: Monotonic time (possibly freq corrected). CLOCK_PROCESS_CPUTIME_ID: Process cpu time. CLOCK_THREAD_CPUTIME_ID: Thread cpu time. The amount of time a thread has been granted by the kernel is really not connected to the real passage of time, at least not in a direct way. CLOCK_MONOTONIC_RAW: Non freq corrected monotonic time. This one comes from commit 2d42244ae71d6c7b0884b5664cf2eda30fb2ae68 and is surely a special case, unrelated to the other clock ids. The commit message mentions that this was added to help the btime.sf.net project. That project does not seem to have had any activity since 2007. If we can justify adding a clock id in this case, surely we can add one for PTP as well! CLOCK_REALTIME_COARSE: Tick granular wall time (filesystem timestamp) CLOCK_MONOTONIC_COARSE: Tick granular monotonic time. These were added in commit da15cfdae03351c689736f8d142618592e3cebc3 in order to fulfill needs of special applications. CLOCK_PTP that you're proposing doesn't seem to be at the same level of abstraction. I'm not saying that this isn't the right place for it, but can we take a step back from PTP and consider what your exposing in more generic terms. In other words, could someone use the same packet-timestamping hardware to implement a different non-PTP time synchronization algorithm? Yes, of course. There is nothing at all in the patch set about the PTP protocol itself. It just lets you access the hardware. In short: 1. SO_TIMESTAMPING delivers timestamped packets 2. the PTP API lets you tune the clock. That's all, folks. Further, if we're using PTP to synchoronize the system time, then there shouldn't be any measurable difference between CLOCK_PTP and CLOCK_REALTIME, no? When using software timestamping, then the clocks are one in the same. When using PTP, with the PPS hook to synchoronize the Linux system time, the clocks will be a close as the servo algorithm provides. I have not measured this yet, but it cannot be much different than using any other PPS source. SYSCALL_DEFINE3(clock_adjtime, const clockid_t, clkid, int, ppb, struct timespec __user *, ts) ppb - desired frequency adjustment in parts per billion ts - desired time step (or jump) in sec,nsec to correct a measured offset Arguably, this syscall might be useful for other clocks, too. So yea, obviously the syscall should not be CLOCK_PTP specific, so we would want it to be usable against CLOCK_REALTIME. That said, the clock_adjtime your proposing does not seem to be sufficient for usage by NTPd. So this suggests that it is not generic enough. I don't think we need to support ntpd. It already has adjtimex, and it won't get any better by using another interface. I think the ancillary features from PTP hardware clocks should be made available throught the sysfs. A syscall for these would end up very ugly, looking like an ioctl. Also, it is hard to see how these features relate to the more general idea of the clockid. This may be a good approach, but be aware that adding stuff to sysfs requires similar scrutiny as adding a syscall. Yes, it will be properly documented and maintained. I have already implemented the ancillary stuff in two ways, via sysfs and with a character device. The next patch set will include them both, and you all can just choose which one to delete (or leave them both). In contrast, sysfs attributes will fit the need nicely: 1. enable or disable pps 2. enable or disable external timestamps 3. read out external timestamp 4. configure period for periodic output Things to consider here: Do having these options really make sense? Yes, since they represent the PTP clock's hardware features. As I explained previously, if you don't have any hardware interfaces, then having your clocks synchoronized to under 100 nanoseconds does not help you more than having them to within 1 microsecond. Why would we want pps disabled? If you are a master clock, then you want to take your PPS from an external time source, like GPS. If you leave the PTP PPS events on, then they will occur close in time to the GPS PPS events and may add unwanted latency to the interrupt handler. And if that does make sense, would it be better to do so via the existing pps interface instead of adding a new ptp specific one? We have not introduced new PPS interface. We use existing PPS subsystem. Same for the timestamps and periodic
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
So if the clock_adjtime interface is needed, it would seem best for it to be generic enough to support not only PTP, but also the NTP kernel PLL. For the proposed clock_adjime, what else is needed to support clock adjustment in general? Multiple PLLs, at least with containers and certain classes of system you want different containers in different timespaces, especially when doing high precision stuff where you need your system tracking say a local master clock for syncing musical instruments and sound events while tracking other clocks like NTP for general system time. I don't mind making the interface generic enough to support any (realistic) conceivable clock adjustment scheme, but beyond the present PTP hardware clocks, I don't know what else might be needed. Put the clock type in the new fields. It becomes u16 clock_type; [clock type specific data] saves having to guess. Alan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
The master node in a PTP network probably takes its time from a precise external time source, like GPS. The GPS provides a 1 PPS directly to the PTP clock hardware, which latches the PTP hardware clock time on the PPS edge. This provides one sample as input to a clock servo (in the PTPd) that, in turn, regulates the PTP clock hardware. A PTP clock is TAI, Unix time is UTC. This is the core issue and source of misunderstanding, in my view. The fact of the matter is, the current generation of computers has multiple clocks, and these are usually unsynchronized. I think we should not try too hard to cover up or work around this. It is a fact of life. In this case I don't think you can. Their divergence is rather difficult to handle unless you have a GPS to hand. But all this talk of PTP this and PTP that is not helpful. Any interface for additional time sources should be generic with PTP being one use case. Alan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
2007. If we can justify adding a clock id in this case, surely we can add one for PTP as well! But PTP isn't really a clock - its a time sync protocol. You can (and may need to) have multiple clocks of this form on the same host because it's master based and you may have to deal with multiple masters who disagree. Further, if we're using PTP to synchoronize the system time, then there shouldn't be any measurable difference between CLOCK_PTP and CLOCK_REALTIME, no? When using software timestamping, then the clocks are one in the same. Technically the POSIX clock is UTC, IEEE1588v2 is TAI. It would be possible, but not too nice, IMHO. In contrast to NTP, there is no real need to place the servo in the kernel. Having the protocol code and servo in user space makes life much easier. We can't currently put it in the kernel anyway for other good reasons. viable approach. After the lkml discussion, I think it is even cleaner and nicer to just offer a new clock id. PTP is not a clock, it's many clocks so a clock id doesn't really work. You could assume a single time domain and add a CLOCK_TAI plus then use PTP to track it I guess ? The question then is who would consume it and how ? Generic applications want POSIX time, which is managed by NTP but could in userspace also be slewed via the existing API to track a PTP source if someone wanted and if there is a GPS source around they can compute UTC from it. Specialist applications will presumably need to know which time source or sources they are tracking and synchronizing too out of multiple potential PTP sources Kernel stuff is more of a problem. I'm not sure shoehorning a source of many clocks and time sync bases into a jump up and down and make it fit single time assumption is wise. Making system time bimble track a source makes sense just as with NTP but making it a new clock seems the wrong model extending a non-too-bright API when you can just put the time sources in a file tree. Alan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
To tell the truth, my original motivation for the patch set was to support PTP clocks and applications. I don't think that is such a bad ptp *clocks* idea. After all, the adjtimex interface was added just to support NTP. At the same time, I can understand the desire to have a generic hardware clock adjustment API. Let me see if I can understand and summarize what people are asking for: clock_adjtime(clockid_t id, struct timex *t); and struct timex gets some new fields at the end. For a new syscall you could equally make it (clockid_t id, void *args) Using the call, NTPd can call clock_adjtime(CLOCK_REALTIME) and PTPd can call clock_realtime(CLOCK_PTP) and everyone is happy, no? If you only have one clock that you are calling 'the PTP clock' - but is that a good assumption ? I agree with your fundamental arguments as I understand them - That it's another clock or clocks possibly not synchronized with the system clock - That there should be a sensible API for doing slews and steps on other clocks but the systen clock. I'm concerned about the assumption that there is a single magic PTP clock, and calling it a PTP clock for two reasons - There can be more than one - PTP is just a protocol, in five years time it might be TICTOC or something newer and more wonderous, in some environments it'll be a synchronous distributed clock generation not PTP etc. Wiring PTP or IEE1588v2 into the clock name doesn't make sense. I'd be happier with a model which says we have some arbitary number of synchronization sources which may or may not have a connection to system time, and may be using all sorts of synchronization methods. Clock in fact seems almost a misnomer. Alan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Fri, Aug 27, 2010 at 02:38:44PM +0100, Alan Cox wrote: 2007. If we can justify adding a clock id in this case, surely we can add one for PTP as well! But PTP isn't really a clock - its a time sync protocol. You can (and may need to) have multiple clocks of this form on the same host because it's master based and you may have to deal with multiple masters who disagree. Okay, I really meant for PTP hardware clocks. In general the discussion is about supporting a kind of hardware and not about the PTP network protocol. In fact, the hardware clocks and clock servo loops are not at all part of the IEEE 1588 standard. Sorry for causing confusion, but please understand a hardware clock with timestamping capabilities than can be used for PTP support whenever I wrote PTP or PTP clock. Well, what I just said is not entirely true. In fact, most of the current crop of PTP hardware clocks operate by recognizing PTP network frames and timestamping them. One clock I know of can timestamp every frame, but that seems to be the exception rather than the rule. So, in theory they are just clocks, but actually most are bound to the PTP protocol. That may change in the future... viable approach. After the lkml discussion, I think it is even cleaner and nicer to just offer a new clock id. PTP is not a clock, it's many clocks so a clock id doesn't really work. You could assume a single time domain and add a CLOCK_TAI plus then use PTP to track it I guess ? The question then is who would consume it and how ? Generic applications want POSIX time, which is managed by NTP but could in userspace also be slewed via the existing API to track a PTP source if someone wanted and if there is a GPS source around they can compute UTC from it. Yes, and even without a GPS, the PTP protocol (this time I really do mean the protocol!) does provide the UTC offset whenever it is known. Specialist applications will presumably need to know which time source or sources they are tracking and synchronizing too out of multiple potential PTP sources Yes, the PTPd will have some special knowledge. Kernel stuff is more of a problem. I'm not sure shoehorning a source of many clocks and time sync bases into a jump up and down and make it fit single time assumption is wise. Making system time bimble track a source makes sense just as with NTP but making it a new clock seems the wrong model extending a non-too-bright API when you can just put the time sources in a file tree. Don't get your meaning here, what did you mean by file tree? Thanks, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
Sorry for causing confusion, but please understand a hardware clock with timestamping capabilities than can be used for PTP support whenever I wrote PTP or PTP clock. Ok that makes sense. Well, what I just said is not entirely true. most are bound to the PTP protocol. That may change in the future... Which seems fine to me too - its an implementation detail of that time source. Specialist applications will presumably need to know which time source or sources they are tracking and synchronizing too out of multiple potential PTP sources Yes, the PTPd will have some special knowledge. Not only that but consumers of different time synchronizations will need to be able to describe which time source they want to talk about from a selection of PTP or similar things. system time bimble track a source makes sense just as with NTP but making it a new clock seems the wrong model extending a non-too-bright API when you can just put the time sources in a file tree. Don't get your meaning here, what did you mean by file tree? Something like /sys/class/timesource/name/... at which point we don't have to enumerate them all, add special system calls and then fret about the fact you can't access them from things like shell scripts. The fact SYS5.4 Unix and SuS got obsessed with numbering things rather than using names unlike Unix doesn't mean it's the right model to number them - usually the reverse is true, a heirarchy of file names is rather more future proof. Alan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
In message: 20100827140205.ga3...@riccoc20.at.omicron.at Richard Cochran richardcoch...@gmail.com writes: : On Fri, Aug 27, 2010 at 01:41:54PM +0100, Alan Cox wrote: : The master node in a PTP network probably takes its time from a : precise external time source, like GPS. The GPS provides a 1 PPS : directly to the PTP clock hardware, which latches the PTP hardware : clock time on the PPS edge. This provides one sample as input to a : clock servo (in the PTPd) that, in turn, regulates the PTP clock : hardware. : : A PTP clock is TAI, Unix time is UTC. : : But TAI and UTC progress at the same rate, and UTC differs from TAI by : a constant offset. In fact, the needed conversion is provided by the : protocol, so it is not hard to take a 1 PPS from GPS and set the PTP : clock to TAI. Except for leap seconds, this is true. However, Unix time isn't UTC either. Unix time is UTC that pretends leap seconds just don't exist. POSIX enshrined this long ago, and nobody is going to change that any time soon. I don't believe IEEEv2 propagates leap seconds, does it? Warner ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
Hi! I'd like to add my two cents about the discussion. Just to shortly introduce myself: I'm working with PTP since version 2002 (now 2008 or PTPv2) and I'm developing matching network cards, drivers, and also sometimes a bit of the stack. I always had the problem of different HW implementations (even my own) and how to access the clocks there. So reading this thread, I strongly support the idea to provide a driver class, which allows the userspace to run certain standard operations (settime, gettime, adjtime, ...) as proposed and leave the detailed implementation to a specific PTP clock driver. I always made my own char device, but I don't want to open this discussion again as for me it doesn't matter. Concerning the long discussion about PTP clock, system time, etc. I'd like to say, that from a point of view of PTP every node/host has only one clock. That means, that if you have a NIC with integrated clock (required for HW timestamping) it is counted as a node. As soon as you want to use multiple NICs this is actually outside the PTP protocol definition, unless you have only one clock available to both network interfaces (which is hard to achieve). So the solution to treat a PTP enabled NIC as a time source for the system time is in general sufficient, unless for applications that require precise timestamps in applications. I know of use cases where code gets instrumented to measure time delays, processing time, and sequence in SW, e.g. distributed databases for trading systems at the stock exchange. Summarizing I think it would be a huge step forward, if all the different HW implementations could be controlled via a standardised interface through the kernel. I need timestamps from my network card with ps resolution and to steer the onboard clock from user space. Then I would be happy already. :-) Thanks, Patrick ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Fri, Aug 27, 2010 at 8:06 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote system time bimble track a source makes sense just as with NTP but making it a new clock seems the wrong model extending a non-too-bright API when you can just put the time sources in a file tree. Don't get your meaning here, what did you mean by file tree? Something like /sys/class/timesource/name/... at which point we don't have to enumerate them all, add special system calls and then fret about the fact you can't access them from things like shell scripts. I agree that this interface is the best way to be future proof. This appears to allow for multiple clocks or nodes, and doesn't get messed up when we add more than one NIC with separate clocks to a machine. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Fri, 2010-08-27 at 13:08 +0200, Richard Cochran wrote: On Mon, Aug 23, 2010 at 01:21:39PM -0700, john stultz wrote: On Thu, 2010-08-19 at 17:38 +0200, Richard Cochran wrote: On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote: My point was that a syscall is better than an ioctl based interface here, which I definitely still think. Given that John knows much more about clocks than I do, we still need to get agreement on the question that he raised, which is whether we actually need to expose this clock to the user or not. If we can find a way to sync system time accurate enough with PTP and PPS, user applications may not need to see two separate clocks at all. At the very least, one user application (the PTPd) needs to see the PTP clock. SYSCALL_DEFINE3(clock_adjtime, const clockid_t, clkid, int, ppb, struct timespec __user *, ts) ppb - desired frequency adjustment in parts per billion ts - desired time step (or jump) in sec,nsec to correct a measured offset Arguably, this syscall might be useful for other clocks, too. This is a mix of adjtime and adjtimex with the addition of the clkid parameter, right? Sort of, but not really. ADJTIME(3) takes an offset and slowly corrects the clock using a servo in the kernel, over hours. For this function, the offset passed in the 'ts' parameter will be immediately corrected, by jumping to the new time. This reflects the way that PTP works. After the first few samples, the PTPd has an estimate of the offset to the master and the rate difference. The PTPd can proceed in one of two ways. 1. If resetting the clock is not desired, then the clock is set to the maximum adjustment (in the right direction) until the clock time is close to the master's time. 2. The estimated offset is added to the current time, resulting in a jump in time. We need clock_adjtime(id, 0, ts) for the second case. Have you considered passing a struct timex instead of ppb and ts? Yes, but the timex is not suitable, IMHO. Could you expand on this? We need to able to specify that the call is for a PTP clock. We could add that to the modes flag, like this: /*timex.h*/ #define ADJ_PTP_0 0x1 #define ADJ_PTP_1 0x2 #define ADJ_PTP_2 0x3 #define ADJ_PTP_3 0x4 I can live with this, if everyone else can, too. I wasn't suggesting adding the clock multiplexing to the timex, just using the timex to specify the adjustments in the clock_adjtime call. So I was asking why a timex was not suitable instead of using just the ppb and timespec. Could we not add a adjustment mode ADJ_SETOFFSET or something that would provide the instantaneous offset correction? Yes, but we would also need to add a struct timespec to the struct timex, in order to get nanosecond resolution. I think it would be possible to do in the padding at the end? The existing struct timeval in the timex can be also used as a timespec. NTPv4 uses it that way specifying the ADJ_NANO flag. You're right that the timex is a little crufty. But its legacy that we will support indefinitely. So following the established interface helps maintainability. We can use it for PTP, with the modifications suggested above. Or we can just introduce the clock_adjtime method, instead. Again, I think you misunderstood my suggestion. I was suggesting something like clock_adjtime(clock_id, struct timex*). So if the clock_adjtime interface is needed, it would seem best for it to be generic enough to support not only PTP, but also the NTP kernel PLL. For the proposed clock_adjime, what else is needed to support clock adjustment in general? I don't mind making the interface generic enough to support any (realistic) conceivable clock adjustment scheme, but beyond the present PTP hardware clocks, I don't know what else might be needed. I think using the timex struct covers most of the existing knowledge of what is needed. thanks -john ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Fri, 2010-08-27 at 14:03 +0200, Arnd Bergmann wrote: On Friday 27 August 2010, Richard Cochran wrote: On Mon, Aug 23, 2010 at 01:21:39PM -0700, john stultz wrote: On Thu, 2010-08-19 at 17:38 +0200, Richard Cochran wrote: On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote: Have you considered passing a struct timex instead of ppb and ts? Yes, but the timex is not suitable, IMHO. Could you expand on this? We need to able to specify that the call is for a PTP clock. We could add that to the modes flag, like this: /*timex.h*/ #define ADJ_PTP_0 0x1 #define ADJ_PTP_1 0x2 #define ADJ_PTP_2 0x3 #define ADJ_PTP_3 0x4 I can live with this, if everyone else can, too. My suggestion was actually to have a new syscall with the existing structure, and pass a clockid_t value to it, similar to your sys_clock_adjtime(), not change the actual sys_adjtime syscall. Could we not add a adjustment mode ADJ_SETOFFSET or something that would provide the instantaneous offset correction? Yes, but we would also need to add a struct timespec to the struct timex, in order to get nanosecond resolution. I think it would be possible to do in the padding at the end? Yes, that's exactly what the padding is for. Instead of timespec, you can probably have a extra values for replacing the existing ppm values with ppb values. Right, although the ppm/ppb issue shouldn't be a problem as the timex allows for much finer then ppb resolution changes. The only adjustment to the adjtimex/timex interface that may be needed is the ability to set the time by an offset (ie: ADJ_SETOFFSET), rather then slewing the offset in (ADJ_OFFSET, or ADJ_OFFSET_SINGLESHOT). This avoids the calc offset, gettime(now), settime(now+offset) method where any latency between the gettime and settime adds to the error. thanks -john thanks -john ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Fri, 2010-08-27 at 14:38 +0200, Richard Cochran wrote: On Mon, Aug 23, 2010 at 01:08:45PM -0700, john stultz wrote: On Thu, 2010-08-19 at 07:55 +0200, Richard Cochran wrote: The clockid_t CLOCK_PTP will be arch-neutral. Sure, but are they conceptually neutral? There are other clock synchronization algorithms out there. Will they need their own similar-but-different clock_ids? Look at the other clock ids and what the represent: IMHO, the presently offered clock ids are a mixed bag... CLOCK_REALTIME : Wall time (possibly freq/offset corrected) CLOCK_MONOTONIC: Monotonic time (possibly freq corrected). CLOCK_PROCESS_CPUTIME_ID: Process cpu time. CLOCK_THREAD_CPUTIME_ID: Thread cpu time. The amount of time a thread has been granted by the kernel is really not connected to the real passage of time, at least not in a direct way. CLOCK_MONOTONIC_RAW: Non freq corrected monotonic time. This one comes from commit 2d42244ae71d6c7b0884b5664cf2eda30fb2ae68 and is surely a special case, unrelated to the other clock ids. The commit message mentions that this was added to help the btime.sf.net project. That project does not seem to have had any activity since 2007. If we can justify adding a clock id in this case, surely we can add one for PTP as well! I'm not opposed to adding a clock id, I just want it to be generic enough to make sense. So while MONOTONIC_RAW it was spurred into being from btime, it isn't a CLOCK_BTIME interface. I've also been pushing the RADClock folks to use it since it avoids the ugly raw hardware access they want to get access to a constant freq counter. In addition, I've used it to monitor freq adjustments done by NTP. CLOCK_REALTIME_COARSE: Tick granular wall time (filesystem timestamp) CLOCK_MONOTONIC_COARSE: Tick granular monotonic time. These were added in commit da15cfdae03351c689736f8d142618592e3cebc3 in order to fulfill needs of special applications. Right, but what they represent and how its different from CLOCK_REALTIME is easy to describe in a generic way. CLOCK_PTP that you're proposing doesn't seem to be at the same level of abstraction. I'm not saying that this isn't the right place for it, but can we take a step back from PTP and consider what your exposing in more generic terms. In other words, could someone use the same packet-timestamping hardware to implement a different non-PTP time synchronization algorithm? Yes, of course. There is nothing at all in the patch set about the PTP protocol itself. It just lets you access the hardware. In short: 1. SO_TIMESTAMPING delivers timestamped packets 2. the PTP API lets you tune the clock. That's all, folks. Right. So CLOCK_SO_TIMESTAMP is maybe a better description? And isn't it just an adjustment interface, not a PTP API to tune the clock? Further, if we're using PTP to synchoronize the system time, then there shouldn't be any measurable difference between CLOCK_PTP and CLOCK_REALTIME, no? When using software timestamping, then the clocks are one in the same. So this is the duplication I don't like. If the API represents CLOCK_PTP or whatever as something different from CLOCK_REALTIME, there shouldn't be a mode where they're the same. That would just cause confusion. Instead CLOCK_PTP calls just return -EINVAL and the PTPd application should use CLOCK_REALTIME. When using PTP, with the PPS hook to synchoronize the Linux system time, the clocks will be a close as the servo algorithm provides. I have not measured this yet, but it cannot be much different than using any other PPS source. SYSCALL_DEFINE3(clock_adjtime, const clockid_t, clkid, int, ppb, struct timespec __user *, ts) ppb - desired frequency adjustment in parts per billion ts - desired time step (or jump) in sec,nsec to correct a measured offset Arguably, this syscall might be useful for other clocks, too. So yea, obviously the syscall should not be CLOCK_PTP specific, so we would want it to be usable against CLOCK_REALTIME. That said, the clock_adjtime your proposing does not seem to be sufficient for usage by NTPd. So this suggests that it is not generic enough. I don't think we need to support ntpd. It already has adjtimex, and it won't get any better by using another interface. I strongly disagree. If the new interface isn't generic enough that NTPd couldn't use it to adjust CLOCK_REALTIME, then its too specific to only your needs. There will be other clock sync algorithms down the road, so if we have to expose this sort of timestamping hardware to userland, we need to allow those other sync methods to use the API you're providing, so if you're API isn't a superset of the existing adjustment needs, then its already missing something. I'm not saying we have to implement the kernel PLL adjustment and every other adjustment mode for every CLOCK_ID right now, but we should be able to extend things
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Wed, 2010-08-25 at 11:40 +0200, Christian Riesch wrote: What you describe here is only one of the use cases. If the hardware has a single network port and operates as a PTP slave, it timestamps the PTP packets that are sent and received and subsequently uses these timestamps and the information it received from the master in the packets to steer its clock to align it with the master clock. In such a case the timestamping hardware and the clock hardware work together closely and it seems to be okay to use the same interface to control both the timestamping and the PTP clock. But we have to consider other use cases, e.g., 1) Boundary clocks: We have more than one network port. One port operates as a slave clock, our system gets time information via this port and steers its PTP clock to align with the master clock. The other network ports of our system operate as master clocks and redistribute the time information we got from the master to other clocks on these networks. In such a case we do timestamping on each of the network ports, but we only have a single PTP clock. Each network port's timestamping hardware uses the same hardware clock to generate time stamps. 2) Master clock: We have one or more network ports. Our system has a really good clock (ovenized quartz crystal, an atomic clock, a GPS timing receiver...) and it distributes this time on the network. In such a case we do not steer our clock based on the (packet) timestamps we get from our timestamping unit. Instead, we directly drive our clock hardware with a very stable frequency that we get from the OCXO or the atomic clock... Ok. Following you here... or we use one of the ancillary features of the PTP clock that Richard mentioned to timestamp not network packets but a 1pps signal and use these timestamps to steer the clock. Wait.. I thought we weren't using PTP to steer the clock? But now we're using the pps signal from it to do so? Do I misunderstand you? Or did you just not mean this? Packet time stamping is used to distribute the time to the slaves, but it is not part of the control loop in this case. I assume here you mean PTPd is steering the PTP clock according to the system time (which is NTP/GPS/whatever sourced)? And then the PTP clock distributes that time through the network? So in the first case we have one PTP clock but several network packet timestamping units, whereas in the second case the packet timestamping is done but it is not part of the control loop that steers the clock. Of course in most hardware implementations both the PTP clock and the timestamping unit sit on the same chip and often use the same means of communication to the cpu, e.g., the MDIO bus, but I think we need some logical separation here. So first of all, thanks for the extra explanation and context here! I really appreciate it, as I'm not familiar with all the hardware details and possible use cases, but I'm trying to learn. So in the two cases you mention, the time flow is something like: #1) [Master Clock on Network1] = [PTP Clock] = [PTPd] = [PTP Clock] = [PTP Clients on Network2] #2) [GPS] = [NTPd] = [System Time] = [PTPd] = [PTP clock] = [PTP clients on Network] And the original case: #3) [Master Clock on Network] = [PTP clock] = [PTPd] = [PTP clock] With a secondary control flow: [PPS signal from PTP clock] = [NTPd] = [System Time] Right? So, just brainstorming here, I guess the question I'm trying to figure out here, is can the System Time and PTP clock be merged/globbed into a single Time interface from the userspace point of view? In other words, if internal to the kernel, the PTP clock was always synced to the system time, couldn't the flow look something like: #3') [Master clock on network] = [PTP clock] = [PTPd] = [System Time] = [in-kernel sync thread] = [PTP clock] So PTPd sees the offset adjustment from the PTP clock, and then feeds that offset correction right into (a possibly enhanced) adjtimex. The kernel would then immediately steer the PTP clock by the same amount to keep it in sync with system time (along with a periodic offset/freq correction step to deal with crystal drift). Similarly: #2') [GPS] = [NTPd] = [System Time] = [in-kernel sync thread] = [PTP clock] = [PTP clients on Network] and #1') [Master Clock on Network1] = [PTP Clock] = [PTPd] = [System Time] = [in-kernel sync thread] = [PTP Clock] = [PTP Clients on Network2] Now, I realize PTP purists probably won't like this, because it effectively makes the in-kernel sync thread similar to a PTP boundary clock (or worse, since the control loop isn't exactly direct). But considering that the kernel (internally) allows for *very* fine-grained adjustments (we keep our long-term offset error in (nanoseconds 32) ie: ~quarter-*billion*ths of a nanosecond - I think that's sub-attosecond, if I recall the unit). And even the existing external
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Mon, Aug 23, 2010 at 10:08 PM, john stultz johns...@us.ibm.com wrote: On Thu, 2010-08-19 at 07:55 +0200, Richard Cochran wrote: On Wed, Aug 18, 2010 at 05:12:56PM -0700, john stultz wrote: Again, my knowledge in the networking stack is pretty limited. But it would seem that having an interface that does something to the effect of adjust the timestamp clock on the hardware that generated it from this packet by Xppb would feel like the right level of abstraction. Its closely related to SO_TIMESTAMP, option right? Would something like using the setsockopt/getsockopt interface with SO_TIMESTAMP_ADJUST/OFFSET/SET/etc be reasonable? The clock and its adjustment have nothing to do with a network socket. The current PTP hacks floating around all add private ioctls to the MAC driver. That is the *wrong* way to do it. Could you clarify on *why* that is the wrong approach? Maybe this is where some of the confusion is coming from? The subtleties of the more generic PTP algorithm and how the existence of PTP hardware clocks change things are not clear to me. My understanding of ptp and the networking details around it is limited, so your expertise is appreciated. Might you consider covering some of this via a Documentation/ptp/overview.txt file in a future version of your patch? Here's a summary of what I understand: So from: http://en.wikipedia.org/wiki/Precision_Time_Protocol#Synchronization We see the message exchange of Sync/Delay_Req/Delay_Resp, and the calculation of the local offset from the server (and then a frequency adjustment over time as offsets values are accumulated). Without the hardware clock, this all of these messages and their corresponding timestamps are likely created by PTPd, using clock_gettime and then adjtimex() to correct for the calculated offset or freq adjustment. No extra interfaces are necessary, and PTPd is syncing the system time as accurately as it can. This is how the existing ptpd projects on the web seem to function. Now, with PTP hardware on the system, my understanding of what you're trying to enable with your patches is that the PTP hardware does the timestamping on both incoming and outgoing messages. PTPd then reads the pre-timestamped messages, calculates the offset and freq correction, and then feeds that back into the PTP hardware via your interface. No time correction is done at all by PTPd. John, What you describe here is only one of the use cases. If the hardware has a single network port and operates as a PTP slave, it timestamps the PTP packets that are sent and received and subsequently uses these timestamps and the information it received from the master in the packets to steer its clock to align it with the master clock. In such a case the timestamping hardware and the clock hardware work together closely and it seems to be okay to use the same interface to control both the timestamping and the PTP clock. But we have to consider other use cases, e.g., 1) Boundary clocks: We have more than one network port. One port operates as a slave clock, our system gets time information via this port and steers its PTP clock to align with the master clock. The other network ports of our system operate as master clocks and redistribute the time information we got from the master to other clocks on these networks. In such a case we do timestamping on each of the network ports, but we only have a single PTP clock. Each network port's timestamping hardware uses the same hardware clock to generate time stamps. 2) Master clock: We have one or more network ports. Our system has a really good clock (ovenized quartz crystal, an atomic clock, a GPS timing receiver...) and it distributes this time on the network. In such a case we do not steer our clock based on the (packet) timestamps we get from our timestamping unit. Instead, we directly drive our clock hardware with a very stable frequency that we get from the OCXO or the atomic clock... or we use one of the ancillary features of the PTP clock that Richard mentioned to timestamp not network packets but a 1pps signal and use these timestamps to steer the clock. Packet time stamping is used to distribute the time to the slaves, but it is not part of the control loop in this case. So in the first case we have one PTP clock but several network packet timestamping units, whereas in the second case the packet timestamping is done but it is not part of the control loop that steers the clock. Of course in most hardware implementations both the PTP clock and the timestamping unit sit on the same chip and often use the same means of communication to the cpu, e.g., the MDIO bus, but I think we need some logical separation here. Christian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
Hello! I'm curious if its possible to do the PTP hardware offset/adjustment calculation in a module internally to the kernel? That would allow the PPS interface to still be used to sync the system time, and not expose additional interfaces. Just my 2 cents on this issue. PTP is very often used in embedded systems, where the PTP timestamps will go into some dedicated hardware, for instance an FPGA. I'm currently working on a project where it is not necessary to adjust the Linux system time via PTP (although it would be a nice to have), but we only need the timestamps from the PHY to put them into our FPGA device. So we need some kind of API to access the PTP timestamp registers. Kind regards, Stephan smime.p7s Description: S/MIME Cryptographic Signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
Sorry for the slow response here, I got busy with other work at the end of last week. On Thu, 2010-08-19 at 07:55 +0200, Richard Cochran wrote: On Wed, Aug 18, 2010 at 05:12:56PM -0700, john stultz wrote: On Wed, 2010-08-18 at 09:19 +0200, Richard Cochran wrote: The timer/alarm stuff is ancillary and is not at all necessary. It is just a nice to have. I will happily remove it, if it is too troubling for people. If there's a compelling argument for it, I'm interested to hear. But again, it seems like just yet-another-way-to-get-alarm/timer-functionality, so before we add an extra API (or widen an existing API) I'd like to understand the need. We don't really need it, IMHO. But if we offer clockid_t CLOCK_PTP, then we get timer_settime() without any extra effort. Sure. There are some clear parallels and the API seems to match, but what I'm asking is: does it make sense from an overall API view that application developers have to understand? I was emulating the posix interface. Instead I should use it directly. I'm definitely interested to see what you come up with here. I'm still hesitant with adding a PTP clock_id, but extending the posix-clocks interface in this way isn't unprecedented (see: CLOCK_SGI_CYCLE) I just would like to make sure we don't end up with a clock_id namespace littered with oddball clocks that were not well abstracted (see: CLOCK_SGI_CYCLE :). For instance: imagine if instead of keeping the clocksource abstraction internal to the timekeeping core, we exposed each clocksource to userland via a clock_id. Every arch would have different ids, and each arch might have multiple ids. Programming against that would be a huge pain. The clockid_t CLOCK_PTP will be arch-neutral. Sure, but are they conceptually neutral? There are other clock synchronization algorithms out there. Will they need their own similar-but-different clock_ids? Look at the other clock ids and what the represent: CLOCK_REALTIME : Wall time (possibly freq/offset corrected) CLOCK_MONOTONIC: Monotonic time (possibly freq corrected). CLOCK_PROCESS_CPUTIME_ID: Process cpu time. CLOCK_THREAD_CPUTIME_ID: Thread cpu time. CLOCK_MONOTONIC_RAW: Non freq corrected monotonic time. CLOCK_REALTIME_COARSE: Tick granular wall time (filesystem timestamp) CLOCK_MONOTONIC_COARSE: Tick granular monotonic time. CLOCK_PTP that you're proposing doesn't seem to be at the same level of abstraction. I'm not saying that this isn't the right place for it, but can we take a step back from PTP and consider what your exposing in more generic terms. In other words, could someone use the same packet-timestamping hardware to implement a different non-PTP time synchronization algorithm? Further, if we're using PTP to synchoronize the system time, then there shouldn't be any measurable difference between CLOCK_PTP and CLOCK_REALTIME, no? So in thinking about this, try to focus on what the new clock_id provides that the other existing clockids do not? Are they at comparable levels of abstraction? 15 years from now, are folks likely to still be using it? Will it be maintainable? etc... Arnd convinced me that clockid_t=CLOCK_PTP is a good fit. My plan would be to introduce just one additional syscall: SYSCALL_DEFINE3(clock_adjtime, const clockid_t, clkid, int, ppb, struct timespec __user *, ts) ppb - desired frequency adjustment in parts per billion ts - desired time step (or jump) in sec,nsec to correct a measured offset Arguably, this syscall might be useful for other clocks, too. So yea, obviously the syscall should not be CLOCK_PTP specific, so we would want it to be usable against CLOCK_REALTIME. That said, the clock_adjtime your proposing does not seem to be sufficient for usage by NTPd. So this suggests that it is not generic enough. I think the ancillary features from PTP hardware clocks should be made available throught the sysfs. A syscall for these would end up very ugly, looking like an ioctl. Also, it is hard to see how these features relate to the more general idea of the clockid. This may be a good approach, but be aware that adding stuff to sysfs requires similar scrutiny as adding a syscall. In contrast, sysfs attributes will fit the need nicely: 1. enable or disable pps 2. enable or disable external timestamps 3. read out external timestamp 4. configure period for periodic output Things to consider here: Do having these options really make sense? Why would we want pps disabled? And if that does make sense, would it be better to do so via the existing pps interface instead of adding a new ptp specific one? Same for the timestamps and periodic output (ie: and how do they differ from reading or setting a timer on CLOCK_PTP?) 1. Use Case: SW timestamping The way I tend to see it: PTP is just one of the many ways to sync system time. 2. Use Case: HW timestamping for industrial control These
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Thu, 2010-08-19 at 17:38 +0200, Richard Cochran wrote: On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote: My point was that a syscall is better than an ioctl based interface here, which I definitely still think. Given that John knows much more about clocks than I do, we still need to get agreement on the question that he raised, which is whether we actually need to expose this clock to the user or not. If we can find a way to sync system time accurate enough with PTP and PPS, user applications may not need to see two separate clocks at all. At the very least, one user application (the PTPd) needs to see the PTP clock. SYSCALL_DEFINE3(clock_adjtime, const clockid_t, clkid, int, ppb, struct timespec __user *, ts) ppb - desired frequency adjustment in parts per billion ts - desired time step (or jump) in sec,nsec to correct a measured offset Arguably, this syscall might be useful for other clocks, too. This is a mix of adjtime and adjtimex with the addition of the clkid parameter, right? Sort of, but not really. ADJTIME(3) takes an offset and slowly corrects the clock using a servo in the kernel, over hours. For this function, the offset passed in the 'ts' parameter will be immediately corrected, by jumping to the new time. This reflects the way that PTP works. After the first few samples, the PTPd has an estimate of the offset to the master and the rate difference. The PTPd can proceed in one of two ways. 1. If resetting the clock is not desired, then the clock is set to the maximum adjustment (in the right direction) until the clock time is close to the master's time. 2. The estimated offset is added to the current time, resulting in a jump in time. We need clock_adjtime(id, 0, ts) for the second case. Have you considered passing a struct timex instead of ppb and ts? Yes, but the timex is not suitable, IMHO. Could you expand on this? Could we not add a adjustment mode ADJ_SETOFFSET or something that would provide the instantaneous offset correction? Is using ppb instead of the timex ppm required to get the accuracy you want? That is one very good reason. Another is this: can you explain what the 20+ fields mean? Consider the field, freq. The comment says frequency offset (scaled ppm). To what is it scaled? The only way I know of to find out is to read the NTP code (which is fairly complex) and see what the unit really is meant to be. Ditto for the other fields. The timex structure reveals, AFAICT, the inner workings of the kernel clock servo. For PTP, we don't need or want the kernel servo. The PTPd has its own clock servo in user space. You're right that the timex is a little crufty. But its legacy that we will support indefinitely. So following the established interface helps maintainability. So if the clock_adjtime interface is needed, it would seem best for it to be generic enough to support not only PTP, but also the NTP kernel PLL. In effect, this would make clock_adjtime(or clock_adjtimex) identical to adjtimex, but only applicable to different CLOCK_ids. Additionally, it would simplify the code for the CLOCK_REALTIME case as you could just call directly into do_adjtimex(). Of course, extending adjtimex for ADJ_SETOFFSET would be needed first, but that seems like a reasonable expansion of the interface that could be used by more then just PTP. thanks -john ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Wed, Aug 18, 2010 at 05:02:03PM +0200, Arnd Bergmann wrote: You might want to use callbacks for these system calls that you can register to at module load time, like it is done for the existing syscalls. Can you point me to a specific example? The simpler way (e.g. for testing) is using Kconfig dependencies, like config PTP bool IEEE 1588 Precision Time Protocol config PPS tristate Pulse per Second depends on PTP || !PTP The depends statement is a way of expressing that when PTP is enabled, PPS cannot be a module, while it may be a module if PTP is disabled. THis did not work for me. What I got was, in effect, two independent booleans. Thanks, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Thursday 19 August 2010, Richard Cochran wrote: On Wed, Aug 18, 2010 at 05:12:56PM -0700, john stultz wrote: On Wed, 2010-08-18 at 09:19 +0200, Richard Cochran wrote: The timer/alarm stuff is ancillary and is not at all necessary. It is just a nice to have. I will happily remove it, if it is too troubling for people. If there's a compelling argument for it, I'm interested to hear. But again, it seems like just yet-another-way-to-get-alarm/timer-functionality, so before we add an extra API (or widen an existing API) I'd like to understand the need. We don't really need it, IMHO. But if we offer clockid_t CLOCK_PTP, then we get timer_settime() without any extra effort. Makes sense. So in thinking about this, try to focus on what the new clock_id provides that the other existing clockids do not? Are they at comparable levels of abstraction? 15 years from now, are folks likely to still be using it? Will it be maintainable? etc... Arnd convinced me that clockid_t=CLOCK_PTP is a good fit. My point was that a syscall is better than an ioctl based interface here, which I definitely still think. Given that John knows much more about clocks than I do, we still need to get agreement on the question that he raised, which is whether we actually need to expose this clock to the user or not. If we can find a way to sync system time accurate enough with PTP and PPS, user applications may not need to see two separate clocks at all. My plan would be to introduce just one additional syscall: SYSCALL_DEFINE3(clock_adjtime, const clockid_t, clkid, int, ppb, struct timespec __user *, ts) ppb - desired frequency adjustment in parts per billion ts - desired time step (or jump) in sec,nsec to correct a measured offset Arguably, this syscall might be useful for other clocks, too. This is a mix of adjtime and adjtimex with the addition of the clkid parameter, right? Have you considered passing a struct timex instead of ppb and ts? Is using ppb instead of the timex ppm required to get the accuracy you want? Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Thursday 19 August 2010, Richard Cochran wrote: On Wed, Aug 18, 2010 at 05:02:03PM +0200, Arnd Bergmann wrote: You might want to use callbacks for these system calls that you can register to at module load time, like it is done for the existing syscalls. Can you point me to a specific example? The struct k_clock contains callback functions to clock source specific implementations of the syscalls and other functions. Adding a new clock source that is (potentially) implemented as a module means you have to define a new k_clock in that module that you register using register_posix_clock. If you need additional syscalls to be implemented by the same module, you can put more callback functions into struct k_clock that would then only be implemented by the new module. The simpler way (e.g. for testing) is using Kconfig dependencies, like config PTP bool IEEE 1588 Precision Time Protocol config PPS tristate Pulse per Second depends on PTP || !PTP The depends statement is a way of expressing that when PTP is enabled, PPS cannot be a module, while it may be a module if PTP is disabled. THis did not work for me. What I got was, in effect, two independent booleans. Hmm, right. I wonder what I was thinking of then. You can certainly do config PTP bool IEEE 1588 Precision Time Protocol depends on PPS != m but that will hide the PTP option if PPS is set to 'm', which is normally not what you want. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Thu, Aug 19, 2010 at 02:29:49PM +0200, Arnd Bergmann wrote: On Thursday 19 August 2010, Richard Cochran wrote: On Wed, Aug 18, 2010 at 05:02:03PM +0200, Arnd Bergmann wrote: You might want to use callbacks for these system calls that you can register to at module load time, like it is done for the existing syscalls. Can you point me to a specific example? The struct k_clock contains callback functions to clock source specific implementations of the syscalls and other functions. Adding a new clock source that is (potentially) implemented as a module means you have to define a new k_clock in that module that you register using register_posix_clock. If you need additional syscalls to be implemented by the same module, you can put more callback functions into struct k_clock that would then only be implemented by the new module. The simpler way (e.g. for testing) is using Kconfig dependencies, like config PTP bool IEEE 1588 Precision Time Protocol config PPS tristate Pulse per Second depends on PTP || !PTP The depends statement is a way of expressing that when PTP is enabled, PPS cannot be a module, while it may be a module if PTP is disabled. THis did not work for me. What I got was, in effect, two independent booleans. Hmm, right. I wonder what I was thinking of then. You can certainly do config PTP bool IEEE 1588 Precision Time Protocol depends on PPS != m but that will hide the PTP option if PPS is set to 'm', which is normally not what you want. Arnd, Perhaps you were thinking of the vhost example (taken from drivers/vhost/Kconfig): config VHOST_NET tristate Host kernel accelerator for virtio net (EXPERIMENTAL) depends on NET EVENTFD (TUN || !TUN) (MACVTAP || !MACVTAP) EXPERIMENTAL They have a similar construct with both TUN and MACVTAP there. Perhaps the parens are a necessary part of the X || !X syntax? Just a random guess. Ira ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote: My point was that a syscall is better than an ioctl based interface here, which I definitely still think. Given that John knows much more about clocks than I do, we still need to get agreement on the question that he raised, which is whether we actually need to expose this clock to the user or not. If we can find a way to sync system time accurate enough with PTP and PPS, user applications may not need to see two separate clocks at all. At the very least, one user application (the PTPd) needs to see the PTP clock. SYSCALL_DEFINE3(clock_adjtime, const clockid_t, clkid, int, ppb, struct timespec __user *, ts) ppb - desired frequency adjustment in parts per billion ts - desired time step (or jump) in sec,nsec to correct a measured offset Arguably, this syscall might be useful for other clocks, too. This is a mix of adjtime and adjtimex with the addition of the clkid parameter, right? Sort of, but not really. ADJTIME(3) takes an offset and slowly corrects the clock using a servo in the kernel, over hours. For this function, the offset passed in the 'ts' parameter will be immediately corrected, by jumping to the new time. This reflects the way that PTP works. After the first few samples, the PTPd has an estimate of the offset to the master and the rate difference. The PTPd can proceed in one of two ways. 1. If resetting the clock is not desired, then the clock is set to the maximum adjustment (in the right direction) until the clock time is close to the master's time. 2. The estimated offset is added to the current time, resulting in a jump in time. We need clock_adjtime(id, 0, ts) for the second case. Have you considered passing a struct timex instead of ppb and ts? Yes, but the timex is not suitable, IMHO. Is using ppb instead of the timex ppm required to get the accuracy you want? That is one very good reason. Another is this: can you explain what the 20+ fields mean? Consider the field, freq. The comment says frequency offset (scaled ppm). To what is it scaled? The only way I know of to find out is to read the NTP code (which is fairly complex) and see what the unit really is meant to be. Ditto for the other fields. The timex structure reveals, AFAICT, the inner workings of the kernel clock servo. For PTP, we don't need or want the kernel servo. The PTPd has its own clock servo in user space. Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Thursday 19 August 2010, Ira W. Snyder wrote: Perhaps you were thinking of the vhost example (taken from drivers/vhost/Kconfig): config VHOST_NET tristate Host kernel accelerator for virtio net (EXPERIMENTAL) depends on NET EVENTFD (TUN || !TUN) (MACVTAP || !MACVTAP) EXPERIMENTAL They have a similar construct with both TUN and MACVTAP there. Perhaps the parens are a necessary part of the X || !X syntax? Just a random guess. Yes, that's the one I was thinking of. My mistake was that the effect is slightly different here. VHOST and TUN are both tristate. What we guarantee here is that if TUN is m, VHOST cannot be y, because its dependency cannot be fulfilled for y. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Tue, Aug 17, 2010 at 05:22:43PM -0700, john stultz wrote: Why would system time not be adjusted to the PTP time? This is my main concern, that we're presenting a fractured API to userland. Suddenly there isn't just system time, but ptp time as well, and possibly multiple different ptp times. John, it is a good thing to make thoughts about the big picture with PTP clocks and the system time, like you are doing. However, the situation is not as troubled as you think. Let me try to explain. The PTP clock is a bit of hardware (usually on the NIC) that can put timestamps on packets (both incoming or outgoing?). Not only on the NIC. There are bunch of new products doing the timestamping in the PHY or in a switch fabric attached to the host like a PHY. The synchronization that one can achieve with PHY timestamps is better that that with MAC timestamping. So while to me, it think it would be more ideal (or maybe just less different) to have a read-only interface (like the RTC), leaving PTPd to manage offset calculations and use that to steer the system time. I can acknowledge the need to have some way to correct the freq so the packet timestamps are corrected. The PTPd need not change the system time at all for PTP clock to be useful. (see below) I still feel a little concerned over the timer/alarm related interfaces. Could you explain why the alarm interface is necessary? The timer/alarm stuff is ancillary and is not at all necessary. It is just a nice to have. I will happily remove it, if it is too troubling for people. So really I think my initial negative gut reaction to this was mostly out of the fact that you introduced a char dev that provides almost 100% coverage of the posix-time interface. That is duplication we definitely don't want. The reason why I modelled the char device on the posix interface was to make the API more familiar to application programmers. After the recent discussion (and having reviewed the posix clock implementation in Linux), I now think it would be even better to simply offer a new posic clock ID for PTP. I was emulating the posix interface. Instead I should use it directly. Also I think the documentation I've read about PTP (likely just due to the engineering focus) has an odd inverted sense of priority, focusing on keeping obscure hardware clocks on NIC cards in sync, rather then the the more tangible feature of keeping the system time in sync. This could be comically interpreted as trying to create a shadow-time on the system that is the real time and yea, maybe we'll let the system know what time it is, but user-apps who want to know the score can send a magic ioctl to /dev/something and get the real deal. ;) I'm sure that's not the case, but I'd like to keep any confusion in userland about which time is the best time to a minimum (ie: use the system time). You are right. As John Eidson's excellent book points out, modern computers and operating systems provide surprisingly little support for programming based on absolute time. It is not PTP's fault. PTP is actually a step in the right direction, but it doesn't yet really fit in to the present computing world. Okay, here is the Big Picture. 1. Use Case: SW timestamping PTP with software timestamping (ie without special hardware) can acheive synchronization within a few dozen microseconds, after about twenty minutes. This is sufficient for very many people. The new API (whether char device or syscall) fully and simply supports this use case. When the PTPd adjusts the PTP clock, it is actually adjusting the system time, just like NTPd. 2. Use Case: HW timestamping for industrial control PTP with hardware timestamping can acheive synchronization within 100 nanoseconds after one minute. If you want to do something with your wonderfully synchronization PTP clock, it must have some kind of special hardware, like timestamping external signals or generating one-shot or periodic outputs. The new API (whether char device or syscall) supports this use case via the ancillary commands. In this case, the end user has an application that interfaces with the outside world via the PTP clock API. Such a specialized application (for example, motor control) uses only the PTP API, since it knows that the standard posix API cannot help. It is irrelevant that the system time is not synchronized, in this case. The PTP clock hardware may or may not provide a hardware interface (interrupt) to the main CPU. In this case, it does not matter. The PTP clock is useful all by itself. 3. Use Case: HW timestamping with PPS to host This case is the same as case 2, with the exception that the PTP clock can interrupt the main CPU. The PTP clock driver advertises the PPS capability. When enabled, the PTP layer delivers events via the existing Linux PPS subsystem. Programs like NTPd can use these events to regulate the system
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Tue, Aug 17, 2010 at 01:36:29PM +0200, Arnd Bergmann wrote: On Tuesday 17 August 2010, Richard Cochran wrote: I've been looking at offering the PTP clock as a posix clock, and it is not as hard as I first thought. The PTP clock or clocks just have to be registered as one of the posix_clocks[MAX_CLOCKS] in posix-timers.c. Ok sounds good. I've been working turning the PTP stuff into syscalls, but here is a little issue I ran into. The PTP clock layer wants to call the PPS code via pps_register_source(), but the PPS can be compiled as a module. Since the PTP layer is now offering syscalls, it must always be present in the kernel. So I need to make sure that the PPS is either absent entirely or staticly linked in. How can I do this? Thanks, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Wednesday 18 August 2010, Richard Cochran wrote: On Tue, Aug 17, 2010 at 01:36:29PM +0200, Arnd Bergmann wrote: On Tuesday 17 August 2010, Richard Cochran wrote: I've been looking at offering the PTP clock as a posix clock, and it is not as hard as I first thought. The PTP clock or clocks just have to be registered as one of the posix_clocks[MAX_CLOCKS] in posix-timers.c. Ok sounds good. I've been working turning the PTP stuff into syscalls, but here is a little issue I ran into. The PTP clock layer wants to call the PPS code via pps_register_source(), but the PPS can be compiled as a module. Since the PTP layer is now offering syscalls, it must always be present in the kernel. So I need to make sure that the PPS is either absent entirely or staticly linked in. How can I do this? You might want to use callbacks for these system calls that you can register to at module load time, like it is done for the existing syscalls. The simpler way (e.g. for testing) is using Kconfig dependencies, like config PTP bool IEEE 1588 Precision Time Protocol config PPS tristate Pulse per Second depends on PTP || !PTP The depends statement is a way of expressing that when PTP is enabled, PPS cannot be a module, while it may be a module if PTP is disabled. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Wed, 2010-08-18 at 09:19 +0200, Richard Cochran wrote: On Tue, Aug 17, 2010 at 05:22:43PM -0700, john stultz wrote: So while to me, it think it would be more ideal (or maybe just less different) to have a read-only interface (like the RTC), leaving PTPd to manage offset calculations and use that to steer the system time. I can acknowledge the need to have some way to correct the freq so the packet timestamps are corrected. The PTPd need not change the system time at all for PTP clock to be useful. (see below) Right, obviously an ok-solution is often more useful then no-solution. But that doesn't mean we shouldn't shoot for a good or even great-solution. :) I still feel a little concerned over the timer/alarm related interfaces. Could you explain why the alarm interface is necessary? The timer/alarm stuff is ancillary and is not at all necessary. It is just a nice to have. I will happily remove it, if it is too troubling for people. If there's a compelling argument for it, I'm interested to hear. But again, it seems like just yet-another-way-to-get-alarm/timer-functionality, so before we add an extra API (or widen an existing API) I'd like to understand the need. But maybe it might simplify the discussion to pull it for now, but keeping it in mind to possibly include later as an extension? So really I think my initial negative gut reaction to this was mostly out of the fact that you introduced a char dev that provides almost 100% coverage of the posix-time interface. That is duplication we definitely don't want. The reason why I modelled the char device on the posix interface was to make the API more familiar to application programmers. After the recent discussion (and having reviewed the posix clock implementation in Linux), I now think it would be even better to simply offer a new posic clock ID for PTP. I was emulating the posix interface. Instead I should use it directly. I'm definitely interested to see what you come up with here. I'm still hesitant with adding a PTP clock_id, but extending the posix-clocks interface in this way isn't unprecedented (see: CLOCK_SGI_CYCLE) I just would like to make sure we don't end up with a clock_id namespace littered with oddball clocks that were not well abstracted (see: CLOCK_SGI_CYCLE :). For instance: imagine if instead of keeping the clocksource abstraction internal to the timekeeping core, we exposed each clocksource to userland via a clock_id. Every arch would have different ids, and each arch might have multiple ids. Programming against that would be a huge pain. So in thinking about this, try to focus on what the new clock_id provides that the other existing clockids do not? Are they at comparable levels of abstraction? 15 years from now, are folks likely to still be using it? Will it be maintainable? etc... Also I think the documentation I've read about PTP (likely just due to the engineering focus) has an odd inverted sense of priority, focusing on keeping obscure hardware clocks on NIC cards in sync, rather then the the more tangible feature of keeping the system time in sync. This could be comically interpreted as trying to create a shadow-time on the system that is the real time and yea, maybe we'll let the system know what time it is, but user-apps who want to know the score can send a magic ioctl to /dev/something and get the real deal. ;) I'm sure that's not the case, but I'd like to keep any confusion in userland about which time is the best time to a minimum (ie: use the system time). You are right. As John Eidson's excellent book points out, modern computers and operating systems provide surprisingly little support for programming based on absolute time. It is not PTP's fault. PTP is actually a step in the right direction, but it doesn't yet really fit in to the present computing world. You'll have to forgive me, as I haven't had the time to check out that book. What exactly do you mean by operating systems provide little support for programming based on absolute time? Okay, here is the Big Picture. 1. Use Case: SW timestamping PTP with software timestamping (ie without special hardware) can acheive synchronization within a few dozen microseconds, after about twenty minutes. This is sufficient for very many people. The new API (whether char device or syscall) fully and simply supports this use case. When the PTPd adjusts the PTP clock, it is actually adjusting the system time, just like NTPd. Again this illustrates the inversion of focus: system time is merely one of many possible PTP clocks in the larger PTP framework. The way I tend to see it: PTP is just one of the many ways to sync system time. 2. Use Case: HW timestamping for industrial control PTP with hardware timestamping can acheive synchronization within 100 nanoseconds after one minute. If you want to do something with your wonderfully
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Wed, Aug 18, 2010 at 05:12:56PM -0700, john stultz wrote: On Wed, 2010-08-18 at 09:19 +0200, Richard Cochran wrote: The timer/alarm stuff is ancillary and is not at all necessary. It is just a nice to have. I will happily remove it, if it is too troubling for people. If there's a compelling argument for it, I'm interested to hear. But again, it seems like just yet-another-way-to-get-alarm/timer-functionality, so before we add an extra API (or widen an existing API) I'd like to understand the need. We don't really need it, IMHO. But if we offer clockid_t CLOCK_PTP, then we get timer_settime() without any extra effort. I was emulating the posix interface. Instead I should use it directly. I'm definitely interested to see what you come up with here. I'm still hesitant with adding a PTP clock_id, but extending the posix-clocks interface in this way isn't unprecedented (see: CLOCK_SGI_CYCLE) I just would like to make sure we don't end up with a clock_id namespace littered with oddball clocks that were not well abstracted (see: CLOCK_SGI_CYCLE :). For instance: imagine if instead of keeping the clocksource abstraction internal to the timekeeping core, we exposed each clocksource to userland via a clock_id. Every arch would have different ids, and each arch might have multiple ids. Programming against that would be a huge pain. The clockid_t CLOCK_PTP will be arch-neutral. So in thinking about this, try to focus on what the new clock_id provides that the other existing clockids do not? Are they at comparable levels of abstraction? 15 years from now, are folks likely to still be using it? Will it be maintainable? etc... Arnd convinced me that clockid_t=CLOCK_PTP is a good fit. My plan would be to introduce just one additional syscall: SYSCALL_DEFINE3(clock_adjtime, const clockid_t, clkid, int, ppb, struct timespec __user *, ts) ppb - desired frequency adjustment in parts per billion ts - desired time step (or jump) in sec,nsec to correct a measured offset Arguably, this syscall might be useful for other clocks, too. I think the ancillary features from PTP hardware clocks should be made available throught the sysfs. A syscall for these would end up very ugly, looking like an ioctl. Also, it is hard to see how these features relate to the more general idea of the clockid. In contrast, sysfs attributes will fit the need nicely: 1. enable or disable pps 2. enable or disable external timestamps 3. read out external timestamp 4. configure period for periodic output 1. Use Case: SW timestamping The way I tend to see it: PTP is just one of the many ways to sync system time. 2. Use Case: HW timestamping for industrial control These specialized applications are part of what concerns me the most. PTP was not invented to just to get a computer's system time in the ball park. For that, NTP is good enough. Rather, some people want to use their computers for tasks that require close synchronization, like industrial control, audio/video streaming, and many others. Are you saying that we should not support such applications? For example, I can see some parallels between things like audio processing, where you have a buffer consumed by the card at a certain rate. Now, the card has its own crystal it uses to time its consumption, so it has its own time domain, and could drift from system time. Thus you want to trigger buffer-refill interrupts off of the audio card's clock, not the system time which might run the risk of being late. But again, we don't expose the audio hardware clock to userland in the same way we expose system time. This is a good example of the poverty (in regards to time synchronization) of our current systems. Lets say I want to build a surround sound audio system, using a set of distributed computers, each host connected to one speaker. How I can be sure that the samples in one channel (ie one host) pass through the DA converter at exactly the same time? Again, my knowledge in the networking stack is pretty limited. But it would seem that having an interface that does something to the effect of adjust the timestamp clock on the hardware that generated it from this packet by Xppb would feel like the right level of abstraction. Its closely related to SO_TIMESTAMP, option right? Would something like using the setsockopt/getsockopt interface with SO_TIMESTAMP_ADJUST/OFFSET/SET/etc be reasonable? The clock and its adjustment have nothing to do with a network socket. The current PTP hacks floating around all add private ioctls to the MAC driver. That is the *wrong* way to do it. 3. Use Case: HW timestamping with PPS to host ... And yes, this seems perfectly reasonable feature to add. Its not controversial to me, because its likely to work within the existing interfaces and won't expose anything new to userland. Okay, then will you support an elegant solution for case 3, that also supports cases 1 and 2
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Mon, Aug 16, 2010 at 09:59:39PM +0200, Arnd Bergmann wrote: Why does it matter how long it takes to read the clock? I wasn't thinking of replacing the system clock with this, just exposing the additional clock as a new clockid_t value that can be accessed using the existing syscalls. Okay, now I see. You are suggesting this: clock_gettime(CLOCK_PTP, ts); clock_settime(CLOCK_PTP, ts); I like this. If there is agreement about it, I am happy to implement the PTP stuff that way. Why did you not want to add syscalls? Adding ioctls instead of syscalls does not make the interface better, just less visible. I bet that, had I posted patch set with new syscalls, someone would have said, You are adding new syscalls. Can't you just use a char device instead! If you add syscalls and introduce CLOCK_PTP, then you add it to everyone's kernel, even those people who never heard of PTP. A char device has the advantage that can it be simply ignored. Also, a syscall has got to have the right form from the very beginning. If the next generation of PTP hardware looks very different, then it is not that much of a crime to change an ioctl interface, provided it has versioning. Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Mon, Aug 16, 2010 at 12:24:48PM -0700, john stultz wrote: 3) I'm not sure I see the benefit of being able to have multiple frequency corrected time domains. In other words, what benefit would you get from adjusting a PTP clock's frequency instead of just adjusting the system's time freq? Having the PTP time as a reference to correct the system time seems reasonable, but I'm not sure I see why userland would want to adjust the PTP clock's freq. For PTP enabled hardware, the timestamp on the network packet comes from from the PTP clock, not from the system time. Of course, you can always just leave the PTP clock alone, figure the needed correction, and apply it whenever needed. But this has some disadvantages. First of all, the (one and only) open source PTPd does not do it that way. Also, only one program (the PTPd or equivalent) will know the correct time. Other programs will not be able to ask the operating system for time services. Instead, they would need to use IPC to the PTPd. The PTP protocol (and some PTP hardware) offers a one step method, where the timestamps are inserted by the hardware on the fly. Here you really do need the PTP clock to be correctly adjusted. All of the PTP hardware that I am familiar with provides a clock adjustment method, so it simpler and cleaner just to use this facility to tune the PTP clock. Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Tuesday 17 August 2010, Richard Cochran wrote: Why did you not want to add syscalls? Adding ioctls instead of syscalls does not make the interface better, just less visible. I bet that, had I posted patch set with new syscalls, someone would have said, You are adding new syscalls. Can't you just use a char device instead! Very possible, but after considering both options, I think we would still end up with the same conclusion. If you add syscalls and introduce CLOCK_PTP, then you add it to everyone's kernel, even those people who never heard of PTP. A char device has the advantage that can it be simply ignored. It's a matter of perspective whether you consider this an advantage or disadvantage. I would expect that since you are trying to get support for PTP into the kernel, you'd be happy for people to know about it and use your code ;-). Also, a syscall has got to have the right form from the very beginning. If the next generation of PTP hardware looks very different, then it is not that much of a crime to change an ioctl interface, provided it has versioning. No, that's just a myth. The rules for ABI stability are pretty much the same. We try hard to avoid ever changing an existing ABI, for both syscalls and ioctl. In either case, if you get it wrong, you have to support the old interface and create a new syscall or ioctl command. As mentioned, versioning does not solve this, it just adds another indirection (which we try to avoid). One difference is that more people take a look at your code when you suggest a new syscall, so the chances of getting it right in the first upstream version are higher. Another difference is that we generally use ioctl for devices that can be enumerated, while syscalls are for system services that are not tied to a specific device. This argument works both ways for PTP IMHO: On the one hand you want to have a reliable clock that you can use without knowing where it comes from, on the other you might have multiple PTP sources that you need to differentiate. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Tue, Aug 17, 2010 at 09:25:55AM +, Arnd Bergmann wrote: Another difference is that we generally use ioctl for devices that can be enumerated, while syscalls are for system services that are not tied to a specific device. This argument works both ways for PTP IMHO: On the one hand you want to have a reliable clock that you can use without knowing where it comes from, on the other you might have multiple PTP sources that you need to differentiate. Yes, I agree. In normal use, there will be only one PTP clock in a system. However, for research purposes, it would be nice to have more than one. I've been looking at offering the PTP clock as a posix clock, and it is not as hard as I first thought. The PTP clock or clocks just have to be registered as one of the posix_clocks[MAX_CLOCKS] in posix-timers.c. My suggestion would be to reserve three clock ids in time.h, CLOCK_PTP0, CLOCK_PTP1, and CLOCK_PTP2. The first one would be the same as CLOCK_REALTIME, for SW timestamping, and the other two would allow two different PTP clocks at the same time, for the research use case. Using the clock id will bring another advantage, since it will then be possible for user space to specify the desired timestamp source for SO_TIMESTAMPING. Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Tuesday 17 August 2010, Richard Cochran wrote: On Tue, Aug 17, 2010 at 09:25:55AM +, Arnd Bergmann wrote: Another difference is that we generally use ioctl for devices that can be enumerated, while syscalls are for system services that are not tied to a specific device. This argument works both ways for PTP IMHO: On the one hand you want to have a reliable clock that you can use without knowing where it comes from, on the other you might have multiple PTP sources that you need to differentiate. Yes, I agree. In normal use, there will be only one PTP clock in a system. However, for research purposes, it would be nice to have more than one. I've been looking at offering the PTP clock as a posix clock, and it is not as hard as I first thought. The PTP clock or clocks just have to be registered as one of the posix_clocks[MAX_CLOCKS] in posix-timers.c. Ok sounds good. My suggestion would be to reserve three clock ids in time.h, CLOCK_PTP0, CLOCK_PTP1, and CLOCK_PTP2. The first one would be the same as CLOCK_REALTIME, for SW timestamping, and the other two would allow two different PTP clocks at the same time, for the research use case. I don't think there is a point in making exactly two independent sources available. The clockid_t space is not really limited, so we could define an arbitrary range of ids for ptp sources that could be used simultaneously, as long as we have space more more ids with a fixed number. Would it be reasonable to assume that on a machine with a large number of NICs, you'd want a separate ptp source for each of them for timestamping? Or would you preferably define just one source in such a setup? I think both could be done with the use of class device attributes in sysfs for configuration. Maybe you can have one CLOCK_PTP value for one global PTP source and use sysfs to configure which device that is. If you also need simultaneous access to the specific clocks, you could have run-time configured clockid numbers in a sysfs attribute for each ptp class device. Using the clock id will bring another advantage, since it will then be possible for user space to specify the desired timestamp source for SO_TIMESTAMPING. God point. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Tue, 2010-08-17 at 10:53 +0200, Richard Cochran wrote: On Mon, Aug 16, 2010 at 12:24:48PM -0700, john stultz wrote: 3) I'm not sure I see the benefit of being able to have multiple frequency corrected time domains. In other words, what benefit would you get from adjusting a PTP clock's frequency instead of just adjusting the system's time freq? Having the PTP time as a reference to correct the system time seems reasonable, but I'm not sure I see why userland would want to adjust the PTP clock's freq. For PTP enabled hardware, the timestamp on the network packet comes from from the PTP clock, not from the system time. Of course, you can always just leave the PTP clock alone, figure the needed correction, and apply it whenever needed. But this has some disadvantages. First of all, the (one and only) open source PTPd does not do it that way. Also, only one program (the PTPd or equivalent) will know the correct time. Other programs will not be able to ask the operating system for time services. Instead, they would need to use IPC to the PTPd. Why would system time not be adjusted to the PTP time? This is my main concern, that we're presenting a fractured API to userland. Suddenly there isn't just system time, but ptp time as well, and possibly multiple different ptp times. Forgive me, as I suspect I'm missing something key here. The PTP protocol (and some PTP hardware) offers a one step method, where the timestamps are inserted by the hardware on the fly. Here you really do need the PTP clock to be correctly adjusted. All of the PTP hardware that I am familiar with provides a clock adjustment method, so it simpler and cleaner just to use this facility to tune the PTP clock. Hmm. So trying to recap here to see if I'm understanding properly: The PTP clock is a bit of hardware (usually on the NIC) that can put timestamps on packets (both incoming or outgoing?). The need to offset/freq correct the PTP clock is important so that the timestamps (incoming and outgoing) are correct, which makes future offset calculations simpler. Hmm. So I'm actually starting to come around to the chardev interface. In a way, it seems it has some similarities to how the RTC device is used in NTPd. Granted, NTPd doesn't correct the RTC (the kernel does when we're synced, but its not a perfect parallel), but it can be used as an input the steer the clock. So while to me, it think it would be more ideal (or maybe just less different) to have a read-only interface (like the RTC), leaving PTPd to manage offset calculations and use that to steer the system time. I can acknowledge the need to have some way to correct the freq so the packet timestamps are corrected. I still feel a little concerned over the timer/alarm related interfaces. Could you explain why the alarm interface is necessary? So really I think my initial negative gut reaction to this was mostly out of the fact that you introduced a char dev that provides almost 100% coverage of the posix-time interface. That is duplication we definitely don't want. Also I think the documentation I've read about PTP (likely just due to the engineering focus) has an odd inverted sense of priority, focusing on keeping obscure hardware clocks on NIC cards in sync, rather then the the more tangible feature of keeping the system time in sync. This could be comically interpreted as trying to create a shadow-time on the system that is the real time and yea, maybe we'll let the system know what time it is, but user-apps who want to know the score can send a magic ioctl to /dev/something and get the real deal. ;) I'm sure that's not the case, but I'd like to keep any confusion in userland about which time is the best time to a minimum (ie: use the system time). thanks -john ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Tue, 2010-08-17 at 13:36 +0200, Arnd Bergmann wrote: On Tuesday 17 August 2010, Richard Cochran wrote: On Tue, Aug 17, 2010 at 09:25:55AM +, Arnd Bergmann wrote: Another difference is that we generally use ioctl for devices that can be enumerated, while syscalls are for system services that are not tied to a specific device. This argument works both ways for PTP IMHO: On the one hand you want to have a reliable clock that you can use without knowing where it comes from, on the other you might have multiple PTP sources that you need to differentiate. Yes, I agree. In normal use, there will be only one PTP clock in a system. However, for research purposes, it would be nice to have more than one. I've been looking at offering the PTP clock as a posix clock, and it is not as hard as I first thought. The PTP clock or clocks just have to be registered as one of the posix_clocks[MAX_CLOCKS] in posix-timers.c. Ok sounds good. Oh no. I'm starting to waffle here. :) So while I'm not a fan of the duplication of the posix clocks interface that the proposed chardev interface introduced, I'm not sure if absorbing the PTP clocks as a clockid is much better. Mainly due to the fact that userland apps now have to chose between two clockids that supposedly represent the same thing (the current wall time). My suggestion would be to reserve three clock ids in time.h, CLOCK_PTP0, CLOCK_PTP1, and CLOCK_PTP2. The first one would be the same as CLOCK_REALTIME, for SW timestamping, and the other two would allow two different PTP clocks at the same time, for the research use case. Why would you have CLOCK_PTP0 == CLOCK_REALTIME? Whats the point of that? I don't think there is a point in making exactly two independent sources available. The clockid_t space is not really limited, so we could define an arbitrary range of ids for ptp sources that could be used simultaneously, as long as we have space more more ids with a fixed number. Would it be reasonable to assume that on a machine with a large number of NICs, you'd want a separate ptp source for each of them for timestamping? Or would you preferably define just one source in such a setup? I think both could be done with the use of class device attributes in sysfs for configuration. Maybe you can have one CLOCK_PTP value for one global PTP source and use sysfs to configure which device that is. If you also need simultaneous access to the specific clocks, you could have run-time configured clockid numbers in a sysfs attribute for each ptp class device. Using the clock id will bring another advantage, since it will then be possible for user space to specify the desired timestamp source for SO_TIMESTAMPING. So how exactly would one map CLOCK_PTPx to an eth device? So this is a little bit further out there, but assuming PTPd can sync the PTP clock correctly, why could the kernel itself not sync the PTP clock to system time? So instead of the sync path looking like: 1) packet from master arrives on NIC, is timestamped by PTP clock 2) PTPd calculates offset between PTP clock and master time 3) PTPd corrects PTP clock freq/offset 4) PTPd corrects system time freq/offset It would look like: 1) packet from master arrives on NIC, is timestamped by PTP clock 2) PTPd calculates offset between PTP clock and master time 3) PTPd corrects system time freq/offset 4) kernel corrects PTP clock freq/offset I'm guessing the indirect PTP clock sync would have greater error, but it avoids the fractured sense of time. thanks -john ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
This patch adds an infrastructure for hardware clocks that implement IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a registration method to particular hardware clock drivers. Each clock is exposed to user space as a character device with ioctls that allow tuning of the PTP clock. Signed-off-by: Richard Cochran richard.coch...@omicron.at --- Documentation/ptp/ptp.txt| 95 +++ Documentation/ptp/testptp.c | 306 ++ Documentation/ptp/testptp.mk | 33 +++ drivers/Kconfig |2 + drivers/Makefile |1 + drivers/ptp/Kconfig | 27 ++ drivers/ptp/Makefile |5 + drivers/ptp/ptp_clock.c | 514 ++ include/linux/Kbuild |1 + include/linux/ptp_clock.h| 79 ++ include/linux/ptp_clock_kernel.h | 137 ++ 11 files changed, 1200 insertions(+), 0 deletions(-) create mode 100644 Documentation/ptp/ptp.txt create mode 100644 Documentation/ptp/testptp.c create mode 100644 Documentation/ptp/testptp.mk create mode 100644 drivers/ptp/Kconfig create mode 100644 drivers/ptp/Makefile create mode 100644 drivers/ptp/ptp_clock.c create mode 100644 include/linux/ptp_clock.h create mode 100644 include/linux/ptp_clock_kernel.h diff --git a/Documentation/ptp/ptp.txt b/Documentation/ptp/ptp.txt new file mode 100644 index 000..46858b3 --- /dev/null +++ b/Documentation/ptp/ptp.txt @@ -0,0 +1,95 @@ + +* PTP infrastructure for Linux + + This patch set introduces support for IEEE 1588 PTP clocks in + Linux. Together with the SO_TIMESTAMPING socket options, this + presents a standardized method for developing PTP user space + programs, synchronizing Linux with external clocks, and using the + ancillary features of PTP hardware clocks. + + A new class driver exports a kernel interface for specific clock + drivers and a user space interface. The infrastructure supports a + complete set of PTP functionality. + + + Basic clock operations +- Set time +- Get time +- Shift the clock by a given offset atomically +- Adjust clock frequency + + + Ancillary clock features +- One short or periodic alarms, with signal delivery to user program +- Time stamp external events +- Period output signals configurable from user space +- Synchronization of the Linux system time via the PPS subsystem + +** PTP kernel API + + A PTP clock driver registers itself with the class driver. The + class driver handles all of the dealings with user space. The + author of a clock driver need only implement the details of + programming the clock hardware. The clock driver notifies the class + driver of asynchronous events (alarms and external time stamps) via + a simple message passing interface. + + The class driver supports multiple PTP clock drivers. In normal use + cases, only one PTP clock is needed. However, for testing and + development, it can be useful to have more than one clock in a + single system, in order to allow performance comparisons. + +** PTP user space API + + The class driver creates a character device for each registered PTP + clock. User space programs may control the clock using standardized + ioctls. A program may query, enable, configure, and disable the + ancillary clock features. User space can receive time stamped + events via blocking read() and poll(). One shot and periodic + signals may be configured via an ioctl API with semantics similar + to the POSIX timer_settime() system call. + + As an real life example, the following two patches for ptpd version + 1.0.0 demonstrate how the API works. + + https://sourceforge.net/tracker/?func=detailaid=2992845group_id=139814atid=744634 + + https://sourceforge.net/tracker/?func=detailaid=2992847group_id=139814atid=744634 + +** Writing clock drivers + + Clock drivers include include/linux/ptp_clock_kernel.h and register + themselves by presenting a 'struct ptp_clock_info' to the + registration method. Clock drivers must implement all of the + functions in the interface. If a clock does not offer a particular + ancillary feature, then the driver should just return -EOPNOTSUPP + from those functions. + + Drivers must ensure that all of the methods in interface are + reentrant. Since most hardware implementations treat the time value + as a 64 bit integer accessed as two 32 bit registers, drivers + should use spin_lock_irqsave/spin_unlock_irqrestore to protect + against concurrent access. This locking cannot be accomplished in + class driver, since the lock may also be needed by the clock + driver's interrupt service routine. + +** Supported hardware + + + Standard Linux system timer + - No special PTP features + - For use with software time stamping + + + Freescale eTSEC gianfar + - 2 Time stamp external triggers, programmable polarity (opt. interrupt) +
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Monday 16 August 2010, Richard Cochran wrote:
This patch adds an infrastructure for hardware clocks that implement
IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a
registration method to particular hardware clock drivers. Each clock is
exposed to user space as a character device with ioctls that allow tuning
of the PTP clock.
Have you considered integrating the subsystem into the Posix clock/timer
framework?
I can't really tell from reading the source if this is possible or
not, but my feeling is that if it can be done, that would be a much
nicer interface. We already have clock_gettime/clock_settime/
timer_settime/... system calls, and while you'd need to add another
clockid and some syscalls, my feeling is that it will be more
usable in the end.
+static const struct file_operations ptp_fops = {
+ .owner = THIS_MODULE,
+ .ioctl = ptp_ioctl,
+ .open = ptp_open,
+ .poll = ptp_poll,
+ .read = ptp_read,
+ .release= ptp_release,
+};
.ioctl is gone, you have to use .unlocked_ioctl and make sure that
your ptp_ioctl function can handle being called concurrently.
You should also add a .compat_ioctl function, ideally one that
points to ptp_ioctl so you don't have to list every command as
being compatible. Right now, some commands are incompatible,
which means you need more changes to the interface.
+struct ptp_clock_timer {
+ int alarm_index; /* Which alarm to query or configure. */
+ int signum;/* Requested signal. */
+ int flags; /* Zero or TIMER_ABSTIME, see TIMER_SETTIME(2)
*/
+ struct itimerspec tsp; /* See TIMER_SETTIME(2) */
+};
This data structure is incompatible between 32 and 64 bit user space,
so you would need a compat_ioctl() function to convert between the
two formats. Better define the structure in a compatible way, avoiding
variable-length fields and implicit padding.
+struct ptp_clock_request {
+ int type; /* One of the ptp_request_types enumeration values. */
+ int index; /* Which channel to configure. */
+ struct timespec ts; /* For period signals, the desired period. */
+ int flags; /* Bit field for PTP_ENABLE_FEATURE or other flags. */
+};
Same problem here, timespec is either 64 or 128 bits long and has different
alignment.
+struct ptp_extts_event {
+ int index;
+ struct timespec ts;
+};
here too.
+#define PTP_CLOCK_VERSION 0x0001
+
+#define PTP_CLK_MAGIC '='
+
+#define PTP_CLOCK_APIVERS _IOR (PTP_CLK_MAGIC, 1, __u32)
Try avoiding versioned ABIs. It's better to just add new ioctls
or syscalls when you need some extra functionality and leave the
old ones around.
+#define PTP_CLOCK_ADJTIME _IOW (PTP_CLK_MAGIC, 3, struct timespec)
+#define PTP_CLOCK_GETTIME _IOR (PTP_CLK_MAGIC, 4, struct timespec)
+#define PTP_CLOCK_SETTIME _IOW (PTP_CLK_MAGIC, 5, struct timespec)
These are also incompatible.
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Mon, Aug 16, 2010 at 04:26:23PM +0200, Arnd Bergmann wrote: Have you considered integrating the subsystem into the Posix clock/timer framework? Yes, but see below. I can't really tell from reading the source if this is possible or not, but my feeling is that if it can be done, that would be a much nicer interface. We already have clock_gettime/clock_settime/ timer_settime/... system calls, and while you'd need to add another clockid and some syscalls, my feeling is that it will be more usable in the end. You are not the first person to ask about this. See this link for longer explanation of why I did not go that way: http://marc.info/?l=linux-netdevm=127669810232201w=2 You *could* offer the PTP clock as a Linux clock source/event device, and I agree that it would be nicer. However, the problem is, what do you do with the PHY based clocks? Just one 16 bit read from a PHY clock can take 40 usec, and you need four such read operations just to get the current time value. Also, I really did not want to add or change any syscalls. I could not see a practical way to extend the existing syscalls to accommodate PTP clocks. Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Mon, Aug 16, 2010 at 4:17 AM, Richard Cochran richardcoch...@gmail.com wrote: This patch adds an infrastructure for hardware clocks that implement IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a registration method to particular hardware clock drivers. Each clock is exposed to user space as a character device with ioctls that allow tuning of the PTP clock. Signed-off-by: Richard Cochran richard.coch...@omicron.at Hey Richard! Its very cool to see this work on lkml! I'm excited to see more work done on ptp. We had a short private thread discussion earlier (I got busy and never replied to your last message, my apologies!), but I wanted to bring up the concerns I have here as well. A few comments below +** PTP user space API + + The class driver creates a character device for each registered PTP + clock. User space programs may control the clock using standardized + ioctls. A program may query, enable, configure, and disable the + ancillary clock features. User space can receive time stamped + events via blocking read() and poll(). One shot and periodic + signals may be configured via an ioctl API with semantics similar + to the POSIX timer_settime() system call. As I mentioned earlier, I'm not a huge fan of the char device interface for abstracted PTP clocks. If it was just the direct hardware access, similar to RTC, which user apps then use as a timesource, I'd not have much of a problem. But as I mentioned in an earlier private mail, the abstraction level concerns me. 1) The driver-like model exposes a char dev for each clock, which allows for poorly-written userland applications to hit portability issues (ie: /dev/hpet vs /dev/rtc). Granted this isn't a huge flaw, but good APIs should be hard to get wrong. 2) As Arnd already mentioned, the chardev interface seems to duplicate the clock_gettime/settime() and adjtimex() interfaces. 3) I'm not sure I see the benefit of being able to have multiple frequency corrected time domains. In other words, what benefit would you get from adjusting a PTP clock's frequency instead of just adjusting the system's time freq? Having the PTP time as a reference to correct the system time seems reasonable, but I'm not sure I see why userland would want to adjust the PTP clock's freq. thanks -john ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Mon, Aug 16, 2010 at 12:24 PM, john stultz johns...@us.ibm.com wrote: On Mon, Aug 16, 2010 at 4:17 AM, Richard Cochran A few comments below +** PTP user space API + + The class driver creates a character device for each registered PTP + clock. User space programs may control the clock using standardized + ioctls. A program may query, enable, configure, and disable the + ancillary clock features. User space can receive time stamped + events via blocking read() and poll(). One shot and periodic + signals may be configured via an ioctl API with semantics similar + to the POSIX timer_settime() system call. As I mentioned earlier, I'm not a huge fan of the char device interface for abstracted PTP clocks. If it was just the direct hardware access, similar to RTC, which user apps then use as a timesource, I'd not have much of a problem. But as I mentioned in an earlier private mail, the abstraction level concerns me. [snip] 2) As Arnd already mentioned, the chardev interface seems to duplicate the clock_gettime/settime() and adjtimex() interfaces. And maybe just to clarify, as I saw your response to Arnd, I'm not suggesting using PTP clocks as clocksources for the internal timekeeping core. Instead I'm trying to understand why PTP clocks need the equivalent of the existing posix clocks/timer interface. Why would only having a read-time interface not suffice? thanks -john ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Monday 16 August 2010 21:00:03 Richard Cochran wrote: On Mon, Aug 16, 2010 at 04:26:23PM +0200, Arnd Bergmann wrote: Have you considered integrating the subsystem into the Posix clock/timer framework? Yes, but see below. I can't really tell from reading the source if this is possible or not, but my feeling is that if it can be done, that would be a much nicer interface. We already have clock_gettime/clock_settime/ timer_settime/... system calls, and while you'd need to add another clockid and some syscalls, my feeling is that it will be more usable in the end. You are not the first person to ask about this. See this link for longer explanation of why I did not go that way: http://marc.info/?l=linux-netdevm=127669810232201w=2 You could offer the PTP clock as a Linux clock source/event device, and I agree that it would be nicer. However, the problem is, what do you do with the PHY based clocks? Just one 16 bit read from a PHY clock can take 40 usec, and you need four such read operations just to get the current time value. Why does it matter how long it takes to read the clock? I wasn't thinking of replacing the system clock with this, just exposing the additional clock as a new clockid_t value that can be accessed using the existing syscalls. Also, I really did not want to add or change any syscalls. I could not see a practical way to extend the existing syscalls to accommodate PTP clocks. Why did you not want to add syscalls? Adding ioctls instead of syscalls does not make the interface better, just less visible. Out of the ioctl commands you define, we already seem to have half or more: PTP_CLOCK_APIVERS - not needed PTP_CLOCK_ADJFREQ - new clock_adjfreq PTP_CLOCK_ADJTIME - new clock_adjtime PTP_CLOCK_GETTIME - clock_gettime PTP_CLOCK_SETTIME - clock_settime PTP_CLOCK_GETCAPS - new clock_getcaps PTP_CLOCK_GETTIMER - timer_gettime PTP_CLOCK_SETTIMER - timer_create/timer_settime PTP_FEATURE_REQUEST - possibly clock_feature Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
