Delio, Thanks for the feedback...
On Mon, Dec 08, 2014 at 10:30:28AM +0100, Delio Brignoli wrote: > We implemented this correction in our driver using a private IOCTL > and it would have been nice to have used some standardised interface > instead. However, I think timestamp correction belongs in the PHY’s > driver (or whatever is doing the times-tamping). Data sheets report > expected delays so defaults can be automatic and the corrections can > be changed automatically according to link-speed for instance. I agree that the drivers should ideally correct this. However, there are many issues to tackle, including lack of vendor documentation, incorrect vendor documentation, MAC time stamping drivers not knowing the PHY delay or even the PHY type, and so on. Because providing corrections in-kernel will be spotty at best, maybe it better just to say, Linux drivers do *not* correct these delays. At leas that makes things consistent. Otherwise end users will have to comb through the kernel source in order to figure out whether the corrections in the data sheet are implemented or not. > There > should also be a standardised mechanism to update correction offsets > at runtime as a fallback mechanism when defaults are not good > enough. Do you mean a standard method in the kernel for drivers to use? > Having said that, having TX/RX timestamps correction also in linuxptp is a > good idea! My comments: Right, so no matter what the kernel does, we will always need to be able to correct mistakes in data sheets, drivers, or simply to handle different kernel versions (should drivers suddenly start correcting the delays). > (1) In some cases is not acceptable to restart linuxptp, so being > able to change the correction at runtime would be useful. This could > be added later. Yes. > (2) For some reason I would prefer (but not strongly) adding a > signed correction offset in both the egress and ingress directions > instead of adding in one direction and subtracting in the other. So far, the data sheets I have seen give these corrections as positive numbers for both egress and ingress delays. The idea was to allow the user to simply enter the values from the data sheet into the configuration file. Thanks, Richard ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel