From: Richard Cochran <richardcochran@gmail.com>
To: "Stern, Avraham" <avraham.stern@intel.com>
Cc: "Greenman, Gregory" <gregory.greenman@intel.com>,
"kuba@kernel.org" <kuba@kernel.org>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"johannes@sipsolutions.net" <johannes@sipsolutions.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: pull-request: wireless-next-2023-03-30
Date: Tue, 25 Apr 2023 19:43:40 -0700 [thread overview]
Message-ID: <ZEiP3LDTQ86c4HaN@hoboy.vegasvil.org> (raw)
In-Reply-To: <SN7PR11MB6996324EBF976C507D382C3AFF649@SN7PR11MB6996.namprd11.prod.outlook.com>
On Tue, Apr 25, 2023 at 07:03:50AM +0000, Stern, Avraham wrote:
> Having the timestamps of the frames seemed like a basic capability that userspace will need to implement ptp over wifi, regardless of the selected approach.
Having time stamps on unicast PTP frames would be a great solution.
But I'm guessing that you aren't talking about that?
> Apparently you had other ways in mind, so I would love to have that discussion and hear about it.
Let's back up a bit. Since you would like to implement PTP over Wifi
in Linux, may I suggest that the first step is to write up and
publish your design idea so that everyone gets on the same page?
Your design might touch upon a number of points...
- Background
- Difficulty of multicast protocols (like PTP) over WiFi.
- What do the networking standards say?
- IEEE Std 802.11-2016
- Timing Measurement (TM)
- Fine Timing Measurement (FTM)
- IEEE 1588
- Media-Dependent, Media-Independent MDMI
- Special Ports
- 802.1AS
- Fine Timing Measurement Burst
- Which of the above can be used for a practical solution?
- What are the advantages/disadvantages of TM versus FTM?
- What alternatives might we pursue?
- unicast PTP without FTM
- AP as transparent clock
- Existing Linux interfaces for time synchronization
- What can be used as is?
- What new interaces or extensions are needed, and why?
- Vendor support
- How will we encourage broad acceptance/coverage?
IMO, the simplest way that will unlock many use cases is to provide
time stamps for single unicast frames, like in
ieee80211_rx_status.device_timestamp and expose an adjustable PHC
using timecounter/cyclecounter over the free running usec clock. Then
you could synchronize client/AP over unicast IPv4 PTP (for example)
with no user space changes needed, AND it would work on all radios,
even those that don't implement FTM.
Thanks,
Richard
next prev parent reply other threads:[~2023-04-26 2:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-30 20:56 pull-request: wireless-next-2023-03-30 Johannes Berg
2023-03-31 7:06 ` Jakub Kicinski
2023-04-03 22:45 ` Richard Cochran
2023-04-13 3:33 ` Richard Cochran
2023-04-18 13:35 ` Greenman, Gregory
2023-04-20 3:43 ` Richard Cochran
2023-04-23 13:33 ` Stern, Avraham
2023-04-24 22:04 ` Richard Cochran
2023-04-25 1:29 ` Richard Cochran
2023-04-25 7:03 ` Stern, Avraham
2023-04-26 2:43 ` Richard Cochran [this message]
2023-04-26 14:04 ` Richard Cochran
2023-05-07 16:32 ` Stern, Avraham
2023-03-31 7:10 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZEiP3LDTQ86c4HaN@hoboy.vegasvil.org \
--to=richardcochran@gmail.com \
--cc=avraham.stern@intel.com \
--cc=gregory.greenman@intel.com \
--cc=johannes@sipsolutions.net \
--cc=kuba@kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).