Project

General

Profile

Task #615

Validation SWF 22s pour 3.0.0.20

Added by Veronique bouzid over 5 years ago. Updated 6 months ago.

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

0%

Estimated time:
revision:
r0

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

plot_delta_SWF_F0_test.png (238 KB) plot_delta_SWF_F0_test.png thomas chust, 10/02/2016 12:37 PM
plot_delta_SWF_F2_test.png (239 KB) plot_delta_SWF_F2_test.png thomas chust, 10/02/2016 12:37 PM
tests_time_asm_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test_b (204 KB) tests_time_asm_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test_b thomas chust, 10/02/2016 12:37 PM
plot_delta_SWF_F1_test.png (235 KB) plot_delta_SWF_F1_test.png thomas chust, 10/02/2016 12:37 PM
tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test_b (45.5 KB) tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test_b thomas chust, 10/02/2016 12:37 PM
tests_time_swf_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test_b (214 KB) tests_time_swf_VHDL-1.1.89_FSW-3.0.0.20_2016_02_09_test_b thomas chust, 10/02/2016 12:37 PM
2016_02_10_14_33_10.png (206 KB) 2016_02_10_14_33_10.png NORM puis SBM1 ap snap 336 - delta 22s - 3.0.0.20 paul leroy, 10/02/2016 04:50 PM
1463
1464
1466
1470

Related issues

Related to Task #614: 3.0.0.20Closed2016-02-09

History

#1 Updated by Veronique bouzid over 5 years ago

  • Tracker changed from Bug to Task

#2 Updated by Veronique bouzid over 5 years ago

#4 Updated by paul leroy over 5 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).

#5 Updated by paul leroy over 5 years ago

1470

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.

#6 Updated by thomas chust over 5 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 ?

#7 Updated by paul leroy over 5 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.

#8 Updated by Alexis Jeandet 6 months ago

  • Status changed from New to Stalled

Also available in: Atom PDF