Task #615
closed
Validation SWF 22s pour 3.0.0.20
0%
Description
Suite à l'installation du soft 3.0.0.20, on relance le test avec les swf à 22s. Ce test etait correct en 3.0.0.19 donc
c'est plutot un tests de non regression.
Ce test enchaine
- 1800s de Normal mode
- 900s de SBM1
- 900s de SBM2
- 600s de NORMAL
- 600s de BURST
- 600s de NORMAL
- Fin en STANDBY
Les fichiers (2016_02_10_08_09_20*) sont stockés sur pc-instru /Weeklyerased/Thomas/run-2016-02-10-3.0.0.20-1.1.89/swf-22s
Les fichiers (2016_02_10_08_09_20_*) sont également sur pc-faust9 dans le répertoire /home/validation/data/R3/3.0.0.20/TESTS-UNITAIRES/all-modes
Contexte du test
---------------------
FSW 3.0.0.20
VHDL 1.1.89
EM sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee
Files
Related issues
Updated by Veronique bouzid almost 9 years ago
- Related to Task #614: 3.0.0.20 added
Updated by thomas chust almost 9 years ago
- File plot_delta_SWF_F0_test.png plot_delta_SWF_F0_test.png added
- File plot_delta_SWF_F1_test.png plot_delta_SWF_F1_test.png added
- File plot_delta_SWF_F2_test.png plot_delta_SWF_F2_test.png added
- File tests_time_asm_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test_b tests_time_asm_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test_b added
- File tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test_b tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test_b added
- File tests_time_swf_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test_b tests_time_swf_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test_b added
- Assignee changed from thomas chust to paul leroy
Test concluant. Silimaire à 3.0.0.19 (#613).
Cependant une différence concerne la resynchro: on observe à la fin un "décrochage" vers +4ms. Paul, est-ce lié à ta dernière modif ?
Updated by paul leroy almost 9 years ago
- Assignee changed from paul leroy to thomas chust
Pour l'instant, je ne vois pas d'autre explication qu'un saut dans la dérive qui du coup serait compensé brutalement (cf #614 et le dessin d'explication de la resynchro pour 3.0.0.20).
Updated by paul leroy almost 9 years ago
- File 2016_02_10_14_33_10.png 2016_02_10_14_33_10.png added
J'ai refait un test de mon côté. Sur un temps long, je ne vois pas de saut brutal.
Je joins les observations effectuées en mode NORMAL, delta_snapshot = 22 secondes, avec transition en SBM1 entre le snapshot 336 et le 337.
Jeu de données préfixé 2016_02_10_14_33_10.
Updated by thomas chust almost 9 years ago
- Assignee changed from thomas chust to paul leroy
- Priority changed from High to Normal
J'y suis: en fait le "décrochage" observé correspond exactement au moment ou l'on passe de BURST à NORMAL. Cela renvoie donc à la façon avec laquelle tu ré-initialises des paramètres. A priori cela devrait pouvoir être amélioré, non ?
Updated by paul leroy almost 9 years ago
- Assignee changed from paul leroy to thomas chust
Ah oui, si il y a un redémarrage des snapshots, ça explique le saut.
Au démarrage, on part a priori avec un retard de au pire T2, soit 3.9ms. C'est peut-être un manque de chance. Je ne pense pas pouvoir améliorer ça.
Updated by 
