https://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012016-01-23T18:40:11ZRedmineLFR-FSW - Task #590: livraison version 3.0.0.13https://hephaistos.lpp.polytechnique.fr/redmine/issues/590?journal_id=17262016-01-23T18:40:11Zthomas chust
<ul></ul><p>Paul, une question bête. Cela marche t-il aussi pour les transitions suivantes: <br />SBM1 => SBM2 ?<br />SBM2 => SBM1 ?</p> LFR-FSW - Task #590: livraison version 3.0.0.13https://hephaistos.lpp.polytechnique.fr/redmine/issues/590?journal_id=17272016-01-25T08:01:01Zpaul leroy
<ul></ul><p>Normalement oui.</p> LFR-FSW - Task #590: livraison version 3.0.0.13https://hephaistos.lpp.polytechnique.fr/redmine/issues/590?journal_id=17282016-01-25T13:57:49ZVeronique bouzid
<ul></ul><p>Installation de la version 3.0.0.13 sur pc-faust9.</p>
<p>Voici donc le nouvel environnement de test<br />FSW 3.0.0.13<br />VHDL 1.1.89<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p>
<p>Le script /home/validation/SCRIPT/just_hk_survey.py a été joué.</p>
<p>1- La version est correctement affichée dans les TM_LFR_HK.</p>
<p>2- Apres la sequence de boot, les champs <br /> HK_LFR_TIME_NOT_SYNCHRO est positionné à 1<br /> HK_LFR_LE_CNT est incrémenté et vaut 1<br />--> cela me semble correct</p>
<p>3- le champ SY_LFR_WATCHDOG_ENABLED est toujours à DISABLED.<br />--> comme indiqué par Paul, on doit determiner son fonctionnement</p>
<p>Les fichiers de test sont dans le répertoire /home/validation/data/3.0.0.13/TESTS6UNITAIRES/just_hk</p> LFR-FSW - Task #590: livraison version 3.0.0.13https://hephaistos.lpp.polytechnique.fr/redmine/issues/590?journal_id=17302016-01-25T14:47:47Zpaul leroy
<ul></ul><p>C'est pas forcément sain qu'une désynchro soit repérée juste après le boot puisque c'est normal de commencer désynchronisé.</p>
<p>Je propose d'attendre une transition synchronisé vers désynchronisé avant de commencer à compter les désynchros.</p> LFR-FSW - Task #590: livraison version 3.0.0.13https://hephaistos.lpp.polytechnique.fr/redmine/issues/590?journal_id=17332016-01-25T23:18:32Zthomas chust
<ul><li><strong>File</strong> <a href="/redmine/attachments/1377">tests_time_VHDL-1.1.89_FSW-3.0.0.13_2016_01_25</a> <a class="icon-only icon-download" title="Download" href="/redmine/attachments/download/1377/tests_time_VHDL-1.1.89_FSW-3.0.0.13_2016_01_25">tests_time_VHDL-1.1.89_FSW-3.0.0.13_2016_01_25</a> added</li><li><strong>Assignee</strong> changed from <i>Veronique bouzid</i> to <i>paul leroy</i></li></ul>J'ai fait des tests (régularité de la période de 22 s + centrage des SWF) sur les données fournies par véro (voir son message ci-dessous). Résultats:
<ul>
<li>plus on va vers la fin du fichier (30 min SBM1 + 30 min SBM2) plus on s'écarte des 22 s (-3.5 s sur les swf2 et swf1) => vraiment pas régulier (alors qu'on est en mode non synchrone)</li>
<li>sur les swf0 même tendance mais en plus il y a des gros bug tout à fait similaire au Bug <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: erreurs d'enregistrement des SWF_F1 et SWF_F0 à 16 s en SBM2 (doublons + temps) (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/548">#548</a> (qui portait sur les swf0 et swf1)</li>
<li>hormis les grandes discontinuités associées au gros bug, les SWF sont bien centrées (du moins de la même manière pour tous les SWF, à 2-4 fine time près)</li>
</ul>
<p>Je joins mon fichier récapitulatif des tests</p>
<p>------- Message transféré --------<br />Sujet : Test à depouiller<br />Date : Mon, 25 Jan 2016 15:08:57 +0100<br />De : veronique bouzid <<a class="email" href="mailto:veronique.bouzid@lpp.polytechnique.fr">veronique.bouzid@lpp.polytechnique.fr</a>><br />Pour : Thomas Chust <<a class="email" href="mailto:thomas.chust@lpp.polytechnique.fr">thomas.chust@lpp.polytechnique.fr</a>>, Bruno Katra <<a class="email" href="mailto:bruno.Katra@lpp.polytechnique.fr">bruno.Katra@lpp.polytechnique.fr</a>></p>
<p>Hello,<br />SUr pc-faust9 compte validation</p>
<p>Dans le répertoire<br />/home/validation/data/R3/3.0.0.13/TEST-UNITAIRES/sbm1-vs-sbm2<br />il ya les 2 fichiers obtenus en parametrant<br />les Snapshots à 22s<br />Les Asm= 4s<br />puis<br />30 mn de sbm1<br />30 mn de sbm2</p>
<p>Je vous laisse découvrir les résultats.</p>
<p>Véronique</p> LFR-FSW - Task #590: livraison version 3.0.0.13https://hephaistos.lpp.polytechnique.fr/redmine/issues/590?journal_id=17382016-01-26T08:57:21Zpaul leroy
<ul></ul><p>J'ai trouvé le bug. Finalement, je suis revenu à une solution ou je resynchronise en utilisant 1 snapshot sur 2:<br />1) je reçois le snapshot 2k, je mesure le temps de centre, je calcule une correction (le snapshot 2k+1 est déjà en cours d'acquisition)<br />2) la correction est utilisée pour le snapshot 2k+2<br />3) à la réception du snapshot 2k+2, je calcule une nouvelle correction<br />Ca fonctionne sur ma machine, ça peut corriger des dérives inférieure à 0.5 secondes sur deux périodes (2*300 secondes dans les conditions nominales)</p>
<p>Correction dans fsw >= 3.0.0.14</p>
<p>A noter, quelquechose que je viens de vérifier et que j'avais oublié:<br />avec VHDL 0.1.68 sur ma MINI-LFR, en l'absence de timcodes, il n'y a pas de dérive, on tombe sur des intervalles exacts (ce qui est le comportement attendu sur les vieilles version du VHDL).<br />avec VHDL 0.1.89 sur MINI-LFR (et donc sur les versions récentes du VHDL), même sans synchro ni timecode il y a une dérive, on ne tombe plus parfaitement sur des temps justes parce que le coarse_time et le fine_time sont basés sur l'oscillateur à 50 MHz et non plus sur l'oscillateur à 49.152 MHz (utilisé pour générer 16, 256, 4096 et 24576 Hz), donc finis les cas où tout tombait juste.</p>
<p>Ce dernier point est à clarifier avec Alexis peut-être.</p> LFR-FSW - Task #590: livraison version 3.0.0.13https://hephaistos.lpp.polytechnique.fr/redmine/issues/590?journal_id=17412016-01-26T14:19:10Zpaul leroy
<ul><li><strong>Assignee</strong> changed from <i>paul leroy</i> to <i>Veronique bouzid</i></li></ul> LFR-FSW - Task #590: livraison version 3.0.0.13https://hephaistos.lpp.polytechnique.fr/redmine/issues/590?journal_id=17452016-01-26T22:56:26Zthomas chust
<ul><li><strong>File</strong> <a href="/redmine/attachments/1380">tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.13_2016_01_25</a> <a class="icon-only icon-download" title="Download" href="/redmine/attachments/download/1380/tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.13_2016_01_25">tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.13_2016_01_25</a> added</li></ul><p>Dans la même veine pour les CWF, test fait sur la régularité des paquets. Résultat dans le fichier joint. Même conclusion que Véronique. Tout semble nominale même pour les paquets CWF3. Les dérives observées sont cohérentes avec la durée des buffers de 2688 points et sont de l'ordre de 4-8 ppm. Cela confirme des observations antérieures: <a class="issue tracker-2 status-5 priority-2 priority-default closed" title="Feature: synchronisation LFR (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/441">#441</a> ou <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: synchronisation des snapshots (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/245">#245</a></p> LFR-FSW - Task #590: livraison version 3.0.0.13https://hephaistos.lpp.polytechnique.fr/redmine/issues/590?journal_id=19982016-02-22T09:38:24ZVeronique bouzid
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Closed</i></li></ul>