00089: we have big time jump after roughly 72min what seems to be a 32bit wrapping problem. we need to solve this
00445: No I only need the parts that are part of our current problem (the ts jumping). Could the 1000 multiplier can lead to the problem we saw, that the offset is always that high?
00985: can you explain, why this should help finding the problem with tx? I mean it worked with git commit sha 7ad796096dcdb1582c406ec57415eb696c9d2c23
01354: I dont know, what you are planning to do. The problem still is, that there are no tx frames are coming through. We need to find that issue first
01361: So TX is happening; the problem is likely TX hardware timestamps not being reported back, not that frames aren’t transmitted.
01418: So the problem is: SKBTX_HW_TSTAMP is usually not set before ath9k, and only occasionally is.
01758: the update process is currently running. In the meanwile lets talk about something: I asked myself wether it could be a problem to have debug output in the tx or rx path of the kernel!? I was wondering because the problems with transmitting the tx timestamps came with our additional terminal (log) output
02664: ptp4l is running on both nodes and no “missing timestamp” errors appear in the logs now. The remaining problem is that both nodes are still assuming grand master, which prevents stable synchronization.
03880: I startet the ptp4l isntances by hand... still the same problem... I think its a better idea (in terms of decoupling the kernel from the ptp4l problems) to have a look at the tcpdump and to ensure, that at least the timestamps are correct, dont you thnik?
03954: I think I see whats the problem: the field originTimeStamp always show 0 seconds and 0 nanoseconds. So there seems something to not work
04380: the dealy measurement could really be a problem. Is there a difference between the original implementation and wifi-ptp?
04435: So you mean, ptp4l is not very likely the problem? then lets go through the wohle rx and tx ts paths in kernel, to identify where the big jumps could come from
04517: we need to be careful, that our changes are to effecting the receive or transmit path directly, this could cause time problems. Have you considered this?
04649: OK the nodes are back running... lets try to get the problem by checking the ptp4l output + tcpdump on both nodes
04673: can you explain to me, what your problem via ssh is about? I saw that you had trouble with starting ptp4l
04675: The “ssh problem” wasn’t ptp4l itself — it was pkill -9 -f ptp4l.
04740: one thing to note: in state s1 the clock should step to the time of the master, right? But what we see is, that it flips in the complete different direction (nearly the same order of magnitude). I think thats no coinsidence but a hint of wehere the problem could come from
05443: Key point: apu00 phc_ns has a backward step of ~1.253 s (max_back=1253097382) while TSF/RX‑ext remain monotonic. That aligns with the ~1.253 s offset we see in ptp4l, and indicates the problem is in the PHC timecounter path (not TSF wrap or RX extension).
05536: the kernel is currently compiling. in the meanwhile lets talk about possible reasons for this problem. Do you think its more likely, that the problem comes from the ptp4l implementation, oder from the driver/kernel code?
05585: I have a problem to understand: so ptp4l requests a time jump and the driver performes it correctly. The requested time jump should be in that direction, so that the offset between master and slave is ideally very small. can we see, that this is wokring?
05754: so the kernel is buidling now... In the meanwhile please tell me in wich direction you are thinking specifically. I mean: you say the problem seams to be in the kernel space. Tx and rx timestamps are transmitted correctly. when the adjustment isnt set correctly: which factor can yause this problem ?
05927: OK, then lets do the following: we first need to solve the s1 problem! What if we add some debugfs extensions in the whole timecounter adj path? What is the task of ptp.c in the ath9k driver?
06014: This means the problem is not the step application itself. The step is correct. The sign flip happens in the offset calculation, i.e., the inputs used by ptp4l (t1/t2/t3/t4) are inconsistent after the step — likely due to delay measurement or timestamp pairing rather than timecounter adjustment.
06063: So the problem is not missing pairs; it is that t2 (the RX timestamp) jumps into a different epoch right after s1, while t1 continues smoothly.
06277: great... now lets think about where the t2 flip could come from: with original wifi-ptp we never saw  such a behaviour. So the problem MUST be part of our modifications... I just thought: what is with the calculatet tsf delta that we use for adjusting, do we need that maybe too for the rx path?
06666: you missed running ptp4l... but anyway: when you say the problem is not the ptp4l traffic but the t2 path: why dont we just analyze the t2 master tx path and the t2 slave rx path?
06951: So t1 is monotonic, and t2 flips sign between two consecutive Syncs. That pins the problem to the t2 (Sync ingress) path, not Follow_Up or message pairing.
07279: No—option 1 does not mean “recompute with post‑step t2.” The problem is mixing pre‑step cycles with a post‑step epoch. So the safe options are:
07373: That means the RX cycle isn’t being flagged as “pre‑step” by our condition, so we didn’t actually drop the problematic sample.
07842: before we start with something else: we need to document everything we have done in this session -> every code change + the reasons for that, the problems with wifi-ptp we found out, the debug possibilies we added, and so on... can you effort that?
08359: unfortunately I had two ptp4l instances running on apu01. Could that lead to problems?
08361: Yes — two ptp4l instances on the same interface/PHC can definitely cause problems. They will both try to control the same clock, fight over adjustments, and you’ll see instability like “clock frequency changed unexpectedly,” jumps, or failed sync.
08418: This should fix the “second wrap” problem if TSF is being adjusted during runtime.
09478: Short answer: it shouldn’t introduce timing problems. ath9k_hw_settsf64() is only called on TSF set/reset paths (beacon re‑sync, resets, etc.), not in the RX/TX hot path, and the rebase just updates a few counters under systim_lock.
09530: That directly addresses the “rebases=0” problem you saw in debugfs even though TSF was clearly being set.
09826: Rebase alone doesn’t solve the PHC continuity problem.
10292: Thats what I meant... when ptp4l never sees them, that cannot be the problem, since we abblied our rebase to everything ptp sees, right? Here is the official ptp repo: https://github.com/richardcochran/linuxptp
10628: the second wrap runs through also with no problems
10799: I think since the second wrap is the key of that problem, I need a way to froce the it. What if we set the TSF to a very high value to see whether this is true?
12423: the rebase works perfectly fine, but the desired wrap after 10 seconds doesnt happen... Maybe here is already the big problem, we need to find that out
13070: OK, another thing: please get the ptp4l version isntalled on apu02 and check the internet whether there was such a problem with it earlier
13291: OK so the problem is the master node? Yes pull the evtlog of apu01 and see if we can see the big phc jump there
13781: so with a view on our problem (the time stepped backwards and breaks the whole ptp path) nothing changed?
13915: Because ath9k_hw_gettsf64() returns the raw TSF register, not the per‑packet timestamp. That causes two problems for PTP event timestamps:
13924: Per‑packet timestamps are captured by hardware at the instant of RX/TX, and in ath9k those timestamps are only 32‑bit (rs_tstamp/ts_tstamp/status->mactime). That creates three concrete problems if you try to “fix it” by reading the full 64‑bit TSF register later:
13943: so the problem isnt really the timestamps the packets are carrieng but the ones that are triggered by the hardware when sendet or received
13945: Exactly. The problem is the hardware‑captured event timestamp (RX/TX timestamp) that the chip attaches at the moment of send/receive — that value is only 32‑bit and not paired with the upper TSF bits. The packet itself doesn’t “carry” a timestamp; the driver reads a 32‑bit latch from the hardware status. That’s why we have to extend and rebase those event timestamps in software.
14377: OK so to break it down cycle_last is the problem here, right? So the monotinic filter youre suggesting would identify such a jump and would do what?
14749: Added a dedicated backward‑jump investigation section and documented the mitigation/observability changes (correction logic, settsf stack logging, debugfs knobs) plus updated the problems/open‑issues bullets so the draft reflects the actual findings and status. All edits are in wifi-ptp_publication_draft.md.
15622: what came into my mind: a read earlier that in multple scentific works on that topic they found out, that the gettsf64 function causes such problems (backward jumping times) because they read both registers high and low after another. So that could be a lock problem...
15660: I also read that in  ath5k/ath9k cards the frimware produces such backflipped timestamps... Our problem is also the real tsf that is jumping, right?
16085: Kurz: ja, Logging kann das Timing beeinflussen – vor allem, wenn es in RX/TX läuft oder oft über debugfs gelesen wird. Das kann Latenzen erhöhen, Softirq‑Pacing verschieben und den Servo früher „aus dem Tritt“ bringen. Es muss nicht die Ursache sein, aber es kann den Zeitpunkt des Sprungs nach vorne ziehen.
16091: Wenn nötig, PHC‑Window nur kurz um den erwarteten Sprung (nicht dauerhaft an).
16135: Kurzfassung: für einen kompletten Run reicht ein größerer Ring allein nicht, weil der Ring bei dauerhaftem PHC‑Logging extrem schnell überschrieben wird. Die Größe hängt direkt von der Eventrate ab.
16163: Kurz: in den bisherigen Snapshots rund um den Sprung (z. B. summary.log) waren RX/TX‑Events monoton – tsf64, ext und hwtstamp_ns sind dort nicht rückwärts gegangen.
16164: Aber: das ist kein Beweis für den ganzen Run, weil wir nur die letzten paar Einträge hatten und oft mit EVTLOG_PTP_ONLY=1 geloggt haben.
16173: OK aber zum debuggen brauchen wir vlt rx und tx nicht, wenn wir alle phc infos haben
16231: aber irgendwie ist die Frage noch nicht geklärt, warum auf einmal der Jump so früh passiert, irgendetwas läuft da gerade nicht rund
16233: Verständlich – „früherer Jump“ ist genau das Muster, das man sieht, wenn sich die System‑Last oder Logging‑Pfad ändert. Es muss nicht die Ursache sein, aber es verschiebt oft den Zeitpunkt.
16269: (wenn EVTLOG_PTP_ONLY=0, wird nicht zurück auf 0 gesetzt!)
16275: Bei späteren Runs mit EVTLOG_PTP_ONLY=0 setzt das Script den Schalter nicht zurück → RX/TX bleiben weiterhin gefiltert.
16291: ptp_evtlog_ptp_only wird jetzt immer auf EVTLOG_PTP_ONLY gesetzt (0/1), nicht nur wenn 1
16351: Das Script startet dort einen Hintergrund‑Loop, der den Debugfs‑Evtlog regelmäßig liest und lokal nach ptp_evtlog_watch_<RUN_ID>.log schreibt.
16373: ptp_evtlog_watch_20260211_141705.log ist 0 B → dort kommt aktuell nichts an.
16430: die drain last ist mir eigentlich egal, außer ptp läuft auf den Knoten quasi nichts nennenswertes
16483: => Wahrscheinlich kommt der Spike nicht von TSF/PHC‑Rebase, sondern von einem einzelnen PTP‑Sample, z. B. Sync/FUP‑Mismatch, verspätetes Paket, oder ein einzelner fehlerhafter HW‑Timestamp.
16488: Dann genau um ~780s/815s die ptp_evtlog Einträge prüfen (PTP‑Frames im Payload/ETHERTYPE 0x88f7) – da müsste das fehlerhafte Sample sichtbar sein.
16568: ptp_evtlog ist im aufgezeichneten Fenster monotonic (keine rückwärts laufenden hwtstamp_ns), aber: der letzte hwtstamp_ns endet ~9.47 s vor dem Snapshot‑Zeitpunkt (evtlog_max ≈ 14:37:37.53 vs. Snapshot 14:37:47). Das heißt, der konkrete PTP‑Frame, der die Spitze auslöst, ist nicht im Ring.
16569: Kurz: Mit diesem Run können wir ausschließen, dass es ein settsf/settime‑Ereignis war, aber wir können die Ursache nicht direkt am RX/TX‑Frame nachweisen, weil der Ring die kritische Sekunde verpasst hat.
16583: In den jump_*‑Ordnern landet nur ein Snapshot des Ring‑Buffers (ptp_evtlog.log), nicht der kontinuierliche Drain.
16605: Wenn du willst, können wir als nächsten Schritt genau die PTP‑Header aus dem evtlog dekodieren (Sequence‑ID, Message‑Type) und damit die Outlier auf Sync/Delay‑Frames zurückführen. Das sollte die Ursache sauber belegen.
16647: Wenn der Jump zwischen zwei geloggten Events passiert, siehst du nur die Folge, nicht den Auslöser. Dafür brauchst du entweder:
16674: interessant, warum sagst du das nicht gleich... warum wir phc gettime nicht gecalled? passeiret das nicht auch wenn ptp seine Berehcnungen durchführt?
16678: Wichtig ist: ath9k_phc_gettime() wird nur aufgerufen, wenn jemand die PHC‑Zeit aktiv abfragt (z. B. phc_ctl, phc2sys, clock_gettime(CLOCK_PTP) auf /dev/ptp3).
16679: ptp4l ruft das nicht pro Berechnung auf. Es arbeitet für die Offset‑Berechnung mit den RX/TX‑Hardware‑Timestamps aus den Paketen (SO_TIMESTAMPING) und stellt die Uhr nur per adjtime/adjfine/settime – dafür braucht es kein gettime.
16691: aber das bedeutet doch auch, dass wir im dümmsten Fall den jump nicht rekonstruieren können, auch wenn wir mit 1 sekunde pollen
16694: Wenn der Jump zwischen zwei PHC‑Reads passiert und wieder verschwindet (oder nur ein einzelner Event betroffen ist), kann er trotz 1‑s‑Polling unbemerkt bleiben. Du siehst dann nur „vorher/nachher“, aber nicht den eigentlichen Trigger.
16734: Wenn Drain aktiv ist, hast du die PHC‑State‑Infos die ganze Zeit, nicht nur um den Jump herum.
16741: OK, aber warum können wir uns denn nun nicht den sprung 
16746: Was wir nicht direkt loggen, ist die ptp4l‑Paarung der Nachrichten (t1/t2/t3/t4, SeqID‑Zuordnung, Follow‑Up‑Match). Genau daraus entsteht der Offset.
16748: Darum sieht man den Sprung nicht „auf einen Blick“, obwohl die Kernel‑Events da sind:
16751: Der Ausreißer kann trotzdem entstehen, wenn ptp4l eine falsche Paarung macht (z. B. Sync/Follow_Up oder Delay_Req/Resp zeitlich vertauscht, verlorenes Follow_Up, etc.).
16771: Warum wir den Jump trotzdem nicht sauber auflösen können:
16774: → Sequence‑ID wird abgeschnitten, daher kann man den Ausreißer nicht exakt zu Sync/Delay‑Pairing matchen.
16825: Wichtig: „alle PHC‑Berechnungen“ bekommst du nur für die Events, die tatsächlich geloggt werden.
16829: ptp_evtlog_phc loggt nur wenn /dev/ptpX gelesen wird (ptp4l macht das nicht ständig).
16842: Wenn der Jump zwischen zwei Events passiert, siehst du ihn erst beim nächsten Event (also nicht die exakte Zwischenzeit).
16859: Läuft pro Node als Hintergrundprozess und schreibt nach ptp_phc_poll_<RUN_ID>.log.
16876: Wenn phc_ctl auf einem Node fehlt, schreibt das Log dort nur „phc_ctl not found“ (bricht den Run nicht ab).
16888: Wenn der Sprung zwischen zwei Events liegt, kannst du den exakten Zeitpunkt nicht sehen, sondern nur:
16898: Ja, wir erkennen den Jump sicher, aber nicht den exakten Zeitpunkt, wenn er zwischen Events passiert.
16902: das bringt nicht wirklich etwas... was wir brauchen ist eine möglichkeit zu sehen, wie sich dieser Jump exakt ergiebt
16904: Verstanden – das jetzige Logging reicht nicht, um den Jump exakt herzuleiten.
16905: Wir sehen nur das Ergebnis (hwtstamp_ns), aber nicht die Zwischenrechnung, die den Sprung erzeugt.
16914: Ohne diese Zwischenwerte kannst du den Jump nicht exakt rekonstruieren.
17052: Hinweis: Lokal laufen gerade zwei ptp_longterm_test.sh Prozesse (PID 3113517 und 3113801). Wenn das nicht absichtlich ist, kann das die Runs überlagern.
17139: Wenn du willst, nenne ich dir die genaue Zeile nochmal oder checke ptp_longterm_test.sh, ob sich da seitdem wirklich nichts geändert hat.
17205: Startup‑Order (Mesh noch nicht stabil, Role‑Wechsel, Path‑Delay) → PTP‑Sprünge, die du im frischen „clean run“ nicht siehst.
17240: → die kommen aus duplizierten Seq‑Blöcken (Log-Reihenfolge), nicht aus einem echten PHC‑Rücksprung.
17263: Der Drain schreibt nur bei neuem seq – wenn ptp_tc_trace_enable/ptp_evtlog_enable aus ist oder kaum PTP‑Traffic kommt, wächst der Watch‑Log nicht.
17318: ok, um nochmal auf das diegramm zurück zu kommen, kannst du mir bitte ein einfaches uml diagramm erstellen, wo rx und tx pfade genau aufgeschlüsselt sind. es muss nicht gut aussehen, es muss nur vollständig sein, damit ich es in draw.io neu zeichnen kann. vlt auch schon so, dass ich es in draw.io importieren kann
17965: Wichtig: Dein Script nutzt noch phc_ctl -g, das gibt hier keine Werte. Soll ich ptp_longterm_test.sh auf phc_ctl /dev/ptp3 get umstellen, damit das in zukünftigen Runs automatisch sauber läuft?
18030: PHC‑Polling läuft aktuell nicht (kein /tmp/ptp_phc_poll_* auf den Knoten).
18082: Das heißt: innerhalb des laufenden Skripts wurde nochmals ptp_longterm_test.sh gestartet. Das kommt nicht aus dem Code – vermutlich wurde die Startzeile in der Shell doppelt ausgeführt (Paste/Enter doppelt) oder es läuft ein Wrapper/Function/Alias, der die Zeile re‑ausführt.
18124: Kurz: nein, der Child‑Prozess wird nicht gebraucht – er hat nichts mit der Jump‑Summary zu tun.
18184: Wichtig: durch den Testlauf wurden ptp4l‑Prozesse auf apu00/01 neu gestartet (wie im Script vorgesehen).
18268: Wenn du willst, kann ich den Guard so umbauen, dass er nur blockt, wenn die Variable schon gesetzt ist (nicht wenn du sie explizit übergibst).
18297: Das zweite ist die Schleife, die in ptp_longterm_test.sh als Hintergrundprozess gestartet wird (done & im JUMP_WATCH‑Block).
18302: Kurz: nicht abgestürzt, sondern der Jump‑Watcher läuft als eigener Prozess.
18307: Beide sind weg – ptp_longterm_test.sh läuft nicht mehr.
18354: Ja, das ist absolut plausibel – genau in unseren Hot‑Path‑Änderungen kann ein falsches Casting oder ein 32‑bit‑Zwischentyp einen “Wrap” oder ein Vorzeichen‑Flip erzeugen, der dann wie ein Zeit‑Jump aussieht.
18391: Wichtig: Ich sehe keinen offensichtlichen 32‑bit‑Cast in der Multiplikation selbst – die großen Sprünge kommen eher aus „backwards = wrap“ im Extender bzw. im timecounter.
18393: Wenn du willst, kann ich gezielt einen Glitch‑Guard ergänzen (z. B. if (delta > 0x80000000) { log+drop }), damit Rückwärts‑Jitter nicht als Wrap interpretiert wird.
18424: Problem: cycle kommt aus RX/TX‑ext; wenn ext rückwärts springt, wird timecounter_cyc2time() wie Wrap behandelt.
18431: Problem: delta = (cycle_now - cycle_last) & mask interpretiert Rücksprung als Wrap.
18438: Problem: fns = tx_ext + duration - 16 → wenn tx_ext + duration < 16 → underflow in u64.
18543: Rücksprünge tauchen nur in unknown/tstamp‑Zeilen ohne rx/tx‑Label auf → das sind sehr wahrscheinlich zeilen-gesplittete Fragmente, nicht echte Events.
18556: Nicht‑atomare TSF64‑Reads
18557: Problem: gettsf64() liest hi/lo getrennt → kann um 2^32 springen.
18560: Problem: cycle_in < cycle_last wird als Wrap interpretiert → großer Jump.
18563: Problem: RX‑Samples vor/nach einem Step vermischt → t2‑Sign‑Flips.
18569: Problem: implizite Sign‑Erweiterungen oder Überläufe in ns_offset, tsf_offset, duration.
18629: Problem: delta = (u32)(tstamp - last) → jeder Rücksprung wird als Wrap interpretiert.
18639: Problem: cycle kommt aus RX/TX‑Extender → bei Rücksprung wird Wrap angenommen.
18646: Problem: delta = (cycle_now - cycle_last) & mask → Rücksprung = Wrap.
18648: Wenn delta > mask/2 → Rücksprung → nicht anwenden (oder nur loggen).
18652: Problem: fns = tx_ext + duration - 16 → unterläuft bei kleinen Werten.
18712: 2) Nicht‑atomare TSF64‑Reads
18718: Durch die Glitch‑Guards in RX/TX kann cycle nicht mehr rückwärts springen. Zusätzlich in ptp.c (ath9k_ptp_tc_read) ist jetzt ein Backward‑Guard eingebaut.
18730: TX fns unterläuft nicht mehr (xmit.c).
18736: nein Punkt zwei ist uns egal, da wir eh nur die unteren 32bit verwenden und TSF bisher immer monoton war... Aber bitte schaue nochmal ganz genau nach, ob irgendwo typen sind, die beim casting oder verrechnung probleme machen können
18738: Ich habe die relevanten Pfade noch einmal gezielt auf Typ-/Casting‑Fallen geprüft. In den kritischen Hot‑Path‑Berechnungen (RX/TX‑Extender + timecounter) sehe ich keinen offensichtlichen Cast, der Sprünge erzeugen sollte. Es gibt aber ein paar potenzielle Typfallen, die Logs verfälschen oder in Grenzfällen wrap‑Effekte erzeugen könnten:
18902: ptp_settsf – manuelles TSF‑Set (Test/Experiment, nicht Produktion).
18946: sehr gut, ich werde mir den gleich ansehen... Lass uns mal bitte darüber sprechen, wie wir den core patch aufsetzen. Wir haben ja mit wi-ptp als basis angefangen, das möchte ich nicht. Mein patch soll komplett allein funktionieren... Gehen wir es durch...
18957: Glitch‑Guard/Threshold: Algorithmisch wichtig, aber keine Debugfs‑Knobs im Core (Default z. B. 1000 Ticks = 1 ms). Optional als #define oder Modul‑Param.
18965: Auf welchem Basiskommit/Branch soll der Core‑Patch aufsetzen (aktueller wrap-fix-base, oder ein bestimmter upstream SHA)?
18970: basis daür sollte der basis SHA vom aktuellen branch sein (wrap-fix-base)... allerdings ist es wichtig, dass alles was dort schon von wi-ptp mit drin ist (/home/apu/kernel_chain/kernelbuildci/ath9k.diff) und in unserer Implementation genutzt wird auch in unserem patch landet. Die Runtime knobs müssen mit in den core patch ja
19037: PTP/PHC‑Grundintegration in ath9k (PHC registration + timecounter‑basierte adjfine/adjtime/settime/gettime).
19155: Ok ich erinnere mich gerade nicht an das HW-Timestamping... passiert da etwas anderes, als wir in unserem observer-patch nicht eh schon machen?
19159: Der Observer‑Patch liefert Telemetrie/Debugfs und hilft beim Debuggen, ändert aber nicht, wie Userspace HW‑Timestamps anfordert.
19160: Das HW‑Timestamping‑Patch ist die mac80211‑Plumbing, damit ptp4l/ethtool -T/SIOCSHWTSTAMP überhaupt sauber mit dem Treiber sprechen können (get_ts_info + hwtstamp_set/get + netdev‑Ops). Ohne das bekommst du oft nur Software‑Timestamps oder fehlerhafte SIOCETHTOOL‑Pfadmeldungen – unabhängig von deiner Debugfs‑Telemetrie.
19176: Aber: Wenn du ptp4l mit time_stamping hardware korrekt laufen lassen willst (inkl. ethtool -T/SIOCSHWTSTAMP), brauchst du diese mac80211‑Plumbing. Sonst bekommst du nur SW‑Timestamps oder Fehlermeldungen, unabhängig vom Observer‑Patch.
19201: Fazit: Core‑Patch ist nicht technisch abhängig, aber funktional brauchst du die mac80211‑Hooks, damit HW‑Timestamping korrekt im Userspace ankommt.
19221: Ohne die Plumbing erreichen die ath9k_get_ts_info() / ath9k_hwtstamp_get/set() den Userspace nicht zuverlässig. Damit wäre HW‑Timestamping zwar im Treiber vorhanden, aber nicht aktivierbar für ptp4l/ethtool – das ist funktional „core“.
19259: Abhängig von core, weil es ptp.c, ath9k.h‑Felder und PTP‑Strukturen/Callbacks voraussetzt. Ohne Core patcht/kompiliert das nicht.
19320: mac80211 TSF/Sync‑Logik (nicht im macfilter‑Patch)
19461: aber sagtest du nicht gerade, dass set tsf quasi immer blockiert ist?
19485: Wichtig: Es heißt nicht, dass jede TSF‑Änderung unmöglich war. Es bleiben noch andere Pfade, die nicht über drv_set_tsf() laufen, z. B.:
19495: nein, diese Änderungen möchte ich eigentlich nicht haben... bitte baue sie aus, wir müssen testen, ob das unsere ptp Messung maßgeblich verändert
19527: Patch mit dem falsch geklammerten set_tsf‑Return erstellt: mesh-tsf-sync.patch
19566: Optional: mesh-tsf-sync.patch existiert, soll aktuell nicht angewendet werden (Revert‑Commit ist drin).
19582: Ursache war genau das: tsf_sync_log* wurde in mesh.h/debugfs_netdev.c referenziert, aber die Definitionen waren durch den Revert aus mesh_sync.c verschwunden. Das habe ich jetzt komplett entfernt und die TSF‑Sync‑Knobs ebenfalls ausgebaut.
19682: => Wenn wir den aktuellen Stand abbilden wollen, darf mesh-tsf-sync.patch nicht angewandt werden.
19693: oder mesh-tsf-sync.patch komplett entfernen soll (wenn er nicht mehr genutzt wird).
19765: Das ist jetzt in den Core‑Patch gewandert. Ich habe in mac80211 eine Debugfs‑Knob eingebaut, die set_tsf zur Laufzeit für Mesh/IBSS sperrt. Default bleibt enabled, damit nichts „überraschend“ kaputt geht.
19780: Wichtig: Das blockiert nur mac80211→drv_set_tsf(); firmware/hardware‑seitige TSF‑Resets bleiben davon unberührt.
19819: Im Script bleibt es unverändert, solange TSF_SET_ENABLE nicht gesetzt ist.
19824: Kurz: im BSS/STA‑Mode setzt mac80211 die TSF in der Regel nicht per set_tsf.
19827: Heißt auch: unser set_tsf‑Disable‑Knob greift nicht für BSS/STA, weil dort die TSF‑Korrektur meist hardwareseitig läuft.
19833: Die STA übernimmt die TSF vom assoziierten AP (Beacon‑Sync), nicht den „schnellsten“.
19837: „Höchste/ schnellste TSF“ ist eher IBSS/mesh‑Logik, nicht BSS.
19875: mesh-tsf-sync.patch ✅ (aber bringt Abweichung zu unserem aktuellen Stand)
19889: mesh-tsf-sync.patch weglassen (sofern nicht gewünscht),
19924: ich habe den mesh-tsf.sync.patch in den ordner unused verschoben, da wir den erstmal nicht nutzen... Bitte checke jetzt alle unter patches außer kernel.config gegen mainline v6.6.0
20016: Repo ist jetzt angelegt und initial commit erstellt in ath9k-ptp-patches (Commit ecfbc67). Ich habe den Unterordner mesh-mac-filter/ nicht mit versioniert und in .gitignore eingetragen, weil dort ein eigenes Git‑Repo liegt; sonst wäre es als Submodule‑Link gelandet.
20399: AP‑Mode ist meist unkritisch, weil der TSF dort typischerweise frei läuft.
20404: uns kam gerade folgende Frage in den Kopf: wir hätten ja gerne den TSF free running, damit unsere PTP Erweiterungen kein zu große Rechenlast haben und die Regelzeiten gering gehalten werden. Was ist, wenn wir z.B. im IBSS/Mesh Mode die Synchronisationsenstcheidnugen auf Grundlage der PHC statt TSF direkt treffen?
20406: Kurzantwort: PHC statt TSF für IBSS/Mesh‑Sync ist nicht „einfach austauschbar“ und bringt euch vermutlich nicht die gewünschte Entlastung.
20412: Die Beacon‑Timestamp‑Felder sind TSF, nicht PHC.
20417: Das ist keine unabhängige Uhr. PHC als Basis für TSF‑Entscheidung ist also zirkulär, solange PHC nicht völlig entkoppelt wird.
20434: Optional set_tsf per debugfs abschaltbar (für Tests), aber nicht als Standard, weil:
20444: wie soll PHC von TSF entkoppelt werden? das Problem beginnt ja eben gerade dann, wenn zwischen zwei TSF calls gesprungen wird
20446: Kurz gesagt: PHC kann in ath9k nicht „physisch“ von TSF entkoppelt werden, weil die PHC‑Zeit aus TSF abgeleitet wird (cyclecounter). Man kann sie aber logisch entkoppeln, sodass TSF‑Steps den PHC nicht springen lassen. Genau das machen wir mit dem Offset‑Anchor + Wrap‑Extender + Guards.
20472: „Problem beginnt ja, wenn zwischen zwei TSF calls gesprungen wird“
20482: Pragmatisch entkoppeln heißt: TSF darf springen, PHC nicht.
20499: das Ding ist, wenn settsf aktiv ist, springt der ptp offset schon realtiv stark... meiner meinung nach hat das etwas mit den Berechnungen im rx tx pfad zu tun, die nicht schnell genug passieren. Wenn wir eine Möglichkeit hätten, das zu beschleunigen, würden die TSF Sprünge auch weniger ins Geicht fallen
20501: Ich verstehe den Gedanken – aber vermutlich ist nicht die Rechenzeit im RX/TX‑Pfad die Hauptursache für die sichtbaren Sprünge. Ein paar Punkte dazu:
20508: Selbst wenn der RX/TX‑Pfad 10–20 µs länger braucht, ändert das die Sprunghöhe praktisch nicht.
20509: Der Offset‑Sprung korreliert eher mit Epoch‑Mixing (Samples vor/nach Step) oder falscher Wrap‑Interpretation, nicht mit CPU‑Zeit.
20514: TSF‑Step nicht sauber geankert
20641: also wenn es nicht das logging ist, dann verstehe ich es nicht... Das ist jetzt nämlich aus und es togglt immer noch wild umher (+-10µs)... wenn wir den Sprung zurück direkt erkennen und die differenz berücksichtigen, sollte das doch eigentlich kein Problem sein... es sei denn es ist ein riesen Problem, dass wir den Anstieg seit dem letzten snap nicht mehr erkennen
20643: Verstehe den Frust – aber ±10 µs “Gezappel” ist bei Wi‑Fi leider normal, auch wenn Logging aus ist. Das hat meist nichts mit TSF‑Steps oder dem Logging‑Overhead zu tun, sondern mit der Natur des Funk‑Pfads und dem Servo:
20648: HW‑Timestamping ist nicht frei von Jitter: Der Timestamp sitzt am MAC, aber die Airtime‑Varianz davor ist real.
20657: Aber zwischen zwei Reads können wir die “Form” nicht rekonstruieren → wir können nur beim nächsten Read korrigieren, nicht die Jitter‑Quelle eliminieren.
20691: Gute Idee als Gedankenexperiment, aber ich würde das nicht als Standard‑Rebase‑Mechanismus nehmen. Gründe:
20693: Rebase soll exakt bleiben, nicht geschätzt. Ein Mittelwert der letzten Deltas kann in Funk‑Umgebungen stark schwanken (Backoff/Retry) und würde dir Bias/Drift einführen.
20694: Wraps sind deterministisch (+2^32 ticks). Ein Mittelwert würde dort falsche Zeit addieren.
20703: Nur als Glitch‑Detektor (z. B. „wenn delta << 평균, dann Glitch“), nicht als Rebase‑Korrektur.
20711: aber du stimmst mir zu, dass beim rebasen und wrappen der Asntieg nicht berücksichtigt wird
20716: Wenn der Rebase‑Anchor mit einem frischen TSF‑Read genau im set_tsf‑Pfad berechnet wird (phc_prev = tsf_old + offset), dann ist der Anstieg bis zu diesem Zeitpunkt enthalten. Da geht nichts verloren.
20721: Wenn mehr als ein Wrap zwischen zwei Samples passiert, kann er das nicht wissen → dann fehlt der „zusätzliche“ Anstieg. Das ist der bekannte „mind. 1 Sample pro Wrap‑Periode“-Limit.
20732: Ja – das ist der Punkt der Rebase‑Logik: der PHC‑Wert bleibt kontinuierlich, also „sieht“ man den TSF‑Sprung im PHC nicht mehr.
20745: Ja: Genau in diesem Schritt kann man aus dem PHC nicht mehr erkennen, dass TSF gesprungen ist – der Sprung wird absichtlich “versteckt”.
20748: Du kannst den Sprung trotzdem erkennen, aber nicht aus PHC, sondern aus:
20756: von "kontinuierlich" kann man hier aber nicht sprechen, denn er bleibt GLEICH verglichen mit dem letzten Wert. Das heißt für PTP sieht es so aus, als wenn die Zeit stehen geblieben ist, der Regler greift stärker ein, und wir schwingen über, richtig
20758: Kurz: Nein – der PHC “steht” nicht, er bleibt nur im exakten Rebase‑Moment gleich und läuft danach normal weiter.
20772: TSF nicht weiterläuft (HW‑Problem), oder
20792: PTP bewertet nicht nur einen Sample, sondern eine Folge.
20795: Die eigentliche Gefahr ist nicht das „Gleichbleiben“, sondern Mischen von Epochen (pre/post‑step) oder falscher Wrap‑Interpretation.
20816: Hinweis: 1 Tick = 1 µs (TSF‑Einheit). Kleiner geht hardwareseitig nicht.
20862: ich habe gerade überlegt: 1µs ist ja auch nicht wirklich korrekt, oder. Is das nicht abhängig von der ptp senderate?
20865: Es ist nicht abhängig von der PTP‑Senderate, weil es aus der TSF‑Tick‑Auflösung kommt (1 µs pro Tick bei 1 MHz TSF).
20884: Stale Basis beim Rebase: base_epoch kommt aus RX/TX‑Extendern, die evtl. seit dem letzten Event nicht aktualisiert wurden. Dann ist der „letzte bekannte“ PHC minimal hinterher.
20888: Extender‑Glitch‑Schwelle: Wenn ptp_wrap_glitch_thresh zu klein/zu groß ist, interpretieren wir Rücksprünge falsch (Wrap vs Glitch).
20893: TX‑Guard analog zum RX‑Guard: verhindert, dass TX‑Stamps aus der falschen Epoche in den Servo gelangen.
20955: Funk‑Timing bleibt unbeeinflusst (TSF/Beacon laufen weiter), weil wir nur Timestamp‑Samples droppen – nicht den eigentlichen MAC‑Betrieb.
20974: ibss_tsf_set_enable existiert auf beiden Knoten nicht (oder ist nicht zugreifbar), daher konnte ich das dort nicht setzen.
21087: kann man sagen, dass im Grunde ausschließlich die Funtkionen ath9k_hw_gettsf64(), ath9k_hw_settsf64() und ath9k_hw_reset_tsf()
21102: Wir lassen die originale TSF free running und bauen eine "shadowTSF", dir ausschließlich die TSF als Monotoniemaß nutzt. Anstatt durch die Funktionen (ath9k_hw_gettsf64(), ath9k_hw_settsf64() und ath9k_hw_reset_tsf()) auf die HW-TSF zuzugreifen, nutzen wir hier die shadowTSF... Bitte noch nicht anfangen mit der Umsetzung, es gibt noch einen sehr wichtigen Punkt zu besprechen
21117: Das heißt: shadow darf die HW‑TSF nicht komplett ignorieren – sie muss Steps erkennen und dann konsistent “umlegen”, sonst entstehen große Deltas.
21127: Hauptprobleme bei globaler shadowTSF:
21132: Nachbarn synchronisieren sich auf HW‑TSF, nicht auf shadow.
21137: Wenn du dort shadow zurückgibst, programmierst du falsche Zeiten in HW‑TSF‑Einheiten (Offset‑Fehler).
21140: Wenn HW‑TSF „free‑running“ bleiben soll, darf set_tsf nicht schreiben.
21157: Beacons senden immer noch HW‑TSF → Nachbarn syncen sich nicht auf shadow.
21173: Du hast den Kern richtig erfasst – und genau deshalb ist die „shadowTSF“-Idee mit Timer nicht der Ausweg, den man sich erhofft. Kurz warum:
21228: Der entscheidende Haken bleibt aber: TSF‑Sprünge sind Diskontinuitäten. Eine Gerade kann das nicht von selbst heilen.
21236: Wenn deine Shadow‑Linie die TSF‑Steps ignoriert, sind die RX/TX‑Stamps nicht mehr konsistent.
21267: ich verstehe irgendwie immernoch nicht, warum das settsf durch beacons einen so großen Einfluss auf unser PTP hat. Im Grunde gleichen wir diesen SPrung doch immer gleich aus, oder?...
21272: Rebase sorgt dafür, dass PHC nicht springt, ab dem Moment des set_tsf.
21287: 3) set_tsf ist nicht synchron mit RX/TX Interrupts
21298: Der Rebase verhindert den PHC‑Sprung, aber er verhindert nicht, dass “alte” Samples in die Auswertung rutschen.
21303: wo exakt ein Sample aus der falschen Epoche den großen Offset erzeugt.
21306: was ist denn, wenn wir nicht eine Sprungerkennung implementieren, sondern die Sprungweite direkt bei settsf berechnen und direkt global ablegen. Bei nächsten PTP event rechnen wir das dann direkt drauf
21317: Ziel des Rebase ist: PHC bleibt monotonic, Sprung wird nicht an Userspace weitergegeben.
21320: Wenn du “Sprungweite” speichern willst, dann nur für Diagnose, nicht für Korrektur:
21335: ich meine: durch beacons wird settsf gecalled. in settsf wird ein gettsf gemacht und vor dem Setzen der HW-TSF die Differenz gespeichert. Bei der nächsten Berechnung der PHC wird der Wert mit drauf addiert (kann pos oder neg sein). Aus PHC-Sicht hat der Sprung also nie stattgefunden (genau was wir wollen)...Wo sollte hier das Problem sein?
21337: Du beschreibst im Grunde genau unser Rebase‑Konzept – und für die PHC‑Zeit alleine ist das korrekt:
21338: offset_new = phc_prev - tsf_new ⇒ PHC springt nicht.
21342: PTP benutzt nicht nur PHC‑Reads
21344: Diese Stamps liegen in der alten Epoche – und die kannst du nicht nachträglich durch „addiere Delta beim nächsten PHC‑Read“ korrigieren.
21347: Zwischen „TSF wurde gesetzt“ und „wir haben den Offset global aktualisiert“ können Events passieren, deren Stamps in der falschen Epoche landen.
21350: Korrektur nur beim nächsten PHC‑Read hilft nicht
21368: Nicht ganz. Wir wechseln die Epoche sofort beim Rebase:
21373: Wir warten nicht bis „PTP einen Zyklus abgeschlossen hat“ – wir wechseln sofort und filtern Nachzügler.
21376: und was ist, wenn wir diese nicht droppen, sondern erkenn, in welchem state ptp gerade ist, mit dem guard also einfach nur abwarten, bis PTP alle vier TS parat hat und erst dann die Epoche wechseln?
21382: Der Kernel kennt den PTP‑Zyklus nicht.
21383: Er sieht nur einzelne RX/TX‑Stamps, aber nicht, wann ptp4l „alle vier“ (t1–t4) komplett hat. Dafür müsste der Kernel PTP‑Pakete parsen und Zustände nachbauen – das wäre ein Schichtverstoß und bricht mit anderen PTP‑Stacks/Configs.
21389: Dann wäre die PHC‑Zeit für eine ganze Weile absichtlich „falsch“, was andere Teile (und andere Ports) stören kann.
21423: → PHC wird nicht geschrieben, Systemzeit folgt PHC
21431: Genau – in einer Boundary‑Clock‑Kette brauchst du auf den Zwischenknoten normalerweise kein phc2sys, zumindest nicht auf die TSF‑abgeleitete PHC.
21443: Optional: phc2sys -s /dev/ptpX -c CLOCK_REALTIME nur wenn Linux‑Zeit wichtig ist
21451: ❌ phc2sys nicht als Writer zur PHC
21463: das sind ja ebenfalls alles Synchroverfahren. Im Grunde nutzen wir die ja niemals gleichzeitig
21465: Genau – das sind alles Synchronisations‑Writer, und die sollte man nicht parallel auf dieselbe Ziel‑Clock loslassen.
21470: phc2sys darf nur die Systemzeit vom PHC ziehen (PHC → system), nicht umgekehrt.
21471: chrony/ntpd sollten dann nicht gleichzeitig die Systemzeit schreiben (wenn phc2sys läuft).
21477: Die Idee ist nachvollziehbar, aber so lässt sich ein „PTP‑Zyklus fertig“ im Kernel nicht zuverlässig erkennen:
21483: PHC‑Reads zählen bringt nichts: ptp4l liest die PHC nicht zwingend pro Zyklus (bei HW‑Timestamps oft gar nicht).
21505: „Warten, bis PTP‑Zyklus fertig“ ist im Kernel nicht robust.
21507: Wenn du Droppen grundsätzlich vermeiden willst, wäre die sauberste Option ein Userspace‑Filter, der auf settsf‑Events reagiert.
21514: Du hast recht: bei 1 Hz PTP wäre eine 10 ms‑Sperre pro Sync völlig unkritisch.
21545: Nach jedem PTP‑RX/TX wird set_tsf für N ms gesperrt, damit TSF‑Steps nicht in laufende PTP‑Zyklen fallen.
21593: Für 1 Hz Sync völlig unkritisch, reduziert Rebase‑Kollisionen.
21649: Der Fehler kommt daher, dass ath9k_hw.ko die Funktion ath9k_ptp_guard_allow_settsf() aus ath9k.ko aufruft – das erzeugt eine Modul‑Abhängigkeit in die falsche Richtung. Deshalb meldet modpost das Symbol als „undefined“.
21684: Ja, das ist gut möglich. Die Guard‑Logik sitzt aktuell im ath9k_hw_settsf64() und blockiert dort die TSF‑Writes. Problem: Die Aufrufer (z. B. ath9k_set_tsf / Beacon‑Reassign) aktualisieren trotzdem tsf_val/tsf_ts, obwohl die HW‑TSF nicht gesetzt wurde. Das kann die Beacon‑/TSF‑Logik durcheinander bringen und in der Folge PTP‑Abbrüche auslösen.
21694: Die Guard‑Entscheidung darf nicht in ath9k_hw_settsf64() passieren, sondern vor der Software‑Aktualisierung, also in:
21704: kannst du das nochmal genauer erklären? Also was macht jetzt der PTP-Guard genau? Also der guard wird immer aktualisiert wenn rx tx ptp traffic erkannt wird (aktuelle Zeit + 10ms) richtig?... und solange diese Zeit nicht erreicht wurde, darf settsf nicht gestezt werden...
21724: Die Aufrufer (z. B. ath9k_set_tsf() oder Beacon‑Reassign) aktualisieren ihre Software‑TSF (tsf_val, tsf_ts) trotzdem, obwohl die HW‑TSF wegen Guard nicht geschrieben wurde.
21731: Ich habe den Guard so umgebaut, dass er vor den Software‑TSF‑Updates greift (und nicht mehr in ath9k_hw_settsf64()), damit tsf_val/tsf_ts nur geändert werden, wenn die HW‑TSF auch wirklich gesetzt wird. Damit sollte das „Auseinanderlaufen“ weg sein und die Abbrüche sich deutlich reduzieren.
21778: ptp_rebase_nudge_ns / ptp_rebase_guard_ns gibt es nicht mehr.
21815: Kurz: Möglich – wenn du bei logSyncInterval = 0 (1 s) fährst, ist der eigentliche 2‑Step‑Zyklus zwar im ms‑Bereich, aber nicht garantiert immer <10 ms. Funk‑Jitter, queuing und mesh‑MAC können das leicht strecken. Wenn du viele Drops/Abbrüche siehst, kann ein größeres Guard‑Fenster helfen.
21849: ibss_tsf_set_enable gibt es auf beiden nicht (NA).
21864: das soll es doch aber machen, settsf enable wurde aber nicht dafault gesetzt... Also nochmal: das Skript soll aktiv alle defaultwerte setzen außer die die als argument übergeben wurden
21941: ... meiner Meinung nach kann das eigentlich nicht mit vom settsf kommen (ich habe den guard jetzt auf 50ms gestellt)... Ich denke unsere Rebase Logik funktioniert nicht so, wie wir denken
21943: Ja, das kann trotz Guard passieren. Zwei wichtige Punkte:
21946: Wenn der PTP‑Traffic nicht erkannt wird (z. B. VLAN, anderes Encapsulation‑Format, oder schlicht kein SKBTX_HW_TSTAMP im Pfad), wird der Guard gar nicht gesetzt. Dann kann settsf trotzdem mitten im Zyklus passieren.
21949: Bei settsf legen wir den Offset so, dass der alte PHC‑Wert erhalten bleibt. Dadurch “steht die Zeit” für einen Sample. Das ist monotonic, aber nicht kontinuierlich. Genau das kann den Servo aufschaukeln – besonders wenn settsf häufiger triggert (Beacon‑Sync, Slot‑Reassign).
21972: → Das passiert, wenn ath9k_ptp_is_ptp_skb() keine PTP‑Frames erkennt.
22077: ptp_guard_hits zählt nur blockierte settsf‑Versuche, nicht wie oft der Guard gearmed wurde. Wenn er 0 bleibt, heißt das nur: kein settsf ist während eines aktiven Guard‑Fensters passiert.
22081: settsf wird gar nicht ausgeführt
22086: (Wenn mesh_tsf_set_enable=0 oder rebases=0, gibt es nichts zu blocken.)
22088: Guard wird nie gesetzt (PTP‑Erkennung greift nicht)
22094: settsf passiert, aber zeitlich nicht nah genug an PTP‑Frames
22096: Wenn ptp_guard_hits dann immer noch 0 bleibt, wird der Guard nicht gearmed oder settsf findet gar nicht statt:
22102: ich sehe jetzt, dass das rebasing nicht wirklich oft mittem im ptp zyklus passiert... ich denke das settsf an sich ist das Problem... überprüfe mal bitte, wie genau wir das rebasing umgesetzt haben
22134: Auch wenn settsf nicht mitten im PTP‑Zyklus passiert, reicht ein häufiger settsf (z. B. Beacon‑Sync / Slot‑Reassign), um immer wieder kleine Stalls in der PHC zu erzeugen. Das kann genau die Oszillation erklären, die du siehst.
22137: Die Rebase‑Logik ist monoton, aber nicht kontinuierlich:
22144: damit PHC bei Rebase nicht „steht“.
22234: ... lassen sich diese riesigen Sprünge mit dem stall erklären? ich denke nicht
22236: Kurzantwort: Die Sprünge bis ~10–20 µs lassen sich teilweise mit einem Stall erklären, aber nicht vollständig. Ein Stall (PHC steht kurz) erzeugt typischerweise eine einzelne starke Korrektur, nicht dieses dauernde Hin‑ und Herspringen im Bereich ±2–10 µs über viele Sekunden.
22247: Stall kann mitspielen, aber die Hauptursache scheint der Delay‑Pfad (t1/t2/t3/t4 + Filter) zu sein, nicht nur Rebase.
22265: Das ist eine starke Bestätigung: die Instabilität kommt sehr wahrscheinlich vom settsf‑Pfad (nicht vom normalen RX/TX‑Timestamping). Wenn settsf aus ist und der Offset stabil bei ±1.5 µs bleibt, ist die aktuelle Rebase‑Strategie bei aktiver TSF‑Synchronisation der Haupttreiber der Schwingung.
22271: Wenn du willst, machen wir als nächsten Schritt gezielt eine kleine, kontrollierte Rebase‑Korrektur (z. B. 1–5 µs), die nur bei settsf greift, damit die PHC nicht „steht“. Oder wir belassen settsf komplett aus und dokumentieren es als required setting für stabile PTP‑Runs.
22274: nein, check mal bitte, ob alle Zeitstempel-Pfade der gleichen Logik folgen. Wichtig ist, dass uns settsf nicht differenzen in den Zeitstempeln erzeugt
22301: Wenn Firmware/HW TSF ändert, ohne dass ath9k_hw_settsf64() aufgerufen wird, läuft die Rebase‑Logik nicht → dann entstehen echte Divergenzen.
22304: Ein RX/TX‑Timestamp aus dem alten TSF‑Epoch kann nach der Rebase‑Reset der Extender ankommen. Das kann zu einem falschen Delta führen (wir haben keinen „Rebase‑Guard“ für in‑flight Stamps).
22305: → Das erzeugt Fehler im RX/TX‑Pfad, nicht im PHC selbst.
22309: Die Instabilität mit aktivem settsf kommt eher von der Rebase‑Stall‑Semantik oder in‑flight Stamps, nicht von Pfad‑Inkonsistenz.
22353: ich glaube übergigens ebenfalls, dass es etwas mit dem path dealy zu tun hat. Lass uns mal bitte alle für die path dealy berechnung wichtigen Stellen durchgehen und checken, ob wir hier wirklich alle ventualitäten abgedeckt haben
22410: negative delay → nur debug log, nicht verworfen
22423: Wenn ingressLatency, egressLatency, delayAsymmetry falsch gesetzt sind, verschiebt sich Path‑Delay massiv.
22516: wenn settsf aktiv ist, gibt es regelmäßig diese riesigen path dealy sprünge. kurz vorher wird wird die Ausgabe nicht wie sonst nach einer Sekunde erneuert, sonern erst nach 2-4 sekunden. Das bedeutet, dass der ptp slave deutlich länger benötigt um die neue ausgabe zu generieren... Unsere Änderung hat leider überhaupt nichts gebracht
22521: DelayReq/DelayResp oder Sync/Fup konnte nicht komplett ausgewertet werden,
22529: Zusätzlich können TSF‑Sprünge Zeitstempel so beeinflussen, dass msg_sots_missing() greift (timestamps fehlen oder passen nicht).
22543: B) Wenn die Lücken dann bleiben, liegt es nicht am Drop‑Window, sondern am settsf‑Rebase selbst (die PHC‑Stalls) oder Timing‑Loss in der HW‑Timestamp‑Kette.
22573: Der Drop hier kommt nicht vom Rebase‑Window, sondern vom RX‑Guard (adj_seq / cycle < adj_cycle). Das kann tatsächlich zu Lücken in ptp4l führen, wenn es häufiger passiert.
22587: rx drop steht bei 1 auch nach langer Laufzeit, der rx guard steht auch sehr lange bei eins... also das kann es beides nicht sein
22589: Verstanden – wenn rx_drop bei 1 stehen bleibt und rebase_drop=0, dann sind die Lücken nicht durch den RX‑Guard oder den Rebase‑Drop verursacht. Dann bleibt als Ursache fast sicher: ein kompletter PTP‑Zyklus ist unvollständig (fehlender TX‑ oder RX‑Timestamp), deshalb wartet ptp4l länger, bis wieder ein vollständiger Satz vorliegt.
22607: Wenn settsf aktiv ist, aber die PTP‑Events selbst fehlen, dann ist es kein Rebase‑Problem, sondern ein Timestamp‑/Message‑Loss im Userspace‑Zyklus.
22609: Wenn du willst, baue ich dir ein kleines Log‑Tool, das automatisch die Zeitlücken in ptp4l erkennt und daneben die letzten ptp_evtlog‑Einträge ausgibt, damit wir den genauen Punkt finden.
22622: Damit ist klar: Path‑Delay bricht weg, weil DELAY_REQ‑TX timestamps fehlen, nicht wegen RX‑Guard.
22628: Hier blockt der Guard, aber es gibt keine Rebase‑Drops. Das passt zu deinem Eindruck: die großen Delay‑Sprünge entstehen nicht nur durch Rebase‑Drops.
22633: Nicht RX‑Guard (zu selten).
22634: Nicht Rebase‑Drop (zu selten, nur 2).
22694: OK es sieht also so aus, als wenn der Master das Problem ist... Wir müssen unbedingt herausfinden, warum bei den sync reqs die ts fehlen
22700: ath_tx_complete_buf() erkennt PTP‑Frames vor dem SKBTX‑Check.
22714: ⇒ Für diese PTP‑Frames wird kein HW‑Timestamp angefordert (kein SKBTX_HW_TSTAMP). Ursache liegt oberhalb (ptp4l/Socket/Stack).
22715: tx_tstamp_req steigt, tx_tstamp_done steigt nicht
22716: ⇒ HW‑Timestamp wird angefordert, aber nicht geliefert (Driver/HW‑Pfad).
22718: ⇒ Timestamp wird erzeugt, kommt aber zu spät oder wird im Userspace nicht gematcht.
22722: Wenn du willst, baue ich zusätzlich RX‑seitige PTP‑Zähler ein, um „received DELAY_REQ without timestamp“ eindeutig als RX‑Problem zu klassifizieren.
22736: RX‑Pfad in recv.c: erkennt PTP, zählt Seen/Done/Miss anhand hwtstamp_ns
22747: ⇒ PTP‑Frames werden erkannt, aber keine RX‑HW‑Timestamp geliefert (Drop/Guard/Rebase oder Pfadproblem).
22749: ⇒ RX‑Timestamps kommen an, Fehler liegt eher TX‑seitig oder im Userspace‑Matching.
22756: aber daran sehen wir noch nicht, warum der Timestamp beim sync request fehlt, oder?
22758: Kurz: nein, damit sehen wir nur, dass ein PTP‑Frame ohne HW‑Timestamp durchkam. Wir sehen nicht, welcher PTP‑Message‑Typ betroffen ist (Sync/Delay_Req/Follow_Up/Delay_Resp) und warum genau der Timestamp fehlt.
22761: Die Meldung “received DELAY_REQ without timestamp” kommt vom Master und bedeutet: RX‑Timestamp für den Delay_Req fehlt. Das ist RX‑Seite, nicht TX.
22777: “Sync TX hat SKBTX_HW_TSTAMP nicht gesetzt → Userspace/Socket‑Setup.”
22788: ja... können wir dadurch ein Problem im Hotpath bekommen?
22835: rx: type=1 seen↑ miss↑ ⇒ Delay_Req RX ohne HW‑TS (genau die Fehlermeldung vom Master)
22837: tx: type=0 req↑ done=0 ⇒ Timestamp angefordert, aber nicht geliefert (Driver/HW‑Pfad)
22839: Der Parser läuft nur, wenn ptp_guard_after_event_ms > 0 oder ptp_evtlog_ptp_only=1. Das ist absichtlich, damit der Hotpath nicht belastet wird.
22868: Das erklärt nicht die Meldung „received DELAY_REQ without timestamp“.
22869: 2) TX‑Seite ist das Problem – und zwar je nach Rolle unterschiedlich.
22898: ptp4l erwartet Timestamp für Delay_Req, aber der Kernel liefert ihn nicht an ptp4l, obwohl HW‑Timestamp vorhanden ist (filtering/flags in hwtstamp config).
22918: Die fehlenden Timestamp‑Anforderungen betreffen bestimmte TX‑Typen (Sync/DelayReq/FollowUp/DelayResp) – und das kommt nicht von der HW‑Timestamp‑Konfig, sondern vom Userspace/Socket‑Setup.
22930: Damit stimmt die Rolle zu den TX‑Zählerbildern.
22937: Das heißt: Die fehlenden TX‑Timestamps sind nicht im Treiber/HW, sondern in der Userspace‑/Socket‑Anforderung.
22938: Für gewisse Typen wird SKBTX_HW_TSTAMP nicht gesetzt.
22980: TX bleibt das Problem – und zwar typ-spezifisch:
22993: -H ändert nichts an den fehlenden TX‑Requests für bestimmte Typen.
22997: ptp4l fordert TX‑HW‑Timestamp nur für Event‑Messages (z. B. Sync, Delay_Req), nicht für General‑Messages (Follow_Up, Delay_Resp, Announce).
23001: Der ungerade Teil ist: auf einem Knoten wird Sync nicht konsequent getimestamped (req << seen). Das deutet auf role‑abhängige tx_timestamping policy oder Socket‑Pfad, nicht auf Hardware.
23003: Wir sollten prüfen, ob ptp4l auf dem jeweiligen Knoten one‑step / two‑step korrekt erkennt und ob tx_timestamp_timeout oder use_one_step o. ä. die Sync‑TX‑Requests beeinflussen.
23017: Die „Sync‑req miss“ kommen von Mesh‑Forwarding, nicht von ptp4l.
23029: Das heißt: kein echtes Sync‑Timestamp‑Problem im Treiber – die „miss“ erklären sich durch Mesh‑Forwarding.
23036: das sollte aber nicht unser eigentliches Problem sein, denn wenn wir settsf deaktivieren, haben wir das Porblem mit den großen Offsetsprüngen nicht... wollen wir das einmal testen zum vergleich?
23066: Ohne settsf sind die Offsets im niedrigen µs‑Bereich und es gibt keine großen Sprünge. Der Max‑Wert ~30 µs wirkt eher wie ein kurzer Transient, aber nicht wie die alten 100–300 µs Sprünge.
23093: Verstanden. Der Punkt ist nicht „noch mehr Statistik“, sondern warum die Pfaddelay‑Werte mit settsf schlechter werden.
23098: Aber die größeren Ausreißer korrelieren sehr wahrscheinlich mit settsf, weil t1/t2/t3/t4 dann nicht im gleichen Epoch‑Fenster liegen.
23099: Unsere Zähler zeigen: Sync‑TX (Master) und Delay_Req‑TX (Slave) haben HW‑TS, d. h. der Fehler ist nicht „fehlender TX‑Timestamp“. Es ist eher Epoch‑Mixing / Guard / Rebase.
23101: Wir schalten settsf nur auf einem Knoten ab und vergleichen den Pfaddelay‑Jitter. Damit sehen wir, ob das Problem aus Master oder Slave stammt.
23130: TSF wird lokal gesetzt, nicht vom anderen Knoten direkt.
23153: Wenn du das Log komplett willst (nicht nur settsf), ersetze grep … durch cat.
23194: TSF‑Set passiert auf beiden Seiten, nicht nur auf einem Knoten.
23237: PTP‑Guard läuft, aber er erklärt die großen Sprünge nicht:
23248: Das heißt: Der Guard verhindert das Setzen nicht zuverlässig – er wird zwar “getroffen”, aber settsf passiert trotzdem (evtlog zeigt die settsf‑Events).
23251: Der Guard wirkt nicht als harte Sperre für settsf.
23257: Wenn Guard aktiv → settsf wird nicht ausgeführt (im eigentlichen call site)
23269: settsf‑Disable‑Knob (mesh_tsf_set_enable) sitzt oberhalb im mac80211‑Mesh‑Code. Wenn der auf 0 steht, wird set_tsf gar nicht mehr aufgerufen.
23271: → Wenn der Knob aus ist, sieht der Guard nichts.
23290: Kurz: Ja, das kann passieren – aber nicht über genau den Codepfad von ath9k_set_tsf(), wenn der Guard dort false zurückgibt. In diesem Pfad wird dann kein HW‑Write ausgeführt und auch tsf_val nicht aktualisiert.
23301: Der Guard blockt nur im Zeitfenster nach PTP‑Traffic. Wenn settsf außerhalb dieses Fensters passiert, wird es nicht blockiert.
23310: Wenn settsf‑Events laufen, aber ptp_guard_block_cnt nicht steigt, dann passieren sie außerhalb der Guard‑Window – also Guard greift “zu spät” (falsche Stelle oder falsches Zeitfenster).
23317: Die neuen ptp_guard_block_cnt zählen automatisch – du musst im Script nichts aktivieren.
23359: Wenn du willst, können wir jetzt messen, wie viele settsf‑Events pro Minute auftreten und wie viele davon blockiert werden – dann sehen wir, ob wir die Guard‑Window verlängern müssen oder ob der Triggerpunkt falsch gewählt ist.
23362: wichtig wäre zu wissen, ob die settsf im richtigen zeitpunkt blockiert werden. Also das ptp normal laufen kann
23386: Wenn ptp_settsf_last_delta_ns unterhalb des Guard‑Fensters liegt, dann ist der Guard an der falschen Stelle oder zu spät getriggert.
23446: Die meisten settsf‑Events passieren außerhalb des Fensters, deshalb werden sie nicht blockiert – das erklärt, warum der Guard allein die großen Sprünge nicht verhindert.
23458: Verstanden – für BC‑Ketten können wir settsf nicht dauerhaft abschalten. Dann brauchen wir eine PTP‑kompatible TSF‑Sync statt “hart aus”.
23463: Wenn settsf während der Guard‑Window kommt, nicht verwerfen, sondern defer und direkt nach Guard-Ende einmal anwenden.
23472: Wenn settsf während Guard: speichern, nicht anwenden.
23498: Der Guard kann sie deshalb nicht blockieren, auch wenn er korrekt funktioniert.
23522: Nein ist Ok, somit zeigen wir ja, dass das Setzen des TSF innerhalb eines PTP Zyklus nie das Problem war... Was wir aber jetzt wissen ist, dass es durchaus Problematisch ist, wenn der Master überhaupt rebased, richtig?
23526: Settsf passiert fast immer außerhalb des PTP‑Fensters → der Guard blockt korrekt, aber das Timing innerhalb des Zyklus ist nicht das Problem.
23528: Wenn der Master nicht rebased, bleiben die Offsets stabil (Case A).
23530: Das Problem ist nicht “settsf im falschen Moment”, sondern die Tatsache, dass der Master überhaupt rebased.
23534: Wir brauchen eine Master‑seitige TSF‑Rebase‑Strategie, die PTP‑Zeit nicht destabilisiert, statt nur “besseres Timing”.
23559: ptp_tsf_offset wird angepasst, sodass PHC nicht springt
23560: ➡️ Ergebnis: PHC bleibt monotonic, aber steht für genau diesen Moment still, weil wir die fehlende “Zeit seit dem letzten Sample” nicht addieren.
23588: Rebase sorgt zwar für Monotonie, aber zerstört die Kontinuität, weil der PHC nicht um die seit dem letzten TSF‑Sample vergangene Zeit fortgeschrieben wird → PTP sieht einen künstlichen “Stall” → Offset‑Sprünge.
23601: Dadurch läuft die PHC weiter und steht beim Rebase nicht mehr still.
23617: Wenn du willst, kann ich dir noch einen kleinen Debugfs‑Knob hinzufügen, um die geschätzte Rebase‑Δ direkt zu sehen (z. B. ptp_rebase_delta_ns), aber für den ersten Test ist das nicht nötig.
23625: Aber: Wir müssen aufpassen, dass wir nicht zu träge werden, sonst driftet die PHC beim Rebase zu weit vom echten TSF weg.
23693: Ich habe den letzten Run in /tmp/ptp_longterm_20260224_100728/jump_1 angeschaut. Das Ergebnis sieht nicht nach einem Rebase‑Bug aus, sondern nach einem Userspace‑Step:
23699: Slave hat keine settsf‑Events: ptp_settsf.log ist leer → der Sprung kann nicht von settsf/rebase kommen.
23702: Kurz: Das “nicht funktioniert” in diesem Run ist ein initialer ptp4l‑Step (Userspace adjtime), nicht unsere Rebase‑Logik.
23710: aber das Problem kommt doch gerade erst mit unserer aktuellen Änderung... Ich denke es eher eine Kombination aus step und rebase
23717: Das heißt: der “Sprung” in diesem Run ist Userspace‑Step, nicht Rebase.
23719: Trotzdem hast du recht: Step + Rebase könnte bei uns problematisch sein, wenn wir den Rebase‑Averager/linearen Fortschreiber über einen adjtime hinweg laufen lassen. Das würde den Step quasi doppelt “verschmieren”.
23730: Wenn du willst, setze ich das direkt um (plus Counter rebase_skip_adjseq in debugfs), dann ist die Hypothese testbar.
23735: der offset ist nicht normal, schau dir das doch mal bitte an
23737: Ich habe mir den aktuellsten Run angeschaut (/tmp/ptp_longterm_20260224_100728/jump_1). Der „nicht normale“ Offset ist dort der initiale Step – nicht Rebase:
23758: Ich hab mir die Zeilen nach -504 direkt auf dem Knoten aus ptp4l_mesh0.log gezogen (die waren im Run‑Ordner nicht drin). Hier der direkte Ausschnitt nach der -504‑Zeile:
23776: Wenn du willst, ziehe ich dir den kompletten ptp4l_mesh0.log in den Run‑Ordner, damit wir das sauber offline analysieren können – aktuell wurde er nicht mitkopiert. Soll ich das sofort machen und das Skript so anpassen, dass der Full‑Log immer dabei ist?
23841: Hat 0 rebase‑Events in ptp_evtlog.log → dort kann rebase gar nicht rückwärts springen.
23849: ich glaube ich hab eine Idee, was das Problem ist: der erste große Zeitsprung wird bei der EMA Glättung mit einbezogen, richtig?
23869: Und wir sehen das in den Logs: ptp_rebase_avg_ns liegt auf apu01 bei ~2.35 s und auf apu00 sogar ~12.5 s – das ist genau dieses Problem.
23986: Fix ist drin. Ursache war, dass ath9k_ptp_rebase_reset() nach der ersten Verwendung stand. Ich habe die Helper‑Funktion jetzt vor ath9k_phc_adjfine() platziert.
23996: Ich hab mir den Slave‑Log direkt auf apu00 angeschaut (ptp4l_mesh0.log). Das sieht klar nach TX‑Timestamp‑Ausfall aus – nicht nach Rebase:
24016: Das heißt: die meisten Sync‑TX‑Timestamps kommen gar nicht zurück, ptp4l geht in FAULTY und die Offsets laufen weg (freq = -1000000). Das erklärt die „riesigen Offsets“ nach der -504‑Zeile.
24059: Kurz: Nein, die EMA greift nicht direkt in den TX‑Pfad ein.
24066: Miss‑Zähler: ath_tx_complete_buf zählt miss, wenn SKBTX_HW_TSTAMP nicht gesetzt ist – unabhängig von EMA.
24071: Das deutet sehr stark auf fehlende HW‑TX‑Timestamps hin, nicht auf EMA.
24097: ok es läuft wieder normal... lass uns nochmal über das stall Problem nachdenken
24099: Alles klar. Lass uns das Stall‑Problem sauber einordnen:
24119: Kurz nach Rebase RX/TX‑Samples verwerfen, damit PTP nicht auf „stehende“ Zeit reagiert.
24121: Rebase ersetzt nicht nur Offset, sondern addiert einen plausiblen Zeitfortschritt (z. B. Zeit seit letztem Event).
24218: RX sieht sauber aus (keine Misses), aber TX timestamping verliert massiv (tx_tstamp_miss hoch). Das passt zu den großen Offsets/Instabilität. Die Stall‑Zähler schlagen nur auf RX an, TX nicht.
24224: um zu sehen, ob die TX‑Misses direkt mit PTP‑Fehlern korrelieren.
24226: aber tx tstamp miss haben wir doch schon darauf zurückgeführt, dass nicht alle packet typen hw ts fordern, oder?
24228: Teilweise ja – aber tx_tstamp_miss zählt nur Fälle, in denen wir einen HW‑Timestamp angefordert haben, aber keiner zurückkam. Pakete, die keinen HW‑Timestamp anfordern (General‑Messages wie Follow_Up/Delay_Resp/Announce), tauchen dort nicht auf.
24235: Wenn tx_tstamp_miss hoch ist, ist das nicht durch “nicht alle Typen brauchen HW‑TS” erklärbar, sondern bedeutet Requests werden gestellt, aber keine TS geliefert. Das ist genau der kritische Pfad.
24250: In unserem Code bedeutet tx_tstamp_miss nicht „HW‑Timestamp angefordert, aber nicht geliefert“, sondern schlicht:
24274: und wir schauen, ob es Rollenwechsel gibt oder ob SO_TIMESTAMPING nicht sauber gesetzt wird.
24278: apu00 ist slave aktuell... Ich glaube das ist nicht das Problem mit unseren großen Offsets, ptp scheint ja sauber durchzulaufen. Ich denke weiterhin, das rebasing ist das Problem... Erkläre nochmal kurz, was wir beim rebasen als Problem annehmen, damit ich weiß, dass wir über das Selbe sprechen
24280: Kurzfassung des Rebase‑Problems, so wie wir es meinen:
24291: Das ist nicht ein echter Rücksprung, sondern eine Stagnation (plateau) im PHC‑Verlauf durch die Rebase‑Korrektur.
24305: Das bedeutet: der reale Zeitfortschritt zwischen letztem Sample und aktuellem Rebase‑Sample wird nicht in die PHC übernommen.
24314: Nicht, weil das Rebase „lange dauert“, sondern weil wir den Fortschritt absichtlich wegrechnen.
24318: Wenn wir den Fortschritt schätzen und aufaddieren, ist das Problem weg – dann ist Rebase nur eine Korrektur des Sprungs, ohne das Plateau.
24341: Wenn du willst, skizziere ich das gern als konkreten Patch‑Flow, damit wir es sauber in den Lock‑Pfad integrieren (damit RX/TX/PHC‑Reads nicht dazwischenfunken).
24344: aber das wrap handling funktioniert ja schon ohne probleme, und frimware set tsf passiert in ibss und mbss nicht (nur in bss und da springt tsf quasi nie)... also eigentlich ist das doch erstmal ne solide lösung, oder?
24351: Jumps ohne settsf (Glitch/Read‑Race/Wrap) werden damit nicht adressiert.
24387: Alles läuft monoton, solange TSF nicht springt.
24399: Die Rebase‑Logik passt den Offset so an, dass die PHC nicht springt.
24413: aber dann berücksichtigen wir doch wieder nicht die zeit seit dem letzt ptp event
24415: Stimmt — in der jetzigen Rebase‑Logik geht die Zeit seit dem letzten PTP‑Event verloren, weil wir die PHC beim Rebase auf dem alten Wert festhalten.
24420: Damit kennen wir den Fortschritt seit dem letzten Read (egal ob es ein PTP‑Event war oder nicht).
24424: Wenn der Sprung nicht über settsf kommt (Glitch/Wrap), dann fehlt uns genau dieser „vorher“‑Wert — dort brauchen wir weiterhin Schätzung (EMA/ktime) oder eine explizite zusätzliche TSF‑Read‑Quelle.
24432: Die „exakte Rebase‑Korrektur“ (Fortschritt vor SetTSF messen und beim Rebase addieren) habe ich noch nicht eingebaut.
24476: Rebase: Offset wird so angepasst, dass PHC nicht springt
24477: Problem: PHC bleibt gleich → Plateau‑Sample
24498: Ergebnis: PHC springt nicht, und macht auch keinen Stillstand.
24519: ⚠️ 4. Wenn Sprung nicht durch settsf
24521: dann gibt es kein tsf_old, und wir können Δc nicht exakt berechnen.
24545: Er enthält nicht den Zeitfortschritt seit dem letzten Event – der steckt im TSF selbst (tsf_old).
24576: Wenn du also wirklich ein „Stall“ siehst, dann kommt er nicht daher,
24612: Hier ist die Analyse des aktuellen Runs mit Fokus auf Zeitstempel/Rebase – und warum wir damit die großen Master‑Offsets gerade nicht erklären können:
24652: Und ja, bei uns wird die PHC direkt beim Rebase angepasst – aber nicht als eigener “Schritt”, sondern indem wir ptp_tsf_offset sofort neu setzen. Die PHC wird nur beim nächsten Read als tsf + offset geliefert.
24678: Selbst wenn settsf nicht mitten im Sync‑Packet passiert, kann es zwischen Sync/FU und DelayReq/Resp liegen.
24729: ptp_rebase_drop_until_ns → in‑flight RX/TX werden verworfen, nicht korrigiert.
24734: t1/t2/t3/t4 fallen in verschiedene Epochen, obwohl der Rebase nicht mitten im Sync‑Frame passiert.
24796: Wichtige Konsequenz für Path‑Delay
24798: Damit können t1/t2/t3/t4 in verschiedenen Epochen landen, obwohl der Rebase nicht mitten im PTP‑Frame passiert. Das reicht aus, um große Path‑Delay‑Spikes zu erzeugen.
24800: Wenn du willst, kann ich dir als nächsten Schritt konkret zeigen, wie man in den evtlogs erkennt, dass ein Rebase‑Wechsel zwischen t2 und t3 stattfindet (und wie man das sauber korreliert).
24941: Wenn settsf nicht innerhalb des Guard‑Fensters liegt, wird ganz normal gesetzt → Rebase passiert → Offset springt.
24945: Rebase findet aber häufig außerhalb dieses Fensters statt → Guard greift nicht.
24946: PTP‑Events liegen 1 s auseinander, Rebase passiert aber asynchron → kann problemlos in der Lücke liegen.
24947: Der Guard blockiert nur settsf, nicht die Rebase‑Folgeeffekte selbst.
24950: Die Rebase‑Wechsel, die wir sehen, passieren trotz Guard, weil sie nicht im Guard‑Fenster liegen.
24955: und zeigen, ob die Rebase‑Wechsel tatsächlich außerhalb des Guard‑Fensters liegen (Beweis statt Vermutung).
24980: nicht der Guard, sondern der sofortige Epoch‑Switch von RX/TX‑Extendern ist der Trigger.
24985: exakte Zeitlinie (tsf64 → Sekunden) pro seq, damit wir die Problem‑Zyklen 1:1 im ptp4l‑Log sehen.
25020: Warum das deinen Guard nicht “rettet”
25080: das passt aber nicht zusammen... wie kann denn ein kompletter PTP-Durchlauf länger dauern als der ganze zyklus?
25087: Das ist nicht der eigentliche Sync‑Zyklus, sondern nur der Abstand zwischen zwei unterschiedlichen Nachrichten‑Typen.
25172: Für den Master fehlen die passenden seq‑Paare (Sync → Delay_Resp ist auf dem Master so im evtlog nicht direkt sichtbar).
25176: Das deutet darauf hin, dass seq‑IDs von Sync und Delay_Resp auf dem Slave nicht 1:1 im gleichen Intervall gepaart sind – also Delay_Resp kommt viel später (wahrscheinlich weil der Log‑Ausschnitt nicht alle Pairs enthält oder die seq‑Nummern nicht direkt konsistent sind).
25196: Damit können wir den vollen t1→t4‑Zyklus aus dem evtlog nicht zuverlässig rekonstruieren.
25199: Der evtlog‑Ausschnitt ist zeitlich eng (nur ~200s) und die Delay_Resp‑Sequenzen scheinen nicht konsistent im gleichen Fenster aufzutauchen. D. h. wir sehen zwar Sync und Delay_Resp, aber nicht als korrektes Paar im gleichen Zeitraum.
25218: ich kann mir ehrlich gesagt überhaupt nicht vorstellen, dass die zeitstempel so weit auseinander liegen. In allen Beschreibungen zum thema ptp inklusive dem Standard, folgen die Teile der Sequenz eventbasiert direkt aufeinander
25221: Meine vorige “Full‑Cycle‑Berechnung” war konzeptionell falsch, weil ich Sync‑Seq und Delay_Resp‑Seq gekoppelt habe – das ist im Standard nicht gekoppelt.
25281: und wie weit liegen die mini-sequenzen auseinander? ich meine: wenn wir jetzt die resync periode von ptp verrringern, kann doch nicht weiterhin so viel Zeit zwischen den Sequenzen liegen
25410: Die Option heißt in eurer ptp4l 4.0‑Version logMinDelayReqInterval, nicht logDelayReqInterval.
25428: ibss_tsf_set_enable gibt es dort nicht (nur Mesh).
25449: Auf apu01 ist es knapp nach dem Guard (0.514 s), daher wird es nicht blockiert.
25462: Das heißt: der laufende Kernel auf den Knoten enthält noch nicht die ptp_settsf_cnt‑Debugfs‑Variable. Vermutlich ist das ein älteres Build ohne die Counter‑Erweiterung.
25510: → settsf passiert außerhalb des 50‑ms‑Guards, also wird nicht blockiert.
25520: Der Guard blockiert kurz (hits steigen), aber settsf passiert später (172–424 ms nach PTP‑Event). Damit ist es nicht wirklich blockiert – und die großen Offsets können wieder auftreten.
25528: also: du hast wahrscheinlich recht und das rebase zwischen t1/t2 und t3/4 ist der problematische Part... wir müssen unbedingt schaffen, dass ein rebase für ptp transparent ist... ich glaube die diskrepanz kommt vom unterscheidlichen hanfling von phc rx und tx ts... wie bekommen wir das so vereinheitlicht, dass die alle matchen trotz epochwechsel?
25530: Du hast recht – der Guard hilft hier nicht, weil das Problem nicht “settsf mitten im Mini‑Event” ist, sondern der Epoch‑Wechsel zwischen den beiden Mini‑Sequenzen (Sync/FU vs DelayReq/Resp).
25595: 👉 Das ist konzeptionell wie bei PHC, nur dass wir hier nicht den globalen Offset ändern, sondern lokal pro Timestamp korrigieren, damit die PTP‑Stränge konsistent bleiben.
25614: Damit passen die RX/TX‑Timestamps weiter zur PHC‑Epoch, aber nicht mehr zur rohen TSF – und das ist genau gewollt.
25738: Wichtig: ptp4l läuft ohne Config‑File (ptp4l -i mesh0 -p /dev/ptp3 -m).
25739: Die ptp4l.conf existiert zwar (mit logSyncInterval -1, logMinDelayReqInterval -1), wird aber gerade nicht genutzt.
25765: Das passt leider zu dem, was ich befürchtet habe: wir pinnen nur die PTP‑Timestamps, die PHC selbst läuft aber in der aktuellen Epoche weiter. Damit sind t2/t4 effektiv in einer anderen Zeitbasis als der PHC, den ptp4l als lokalen Clock regelt → das kann die Offsets massiv verschlechtern.
25770: Problem: Timestamps werden in alte Epoche zurückgeschoben, PHC nicht.
25784: ja, die pin logik muss wieder raus, das funktioniert nicht... und baue bitte den debugfs nachweis ein... was spricht eigentlich dagegen, wenn wir rx und tx einfach die phc nehmen?
25815: Zu deiner Frage: „Warum nicht RX/TX einfach die PHC nehmen?“
25817: Kurzfassung: Weil PHC‑Reads nicht den Event‑Zeitpunkt abbilden.
25819: RX: PHC wird im Softwarepfad gelesen → enthält Scheduler‑Jitter/IRQ‑Latenz, nicht die tatsächliche Empfangszeit.
25820: TX: du brauchst den tatsächlichen Sendezeitpunkt, nicht den Zeitpunkt, zu dem der Treiber den Frame abarbeitet.
25821: Dadurch würdest du Hardware‑Timestamping funktional verlieren und PTP bekommt systematisch falsche Timestamps.
25828: Kurz: ja, RX/TX nutzen die realen HW‑TSF‑Event‑Timestamps, nicht die PHC‑Zeit.
25835: Die PHC wird nicht direkt als Zeitquelle für RX/TX benutzt, weil sie den Eventzeitpunkt nicht abbildet (Latenz/Jitter im Treiberpfad).
25845: Den Offset “nochmal” draufrechnen wäre falsch → doppelte Verschiebung.
25846: Falls du meinst: „den Offset, der genau zum Eventzeitpunkt gültig war“ (nicht den evtl. nach Rebase geänderten), dann müssten wir den Offset beim Event latching und explizit in die Umrechnung einspeisen.
25864: Ich hab die aktuellen Werte von beiden Knoten geholt. Kurzfazit: RX/TX verwenden gerade denselben ptp_tsf_offset wie die PHC (Offset passt), aber wir sehen weiterhin Rebase‑Zähler laufen. Hier die wichtigsten Punkte:
25925: Das heißt: bei ~34–45 % der PTP‑Zyklen liegt Sync und Delay_Req in unterschiedlichen Rebase‑Epochen. Das ist genau die Ursache für inkonsistente Timestamps innerhalb einer Sequenz.
25945: Ja, das sollte verborgen sein – aber aktuell ist es das nur für die PHC, nicht für die PTP‑Sequenz.
25951: PTP‑Events sind es nicht, weil sie mit dem jeweils aktuellen Offset konvertiert werden – und der kann zwischen den Teil‑Sequenzen wechseln.
25958: Nachteil: blockiert TSF‑Settlings über lange Zeit (Mesh/IBSS evtl. kritisch).
25966: Was wir getestet haben (nur RX/TX pinnen) war falsch, weil PHC weiterlief.
25967: Wenn man das macht, müsste man PHC‑Reads für PTP‑Nutzer im selben Epoch halten, sonst stimmt die Servo‑Referenz nicht.
25970: Wir handlen den Epochenwechsel für die PHC, aber nicht konsistent für alle PTP‑Events einer Sequenz.
25979: Die Idee ist: der „richtige“ Offset ist der, der zum Zeitpunkt des Events galt – nicht der, der gerade beim Verarbeiten gilt.
26012: Mit rebase_cnt arbeiten ist nicht zuverlässig, weil ein Rebase zwischen Event und Verarbeitung passieren kann → der Zähler ist dann schon „zu neu“.
26062: Der Sprung nach dem 2. Wrap ist konsistent mit einem falschen Offset‑Lookup durch zu kurze Rebase‑Historie.
26083: Wenn zwischen t1/t2 und t3/t4 >16 Rebases liegen, findet die Lookup‑Logik nicht mehr den richtigen Offset und nimmt den “ältesten verfügbaren”.
26084: Das führt zu einem Fehler in der Größenordnung mehrerer Wraps – genau der beobachtete ~2×2^32×1000 ns‑Sprung.
26086: Der große Sprung kommt nicht von ptp_tsf_offset selbst (der bleibt klein), sondern von zu kurzer Rebase‑Historie → falscher Offset für die älteren PTP‑Events.
26097: Ich sehe es auch direkt an den Logs: In ptp_rx_ts.log fehlt das neue Feld rx_offset_delta_ns/cur_offset, d. h. das ist noch der alte Stand. Mein Schluss von eben war daher nicht gültig. Sorry für die Verwirrung.
26127: Ich habe den aktuellen Run /tmp/ptp_longterm_20260224_201351/jump_1 geprüft – und hier ist die wichtige Klarstellung:
26135: 2) Der große Offset kommt nicht vom Wrap
26158: Das ist aber ein sehr kleines Fenster – und ohne Wraps ist das noch nicht aussagekräftig.
26161: Der große Sprung in diesem aktuellen Run ist ein PTP‑Step, kein Wrap‑/Rebase‑Fehler.
26171: Kurzfassung: im aktuellen Run ist kein Wrap passiert, daher können wir den „2×32‑bit‑Jump nach dem 2. Wrap“ hier noch nicht bewerten.
26183: Aber im Snapshot steht rx_offset_delta_ns=0 → die Korrektur wurde beim letzten Event nicht angewandt.
26187: Wenn die Korrektur greifen würde, müssten wir gelegentlich nicht‑null *_offset_delta_ns sehen.
26313: Stimme dir zu – 13 s kann nicht die reale t2→t3‑Zeit sein.
26314: Die Zahl entsteht durch falsches Pairing bzw. fehlende Events im ptp_evtlog:
26338: Kurz: nur mit UDP‑Paketen kannst du nicht garantiert exakt „den“ Zyklus zuordnen, weil PTP zwei getrennte Sequenzen hat:
26342: Die IDs sind nicht gleich ⇒ du kannst t2 (RX Sync) und t3 (TX Delay_Req) nicht 1:1 per Seq‑ID matchen.
26362: Damit bekommst du exakt das, was PTP wirklich in der Luft macht – ohne fehlerhafte Pairings.
26479: Die 13 s kamen von falschen Pairings ohne Fenster (alte Syncs werden mit späteren Delay_Req gepaart). Mit 1‑s‑Fenster verschwindet das.
26506: das kann nciht sein... dann würde PTP nicht so lange laufen... Zähle mal bitte alle PTP pakete und stelle den menge nach typ dar
26601: wrap-fix-ase existiert nicht.
26634: wir müssen weiter überlegen, wie wir verhindern, das aus ptp sicht die Zeit zwischen t2 und t3 die Zeit springt... bitte schriebe einmal alle unsere Erkenntisse dazu hier auf
26636: Hier ist eine kompakte Zusammenfassung aller bisherigen Erkenntnisse zu den „Sprüngen“ zwischen t2 (RX Sync auf Slave) und t3 (TX Delay_Req auf Slave) – speziell aus PTP‑Sicht:
26641: Mit settsf aktiv steigen die Offsets auf ±20–30 µs (deutlich schlechter).
26642: Große Sprünge korrelieren mit Rebase/TSF‑Setzen (auch wenn nicht mitten im PTP‑Zyklus).
26643: ptp_guard_hits war lange 0 → Guard hat anfangs kaum gegriffen bzw. wurde nicht getroffen.
26644: In Logs tauchten riesige t2→t3‑Deltas (sekunden) auf, die nicht real sind, sondern aus falschem Pairing resultieren.
26657: Rebase ändert die Epoche, und RX/TX‑Timestamps wechseln die Epoche nicht konsistent.
26667: Daher muss die Lösung im Kernel‑Timestamping liegen, nicht in ptp4l‑Parametern.
26678: aber wir ergänzen doch die Zeitstempel (rx und tx) mit dem ebenfalls bei der berechnung angewandten offset, woher soll denn da bitte aus ptp sicht der epochwechsel kommen? lass uns unseren code nochmal konkret nach fehler durchsuchen
26682: Hier ist eine konkrete Code‑Durchsicht (aktueller Stand a1b918f0…) mit den wichtigsten Auffälligkeiten, warum aus PTP‑Sicht trotzdem ein Epoch‑Wechsel zwischen t2/t3 sichtbar werden kann – obwohl ihr glaubt, den Offset anzuwenden.
26698: Befund 2 (mittel): TX‑Extender kann Epoche „falsch“ wählen, wenn TSF zwischen TX‑Timestamp und Completion umspringt
26703: Falls settsf/rebase zwischen Sende‑Zeitpunkt (ts->ts_tstamp) und Completion passiert, wird die 32‑bit TSF in falsche Epoche erweitert → t3‑Fehler.
26709: Wenn TSF in diesem Zeitraum gesetzt wird, können spätere RX‑Frames einen falschen Extender‑Bezug bekommen.
26710: Das tritt seltener auf, kann aber im worst case ebenfalls Epoche‑Fehler erzeugen.
26712: Nein, wir addieren den Offset aktuell nicht zu RX/TX‑Zeitstempeln.
26729: Kurz: wir verändern den RX/TX‑Zeitstempel aktuell nicht durch einen Offset, sondern nur die Erzeugung und ggf. das Droppen.
26746: Wir loggen ptp_tsf_offset für RX/TX (ptp_last_rx_tsf_offset, ptp_last_tx_tsf_offset), aber wir addieren ihn nicht in den RX/TX‑Zeitstempel ein.
26747: Damit bleibt RX/TX in der raw‑TSF‑Epoche – der Offset wirkt nur auf PHC (cyclecounter‑read), nicht auf RX/TX.
26754: Hier sind die relevanten Stellen mit Markierung, wo RX/TX‑Zeitstempel erzeugt und nicht mit Offset angepasst werden.
26770: → Offset wird nur gespeichert, nicht angewandt.
26789: Zeitstempel‑Umrechnung (verwendet PHC‑Cyclecounter, nicht RX/TX‑Offset)
26811: Wenn du willst, markiere ich dir zusätzlich die Extender‑Logik (RX/TX wrap + glitch guard), aber Offset‑Apply gibt es dort ebenfalls nicht.
26847: OK und genau hier muss doch unser offset mit eingerechnet werden, den wir auch für phc nutzen. Ansonsten fließt doch rebase gar nicht mit in die Zeitstempel ein, oder sehe ich das falsch?
26849: Du siehst das nicht falsch – genau dort (RX/TX‑Zeitstempel) fehlt aktuell der Offset.
26867: (dazu brauchen wir aber Offset in ns, nicht in TSF‑Ticks).
26868: Aktuell haben wir ptp_tsf_offset in TSF‑Ticks, nicht ns →
26926: Drop‑Logik (adj_seq / rebase) nutzt jetzt cycle_adj, nicht cycle.
26955: Nicht „vor dem letzten Timestamp“ – das prüfen wir separat über timecounter_cyc2time() und cycle_last.
26986: Wenn du willst, kann ich zusätzlich in recv.c/xmit.c den verwendeten Offset im Debug‑Log mitführen, aber für die eigentliche Epoch‑Korrektur ist es nicht nötig.
27009: Genau – wenn der Offset bislang nicht in RX/TX eingerechnet wurde, dann haben die beacon‑basierten settsf‑Steps zwar die PHC‑Epoche verschoben, aber die Packet‑Timestamps blieben in der alten Epoche.
27010: Dass die Sprünge “nur” im Bereich einiger 10 µs lagen, heißt im Umkehrschluss: die Rebase‑Steps waren tatsächlich klein – sonst wären die Path‑Delay‑Sprünge viel extremer ausgefallen.
27015: OK, also die einzigen pakete auf dem Kanal, die jetzt noch raw tsf nutzen sind im Grunde die beacon frames, richtig?
27053: Nicht „halb fertige“ Timestamps in den PHC/Packet‑Pfad lassen, wenn die Epoche gerade wechselt.
27075: Wir droppen Timestamps kurz nach einem TSF‑Rebase, damit PTP nicht eine Epoche mit der nächsten mischt.
27083: Dann ist ptp_rebase_drop_until_ns immer 0 und es wird nichts mehr gedroppt.
27168: ja berechne das mal bitte (1.)... ich habe das Gefühl, dass wir in rx und tx in die falsche richtung springen
27194: RX und TX liegen nicht nur im Mittel negativ, sondern fast ausschließlich negativ gegenüber phc_tsf.
27195: Das sieht nach einem systematischen Offset‑Bias aus (≈ ‑200k…‑270k TSF‑Ticks), nicht nach zufälligem Jitter.
27197: Das bedeutet nicht, dass RX/TX “vorwärts oder rückwärts springen”, sondern dass sample_cycle konstant hinter phc_tsf liegt. Das kann z. B. durch:
27200: Offset‑Update Timing (Rebase setzt Offset, aber Timecounter nicht resynchronisiert)
27229: Der große Abstand kommt nicht von einem durchgehenden Drift, sondern von einzelnen RX‑Events, bei denen sample_cycle deutlich vor oder nach dem phc_tsf liegt. Das ist typisch, wenn:
27231: tsf64 in evtlog nicht denselben Zeitpunkt wie rx_ext referenziert
27238: Der Ausreißer ist also ein Timing‑Artefakt in der Log‑Erfassung, nicht zwingend ein echter Epoch‑Mismatch.
27257: Wenn wir bei einem Rebase den ptp_tsf_offset ändern, ändert sich die Beziehung zwischen TSF‑Cycle und PHC‑Zeit, aber der timecounter weiß davon nicht – er rechnet weiter mit dem alten Anker.
27289: aber das erklärt nicht die kontinuierlich großen offset schwankungen
27291: Stimmt – ein timecounter‑Resync würde nur einzelne Ausreißer glätten, aber nicht die kontinuierlichen großen Offset‑Schwankungen erklären.
27293: Wenn wir jetzt schon Offset in RX/TX anwenden, bleiben als plausible Ursachen für die dauerhaften Schwankungen nur noch wenige Kandidaten:
27295: 1) TX‑Timestamp in falscher Epoche wegen Completion‑Zeitpunkt
27296: In xmit.c wird TSF bei Completion gelesen, nicht beim Sendezeitpunkt.
27297: Wenn zwischen ts->ts_tstamp (HW‑Timestamp) und diesem TSF‑Read ein settsf/rebase passiert, wird der 32‑bit TX‑Timestamp in falsche Epoche erweitert → t3 springt.
27301: Wenn TSF zwischenzeitlich gesetzt wurde, wird die 32‑bit RX‑TSF in die falsche Epoche erweitert → t2 springt.
27448: wärhend wir bauen, lass uns mal den aktuellen Run weiter analysieren und ein paar Theorien aufstellen... Die Schwankungen sind seit dem einbau des rx und tx offsets dermaßen groß, mMn ist das ein systematischer Fehler
27477: Offset wird am falschen Zeitpunkt angewandt.
27504: Wenn settsf vor dem RX/TX‑Event passiert (oder zwischen Event und späterer Umrechnung), greift der Guard nicht.
27507: Der Guard schützt den Zeitpunkt des Events, nicht den Zeitpunkt der Umrechnung.
27528: Wir rechnen mit dem Offset zum Zeitpunkt der Umrechnung, nicht zum Event‑Zeitpunkt.
27529: Wenn settsf/rebase zwischen Event und Umrechnung passiert, ist das systematischer Fehler.
27591: Der Guard blockiert nur kurz nach RX/TX, aber t2→t3 liegt typischerweise deutlich weiter auseinander (DelayReq‑Intervall). Ein Rebase zwischen t2 und t3 bleibt damit möglich, und genau das erzeugt die großen Path‑Delay/Offset‑Sprünge, obwohl „innerhalb 50 ms“ nichts passiert.
27600: aber: wenn wir uns beim rebasing den offset merken und ihn dann bei der Zeitstempelberechnung anwenden (raw tsf + offset), sollte dann nicht die Zeit aus sicht von ptp nahezu konstant sein? ich glaube wir machen da einen Fehler... Bitte alle entsprechenden Codestellen nochmal analysieren!
27612: new_ext ist PHC‑Domain, nicht Raw‑TSF
27657: Ergebnis = PHC + Offset → falsche Epoch/Skalierung.
27667: Behandle rx_ext/tx_ext als raw TSF, dann aber darf ath9k_ptp_wrap_rebase() nicht mehr anchor_phc in ext schreiben – sonst mischen wir Domains.
27704: größere Änderung: Rebase muss nicht mehr anchor_phc als ext setzen
27716: Kurzantwort: Ja, in beiden Varianten soll der Offset genau einmal wirken – aber die Frage ist wo. Das ist nicht nur kosmetisch, weil es bestimmt, in welcher Domäne rx_ext/tx_ext lebt und wie Wrap/Rebase gerechnet werden.
27733: Rebase darf rx_ext/tx_ext nicht mehr in PHC‑Domain setzen.
27736: => Ergebnis: wieder PHC‑Domain, aber der Offset wirkt erst bei der Conversion, nicht in den Extendern.
27783: Kurz: Nein, bei Option B ist Rebase/Wrap nicht mehr PHC‑Domain, sondern raw‑TSF‑Domain.
27784: PHC‑Kontinuität kommt dann ausschließlich über den Offset, der bei der Conversion addiert wird. Das ist genau der Punkt: Offset nur einmal, aber erst beim cyc2time – nicht mehr in den Extendern.
27807: Stimmt – konzeptionell war Option B größer, weil man die Domänen sauber trennen muss (raw vs. PHC) und sicherstellen muss, dass alle Pfade konsistent bleiben.
27900: Der Fehler war: ext wurde schon auf PHC‑Domain gezogen, und danach wurde beim cyc2time der Offset nochmal addiert.
27907: OK und wenn wir diese beiden Optionen miteinander vergleichen und davon ausgehen, dass wir nicht doppelt addieren, also entweder sofort ext oder erst bei rx und tx: was ist der unterschied beim entsehenden Zeitstempel? Also was ist deine Vermutung?
27967: ➡️ Heißt: die Epoch‑Konsistenz ist jetzt sauber, und der Offset wird exakt einmal angewandt. Der große systematische Fehler durch doppelte Addition ist weg.
27976: (dann liegt der Fehler nicht im Rebase‑Pfad).
28001: Kurz: ja, wir können das verifizieren – und die Daten sprechen klar gegen „Rechen‑Jitter“ als Ursache.
28011: Die +/‑ Wechsel in den Offsets kommen mit sehr hoher Wahrscheinlichkeit aus dem PTP‑Regler/Delay‑Pfad, nicht aus der Conversion.
28017: nein, ich möchte weiter darüber sprechen... ich möchte gerne wissen, was sich jetzt gegenüber der ursprünglichen "settsf-off" logik verändert hat... ich meine bevor wir die offset berechnung direkt am rx und tx gemacht haben, hatten wir diese starken schwankungen nicht, da waren die deutlich smoother
28032: Die “smoothness” früher kam daher, dass RX/TX nicht in PHC‑Domain waren.
28049: aber offsetänderungen haben wir doch jetzt gar nicht mehr, der ist doch starr
28067: → Das glättet Schwankungen künstlich, weil ein konstanter Epoch‑Offset im Fehlerbild steckt.
28098: Ergebnis: der Offset ist NICHT konstant.
28117: Die Schwankungen kommen nicht von „zusätzlicher Berechnung“, sondern von sprunghaften Änderungen des Offset‑Wertes (vermutlich durch Rebase/Wrap‑Logik, evtl. Trigger durch RX/TX‑Extender).
28122: das kann nicht sei... ein rebase kann sich nicht auswirken, denn wir haben settsf deaktiviert und wraps haben wir nur alle 71.6 min... also woher kommen die offsetschwankungen?
28127: Was du als „Schwankung“ siehst, sind Sprünge zwischen mehreren Epochen, nicht Jitter innerhalb einer Epoche.
28140: Guard blockiert nur set_tsf() in main.c + beacon.c, nicht Hardware‑Resets.
28157: Die Offsetschwankung kommt nicht von der zusätzlichen Berechnung, sondern von echten Rebase‑Epochen, die weiterhin passieren, weil settsf nicht wirklich deaktiviert ist (und Resets TSF trotzdem setzen).
28194: Das „settsf‑disable“ ist nicht weg, es sitzt in mac80211‑Debugfs, nicht im ath9k‑Ordner.
28238: Die „Offsetschwankungen“ kommen nicht von Wraps, sondern von Rebases, die weiterhin passieren – selbst wenn settsf in Mesh deaktiviert ist.
28258: Offset‑Sprünge = Rebase‑Events, nicht Wraps.
28259: Sie kommen nicht aus Mesh‑Set‑TSF, sondern aus HW‑Reset‑Pfaden.
28287: Wenn du in diesem Fenster trotzdem Offset‑Schwankungen in ptp4l siehst, dann kommt das nicht vom Rebase‑/Offset‑Pfad, sondern sehr wahrscheinlich aus:
28295: nein sehe ich nicht mehr... jetzt ist alles gut... schalte mal bitte settsf wieder ein auf dem master knoten
28317: Kurz: Path‑Delay wird nicht nur aus der zweiten Sequenz berechnet, sondern aus beiden Paaren (t1/t2 und t3/t4).
28348: Damit kann zwischen t1/t2 und t3/t4 problemlos ein Rebase stattfinden, obwohl innerhalb der jeweiligen Paar‑Sequenz nichts passiert.
28357: Er blockt innerhalb des PTP‑Paares, aber nicht die gesamte PTP‑Periode.
28408: wenn t1 und t2 in der selben epoche liegen und t3 und t4 auch, dann kann ein rebase doch keinen Einfluss haben, denn es werden doch nur die differenzen zwischen den beiden berechnet... der oszillator läuft doch normal weiter, wir rechnen ausschließlich mit differenzen, die Zeitstempel der einzelnen sequenzen sind also relativ zueinander... es sei denn wir brechnen irgendetwas falsch
28410: Dein Gedanke ist grundsätzlich richtig – aber nur, wenn beide Differenzen in der gleichen Epoche liegen.
28427: Darum sind relative Paare allein nicht genug, sie müssen epoch‑kompatibel sein.
28443: PTP benutzt zwei verschiedene Uhren (Master‑Clock und Slave‑Clock). Wenn sich die Slave‑Epoch zwischen t2 und t3 ändert, dann steckt genau diese Änderung als Fehlerterm in der Rechnung.
28466: Epochen sind nicht egal, weil die beiden Differenzen nicht aus derselben Uhr stammen.
28479: → keine Epoch‑Mismatch‑Fehler im Delay‑Term
28530: Der große Effekt kommt eher von Rebase zwischen t2 und t3, nicht in dieser µs‑Lücke.
28579: Damit sind t1/t2 und t3/t4 jeweils sauber – aber nicht garantiert im selben Epoch, weil zwischen t2 und t3 weiterhin ein Rebase passieren kann.
28583: Das verhindert den µs‑Race innerhalb eines Events, aber nicht den großen Epoch‑Wechsel zwischen t2 und t3.
28588: ich möchte, dass wir bevor wir den ts berechnen (rx/tx + offset) den guard setzen und zwar immer wenn ein zeitstempel gefordert ist. Das Paket muss dafür mMn nicht inspiziert werden
28646: Guard wird jetzt für jedes HW‑timestamped Paket gesetzt (nicht nur PTP).
28656: oder einen Cooldown: Guard nur dann setzen, wenn er gerade nicht aktiv ist (also keine Verlängerung bei jedem Paket).
28662: Gute Frage – das würde am Ergebnis des Timestamp selbst nichts ändern, solange wir den Snapshot (TSF/Offset) wirklich verwenden.
28669: Guard beeinflusst den Timestamp nicht (sowieso nicht).
28676: Das löst nicht das Hauptproblem (Rebase zwischen t2 und t3), weil der Guard trotzdem nur kurz ist.
28679: Snapshot → Guard ist ok, aber bringt keine echte Verbesserung.
28703: Das ist problematisch, weil der Slave‑Epoch‑Sprung auch die Bedeutung der raw_tsf‑Differenzen verändert.
28707: Auch wenn beide relativ korrekt sind, sind sie nicht kompatibel, wenn zwischen ihnen ein Epoch‑Shift lag.
28719: aber der Systemzeit‑Bezug ist verschoben, und genau das wirkt als Fehlerterm in der Delay‑Berechnung.
28729: jetzt hab ich dich: die Monotonie beider Epochen hängt aber direkt mit dem Anstieg der raw tsf und diese ist immer gleich, denn es wird ja nicht der oszillator ausgetasucht
28732: Aber das ist nicht das Problem. Das Problem ist der Sprung (Offset‑Step) zwischen t2 und t3. Der ist eine Diskontinuität, und die taucht genau einmal in der PTP‑Formel auf.
28755: Der Offset‑Sprung kürzt sich also nicht weg, weil er nur in t3 steckt, nicht in t2.
28767: Der Fehler kommt nicht vom Oszillator, sondern von der einmaligen Offset‑Diskontinuität zwischen den Paaren.
28809: Kurzfassung: Ja, das Gleiche kann auf der Master‑Seite zwischen t1 und t4 passieren. Wenn der Master zwischen Sync‑TX und DelayReq‑RX rebased, steckt derselbe Offsetsprung in t4 − t1. Dann wirkt der Fehler genauso in die Path‑Delay‑Berechnung. Deshalb muss die Korrektur symmetrisch auf beiden Seiten greifen.
28815: Das ist korrekt für den Zeitpunkt, aber bei einem Rebase zwischen t2 und t3 landen die beiden in verschiedenen Epochen. Genau daraus entsteht der Fehlerterm.
28824: Solange der Guard aktiv ist: alle HW‑Timestamps nutzen guard_epoch_offset (egal ob RX/TX, PTP oder nicht).
28829: Contra: Nicht‑PTP‑TS in diesem Fenster „hängen“ kurz an der alten Epoche und folgen der PHC nicht sofort. Für unsere Use‑Cases vermutlich ok, aber es ist eine bewusste Semantikänderung.
28872: Wenn sync_tx_valid & nicht stale:
28884: Wenn sync_rx_valid & nicht stale:
28899: Kein Einfluss auf nicht‑PTP Traffic.
29088: Nicht‑PTP bleibt unverändert (weiter current_offset).
29105: Ergebnis: Rebase zwischen den PTP‑Minisequenzen wird unsichtbar, ohne Nicht‑PTP zu beeinflussen.
29106: Wichtig: Rebase/Wrap/PHC‑Logik bleibt vollständig gleich – wir ändern nur den Offset, der bei PTP‑DelayReq in die Zeitstempelrechnung geht.
29117: Wenn msg_type == DELAY_REQ → tsf_offset = sync_tx_offset (falls valid + nicht stale)
29246: - Ein kurzer Guard (z. B. 50–60 ms) verhindert Settsf **im direkten PTP‑Fenster**, schützt aber **nicht** vor Rebases zwischen `t2` und `t3`, da diese in der Praxis oft >500 ms auseinander liegen können.
29248: - Das **globale** Anwenden des Offset‑Korrekturwegs auf *alle* HW‑Timestamps (nicht‑PTP) erhöhte die Jitter‑Amplitude und brachte keine Stabilisierung der PTP‑Offsets.
29249: - Die **Pin‑Logik auf PHC‑Ebene** (globales „Festhalten“ der Epoche) war kontraproduktiv und wurde entfernt; sie verschlechterte die PTP‑Stabilität messbar.
29251: - Das **Drop‑Fenster nach Rebase** (rebase_drop) hat die großen Offsets nicht eliminiert; die Drop‑Counter blieben niedrig, daher war es nicht die Hauptursache.
29252: - Die Annahme „keine Rebases innerhalb eines PTP‑Zyklus“ ist **falsch**: Rebases treten zwar nicht zwischen `t1/t2` oder `t3/t4`, aber häufig **zwischen den Mini‑Sequenzen** auf.
29253: - Ursache für den großen Path‑Delay‑Jitter ist primär ein **Epochenwechsel zwischen `t2` und `t3`** (bzw. `t1` und `t4`) – nicht die reine Wrap‑Logik.
29254: - Der robuste Ansatz war **PTP‑spezifisches Epoch‑Pinning**: Sync‑Offset merken und für Delay_Req wiederverwenden, ohne Nicht‑PTP‑Timestamps zu verändern.