Project

General

Profile

Bug #245

synchronisation des snapshots

Added by paul leroy about 7 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
01/10/2014
Due date:
% Done:

90%

Estimated time:
revision:
r0

Description

Also tracked in https://jira-lesia.obspm.fr/browse/RPWSWR-627 and https://jira-lesia.obspm.fr/browse/RPWSWR-628

Lorsque LFR est synchronisé par un système extérieur (timegen par exemple, ou la brique Star Dundee avec des time codes à 1 Hz), le centre des snapshots se décale lentement (200 ms sur 12 heures de tests). C'est dû à la mise en oeuvre de la période de répétition des snapshots, qui est basée sur l'horloge locale à 256 Hz.

Solution: contrôler à chaque snapshot le décalage et ajuster le période de répétition (paramètre delta_snapshot du waveform picker).

History

#1 Updated by paul leroy about 7 years ago

  • Status changed from New to Resolved

fsw > = 2.0.1.1

J'ai ajouté une fonction de resynchronisation des snapshots. Je vais détailler le fonctionnement dans le software design report.

En résumé:
Lorsqu'un snapshot à f0 est généré, disons le snapshot [n], le soft regarde la date du centre et la compare à la seconde entière la plus proche. Si la différence est supérieure à une période à f2 (1/256 = 3.906 ms), le snapshot [n+2] est recalé, le [n+1] n'est pas modifié. La nécessité du recalage est reconsidérée un snapshot sur deux.

#2 Updated by paul leroy almost 7 years ago

  • Status changed from Resolved to Closed

fonction implémentée et testée

#3 Updated by thomas chust about 6 years ago

Nouveau bug observé depuis, dans des versions récentes du soft et du VHDL:
- Bug #476 (VHDL-1.1.88 FSW-3.0.0.8)
- Bug #496 (VHDL-1.1.89 FSW-3.0.0.8)

En fait ce bug est également observé à l'identique (dans sa logique) sur une ancienne version du soft et du VHDL. A savoir:
- sous VHDL-1.1.68 et FSW-2.0.3, un enregistrement de 11 snapshots tout les 300 s (datant du 7 avril 2015) montre
- le 2èmes SWF_F1 & SWF_F0 en retard de ~0.22s par rapport à 300s (ensuite quasi nominal avec des écarts de ~12 ms tous les 2 snapshots);
- le 3ème SWF_F2 en retard de ~0.22s (ensuite idem quasi nominal avec des écarts de ~12 ms tous les 2 snapshots);
- tous les SWF_F0 centrés sur les SWF_F1 de manière identique (à 2^-16 s près);
- ce qui implique que les 2ème SWF_F1 & SWF_F0 sont décentrées par rapport au 2ème SWF_F2: ils sont en retard d ~0.22s
- que tous les autres SWF sont centrés de la même manière que le 1er snapshot, à des écarts près de l'ordre de 12 ms tout les 2 snapshots.

Fichiers joints: tests_time_VHDL-1.1.68_FSW-2.0.2.3_2015_04_07 + les fichiers ascii des SWF

Jean-Christophe a une idée sur l'origine de cela: si j'ai bien compris, l'actualisation des décompteurs des SWF se ferait dans la même logique que celle qui actualise la seconde de LFR avec celle du S/C, ce qui implique une prise en compte effective tout les deux snapshots au mieux et si l'on démarre avec des mauvais paramètres cela met un certain temps à s'autocorriger ...

#4 Updated by bruno katra about 6 years ago

  • Status changed from Closed to In Progress

#5 Updated by bruno katra almost 6 years ago

  • Description updated (diff)

#6 Updated by paul leroy almost 6 years ago

  • Assignee changed from paul leroy to bruno katra

J'ai fait une modification dans la version 3.0.0.13 au niveau de la fonction de synchronisation des snapshots. La correction est calculée à chaque génération d'un snapshot, c'est plus efficace.

Ceci dit, j'explique quand même mal des décalages de centaines de ms. Une explication pour un décalage si important dans les mesures que vous avez effectuées serait un démarrage du mode avec un enter_mode_time = 0 qui lance le mode immédiatement, sans référence à une seconde entière.
Ca m'a fait reconsidérer le comportement à la réception d'un enter_mode_time = 0. Pour que ce soit plus sain pour la synchro des snapshots, il faudrait qu'en cas de réception d'un enter_mode_time = 0 je lance le mode à la date 'coarse_time local LFR + 1'. Qu'en pensez-vous?

Explication de la resynchro:
A chaque production d'un snapshot à f0, le centre de la série temporelle est mesuré et le temps avant le prochain snapshot est modifié. Tout cela se fait avec un retard puisque à la réception d'un snapshot n, le compteur permettant de démarrer l'aacquisition du snapshot n+1 a déjà été lancé. Donc la correction calculée sur le snapshot n ne sera appliquée qu'au snapshot n+2.

#7 Updated by thomas chust almost 6 years ago

  • Priority changed from Urgent to Normal
  • % Done changed from 0 to 80

Pour les dernières avancée sur ce point voir: #614

#8 Updated by bruno katra over 5 years ago

  • % Done changed from 80 to 90

Nombreuses modifications/améliorations faites par Paul entre 3.0.0.13 et 3.0.0.22 (tracés dans #612 #616 #618 #624 #630).
A partir de 3.0.0.22 ; le jitter est stable même après plusieurs heures de tests : entre -11ms et +3 ms pour F0 par exemple avec ne synchro TIMEGEN. (voir graphes #630)
Une RFW 230 a été émise concernant la nc avec les 1ms demandé par SSS-CP-EQS-350.
Le jitter actuel permet néanmoins un recouvrement complet des SWF de TDS, ce qui est l'exigence scientifique voulue par SSS-CP-EQS-350.

#9 Updated by bruno katra over 5 years ago

  • Status changed from In Progress to Feedback

JIRA 627 :

After several improvements on swf resync algorithm, the centering precision of swf has a jitter which is stable and characterized (depending on sampling frequency). 3 figures are attached in this issue showing the jitter for SWF_F0, SWF_F1 and SWF_F2 during 15 hours when LFR is synchronized with an external sources which are approx :
F0 : -11ms/+3ms
F1 : -11.5ms/+3ms
F2 : -14ms/+1ms

Even if more than 1ms required, those range are still scientifically acceptable as they cover TDS SWF range.
All of this has been written in RFW 230.

#10 Updated by bruno katra over 4 years ago

  • Status changed from Feedback to Closed

Pas d'objection à la RFW reçu.

Also available in: Atom PDF