Project

General

Profile

Task #614

3.0.0.20

Added by paul leroy over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
09/02/2016
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

J'ai trouvé un bug sur la resynchro des snapshots. Je propose de lancer le test NORMAL long sur cette version, j'aimerais voir le résultat sur la période des snapshots, j'ai un peu changé la stratégie.
Le bug venait du fait que les corrections supérieures à 1 tick à f2 n'étaient pas correctement gérées.


  • 3.0.0.20 *** 09 FEB 2016
    _______________________________
    _ fsw__ Changeset: 274 (4b39bb5ceb61)

snapshot resynchronisation modified, correction is multiplied by 2 when above 1
f2 tick

Bug #491 => modification of hk_lfr_vhdl_aa_sm

snapshot resynchronisation updated following #612 task

README (18 KB) README paul leroy, 09/02/2016 05:03 PM
fsw-3-0-0-20 (4.06 MB) fsw-3-0-0-20 paul leroy, 09/02/2016 05:03 PM
test_modes.py (2.88 KB) test_modes.py Veronique bouzid, 10/02/2016 08:17 AM
plot_delta_SWF_F0_test.png (245 KB) plot_delta_SWF_F0_test.png thomas chust, 10/02/2016 09:44 AM
plot_delta_SWF_F1_test.png (241 KB) plot_delta_SWF_F1_test.png thomas chust, 10/02/2016 09:44 AM
plot_delta_SWF_F2_test.png (243 KB) plot_delta_SWF_F2_test.png thomas chust, 10/02/2016 09:44 AM
tests_time_asm_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test (38 KB) tests_time_asm_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test thomas chust, 10/02/2016 09:44 AM
tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test (37.7 KB) tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test thomas chust, 10/02/2016 09:44 AM
tests_time_swf_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test (183 KB) tests_time_swf_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test thomas chust, 10/02/2016 09:44 AM
LFR - snapshot resynchronization Rev1.1.pdf (41.7 KB) LFR - snapshot resynchronization Rev1.1.pdf resynchro dans 3.0.0.20 paul leroy, 10/02/2016 02:22 PM
LFR - snapshot resynchronization Rev1.2.pdf (41.7 KB) LFR - snapshot resynchronization Rev1.2.pdf paul leroy, 11/02/2016 11:36 AM
1457
1458
1459

Related issues

Related to Task #615: Validation SWF 22s pour 3.0.0.20Stalled2016-02-10

Related to Bug #616: Long test in SBM1 and SBM2 modesClosed2016-02-10

Related to Task #618: Long test with SBM1 and SBM2 FSW 3.0.0.20Closed2016-02-11

Related to Task #622: livraison srec 3.0.0.20 et 3.0.0.22Closed2016-02-12

Related to Task #630: Long Test in normal mode in 3.0.0.22Closed2016-02-18

History

#1 Updated by bruno katra over 5 years ago

  • Status changed from New to In Progress

Installation du software le 09/02/2016
dans /opt/LFR/LFR-FSW/3.0.0.20 + renommage de l'exe sans l'extension 3-0-0-20
Adaptation des scripts pour utiliser cette version.

#2 Updated by bruno katra over 5 years ago

Lancement du tests long à 17h18 : 14h40 de NORMAL avec TIMEGEN et tous les produis nominaux (SWF à 300s et ASM à 3600s).
FIN PREVUE le 10/02/2016 à 7h58.

#3 Updated by Veronique bouzid over 5 years ago

14h40 de NORMAL mode joués cette nuit. Les parametres utilisés sont ceux par défaut du normal mode. Le test s'est bien terminé

Premier test d'analyse sur les Snapshots à 300s et les CWF_F3 (vérifier si premiere salve de CWF_F3 correcte)

Les fichiers (2016_02_09_17_18_56*) sont pc-instru/weekly erased /Thomas/run-2016-02-09-3.0.0.20-1.1.89.

Les fichiers (2016_02_09_17_18_56*)sont rangés également sur pc-faust9 répertoire/ home/validation/data/R3/3.0.0.20/TESTCHARGE/normal.

En piece jointe le script /opt/VALIDATION_R3/test_modes.py joué
Contexte du test
---------------------
FSW 3.0.0.20
VHDL 1.1.89
Timegen 0.0.0.1
EM AVEC Timegen

SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee

#4 Updated by thomas chust over 5 years ago

1457
1458
1459

Tests faits sur les SWF montrent une nette amélioration par rapport au premier test long #612
La logique de resynchronisation semble de nouveau maitrisée mais les amplitudes des oscillations sont 2 à 3 fois supérieures par rapport aux meilleurs tests précédents.

#5 Updated by Veronique bouzid over 5 years ago

  • Related to Task #615: Validation SWF 22s pour 3.0.0.20 added

#6 Updated by paul leroy over 5 years ago

On va y arriver! Merci en tout cas pour les nombreux tests et validations effectués. Vous êtes des pros!

Les oscillations sont plus importantes parce que la dérive est plus importante avec une période de 300s qu'avec 22s (toujours supérieure à plusieurs T2 sur ma machine ici). Je vous joins le dessin que j'ai fait pour expliquer la resynchro dans la version 3.0.0.20. Le terme de correction est calculé comme l'écart, positif ou négatif entre le centre du snapshot reçu et la seconde exacte, ceci en float, l'unité étant T2:

switch (state)
    {

    case MEASURE:
        // ********
        PRINTF1("MEASURE === %d\n", nbSnapshots);
        state = CORRECTION;
        correction = computeCorrection( timePtr );
        PRINTF1("MEASURE === correction = %.2f\n", correction );
        applyCorrection( correction );
        PRINTF1("MEASURE === delta_snapshot = %d\n", waveform_picker_regs->delta_snapshot);
        //****
        break;

    case CORRECTION:
        //************
        PRINTF1("CORRECTION === %d\n", nbSnapshots);
        state = MEASURE;
        computeCorrection( timePtr );
        set_wfp_delta_snapshot();
        PRINTF1("CORRECTION === delta_snapshot = %d\n", waveform_picker_regs->delta_snapshot);
        //****
        break;

    default:
        break;

    }

Une fois sur deux, on applique la valeur nominale de delta_snapshot et une fois sur deux la valeur de ldeta_snapshot corrigée de la dérive mesurée.

Avec la fonction qui applique la correction:


void applyCorrection( double correction )
{
    int correctionInt;

    if (correction >= 0.)
    {
        if ( (1. > correction) && (correction > 0.5) )
        {
            correctionInt = 1;
        }
        else
        {
            correctionInt = 2 * floor(correction);
        }
    }
    else
    {
        if ( (correction < -1.) && (correction < -0.5) )
        {
            correctionInt = -1;
        }
        else
        {
            correctionInt =  2 * ceil(correction);
        }
    }
    waveform_picker_regs->delta_snapshot = waveform_picker_regs->delta_snapshot + correctionInt;
}

delta_snapshot est un entier. Suivant les valeurs du terme de correction:
=> on applique 0 si 0.5 > correction > 0
=> on applique 1 si 1 > correction > 0.5
=> on applique 2*floor(correction) si correction > 1

Facile non?

#8 Updated by paul leroy over 5 years ago

  • Assignee changed from paul leroy to thomas chust

#9 Updated by bruno katra over 5 years ago

  • Related to Bug #616: Long test in SBM1 and SBM2 modes added

#10 Updated by thomas chust over 5 years ago

  • Assignee changed from thomas chust to paul leroy

Super Paul pour toutes ces explications et cela n'est pas de trop! :) Effectivement on avance mais j'ai encore des questions :

  1. Sur ta figure, "delta_snapshot + 2 x correction" signifie t-il bien "delta_snapshot += correctionInt" (cf le code de applyCorrection) ? De sorte que ce que tu appelles la valeur nominale de delta_snapshot est en fait sa valeur avant l'application d'une correction (le coup d'avant)? Ou de fait la valeur nominale est la valeur initiale que tu nommes delta_f2 ? Cela est important car si la dérive est bien supérieure à T2 on sera toujours en retard ou en avance (par manque d'adaptation à la situation courante puisque delta_f2 est fixé à l'avance). Aussi quand tu écris sur la figure " + 2 x correction" c'est dans le cas seulement où "correctionInt" vaut cette valeur, non ?
    Le fait que tu appliques "2 x correction" c'est bien parce que la prise en compte ne sera effective que dans 2 coups (2 dérives qui se seront accumulées depuis la mesure de "correction")?
  2. Dans le cas d'une correction négative il me semble que tu as codé une boulette : dans "( (correction < -1.) && (correction < -0.5) )" tu voulais certainement écrire "( -1. < correction)", non ? Jusqu'à présent nous avions des corrections positives à faire je crois (dérive négative) de sorte que cette coquille n'aurait pas été détectée ...
  3. dans le bloc CORRECTION, à quoi sert la ligne "computeCorrection( timePtr );" qui n'affecte aucune valeur ?
  4. Une suggestion naïve: remplacer floor par ceil dans le cas d'une correction positive et inversement ceil par floor dans le cas opposé ? As-tu déjà essayé? Dans mon intuition j'imagine que cela correspondrait à une correction plus efficace (i.e. qui nous ramène plus près d'une sharp seconde). Mais cela est peut-être instable ...

Merci encore pour ton boulot!

#11 Updated by paul leroy over 5 years ago

J'ai mis à jour mon dessin (révision 1.2), ce n'était pas assez clair.
  1. la valeur delta_f2 est utilisée une seule fois au démarrage pour décompter le temps jusqu'au départ du premier snapshot à f2. Ensuite, le compteur est rechargé avec la valeur delta_snapshot_init (valeur nominale) ou delta_snapshot_init + correctionInt. delta_snapshot_init est la valeur nominale que devrait avoir delta_snapshot si il n'y avait pas de dérive. Effectivement, le x2 vient du fait que la dérive est double entre le moment où on utilise delta_snapshot_init et le moment où on utilise la correction
  2. tout à fait d'accord avec la remarque. Halala, c'est dur ce passage du code. Je fais le correction!
  3. le bloc computeCorrection me sert juste à faire des printf indicatifs pour le debug, la valeur n'est pas utilisée
  4. une suggestion intéressante mais j'ai effectivement eu des cas instables au cours du développement alors j'ai mis la solution avec l'intervalle 0.5-1 qui permet d'appliquer une correction un peu en avance, avant que la dérive ne soit supérieure à un T2

#12 Updated by Veronique bouzid over 5 years ago

  • Related to Task #618: Long test with SBM1 and SBM2 FSW 3.0.0.20 added

#13 Updated by thomas chust over 5 years ago

  • Assignee changed from thomas chust to paul leroy

Hello Paul, je suis en train d'analyser le dernier test long en date (#618), je vais a priori vous sortir des résultats tout à fait similaires à ceux d'ici. Par contre je n'arrive pas vraiment encore à coller ton algorithme sur les courbes d'écart observées. Donc encore une question pour éclaircir ma lanterne:
- comment fixes-tu la valeur nominale delta_snapshot_init ? Cette valeur ne change t-elle plus jamais ?

#14 Updated by paul leroy over 5 years ago

  • Assignee changed from paul leroy to thomas chust

On récupère le paramètre sy_lfr_n_swf_p dans les paquets ou on prend la valeur par défaut (300s) puis j'applique la fonction suivante pour mettre à jour le paramètre utilisé par le VHDH

void set_wfp_delta_snapshot( void )
{
    /** This function sets the delta_snapshot register of the waveform picker module.
     *
     * The value is read from two (unsigned char) of the parameter_dump_packet structure:
     * - sy_lfr_n_swf_p[0]
     * - sy_lfr_n_swf_p[1]
     *
     */

    unsigned int delta_snapshot;
    unsigned int delta_snapshot_in_T2;

    delta_snapshot = parameter_dump_packet.sy_lfr_n_swf_p[0]*256
            + parameter_dump_packet.sy_lfr_n_swf_p[1];

    delta_snapshot_in_T2 = delta_snapshot * 256;
    waveform_picker_regs->delta_snapshot = delta_snapshot_in_T2 - 1;    // max 4 bytes
}

#15 Updated by bruno katra over 5 years ago

Bonjour à tous.
Nous venons de livrer le FSW 3.0.0.20 via l'issue JIRA dédiée :
https://jira-lesia.obspm.fr/browse/RPWSSS-197

Il y a un résumé des nouvelles modifications et fonctionnalités dans le commentaire du JIRA.
Cette version a été validée de façon intensive et quasi exhaustive (tests des nouveautés + beaucoup de non-regression).
Cependant nous avons eu ce matin une nouvelle livraison de 3.0.0.22 qui est en cours de validation. Elle corrige un pb au niveau de la resynchro des SWF mais c'est un bug mineur à priori pas facilement reproductible en test.
Par souci de fiabilité et afin de ne pas vous retarder plus : nous avons préféré vous livrer la version la mieux validée (3.0.0.20) mais nous vous livrerons la 3.0.0.22 la semaine prochaine une fois qu'elle aura le même niveau de validation que celle d'aujourd'hui. Cela vous laisse le choix selon qu' un aménagement de votre planning le permet ou non de démarrer vos tests quand vous le souhaiterez.

Merci une fois encore à tous de votre compréhension sur les délais imprévus que nous avons eu mais soyez sûrs que cela en valait la peine ! La marche entre 3.0.0.10 livré en octobre et la livraison d'aujourd'hui est conséquente.

Bonne fin de journée

Bruno

#16 Updated by bruno katra over 5 years ago

  • Related to Task #622: livraison srec 3.0.0.20 et 3.0.0.22 added

#17 Updated by Veronique bouzid over 5 years ago

  • Category set to SRS

#18 Updated by thomas chust over 5 years ago

  • Related to Task #630: Long Test in normal mode in 3.0.0.22 added

#19 Updated by bruno katra over 5 years ago

  • Category deleted (SRS)
  • Status changed from In Progress to Closed

Also available in: Atom PDF