linuxptp-users Mailing List for linuxptp (Page 163)
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users — Open discussion on using the linuxptp software.
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
(10) |
Mar
(47) |
Apr
|
May
(26) |
Jun
(10) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(20) |
Nov
(14) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(6) |
Feb
(18) |
Mar
(27) |
Apr
(57) |
May
(32) |
Jun
(21) |
Jul
(79) |
Aug
(108) |
Sep
(13) |
Oct
(73) |
Nov
(51) |
Dec
(24) |
| 2014 |
Jan
(24) |
Feb
(41) |
Mar
(39) |
Apr
(5) |
May
(6) |
Jun
(2) |
Jul
(5) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(7) |
| 2015 |
Jan
(27) |
Feb
(18) |
Mar
(37) |
Apr
(8) |
May
(13) |
Jun
(44) |
Jul
(4) |
Aug
(50) |
Sep
(35) |
Oct
(6) |
Nov
(24) |
Dec
(19) |
| 2016 |
Jan
(30) |
Feb
(30) |
Mar
(23) |
Apr
(4) |
May
(12) |
Jun
(19) |
Jul
(26) |
Aug
(13) |
Sep
|
Oct
(23) |
Nov
(37) |
Dec
(15) |
| 2017 |
Jan
(33) |
Feb
(19) |
Mar
(20) |
Apr
(43) |
May
(39) |
Jun
(23) |
Jul
(20) |
Aug
(27) |
Sep
(10) |
Oct
(15) |
Nov
|
Dec
(24) |
| 2018 |
Jan
(3) |
Feb
(10) |
Mar
(34) |
Apr
(34) |
May
(28) |
Jun
(50) |
Jul
(27) |
Aug
(75) |
Sep
(21) |
Oct
(42) |
Nov
(25) |
Dec
(31) |
| 2019 |
Jan
(39) |
Feb
(28) |
Mar
(19) |
Apr
(7) |
May
(30) |
Jun
(22) |
Jul
(54) |
Aug
(36) |
Sep
(19) |
Oct
(33) |
Nov
(36) |
Dec
(32) |
| 2020 |
Jan
(29) |
Feb
(38) |
Mar
(29) |
Apr
(30) |
May
(39) |
Jun
(45) |
Jul
(31) |
Aug
(52) |
Sep
(40) |
Oct
(8) |
Nov
(48) |
Dec
(30) |
| 2021 |
Jan
(35) |
Feb
(32) |
Mar
(23) |
Apr
(55) |
May
(43) |
Jun
(63) |
Jul
(17) |
Aug
(24) |
Sep
(9) |
Oct
(31) |
Nov
(67) |
Dec
(55) |
| 2022 |
Jan
(31) |
Feb
(48) |
Mar
(76) |
Apr
(18) |
May
(13) |
Jun
(46) |
Jul
(75) |
Aug
(54) |
Sep
(59) |
Oct
(65) |
Nov
(44) |
Dec
(7) |
| 2023 |
Jan
(38) |
Feb
(32) |
Mar
(35) |
Apr
(23) |
May
(46) |
Jun
(53) |
Jul
(18) |
Aug
(10) |
Sep
(24) |
Oct
(15) |
Nov
(40) |
Dec
(6) |
|
From: Richard C. <ric...@gm...> - 2012-02-18 08:06:34
|
On Fri, Feb 17, 2012 at 11:38:40PM +0000, Keller, Jacob E wrote: > When enabling software based timestamps via the '-s' switch, the > program switches to the faulty state instantly after transmitting a > packet that should be timestamped because the software timestamp is > never obtained. With further investigation, it turns out that > software timestamping appears to be disabled. I tested with the > kernel timestamping.c program, and indeed just selecting > sof_timestamping_tx_software, sof_timestamping_rx_software and > sof_timestamping_software does not return timestamps. The additional > option of sof_timestampns must also be enabled. But that gets the time stamp using the legacy BSD loopback method. I did not support this in ptp4l because it only works on UDPv4 packets. > I would like to use > software timestamping in order to connect ptp4l to a grandmaster > clock as verification that the protocol implementation works with a > known good PTP clock. Background: When Patrick Ohly introduced SO_TIMESTAMPING, the idea was to support Tx time stamps in a centralized place in the stack, for all drivers, just like to Rx time stamping. Several kernel crashes later, he discover that this can only be done in each individual driver. Presently there are only a dozen or so drivers with this support. I have a table of them on the linuxptp home page. So, you need to add one line, skb_tx_timestamp(), into the MAC driver in order to get ptp4l working with SW timestamping on your hardware. [ And please then submit a patch to netdev. I am trying to get SO_TIMESTAMPING support into every Ethernet driver, but there are lots and lots of them. ] > While the intention is for ptp4l to be used with hardware > timestamping, there still is issue with software timestamping not > working (for when the hardware doesn't support offloading) Yep, but I do consider this a driver issue. Let us work to get SO_TIMESTAMPING support into the kernel across the board. Thanks, Richard |
|
From: Keller, J. E <jac...@in...> - 2012-02-17 23:38:49
|
When enabling software based timestamps via the '-s' switch, the program switches to the faulty state instantly after transmitting a packet that should be timestamped because the software timestamp is never obtained. With further investigation, it turns out that software timestamping appears to be disabled. I tested with the kernel timestamping.c program, and indeed just selecting sof_timestamping_tx_software, sof_timestamping_rx_software and sof_timestamping_software does not return timestamps. The additional option of sof_timestampns must also be enabled. I would like to use software timestamping in order to connect ptp4l to a grandmaster clock as verification that the protocol implementation works with a known good PTP clock. While the intention is for ptp4l to be used with hardware timestamping, there still is issue with software timestamping not working (for when the hardware doesn't support offloading) |
|
From: Richard C. <ric...@gm...> - 2012-02-15 18:01:47
|
On Tue, Feb 14, 2012 at 02:21:34PM -0800, Michael Skoog wrote: > Hi Richard, > > When you were testing the DP83640.c phy driver, which MAC were you using? I have used the Intel Xscale IXP, and I also saw it working with the TI davinci EMAC driver. > The reason I'm asking is that I'm attempting to debug a problem I'm having > using the mv643xx_eth.c file as the MAC driver. When I receive a Delay > Response, the recvmsg function (in linuxptp) returns only EAGAIN. If the > required time-stamping is done rx_timestaming_work routine, then my > dp83640->rxts list doesn't have anything queued up in it. > > If you can point me in the right direction, it will be much appreciated. You my be the first person ever to try this out, so there might be a driver issue. But first, does your kernel have CONFIG_NETWORK_PHY_TIMESTAMPING? Richard |
|
From: Michael S. <sko...@gm...> - 2012-02-14 22:21:40
|
Hi Richard, When you were testing the DP83640.c phy driver, which MAC were you using? The reason I'm asking is that I'm attempting to debug a problem I'm having using the mv643xx_eth.c file as the MAC driver. When I receive a Delay Response, the recvmsg function (in linuxptp) returns only EAGAIN. If the required time-stamping is done rx_timestaming_work routine, then my dp83640->rxts list doesn't have anything queued up in it. If you can point me in the right direction, it will be much appreciated. Thank you very much, Michael Skoog |
|
From: Richard C. <ric...@gm...> - 2012-02-08 09:47:39
|
On Tue, Feb 07, 2012 at 11:20:13PM +0000, lin...@li... wrote: > > Hello Richard, > > I'm developing a product using Linux 3.2.2, mv643xx_eth.c and dp83640.c. I > ran into the "sk null assignment" problem that you were looking earlier in > http://lists.openwall.net/netdev/2011/10/11/42. > > Have any progress been made in this area? Or is it has it been solved alway? Yes, this issue was fixed with commits: 8b3408f8ee994973869d8ba32c5bf482bc4ddca4 dp83640: free packet queues on remove f5ff7cd1a84caa9545d952a37ac872ccb73825fb dp83640: use proper function to free transmit time stamping packets da92b194cc36b5dc1fbd85206aeeffd80bee0c39 net: hold sock reference while processing tx timestamps These commits also were applied to stable kernels 3.0 and 3.1. HTH, Richard > If not, I may have to dig into this area (and I am NOT a Linux expert; just > an embedded software eng.). > > Thank you very much for all the work you have done on PTP, > > Mike Skoog, Software Engineer |
|
From: Michael S. <sko...@gm...> - 2012-02-07 23:20:12
|
Hello Richard, I'm developing a product using Linux 3.2.2, mv643xx_eth.c and dp83640.c. I ran into the "sk null assignment" problem that you were looking earlier in http://lists.openwall.net/netdev/2011/10/11/42. Have any progress been made in this area? Or is it has it been solved alway? If not, I may have to dig into this area (and I am NOT a Linux expert; just an embedded software eng.). Thank you very much for all the work you have done on PTP, Mike Skoog, Software Engineer |
27 messages has been excluded from this view by a project administrator.
