public/Telereview
1
0
Fork 0
mirror of https://git.roussel.pro/telecom-paris/pact.git synced 2026-02-09 10:30:17 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

completion rapport

Browse Source
This commit is contained in:
Quentin Roussel
2023-01-26 14:25:38 +01:00
parent 984200a69e
commit 6ee10d2f16
2 changed files with 18 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/rapports_pan2/module_hardware/TODO.md
View File

@@ -1,6 +1,6 @@
Truc a corriger sur le rapport
* Remplacer les screen par des vrai graphiques
* Ajouter des standard deviation aux graphiques
* Peut être ajouter des valeurs absolues sur les benchmark
* Regarder si utiliser un power saving mode sur le CPU est intéressant (température vs perofrmances)
* Dire que c'est pas du temps mais que ça nous convient
* XRemplacer les screen par des vrai graphiques
* XAjouter des standard deviation aux graphiques
* XPeut être ajouter des valeurs absolues sur les benchmark
* X Regarder si utiliser un power saving mode sur le CPU est intéressant (température vs perofrmances)
* X Dire que c'est pas du temps mais que ça nous convient

20
docs/rapports_pan2/module_hardware/rapport.md
View File

@@ -41,18 +41,19 @@ En parallèle firefox est ouvert pour afficher l'interface graphique de la borne
### Résultats
En réglant la camera a 640x480@30fps, aucune perte d'image n'est observée dans le retour vidéo dans firefox.
Mediapipe est capable d'analyser l'image de la camera et de communiquer les résultats à l'interface web 15 fois par seconde en moyenne
Nous avons observé la capacité de Mediapipe l'image de la camera et de la communiquer à l'interface web qui affiche le résultat.
Nous avons obtenu les résultats suivants
| CPU Schduler | FPS moyens | Ecart type |
|--------------|------------|------------|
| schedutil |10.4 | 1.4 |
| performance | 10.1 | 0.9 |
<img src="img/reconnaissance_fps.png">
Ce taux de rafraichissement est suffisant pour que l'application paraisse réactive à l'utilisateur.
Ce taux de rafraichissement est suffisant pour que l'application paraisse relativement réactive à l'utilisateur, bien que cela ne soit pas du temps réel.
Pendant ce temps l'api de traitement des avis et la base de donnée fonctionnent correctement en affichant une lattence de 8ms pour une récupération de la liste d'avis.
<img src="img/latence.png">
Pendance ce temps l'utilisation du processeur qui varie de 250 à 280% (sur 400% pour les 4 coeurs) et une utilisation de la RAM de 50% ce qui nous laisse de la marge en cas d'ajout imprévu.
<img src="img/htop.png">
Pendance ce temps l'utilisation du processeur qui varie de 250% à 280% (sur 400% pour les 4 coeurs) et une utilisation de la RAM de 50% (1.96Go) ce qui nous laisse de la marge en cas d'ajout imprévu.
Les processus utilisant le plus de CPU sont la reconaissance d'image (70%) et firefox pour afficher l'interface de la borne (70-80%). En cas de besoin ces valeurs pourront être diminuées au prix de la fluidité du retour vidéo.
Pour la RAM c'est le serveur mysql (10%) et firefox (10%) qui consomment le plus.
@@ -99,6 +100,11 @@ Les résultats de ce test on permis de conclure que l'impact de docker était n
<img src="img/benchmark.png" width=400>
| Type | CPU (Evts/s) | RAM (Mbi/s) | Disque lecture(Mbi/s) | Disque écriture (Mbi/s) |
|--------------|------------|------------|---|---|
| Normal | 613.14 | 3259.84 | 12.34 | 8.22 |
| Docker | 552.76 | 2794.21 |12.27 | 8.18 |
## Conclusion
Au vu des tests effectués le materiel dont nous disposons semble adapté à notre projet. Il est cependant possible de réduire l'utilisation faite de l'ordinateur embarqué dans la borne en déplaçant la partie stockage et traitement des avis sur un autre serveur. Pour l'instant cette possibilité n'est cependant pas envisagée par soucis de sécurité des données et car elle n'est pas nécessaire.