lien zoom : https://ijclab.zoom.us/j/93437044377?pwd=bnhSWWxzN3RVbUs1SHNLNUE2cVJrQT09
Présents :
O. Perdereau, H. Grasland, D. Charlet, R. Ansari, Cédric Esnault , M. Taurigna, Cédric Viou
1) Point sur les cartes IDROGEN et les mezzanines ADC
- Daniel devra se pencher sur les deux cartes IDROGEN qui ont des soucis - Problème avec la mémoire flash qui stocke le firmware pour l'une et difficulté d'accrochage WR sur l'autre
- Monique doit faire un bout de code pour configurer l'ADC à travers le SPI et IPBus
- Les nouvelles cartes (PCB) pour les mezzanines ADC devront arriver début juin, on va en câbler une, vérifier avant de câbler les autres
- Peut-être tenter de réparer la mezzanine qui a "chauffé" - au cas où ça soit les circuits régulateurs de l'alimentation ...
2) Discussion sur les sources possibles de l'asymétrie observée au niveau des échanges réseau (en TCP/IP) avec la machines bao3.
Aucune poste n'est trouvée par une comparaison rapide des hardwares par Hadrien entre bao3 et une machine similiaire ( bao8 ?)
3) Quelques discussions sur les limites en flux de données entrant que peut absorber le système d'acquisition - où les échanges
des paquets FFT par liens TCP/IP semblent être limitant selon les tests faits par Olivier.
Hadrien commente ses tests sur bao1 (une des deux machines les plus puissantes( où il génèrent les données pour 8 liens ,
et les traitent par un mfacq tourant sur la même machine (deux processeurs - échange par la boucle locale 127.0.0.0 ) -
Ce n'est pas la corrélation qui limite, mais le calcul des FFT (6 threads) - ~150 MO/s / lien avec un taux de perte <~ 5%
Hadrien présente aussi de l'analyse des performances et de l'utilisation des ressources de calcul grâce à l'outil perf et la visualisation des résultats par firefox.
4) Discussions sur les configurations possibles pour l'acquisition :
(a) soit deux machines (bao3 et bao?) en front-end , réception UDP, FFT , envoi par TCP/IP vers bao1 et bao2 (moitié de la bande chacune) pour le calcul des corrélations
(b) ou l'utilisation de bao1 et bao2 , qui recevront chacune 4 liens UDP, FFT , envoi de la moitié de la bande vers l'autre machine et calcul des corrélations sur une moitié de bande
On pourra envisager l'utilisation des GPU (un GPU sur chaque machine) dans une phase ultérieure -
L'objectif de la première phase est d'avoir une temps utile ciel ~ 20-25% , ce qui correspond à environ 400 MO/s / lien ( A VERIFIER - d'apres des notes ds le cahier
c'est plutot 240 MByte/s)
5) Il faut optimiser la configuration d'execution des mfacq , en assignant les différents threads à tel ou tel CPU - outil task-set et lstopo
6) Olivier monter quelques plots - mesure de l'écart en temps entre deux voies, mesuré en injectant un signal à 62 MHz (?) -
délai ~ - 200 ps (offset moyen ) et sigma=jitter ( ~ 22 s) - semble varier avec ~ 40 Hz
Il faudra essayer de savoir si ce délai se retrouve ds le PPS / horloge 10 MHz de WR , ou si c'est l'ADC qui en est la cause
Cédric V. va envoyer la note avec des mesures similaires qu'il a faites pour NenuFar
7) Il faudra faire aussi des mesures pour caractériser les cartes IDROGEN et les mezzanines ADC
- Qualité / reproductibilité de la synchronisation WR
- linéarité de la réponse à différentes fréquences
- Réponse dans les différentes bandes de Nyquist - en particulier dans la bande de PAON4 : 1000 - 1500 MHz
- Niveau de bruit, cross-talk entre voies d'un même ADC et deux ADC différents
- ...
On pourra faire quelques mesures avec deux cartes, mais les mesures systématiques devront être effectuées avec le système complet
(8 voies, 4 cartes, toute la chaîne analogique ) - Il faudra peut-être trouver un endroit pour avoir moins de "bruit" (RFI)
8) A faire dans mfacq
- Modifier mfacq pour permettre de générer les paquets de "données" au lieu de les lire sur UDP (test de performance)
- régler les problèmes de socket mal fermé à la fin de l'exécution de mfacq
- Lecture de trame de numérisation découpée en plusieurs paquets UDP
- programme de contrôle / supervision
