Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2767 connectés 

  FORUM HardWare.fr
  Programmation
  Divers

  MCU SIP en CUDA

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

MCU SIP en CUDA

n°1741803
simaril
Posté le 05-06-2008 à 11:29:50  profilanswer
 

Hello

 

Je pensais à un truc.

 

Dans les systèmes de communication (voix voire vidéo) moderne, il y a une fonction qui est extrêmement gourmande en ressource sur des grosses capacités, c'est la fonction MCU (conférence, conversion de codecs, etc...).

 

Comme ces traitement ne sont pas individuellement très complexes et que le problème de charge est principalement du au nombre de traitement simultanés, je me demandais si il ne serait pas possible de coder ces traitement en en CUDA pour les faire exécuter par un bon GPGPU (nvidia...).

 

Est-ce que ça ne permettrait pas d'augmenter considérablement la charge que serait capable de traiter un simple serveur?

 

merci


Message édité par simaril le 05-06-2008 à 11:31:21
mood
Publicité
Posté le 05-06-2008 à 11:29:50  profilanswer
 

n°1741806
Joel F
Real men use unique_ptr
Posté le 05-06-2008 à 11:31:40  profilanswer
 

CUDA : windows avec visual studio et sosu linux aussi sans problèmes.
après la limite première de cette approche provient du cout de transfert entre la carte et le CPU qui limite les perfs. Donc il faut vraiment que le traitement soit long.

n°1741850
simaril
Posté le 05-06-2008 à 12:05:26  profilanswer
 

"cout du transfert", tu veux dire la bande passante PCI express?

 

si c'est ca, pas d'inquiétude, parce que presque toutes les données proviendront du réseau... donc 1 Gbit/s max.
un flux G711, c'est  64 kbit/s au niveau applicatif, 78,4 kbits/s au niveau ethernet
un flux G723, c'est 6,3kbits/s au niveau applicatif, 20,8 kbits/s au niveau ethernet.

 

Une bonne MCU actuelle (Genesys Stream Manager, pour ceux qui connaissent) est capable de traiter 100 communications simultanées par CPU (core), soit, par exemple, 800 communications simultanées avec un  serveur double CPU quad cores.

 

soit au niveau Ethernet, dans le pire des cas (G711), 61 Mbits/s.... on est loin du gigabit de l'interface réseau et tres tres loin de la bande passante du PCI express 16x (4 Go/s)

 

en imaginant qu'on sature l'interface gigabit ethernet (et qu'on se contente d'une seule interface par serveur), on pourrait absorber jusqu'à 13374 communications simultanées (ou 50412 en G723).
Il faudrait donc réussir à multiplier la puissance de traitement du serveur par 16 ou 63 pour risquer de saturer l'interface réseau (facteur bien plus limitant que l'interface PCI express)... ca laisse déjà pas mal de marge, non?

 

je dis ça, j'y connais pas grand chose, hein...je n'ai qu'une vue très macroscopique des choses, mais il me semble quand même qu'il y a quelque chose d'intéressant à faire. Vous ne croyez pas?


Message édité par simaril le 05-06-2008 à 12:07:49
n°1742110
Joel F
Real men use unique_ptr
Posté le 05-06-2008 à 17:01:05  profilanswer
 

nana ^^ le problème est que la bande passante pratique du PCI express telle qu'accessible via CUDA est de l'ordre de 30 à 50% du max théorique [:dawa]
Mais bon c'est à mesurer ;) Aprés faut rester le plus longtemps possible sur la carte dans la memoire partagé histoire de bénéficier de la mémoire la plus rapide.

 

En gros, gain moyen sur une GPU à 128 shaders : entre 40 et 90. Faut aussi que ton probleme rentre bien dnas le modele stream computing


Message édité par Joel F le 05-06-2008 à 17:02:12
n°1742140
simaril
Posté le 05-06-2008 à 17:24:04  profilanswer
 

D'après les calculs que j'ai fait ci-dessus, meme 30% de la BP du PCI express suffiraient... même 10%, ca serait bon, il me semble...

 

bah.... mon problème c'est d'appliquer des fonctions basiques de traitement de signal sur un très grand nombre de flux
- pas mal de compression/décompression audio temps réel ,
- plus de la conférence, c'est à dire de l'addition de signaux (avec j'imagine une normalisation du volume ou une truc comme ça, pour qu'une conférence à 10 ne soit pas 10 fois plus bruyante qu'une communication téléphonique normale)
- et puis aussi de la détection de fréquences

 

J'imagine que c'est je genre de chose qui doit se faire assez bien avec un GPGPU, mais ce n'est effectivement qu'une supposition. comme je l'ai déjà dit, je n'y connais rien


Message édité par simaril le 05-06-2008 à 17:26:26
n°1742171
Joel F
Real men use unique_ptr
Posté le 05-06-2008 à 18:24:31  profilanswer
 

oui ca passera :) l'efficacité sera faible mais le gain substantiel


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  Divers

  MCU SIP en CUDA

 

Sujets relatifs
SIP SECURITE (EKIGA)3 Questions en une (Java J2EE et SIP Servlets)
comment integrer JAIN SIP et JCC à Java que j'ai déjà installer??Comment integrer JAIN SIP et JCC à Java que j'ai déjà installé?
le protocol SIPAPI de SIP
Application FLASH + SIPApplication SIP + Proxy SIP
Envoi de xml vers un téléphone SIPH323 vs SIP
Plus de sujets relatifs à : MCU SIP en CUDA


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR