Recherche avancée

Sur d’autres sites (8184)

• Multiple nVidia GPU transcoding (NOT computing) bottleneck

  11 décembre 2018, par Daniel Cantarin

  I’m doing some nVidia multi-GPU testing. However, this tests are not on the computing field but transcoding, using nvenc/nvdec.

  I have a setup with 3 Quadro GPUs (max 4 on this motherboard), and running some transcoding jobs using ffmpeg.

  Thing is, up to 8 jobs everything is fine, with tolerable GPU and CPU stats.
  But when reaching the 9th job, the nVidia cards metrics start to fall down. Whats troublesome is this : it doesn’t matter the job distribution. That is, if I send 8 jobs to GPU0, and 1 job to GPU1, is the same as 4-5, or 4-4-1, or 0-4-5, etc.

  What I see beggining on the 9th job is :

  1. CPU gets to about 60% usage (30% up to 8th jobs) and doesn’t go up much after adding more jobs.
  2. DECODING metrics falls from about 75% (when single card has 8 jobs) to about 20%.
  3. Every card behaves the same when this problem starts, no matter how many jobs they have.

  And the last strange thing I see : when that problem happens, and I kill all the jobs, the cards keep working for a while (sometimes even minutes).

  All this points to some bottleneck somewhere on the motherboard. Maybe the PCIe bus, maybe some CPU subsystem, I’m not sure. It also points to some buffering happening somewhere. I’m using the usual popular tools to see high-level metrics and curves (top/htop, nvidia-smi, nvtop, etc).

  My question : does anybody knows some common bottlenecks regarding multi-GPU setups that could lead to a problem like this ?

  Any tip would be nice.

  Thanks in advance.

• Evolution #4148 : Augmenter la largeur de l’espace privé

  23 juin 2018, par tcharlss (*´_ゝ｀)

  Hop, j’ai pu tester un peu le remix (j’en ai profité pour piquer quelques trucs au passage ^^).

  1ère impression très sympa avec la largeur augmentée, la police plus grande, et les autres détails.
  Je ne vais commenter que ces 2 premiers points et le layout (ces 3 points étant liés), pour ne pas qu’on sorte du sujet du ticket.

  (...) pour que la colonne #extra soit sous la #navigation en dessous d’une certaine largeur, et qu’elle passe à droite au delà

  3 fois oui, comme ça le layout s’adapte à la largeur de l’écran. La colonne de droite peut avoir son utilité, c’est très bien qu’elle soit affichée quand il y a la place.
  Dans le trunk c’est sur ça que je suis parti.

  Toujours sur le layout, il y a un point qui me semble important, c’est qu’en absence de contenu dans une colonne, les autres doivent remplir l’espace libéré.
  Par exemple sur la page des articles, où on a une grande marge vide à gauche actuellement.
  Ça c’était la 2ème raison principale du plugin, et on a perdu ça dans le remix apparemment.
  La difficulté, c’est qu’on ne peut pas poser de taille directement sur une colonne #navigation ou #extra, car elles sont toujours présentes même si elles sont vides. Et même à coup de flex-shrink puissance 10, c’est très compliqué d’avoir la main sur leur taille du coup.
  J’ai contourné le problème en posant la largeur sur le contenu direct de ces colonnes , jusqu’à présent je n’ai pas constaté de dommage collatéral :
  

  #navigation > .ajaxbloc > *,
  #navigation > :not(.ajaxbloc),
  #extra > .ajaxbloc > *,
  #extra > :not(.ajaxbloc) 
        width : calc(8em + 12vw) ;
  
  

  La taille de police augmentée, très bien, c’est plus lisible et agréable.
  Je pense qu’elle pourrait être un brin responsive, c’est à dire partir d’une base un peu moins grande et augmenter proportionnellement à la largeur de l’écran.
  Dans le trunk je teste cette règle qui donne 14px à la base, et 15px en 1920px par ex. : font-size: calc(0.8em + 0.133vw);
  Un dommage collatéral quand même : on perd un peu de la place libérée avec la nouvelle largeur, mais c’est un mal nécessaire.

  Et donc j’en viens au truc principal : la largeur.
  Bon, si on part sur du 1200px, ce sera déjà une bonne avancée, je ne vais pas me plaindre. Allez, tant qu’à faire on peut pousser vers 1400px ?

  Mais d’une façon générale, je reste persuadé qu’à terme, la pleine largeur est la meilleure option pour une interface (et là je peux reprendre la citation de Coluche à mon compte si j’ai bien compris ?).
  C’est du coup un peu plus compliqué que de mettre un witdh: 100% au conteneur général d’un coup de baguette magique, en fait il y a finalement pas mal de choses concomitantes à régler (plus que ce que j’imaginais à la base).
  Notamment la taille de la police, en augmentant comme dans le remix de nicod_, c’est déjà beaucoup plus équilibré.
  Après d’une façon générale, il faut que cette largeur soit bien exploitée. Là on part d’une interface où les contenus ont été pensés pour rentrer dans du 780px de large, donc forcément au départ il y aurait des choses un peu bancales, quelques pages déséquilibrées. Mais dans l’ensemble je suis sûr qu’on y gagnerait à terme et ça poserait les bases pour la suite.

  Enfin, il y a un point que je veux souligner, parceque je ne suis pas du tout d’accord avec certaines remarques : la proposition de pleine largeur n’est pas une préférence esthétique, c’est un besoin imposé par le contenu.
  C’est ça la demande à la base pour ce ticket, le but est de parvenir à « faire rentrer » du contenu qu’il est difficile de placer actuellement.
  Ne pas en avoir « l’utilité » personnellement certes, mais il y a tout un écosystème de plugins avec des besoins divers pour lesquels ça devient nécessaire.

• Anomalie #4235 (Nouveau) : un cache sessionné contamine les caches non sessionnés suivant

  28 novembre 2018, par jluc -

  Dans une suite d’inclusion dynamique de squelettes, si l’un d’entre eux est sessionné, tous les squelettes suivants seront compilés comme sessionnés.

  Jeu de test :

  Squelette principal :
  

  <span class="CodeRay"><span class="tag">span><span class="error">{</span><span class="attribute-name">fond</span>=<span class="attribute-value">inclure</span><span class="error">/</span><span class="attribute-name">shouldbesafe</span><span class="error">}</span><span class="tag">></span>
  
  <span class="tag">span><span class="error">{</span><span class="attribute-name">fond</span>=<span class="attribute-value">inclure</span><span class="error">/</span><span class="attribute-name">contaminant</span><span class="error">}</span><span class="tag">></span>
  
  <span class="tag">span><span class="error">{</span><span class="attribute-name">fond</span>=<span class="attribute-value">inclure</span><span class="error">/</span><span class="attribute-name">shouldbesafetoo</span><span class="error">}</span><span class="tag">></span>
  
  </span></span></span></span>

  noisette inclure/shouldbesafe :
  

  <span class="CodeRay">HMMM ici ça devrait pas être sessionné !</span>

  noisette inclure/contaminant :
  

  <span class="CodeRay">Vous êtes #SESSION{nom}
  
  </span>

  noisette inclure/shouldbesafetoo :
  

  <span class="CodeRay">HMMMNNNNNN ici ça devrait pas être sessionné NON PLUS !</span>

  On constate que shouldbesafe est non sessionné et que contaminant est sessionné comme ils se doivent,
  mais que shouldbesafetoo est sessionné alors qu’il devrait ne pas l’être.
  Si on supprime l’inclusion de contaminant, shouldbesafetoo n’est pas sessionné.

  Càd que la compilation de contaminant "contamine" le compilateur qui "contamine" shouldbesafetoo.

  Dans le compilateur, c’est $GLOBALS[’cache_utilise_session’] qui propage la nécessité de sessionner. Dans la fonction evaluer_fond, il est indiqué "il faut bien lever ce drapeau après avoir evalué le fond pour ne pas faire descendre le flag vers les inclusions appelees" : il semble que ça ne soit pas correctement fait dans tous les cas.