linuxptp-users Mailing List for linuxptp (Page 131)
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: Kiran <kir...@gm...> - 2015-01-09 11:52:13
|
Hi Richard, I am trying to run PTP and I would like to know if it is possible to run a master with hardware timestamping and a slave with software timestamping or the other way around. Thanks and Regards, Kiran |
|
From: Kiran <kir...@gm...> - 2015-01-09 11:46:53
|
Hi Richard, I am trying to run PTP and I would like to know if it is possible to run a master with hardware timestamping and a slave with software timestamping or the other way around. Thanks and Regards, Kiran |
|
From: Kiran <kir...@gm...> - 2015-01-09 11:41:54
|
Hello Richard, I have a question about the timestamping. Is it possible to use hardware timestamping at the master and software timestamping at the slave? Thanks and Regards, Kirans |
|
From: Kiran <kir...@gm...> - 2015-01-09 11:39:57
|
Hi Richard, I am trying to run PTP and I would like to know if it is possible to run a master with hardware timestamping and a slave with software timestamping or the other way around. Thanks and Regards, Kiran |
|
From: Holzinger, A. (A. N. GmbH) <Axe...@al...> - 2015-01-07 16:38:24
|
On Wed, 2015-01-07 at 17:27 +0100, Richard Cochran wrote: > So YRMV with the free running error statistics. Sometimes they > don't make sense. Thanks for the explanation. I think I remember that running in gPTP mode I didn't saw the huge (offset) numbers, so it might be that on this system the PHC was running on TAI initially. > One new feature idea is programmable output strings... patches? Good answer :-) Got us! Well this would lead to additional configuration params I guess. We'll keep that in mind if we stumble over this another time. Using free running mode was just a test to see if results differ significantly. Thanks a lot! Axel |
|
From: Richard C. <ric...@gm...> - 2015-01-07 16:26:56
|
On Wed, Jan 07, 2015 at 03:48:24PM +0000, Holzinger, Axel (ALC NetworX GmbH) wrote: > Does it make sense to print the offset error of the PHC when it's free running? (Sometimes it does ;) 1. I often use "free_running 1" with software time stamping to test my NTP performance against a local GPS GM clock. 2. When developing a GPS GM with hardware time stamping and a PHC, it is interesting to steer the PHC with the GPS PPS, and check the result with another GPS GM with ptp4l free running. So YRMV with the free running error statistics. Sometimes they don't make sense. One new feature idea is programmable output strings... patches? Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2015-01-07 16:07:46
|
On Wed, Jan 07, 2015 at 12:35:19PM +0000, Koehrer Mathias (ETAS/ESW5) wrote: > Is it possible to get these values from phc2sys directly without the need to parse the logfile? We don't have any other interface for phc2sys. You could monitor the output with your own program or script, starting phc2sys with '-m' and piping the output, eg: phc2sys -q -m 2>&1 | my_monitor_program > The background of the question is that I have to wait for the start of my proprietary application until the clocks of the PCs run in a well synchronized state. > Or what is the recommendation for this use case? I guess that you also want to know the state of ptp4l, because the slave side will have to wait for the PHC to get the master's time. I think it is hard to offer a general solution to the problem of knowing whether a distributed application is ready to start, because applications define "ready" in different ways. However, I also think all of the information needed to decide that the system is "ready" is available. You just need to integrate these inputs into your own application. Maybe the phc2sys status could be offered in a more convenient way... patches are welcome! Thanks, Richard PS It sounds like phc2sys's new "automatic mode" might interest you: phc2sys -a -rr |
|
From: Holzinger, A. (A. N. GmbH) <Axe...@al...> - 2015-01-07 15:48:34
|
On Wed, 2015-01-07 at 16:38 +0100, Tino Keitel wrote: > On Wed, 2015-01-07 at 16:30 +0100, Richard Cochran wrote: > > Tino, > > > > On Wed, Jan 07, 2015 at 03:10:21PM +0100, Tino Keitel wrote: > > > ptp4l[3620464.599]: rms 34999387468 max 34999407058 freq - > > > 19592 +/- 0 > > > ptp4l[3620468.598]: rms 34999465846 max 34999485433 freq - > > > 19595 +/- 7 > > > > Max here is always positive. It is the absolute value > > (magnitude) of the maximum offset during the interval. > > > > > Querying ptp4l using pmc gives this output (note the first > > > offsetFromMaster value): > > > > > > $ pmc -u "get CURRENT_DATA_SET" > > > sending: GET CURRENT_DATA_SET > > > 001b21.fffe.929906-0 seq 0 RESPONSE MANAGMENT > > > CURRENT_DATA_SET > > > stepsRemoved 2 > > > offsetFromMaster -35000968295.0 > > > > Here the plain offset is given. > > > > Both values show the offset error to be about 35 seconds, which > > is the TAI/UTC offset. Probably your PHC driver sets its time > > to the UTC system time when loading. > > Hi Richard, > > this sounds like it is normal behavior to show the offset to the > PHC even if the PHC is not touched (free_running set to 1). > > Regards, > Tino Rchard, Tino et al. Does it make sense to print the offset error of the PHC when it's free running? This value will always increase as the PHC drifts away over time, if it's free running. Shouldn't the message contain the true offset after calculation with the software offset? IMHO in free running mode it doesn't matter at which position the PHC starts (with or without UTC offset or any other weird position like zero = 01/01/1970). Just my 0.02€ Axel |
|
From: Tino K. <tin...@al...> - 2015-01-07 15:38:15
|
On Wed, 2015-01-07 at 16:30 +0100, Richard Cochran wrote: > Tino, > > On Wed, Jan 07, 2015 at 03:10:21PM +0100, Tino Keitel wrote: > > ptp4l[3620464.599]: rms 34999387468 max 34999407058 freq -19592 +/- 0 > > ptp4l[3620468.598]: rms 34999465846 max 34999485433 freq -19595 +/- 7 > > Max here is always positive. It is the absolute value (magnitude) of > the maximum offset during the interval. > > > Querying ptp4l using pmc gives this output (note the first > > offsetFromMaster value): > > > > $ pmc -u "get CURRENT_DATA_SET" > > sending: GET CURRENT_DATA_SET > > 001b21.fffe.929906-0 seq 0 RESPONSE MANAGMENT CURRENT_DATA_SET > > stepsRemoved 2 > > offsetFromMaster -35000968295.0 > > Here the plain offset is given. > > Both values show the offset error to be about 35 seconds, which is the > TAI/UTC offset. Probably your PHC driver sets its time to the UTC > system time when loading. Hi Richard, this sounds like it is normal behavior to show the offset to the PHC even if the PHC is not touched (free_running set to 1). Regards, Tino |
|
From: Richard C. <ric...@gm...> - 2015-01-07 15:30:49
|
Tino, On Wed, Jan 07, 2015 at 03:10:21PM +0100, Tino Keitel wrote: > ptp4l[3620464.599]: rms 34999387468 max 34999407058 freq -19592 +/- 0 > ptp4l[3620468.598]: rms 34999465846 max 34999485433 freq -19595 +/- 7 Max here is always positive. It is the absolute value (magnitude) of the maximum offset during the interval. > Querying ptp4l using pmc gives this output (note the first > offsetFromMaster value): > > $ pmc -u "get CURRENT_DATA_SET" > sending: GET CURRENT_DATA_SET > 001b21.fffe.929906-0 seq 0 RESPONSE MANAGMENT CURRENT_DATA_SET > stepsRemoved 2 > offsetFromMaster -35000968295.0 Here the plain offset is given. Both values show the offset error to be about 35 seconds, which is the TAI/UTC offset. Probably your PHC driver sets its time to the UTC system time when loading. HTH, Richard |
|
From: Tino K. <tin...@al...> - 2015-01-07 14:10:37
|
Hi Richard, I get a strange behavior when using "free_running 1". The summary looks like this: $ ptp4l -f /etc/ptp4l.conf -i eth1 -m ptp4l[3620445.368]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[3620445.368]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[3620445.600]: port 1: new foreign master 008063.fffe.b6706b-13 ptp4l[3620447.600]: selected best master clock 00606e.fffe.7c230f ptp4l[3620447.600]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[3620448.515]: port 1: minimum delay request interval 2^3 ptp4l[3620452.600]: rms 34999153762 max 34999173342 freq -19583 +/- 2 delay 7694 +/- 246 ptp4l[3620456.599]: rms 34999231855 max 34999251436 freq -19587 +/- 3 delay 5256 +/- 0 ptp4l[3620460.599]: rms 34999309648 max 34999328697 freq -19591 +/- 8 delay 5141 +/- 0 ptp4l[3620464.599]: rms 34999387468 max 34999407058 freq -19592 +/- 0 ptp4l[3620468.598]: rms 34999465846 max 34999485433 freq -19595 +/- 7 Querying ptp4l using pmc gives this output (note the first offsetFromMaster value): $ pmc -u "get CURRENT_DATA_SET" sending: GET CURRENT_DATA_SET 001b21.fffe.929906-0 seq 0 RESPONSE MANAGMENT CURRENT_DATA_SET stepsRemoved 2 offsetFromMaster -35000968295.0 meanPathDelay 5354.0 008063.fffe.b6706b-13 seq 0 RESPONSE MANAGMENT CURRENT_DATA_SET stepsRemoved 1 offsetFromMaster -33.0 meanPathDelay 87.4 000b72.fffe.0585b6-1 seq 0 RESPONSE MANAGMENT CURRENT_DATA_SET stepsRemoved 2 offsetFromMaster -2.0 meanPathDelay 3818.0 Everything is fine as soon as I use "free_running 0". Regards, Tino |
|
From: Koehrer M. (ETAS/ESW5) <mat...@et...> - 2015-01-07 12:35:30
|
Hi all, I have two PCs synchronized with linuxptp (V1.4 or V1.5 - the question is valid for both versions). On both PCs I run the following commands: /usr/local/sbin/ptp4l -i eth1 -p /dev/ptp1 -f /etc/linuxptp.conf and /usr/local/sbin/phc2sys -s /dev/ptp1 -w -u 15 -l 6 This works and I can see in the log file of the PCs the synchronization accuracy. Example of the logging in my system logfile: Jan 7 13:23:59 pcA phc2sys: [2964.861] rms 17 max 31 freq -8176 +/- 18 delay 2687 +/- 21 Jan 7 13:24:14 pcA phc2sys: [2979.862] rms 19 max 46 freq -8167 +/- 18 delay 2690 +/- 20 Jan 7 13:24:29 pcA phc2sys: [2994.863] rms 23 max 45 freq -8158 +/- 20 delay 2690 +/- 24 or from the second PC: Jan 7 13:23:59 pcB phc2sys: [2974.050] rms 16 max 38 freq +1822 +/- 18 delay 5750 +/- 33 Jan 7 13:24:14 pcB phc2sys: [2989.051] rms 24 max 53 freq +1837 +/- 21 delay 5755 +/- 87 Jan 7 13:24:29 pcB phc2sys: [3004.053] rms 16 max 34 freq +1850 +/- 13 delay 5736 +/- 84 Is it possible to get these values from phc2sys directly without the need to parse the logfile? The background of the question is that I have to wait for the start of my proprietary application until the clocks of the PCs run in a well synchronized state. Or what is the recommendation for this use case? Thanks for any help on this question. Best Regards Mathias |
|
From: Keitel, T. (A. N. GmbH) <Tin...@al...> - 2015-01-06 20:30:12
|
Hi, packaging for 1.5 is now available via git, as a source package and amd64 binary package. http://tikei.de/git/linuxptp-debian.git http://tikei.de/debian/linuxptp/ Now a default config is installed, as well as systemd services for ptp4l and phc2sys (see README.Debian). Regards, Tino |
|
From: Kiran <kir...@gm...> - 2015-01-05 14:20:12
|
Hello Richard, Thank you for your prompt response. Regards, Kiran |
|
From: Kiran <kir...@gm...> - 2015-01-05 14:17:16
|
Hello Richard, Thank you for your prompt response. Regards, Kiran |
|
From: Richard C. <ric...@gm...> - 2015-01-05 13:12:02
|
On Mon, Jan 05, 2015 at 10:39:51AM +0000, Kiran wrote: > Hello, > > I am doing a project for my final year using linuxptp and I would like to > know the exact method linuxptp uses to synchronise two systems. Even the > name of the file that implements this part would do. The synchronization in performed in the function, clock_synchronize(), in the file, clock.c. > Also, I found from the archives that the unicast funcitonality is still > under development. Is this true as of now? Unicast is not implemented, and it is not under active development either. HTH, Richard |
|
From: Kiran <kir...@gm...> - 2015-01-05 10:45:13
|
Hello, I am doing a project for my final year using linuxptp and I would like to know the exact method linuxptp uses to synchronise two systems. Even the name of the file that implements this part would do. Also, I found from the archives that the unicast funcitonality is still under development. Is this true as of now? Thanks and Regards, Kiran |
|
From: Richard C. <ric...@gm...> - 2014-12-23 17:57:34
|
Dear linuxptp users and developers,
Just in time for Christmas, I announce version 1.5 of linuxptp. This
release comes ten months since the previous one.
I have pushed out the v1.5 tag and released a tar ball on SF.
Once again, my thanks go out to the contributors, Delio, Jacob, Jiri,
and Miroslav, and to Joe Schaack for SO_SELECT_ERR_QUEUE. The short
log is appended, below.
Enjoy,
Richard
Delio Brignoli (2):
port: adjust peer delay calculation using neighborRateRatio
config: Add min_neighbor_prop_delay configuration variable
Jacob Keller (4):
missing: add SIOCGHWTSTAMP to missing.h
hwtstamp_ctl: use SIOCGHWTSTAMP ioctl before destructively setting policy
gitignore: add .version as this is generated during a make
linuxptp: add phc_ctl program to help debug PHC devices
Jiri Benc (40):
Move check of TLV length for management COMMAND messages
Move common code into port_prepare_and_send
raw: fix reading of uninitialized memory on recv
raw: replace hard coded constants by MAC_LEN
raw: separate src and dst addresses
Let transport_recv/send/peer use ptp_message
Common type holding an address
Implement transport_sendto
uds: don't output "Connection refused"
Respond with an error to management messages to non-existing ports
Remove unneeded parameter in port_forward
Implement port_forward_to
Event subscribing
Subscription time limit
port: event notification
clock: event notification
Event notification: port state
Custom management TLV PORT_PROPERTIES_NP
phc2sys: generalize run_pmc
phc2sys: split update_sync_offset
phc2sys: split clock and node
phc2sys: store information about clocks being UTC or TAI
phc2sys: rearrange declarations
phc2sys: open devices in clock_add
phc2sys: track ports
pmc_common: easy way to set port and broadcast target
phc2sys: event subscription
phc2sys: propagate received errors
phc2sys: autoconfiguration
phc2sys: autoconfigure realtime clock on demand only
phc2sys: check clockIdentity
phc2sys: man page update for -a and -r options
phc2sys: reset sync offset if non PTP timescale
Put fault_fd into struct port
Make uds port a separate field in struct clock
Dynamic port allocation
Lazy regeneration of pollfd
Remember last used port number
Dynamic allocation of interface config entries
phc2sys: fix overwriting of the clock state
Miroslav Lichvar (36):
Fix conversion of cumulativeScaledRateOffset in TIME_STATUS_NP.
Initialize clock rate ratio.
pmc: print cumulativeScaledRateOffset as offset.
Restrict SET actions to UDS port.
Don't always step clock on PI servo reset.
Move PI step threshold and max frequency settings to common servo code.
Add an adaptive servo based on linear regression.
Include clock rate ratio in delay calculation.
Increase default first step threshold to 20 us.
Print warning message on deprecated ptp4l options.
Fix sk_interface_addr().
Remove unused field from struct config.
Add new servo for NTP SHM reference clock.
phc2sys: track sync offset and leap second status in each clock.
Set TAI offset of system clock.
phc2sys: Use CLOCK_MONOTONIC to time pmc updates.
Add leap function to servo.
ntpshm: Pass upcoming leap second.
linreg: Handle leap second gracefully.
Disable clockcheck and kernel leap with ntpshm servo.
Prefix TLV IDs.
phc2sys: Add option to set path to ptp4l UDS.
Remove socket when closing UDS transport.
Move signal handling to util.c.
Close client UDS transport before exit.
Append PID to client UDS paths.
Add option to set NTP SHM segment number.
Fix copying of device name to ifreq.
Fix Coverity warning in sk_interface_addr().
Don't print messages in signal handler.
Don't include config.h in util.h
Add string and pointer array utility functions.
Add timemaster.
port: fix fda initialization.
clock: keep ports in specified order.
linreg: fix servo resetting
Richard Cochran (21):
Fix a trivial spelling mistake in a comment.
Bump the date on the hwstamp_ctl man page.
Add a macro for ADJ_TAI used when missing from the tool chain headers.
Merge Jiri's Dynamic port allocation series.
Restore the peer addresses in P2P mode.
Use SO_SELECT_ERR_QUEUE when available.
Coding style: add missing break statement from a switch/case construct.
trivial: do not assign a FP constant to an integer.
trivial: update gitignore with the timemaster build product.
config: remove useless parameter.
Add a bunch more drivers into the support matrix.
Introduce a helper function to identify valid (non-zero) time stamps.
Invoke the clock check even if the time stamp nanoseconds field is zero.
config: Introduce options for correcting transmit and receive delays.
port: correct transmit and receive time stamps for their calibrated delays.
config: add a option to enable a poor man's boundary clock.
clock: Introduce a function to switch the PTP Hardware Clock.
port: allow running a boundary clock with multiple clock devices.
phc2sys: automatic mode: synchronize all non-slave ports.
phc2sys: default to the first clock in automatic mode.
Version 1.5
|
|
From: Richard C. <ric...@gm...> - 2014-12-20 22:33:07
|
Rich, On Sat, Dec 20, 2014 at 05:04:10PM -0500, Rich Schmidt wrote: > I find it useful to output offset_stats.mean along with > offset_stats.stddev in clock_stats_update() in file clock.c, also replace > the reference to temporal vortex... Can you please post a unified diff [1] to the linuxptp-devel list? Thanks, Richard 1. command: diff -up |
|
From: Rich S. <sch...@gm...> - 2014-12-20 22:04:17
|
I find it useful to output offset_stats.mean along with
offset_stats.stddev in clock_stats_update() in file clock.c, also replace
the reference to temporal vortex...
clock.dif
357c357
< pr_info("rms %4.0f max %4.0f "
---
> pr_info("offs %+6.0f +/- sd %4.0f max %4.0f "
360c360,361
< offset_stats.rms, offset_stats.max_abs,
---
> offset_stats.mean,
> offset_stats.stddev, offset_stats.max_abs,
481c482
< pr_warning("running in a temporal vortex");
---
> pr_warning("tds.currentUtcOffset < CURRENT_UTC_OFFSET");
|
|
From: Richard C. <ric...@gm...> - 2014-12-19 17:53:41
|
Dear linuxptp developers and users, I plan on releasing version 1.5 before Christmas. If you have any remaining patches or issues, please post them ASAP. Thanks, Richard |
|
From: Tino K. <tin...@al...> - 2014-12-18 09:57:17
|
Hi, just a small addition: I'm not a Debian developer. So if anyone would like to sponsor the package, feel free to contact me. Regards, Tino |
|
From: Richard C. <ric...@gm...> - 2014-12-18 09:51:41
|
On Thu, Dec 18, 2014 at 10:11:38AM +0100, Tino Keitel wrote: > a preliminary Debian package based on linuxptp 1.4 is available here: Thanks for getting this started. It would be great to have an official debian package for linuxptp. Cheers, Richard |
|
From: Tino K. <tin...@al...> - 2014-12-18 09:24:45
|
Hi, a preliminary Debian package based on linuxptp 1.4 is available here: http://tikei.de/debian/linuxptp/ The corresponding git repository can also be fetched: git clone http://tikei.de/git/linuxptp-debian.git It is very rough and yet untested. Currently it just installs the binaries and manpages. The next steps are systemd integration and its config files. This will be very much like in the Fedora package. The Debian ITP bug is here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771843 If anyone wants to participate, feel free to send patches against the git repository or just a comment to 77...@bu.... Regards, Tino |
|
From: Richard C. <ric...@gm...> - 2014-10-27 10:07:14
|
On Fri, Oct 24, 2014 at 05:29:22PM +0200, Julian Scheel wrote: > Hi, > > I am trying to migrate from ptp2 to ptp4l currently. Using wired > networking I got everything to work quite well using software > timestamping yet and get very good results. But I also need sync via > wifi (I am aware the results will not be as good as via cable, but > through ptp2 I was able to achieve at least 100us accuracy). > Now it seems that the wifi stack in recent linux kernels is not > supporting SOF_TIMESTAMPING_TX_SOFTWARE at all. But this seems to be a > hard requirement for using ptp4l with software timestamping, right? Right. > I am just wondering how ptp4l was running on a wireless device in this > discussion: > http://permalink.gmane.org/gmane.comp.linux.ptp.user/295 Drasko (who started the topic) apparently hack Tx time stamping into the wireless stack, but he did say how or where he did it, IIRC. See also the other threads he started on May 31, 2013. > I'd be glad about any hints how to get ptp4l working with a wireless > device. Actually I am using a rtl8192cu device right now. > Are there some kernel patches around implementing > SOF_TIMESTAMPING_TX_SOFTWARE for wireless devices maybe? None that I know of. Once or twice I looked at adding this into the wireless code, but I could not find the right place to do it. (but maybe there is some way to do it...) Thanks, Richard |
27 messages has been excluded from this view by a project administrator.
