Project

General

Profile

Bug #863

Produits SCIENCE : périodes des ACQUISITION_TIME et TIME non nominaux avec TIMEGEN

Added by bruno katra almost 5 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Urgent
Category:
R3+
Target version:
-
Start date:
28/12/2016
Due date:
% Done:

10%

Estimated time:
revision:
r0

Description

Les produits BP arrivent à la cadence attendue mais avec des champs ACQUISITION_TIME qui n'ont pas la bonne période seulement lorsqu'on utilise TIMEGEN.
Exemple:
2016 12 28 12:33:59:717 TM_LFR_SCIENCE_NORMAL_BP2_F0 time = 0x 1ff66d6c ffeb
2016 12 28 12:34:19:797 TM_LFR_SCIENCE_NORMAL_BP2_F0 time = 0x 1ff66d7a ffcf
2016 12 28 12:34:39:771 TM_LFR_SCIENCE_NORMAL_BP2_F0 time = 0x 1ff66d88 ffb4
2016 12 28 12:34:59:771 TM_LFR_SCIENCE_NORMAL_BP2_F0 time = 0x 1ff66d96 ff9a
2016 12 28 12:35:19:782 TM_LFR_SCIENCE_NORMAL_BP2_F0 time = 0x 1ff66da4 ff81

Les BP2 sont bien arrivés toutes les 20s mais leur ACQUISITION_TIME est espacé de 14s

Idem BP1:
2016 12 28 12:33:43:773 TM_LFR_SCIENCE_NORMAL_BP1_F0 time = 0x 1ff66d60 ffff
2016 12 28 12:33:47:711 TM_LFR_SCIENCE_NORMAL_BP1_F0 time = 0x 1ff66d63 fffb
2016 12 28 12:33:51:711 TM_LFR_SCIENCE_NORMAL_BP1_F0 time = 0x 1ff66d66 fff5
2016 12 28 12:33:55:774 TM_LFR_SCIENCE_NORMAL_BP1_F0 time = 0x 1ff66d69 fff0

Les BP1 ont bien arrivés toutes les 4s mais leur ACQUISITION_TIME est espacé de 3s

Idem pour les ASM : 3s au lieu de 4s
Idem pour les SWF : 15s au lieu de 22s

NB : les mêmes tests SANS TIMEGEN ne montrent pas le problème.
NB2 : Le bug n'était pas présent en R3 + ancien VHDL (nous avons revérifié les résultats des tests de charge effectués en oct 2015)
NB2 : il est probable que TOUS les produits soient impactés.

Contexte du test
---------------------
FSW 3.1.0.4
VHDL 1.1.91
EM1 avec TIMEGEN

History

#1 Updated by bruno katra almost 5 years ago

  • Subject changed from BP1 et BP2 : périodes des ACQUISITION_TIME et TIME non nominaux avec TIMEGEN to Produits SCIENCE : périodes des ACQUISITION_TIME et TIME non nominaux avec TIMEGEN
  • Description updated (diff)

#2 Updated by bruno katra almost 5 years ago

  • Description updated (diff)

#3 Updated by bruno katra almost 5 years ago

Uen piste supplémentaire, on voit dans le temps des HK les saut de secondes qui explique le pb :

Seconds : 536173285.0282440185546875
Seconds : 536173286.0282440185546875
Seconds : 536173287.0282135009765625
Seconds : 536173287.0281982421875000
Seconds : 536173288.0281982421875000
Seconds : 536173289.0281829833984375
Seconds : 536173290.0281829833984375
Seconds : 536173290.0281982421875000
Seconds : 536173291.0281829833984375
Seconds : 536173292.0281677246093750
Seconds : 536173292.0282287597656250
Seconds : 536173293.0281372070312500
Seconds : 536173294.0281219482421875
Seconds : 536173294.0281066894531250
Seconds : 536173295.0280914306640625

#4 Updated by bruno katra almost 5 years ago

  • Status changed from New to In Progress
  • Assignee changed from paul leroy to Alexis Jeandet
  • % Done changed from 0 to 10

Nouveau test avec une mini-LFR TIMEGEN : le problème n'apparait pas.
DONC
Le problème vient du nouveau VHDL TIMEGEN.

#5 Updated by Alexis Jeandet almost 3 years ago

  • Status changed from In Progress to Closed

Also available in: Atom PDF