Presentation of the 1st year Ph.D. students of the LIG

Ingénieur INSA Lyon, CIFRE CEA/ST, Andrej Duda

Cross layer Optimization in Energy Harvesting in Wireless Sensor Networks

• Propose a multi-MAC architecture to bring interoperability in harvesting
• Context = IoT growth -> development of a wide range of protocols, hence the need for interoperable protocols
• 2 approaches: over IP or application-level (best-connected)
• Greennet platform (ST): energy harvester solar panel. Currently porting the 802.15.4 E protocol with OpenWSN
• Wants to study the energy efficiency of several protocols (802.15.4, 802.15.4e, wifi, bluetooth…)
• Sets up a simple evaluation scenario (perfect channel, stationary, single user/channel, …)
• Presents early evaluation results. Needs to determine how the different technology react to a given workload to know how to compare them in term of energy. Wifi has a much better capacity but consumes way less.
• Future work:
  • Use a more realistic workload injection
  • Define new metrics
  • Complete the porting

• Uniquement de l'énergie solaire ? Est-ce que ça changerait quelque chose si on considérait d'autres types de récupération d'énergie.
  • Oui, uniquement ça pour greennet.
• Tu as comparé des protocoles. Pour l'énergie et l'efficacité, on voit bien le lien avec greennet mais ce sont en général des résultats connus?
• Slide "Capacity": ce sont des mesures ? C'est étonnament stable. Lis le Jain, ça t'apprendra à faire des courbes plus lisibles…
  • The evaluation is purely theoretical/analytical at the moment but the model is fed with measured or well-known values
• La forme de la courbe de la consommation énergétique qui diminue puis remonte est surprenante. Était-ce attendu ?
• Numérote tes slides

Ingénieur INSA Lyon, CIFRE ST, Andrej DUDA, in the context of the greennet platform

Quality of Service in Wireless Sensor Networks

• Greennet = photovoltaic cell + small coin cell battery + wide array of on-board sensors
• Wireless Sensor Networks: different network protocols and topology, synchronized or unsynchronized access policy, …
• Quality of Service: typical criteria = throughput, end-to-end delay
• Approach: Analytical comparison, simulation, experiment
• Network bootstrap : how to arrive from a set of independent nodes to a fully functioning network (discovery, synchronization, communication scheduling, …)
• Part of the thesis is devoted to energy consumption for point-to-point communication and also to the study of the bootstrap phase.

• Other criteria of interest in this context ? E.g., Jitter ?
  • Do not answer it is not worth of interest
• A question on the duty cycle due to a very misleading graph. Read the Jain.
• A question on what is exactly the subject of your PhD thesis. I wasn't completely sure myself in the end
• Your presentation as little too short 7 minutes compared instead of 10 minutes
• Number your slides

Thèse avec Andrej Duda

DataTweet: public service for opportunistic …

• Context: IoT growth, smartphone expension. Mobile users seen as a data source. Data tweet: communication protocol to fullfill interoperability lack à la twitter.
• Problem Analysis:
  • Huge underused wifi coverage (private access most of the time)
  • Internet providers have to provice a dedicated data channel
  • Pros: Wifi is more energy efficient than 3G/4G and is already deployed
  • Cons: Wifi is not built for mobility.
• Conduct a city wide wifi coverage
  • Validate the coverage hypothesis and estimate the mobility
  • Use Grenoble dataset and generate new ones
• Randomly generated path.
• Reactivity issue on the handover when there is mobility.
• Future work
  • Improve the handoff value model (analyze smartphone's scanning and associating process)
  • Extend to other cities
  • Use Bluetooth Low Energy as a side channel when there is a handover

• Always check the video before projecting…
• On peut pas faire du side channel wifi avec du wifi ?
  • A priori, il faut deux cartes…
• How did you get the access points datasets ?
  • Generate a number of access points depending on the area of the buildings.
  • Many approximations and hypothesis in the end but you're fully aware of them so it's fine.
• How do you generate the random path ?
  • Draw two random points in the area and uses Google maps for determining which path to use.
• Data-tweet = à l'origine mise en place de système de tweet mais finalement focalisé sur maintenir une connectivité forte.

Data optimization for linear algebra on many-core processor

Kalray, Bernard Tourancheau

• contexte: exascale
• 2 classical applications: BLAS and stencils (compact stencil PDE solvers)
• cache coherence; how and where
• 1st approach: Manycore as a stand-alone node
  • 16+1 MPI process: 1 process on each compute node
  • Made an MPI implementation:
    • implemented different communication approaches (eager send, lazy send, DMA, …)
• 2nd approach:
  • Port MAGMA CLBLAS to KALRAY
  • First results: 2.6 Gflops pour SGEMME et 1.3 pour DGEMM
  • Bad results because of bad blocking. Often concurren accesses to same memory block.
  • Kernels initially written for GPU, non optimal for manycore
• Benchmark:
  • Ran HPL on the MPPA
  • Limited size on the MPPA hence matrix size 1500x1500
  • Not very good performances but could gain 10% thanks to the eager MPI implementation
• Future work:
  • use DSM to increase memory space via I/O DDR
  • Extend MPI to multi-mppa
  • Tune block size to increase the Benchmark performance
• Article accepté à Parco sur la communication MPI sur MPPA.

• Regarding the performance plots (Many-core)
  • Ping-pong without any background load. How would contention be managed ? You should check this is indeed well managed.
• Stencil
• Are your looking at the energy consumption ?
• Link with BOAST for tuning tile size ? See Jean-François Méhaut for this.

• Stuxnet: virus visant à détruire des systèmes de contrôle commande (centrales d'enrichissement d'uranium)
• Cyberguerre: projet ARAMIS = développer un module pour analyser et sécuriser les communications au sein des systèmes de contrôle commande des grands réseaux et infrastructures.
• Rupture de protocole:
  • rajouter un module entre les communications client-serveur qui ajoute de la robustesse et permet d'inspecter le contenu des communications
  • l'idée est également de faire toutes les opérations liées au protocole pour ne récupérer que le contenu : par ex. extraire les payloads pour TCP
• Plusieurs couches de protocoles: TCP/ICP, SSH/TLS, Modbus/OPC-UA/FTP/SFTP
• Le serveur est en zone sensible et doit donc résister à des violations de protocole et à des attaques
• Analyse: lexicale/syntaxique,sémantique. Analyse sémantique faite à VERIMAG.
• Sécurisation niveau système: DEP/ASLR pour les dépassement de tampons, role-based access control, stack-smashing protector du compilateur, … L'ensemble de ces techniques est inclue dans un patch linux appelé grsecurity.
• Besoin de toute la toolchain pour recompiler pour ARMv7/FPGA.
• A passé pas mal de temps pour se mettre au parfum de toutes ces technologies.
• Un premier prototype destiné à filtrer des communications modbus a été développé.
• Future Work:
  • SYN proxy pour le flood
  • extension à d'autres protocoles que Modbus
  • multiplexage du serveur

• Évaluation de la fiabilité de l'approche. Des code monkey ? Jelena Mirkovic ? Vivien évoque un papier sur la détection de cheval de troye à ASLPLOS dans les systèmes distribués l'an dernier.
  • On va développer des cas tests qui viennent des industriels.
  • Je suis plus sur l'aspect sécurisation coté linux que sur les aspects attaque.
  • Au niveau du noyau, on ne peut que se limiter aux failles connues
  • De la même manière on met en place les contre-mesures connues pour empêcher, ou au moins limiter l'exploitation d'une vulnérabilité
  • De manière générale, des équipes travaillent à temps complet pour chercher des failles sur les noyaux et programmes, et les corriger leurs résultats sont intégrés au fur et à mesure dans les nouvelles versions du noyau
• Tu vérifies que le protocole est utilisé correctement. Mais pour le cas de stuxnet, ça dépasse le cadre du protocole. Ça peut se faire avec de la réplication du consensus, non ?
  • De mon côté je m'attache plus à éviter des requêtes qui pourraient faire planter le serveur, ou provoquer un DoS par non respect des protocoles pour ce qui est de savoir si une opération est légitime (par ex. accélerer une turbine pour stuxnet), on est dans la dimension sémantique (le sens de la commande) cette partie est vérifiée par les filtres centraux, qui sont développés dans le cadre d'une autre thèse à Verimag
• Vous allez évaluer l'overhead de ce type de technique ?
  • Les boites mettront les processeurs en plus s'il y a besoin.
  • Le but est quand même de faire une implémentation efficace (même si ça n'est pas une finalité de la thèse) car on a des timing assez serrés on projete d'évaluer l'overhead pour des aspects qui ne sont pas fondamentaux au projet (proxy transparent, SYN proxy) pour le reste (on peut parler d'overhead incompressible) on ajustera les performances matérielles pour coller aux timings

• Tu sembles avoir consacré pas mal de temps à travailler sur des aspects liés à la transparence. Avoir un proxy complètement transparent était une contrainte centrale du projet et pourquoi ?
  • Je n'y ai passé tant de temps que ça, c'est juste que je mets en avant une solution nouvelle par rapport à ce qui est fait actuellement ce n'est pas une contrainte centrale, mais elle offre plus de simplicité en terme de configuration : pour l'instant, on affecte à l'interface toutes les adresses des serveurs industriels avec cette solution, on a juste à configurer le routage dans le réseau industriel
• Tu évoques une plate-forme matérielle. Est-ce une contrainte ou plutôt une opportunité ? Ça pourrait être un PC lambda, non ?

Thèse co-tutelle Méhaut/Tchuente (LIG/Yaounde 1)

DSL pour la fouille des réseaux sociaux sur des plates-formes multi-coeur

• réseau social souvent modélisés par des graphes de faible densité
• Comment réduire le temps d'exécution ?
  • réponse = usage du parallélisme
• Prototypage en R ou python, réécriture en C/C++, parallélisation avec OpenMP/CUDA/MPI…
• Alternative: utiliser des DSL.
• Related work on DSL.
  • Green-Marl, DSL pour les graphes, parallelisme avec openMP
  • Galois
• Refaire un nouveau DSL ou bien étendre l'existant ?
  • Green-Marl semble le plus proche de notre objectif final donc c'est lui qu'on souhaite étendre.

• Question/réponse: réduire le temps d'exécution/parallélisme. C'est une réponse très bizarre. Avec ton introduction, le problème semble avant tout algorithmique avec des algorithmes qui devraient être à même de prendre en compte le caractère creux des données. Les physiciens qui font du maillage ont la même problématique.
  • Travail en collaboration avec des algorithmiciens de Paris qui vont utiliser ces DSLs. Et eux, leurs algorithmes sont creux.
• Il y a des gens à l'ENS Lyon qui travaillent sur les aspects grands graphes, quelle algorithmique pour les grands graphes creux (équipe d'Éric Fleury).
• Fait attention au texte en vert qui ressort super fluo et fait mal aux yeux… :)
• Je ne suis pas sûr que TeX/LaTeX/HTML soient les meilleurs exemples de DSL.

Next Generation State Machine Replication Protocols Among Data Centers.

PhD with Vivien Quema

• State Machine Replication:
  • Technique for fault tolerance. The same data and machine is replicated to improve reliability with strong consistency (deterministic and atomic execution of commands)
  • Clients access the nearest server
• Total Order Broadcast protocol
  • Main criteria = latency and broadcast
• State of the art:
  • Many already existing work.
  • Some have good properties in term of low latency and optimal throughput
• Goal of the PhD:
  • Can such algorithms work with multiple Data-Centers

• How do you plan to evaluate your proposals?
  • Plan to test on local LANs first and then on grids and amazon.
• How is the multiple Data-center changing the evaluation hypothesis:
  • Previous evaluations were made on LANs. Latency is very different.
  • Most articles are focused on LANs.

Thèse CEA/LIG, Vivien Quéma

Global optimizaion in heterogeneous many core systems

• Applications from embedded systems (vehicle, vision, …) with potentially heterogeneous architectures.
• Here, adapteva parallela, a many-code architecture
• Requirements in term of performance, battery life time, temperature (decreases lifetime and increases failures and energy leaking), lifetime.
• Task mapping and scheduling, DVFS, application QoS.
• Lack of
  • multi-objective optimization of energy/temperature/reliability
  • common implementation/evaluation (not suited to embedded manycore architectures)
  • well defined interfaces for accessing to measurements
• How to optimize energy/temperature/reliability for embedded many-core applications ?
• Design a framework (interfaces + resource manager)
• So far: related work, choose a platform (parallela vs. STHORM and chose rather STHORM), played with OpenCL, and selected a benchmark application (Lidar sensor fusion, a vehicular data fusion application)
• Future work:
  • application profiling, define a testing environment,

• Peut-il y avoir plusieurs applications qui tournent sur la plate-forme ?
  • On part sur seulement une application pour le moment mais on envisage plusieurs pour la suite.
• La plate-forme est hiérarchique. Le DVFS est global ou par ilots/clusters. Est-ce des leviers envisageables ?
  • Plus il y a de leviers, plus c'est difficile.
  • Éteindre complètement un ilot, parait délicat. Mais passer à un état low-power, pourquoi pas ?

Thèse Trystram/Dutot

Ordonnancement multi-critère efficace pour plates-formes à grande échelle.

• Context: HPC platforms
• Job submission and batch scheduling:
  • user-oriented criteria (average waiting time, bounded slowdown, …)
  • Total energy consumption
  • Power peak
• Needs online algorithms that can scale (low complexity)
• Limited knowledge of the jobs (uncertain job runtime, unknown resource usage)
• How to compare: simulation -> development of Batsim
  • Rely on a simulation framework
  • Strong separation of the scheduler and of the simulator, which allows to reuse existing scheduling implementations
• First results:
  • Assumption: hierarchical platform (clusters) and allocations have to be contiguous and local (have to fit within a cluster)
  • Imposing such constraints can reduce the solution space and degrade the solution
  • Funny plots in R with no legends… Read the Jain!
• Early conclusions:
  • Increased communication amount -> increased gain with locality constraints.
  • Paper submitted to HeteroPar
• Future work
  • Energy, IO, OAR, SLURM ?
  • New algorithms

• Tu parles d'OAR, l'objectif est de passer en production ?
  • Non, c'est plutôt l'inverse. On souhaite évaluer plus proprement les performances de l'existant (OAR).
• Tu disais que vous n'aviez pas commencé par l'énergie car c'était plus difficile. Tu peux développer ?
  • Au niveau théorique, il y beaucoup moins de résultats.
• Pas de retour vers la pratique, c'est pas un problème ?
  • Les simulateurs sont souvent peu réalistes, c'est déjà bien mieux que ce qui existe. Les comparaisons avec la réalité permettent d'augmenter la confiance qu'on peut avoir dans ce qu'on fait.