Le Forum de l'Alliance Francophone

Nouvelles:

Auteur Sujet: PrimeGrid  (Lu 581951 fois)

fzs600 et 2 Invités sur ce sujet

Hors ligne GuL

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 2225
  •   
Réponse #2325 le: 10 November 2018 à 09:11
Je préfère libérer un thread par GPU dans les préférences locales et fixer 0.05 cpu dans le app_config pour forcer le système à conserver un thread libre pour le GPU quoi qu'il arrive. Avec la configuration par défault:
  • si le projet GPU prévoit moins de 1 CPU, il ne libérera pas un thread et le GPU n'aura pas assez à manger
  • si un projet VM demande tous les CPU, il utilisera y compris celui réservé par le GPU
  • idem si un projet passe en haute priorité



Hors ligne JeromeC

  • CàA
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 31106
  •   
Réponse #2326 le: 10 November 2018 à 10:01
"libérer un thread par GPU dans les préférences locales" tu veux dire mettre x% d'utilisation CPU c'est ça ?

Et je suis désolé mais je comprends pas bien ton dernier message Gul, tu pourrais pas expliquer plus longtemps et surtout plus fort ? :siflotte:

"si le projet GPU prévoit moins de 1 CPU, il ne libérera pas un thread et le GPU n'aura pas assez à manger" : c'est à dire que dans le développement de l'appli GPU ils ont "réservé" l'utilisation de thread CPU "jusqu'à un certain point" ? et en quoi la configuration que tu recommandes aide en ça ?  en se basant juste sur le fichier config ?

"si un projet VM demande tous les CPU, il utilisera y compris celui réservé par le GPU" : tu veux dire "si tu ne réserves pas un CPU dans les pref locales" ?

"idem si un projet passe en haute priorité" : j'ai déjà remarqué que les hautes priorités font souvent faire des bêtises à boinc, par exemple j'ai une tâche LHC en VM multithread (que j'ai limité à 6 cores via les prefs projet, ça marche bien) et j'ai 4 tâches SRBase en priorité (des long2, j'arrive jamais à les finir, là elles ont déjà dépassé la deadline après plus de 3 jours de calcul), soit 10 threads théoriques alors que j'en ai 8 :) Et donc en quoi ton réglage y change quelque chose ? 

A quoi bon prendre la vie au sérieux, puisque de toute façon nous n’en sortirons pas vivants ? (Alphonse Allais)



Hors ligne JeromeC

  • CàA
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 31106
  •   
Réponse #2327 le: 10 November 2018 à 12:15
Sinon dans la suite des nombreuses discussion sur le forum de PG au sujet de la décision du "crypto-blocage", il faut voir que l'admin qui a décidé cela et est beaucoup intervenu dans ce topic pour expliquer (pas pour se justifier) a à diverses reprises défendus les crunchers de GC eux même, et ce post clarifie bien je trouve la situation :

Citer
(un gars intervient)
Citer
    Je trouve cela malheureux, mais c'est à chaque projet de faire ce qu'il veut.

    Je n'aime pas la description de "DDOS Attack" cependant, Gridcoin n'est pas une entité unique, c'est une collection d'individus, des individus téléchargeaient des statistiques dans le but d'accéder aux statistiques, pas pour causer une attaque. Il se trouve que le concept de décentralisation est d'une importance cruciale dans la cryptocurrency, pour arrêter de tricher comme il se produit.
(et l'admin répond)

En fait, dans ce cas, il s'agissait d'une attaque DDOS coordonnée par une seule entité. Encore une fois, ce n'était pas intentionnel, mais c'était quand même une attaque coordonnée. Le "réseau neuronal" de Gridcoin a été conçu de manière à ce que tous les ordinateurs puissent accéder aux statistiques en même temps. Ce n'était pas "chacun agissant seul". C'était, littéralement, "chacun agissant comme un seul homme".

Pour être clair, la faute incombe aux personnes (programmeurs) qui ont conçu le système Gridcoin, et non aux utilisateurs. Les utilisateurs sont 100% irréprochables.

Je ne pense pas comme lui que les utilisateurs soient 100% irréprochables, je pense que à tort (1) ou à raison (2) un petit % d'individus essaye de contourner le système à leur profit en méprisant l'intérêt du système lui même (pour les autres crunchers, pour la recherche scientifique), sachant que s'ils existent ces membres là ne viennent pas en faire la publicité sur les forums publics...

D'un autre côté je pense qu'il a raison de dire ça, il ne veut pas se mettre à dos tous ces utilisateurs - y'en a ptet qui auront envie de cruncher pour PG en dehors de GC, aussi :)


(1) car inutile, tous les membres de GC qui interviennent disent que les gains ne couvrent même pas les coûts de l'électricité, c'est juste pour eux une "petite compensation"

(2) car un vrai gain potentiel pourrait en être tiré si on est assez "malin"
« Modifié: 10 November 2018 à 12:18 par JeromeC »

A quoi bon prendre la vie au sérieux, puisque de toute façon nous n’en sortirons pas vivants ? (Alphonse Allais)



Hors ligne [AF] fansyl

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 2397
  •   
Réponse #2328 le: 10 November 2018 à 12:48
Le problème de yoyo a t'il disparu ?

Oui avec 2 tâches en // le GPU est chargé 100% en permanence, la contre-partie est que ma 970 Strix consomme 130W selon HWinfo.

L'ensemble de mes GPU devrait sortir 1M de points pour le sprint FB.

 :hello:

Je crunche dans le silence et c'est ma joie !
Ryzen 1700X/32Go/GTX970 (sous WC) - i7-3770T/16Go/HD4000 - Ryzen 5700G/32Go/GTX1050 - Q9550/8Go/GT1030 - 3xAndroidBox S912



Hors ligne GuL

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 2225
  •   
Réponse #2329 le: 10 November 2018 à 14:17
Décidément, c'est un sujet qui est difficile à comprendre, vu que nous en avons déjà parlé à plusieurs reprises. Mais je ne te jette pas la pierre, c'est sûrement moi qui explique mal.  cocoricooo

Introducion
On va partir sur l'hypothèse d'un CPU avec 8 threads plus un GPU. Pour que le GPU ait suffisamment de travail, il faut qu'un thread CPU lui soit réservé. Même si le GPU n'utilise le CPU que par pic, il faut qu'il soit accessible dès que le GPU en a besoin pour éviter les creux d'utilisation. On va étudier trois configurations (default, app_config seul, app_config + préférences locales) et trois modes possibles (normal, haute priorité, machine virtuelle multi-thread).

A) Première configuration: default. On n'a fait aucune modification dans les fichiers de configuration et 100 % du CPU est dédié à Boinc dans les préférences locales.
1) Mode normal
Le GPU réclame 0.89 CPU (c'est un exemple), ce qui est inférieure à 1. Boinc ne connaissant que les valeurs entières de threads, il va lancer 8 tâches CPU plus une tâche GPU. Le GPU n'aura que les miettes du temps CPU et des trous de calcul seront présents.
2) Mode haute priorité
Une tâche passe en haute priorité et passe devant toutes les autres. Une tâche CPU s'arrête pour lui laisser sa place (comme quand on se lève dans le métro face à une personne âgée  ;) ). La tâche GPU continue à tourner avec moins de miettes de temps CPU que dans le cas A1.
3) Mode machine virtuelle multi-thread
La tâche demande le nombre maximum de threads disponibles, soit 8. Ce mode est équivalent au mode haute priorité pour tous les threads à la fois. Le GPU n'a presque plus de temps CPU et se tourne les puces.

B) Deuxième configuration: fichier app_config. Les préférences locales conservent 100 % du CPU dédié à Boinc. Un fichier app_config.xml a été ajouté dans le dossier de tous les projets GPU, avec pour chaque application concernée une section comportant, entre autres:
Citer
        <gpu_versions>
            <gpu_usage>1</gpu_usage>
            <cpu_usage>1</cpu_usage>
        </gpu_versions>
1) Mode normal
Le GPU réclame 1 CPU. Boinc va lancer 7 tâches CPU et réserver un thread CPU pour la tâche GPU. Le GPU sera suffisamment alimenté et n'aura pas de trous de calculs.
2) Mode haute priorité
Une tâche passe en haute priorité devant toutes les autres, y compris la tâche GPU. Cette dernière peut potentiellement repasser dans le cas A2.
3) Mode machine virtuelle multi-thread
La tâche demande le nombre maximum de threads disponibles, soit 8. C'est identique au cas A3 et le GPU se tourne les puces.


C) Troisième configuration: fichier app_config et préférences locales. Les préférences locales sont modifiées pour ne dédier que 87.5 % du CPU à Boinc, soit n-1 threads (7/8*100=87.5). Un fichier app_config.xml a été ajouté dans le dossier de tous les projets GPU, avec pour chaque application concernée une section comportant, entre autres:
Citer
        <gpu_versions>
            <gpu_usage>1</gpu_usage>
            <cpu_usage>0.05</cpu_usage>
        </gpu_versions>
1) Mode normal
Le GPU réclame 0.05 CPU. Il n'aura pas de thread supplémentaire attribué par Boinc, mais ce n'est pas grave puisque un thread est libre dans les préférences. Boinc va lancer 7 tâches CPU et une tâches GPU, qui bénéficiera des 12.5 % restant.  Le GPU sera suffisamment alimenté et n'aura pas de trous de calculs.
2) Mode haute priorité
Une tâche passe en haute priorité devant toute les autres, mais cela ne change rien pour le GPU qui n'a pas de temps CPU attribué par Boinc.
3) Mode machine virtuelle multi-thread
La tâche demande le nombre maximum de threads disponibles, soit seulement 7. Cela ne change rien non plus pour le GPU qui bénéficie toujours des 12.5 % restant du CPU. Il sera peut-être juste un peu ralenti à cause de la mémoire cache du CPU.

Conclusion
Comme on l'a vu ci-dessus, le GPU est impacté en permanence dans la configuration A. Dans la configuration B, des problèmes apparaissent dès qu'une tâche demande la priorité ou avec une VM multi-thread. Il n'y a que dans la configuration C que le GPU sera le moins impacté par les autres tâches. C'est celle que je préconise. En complément, il est possible de faire tourner deux tâches simultanées sur le GPU avec l'option <gpu_usage>0.5</gpu_usage> (1/2=0.5)



Hors ligne Maeda

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 2470
  •   
Réponse #2330 le: 10 November 2018 à 16:28
Alors pourquoi si je mets 99% CPU, Boinc stoppe immédiatement le 8ème calcul CPU, et mon GPU ayant besoin de 0.08CPU ne met pas plus de temps à faire sa tâche qu'avec 100% de CPU ? A cause du faible taux CPU dont il a besoin ?


Hors ligne DocPhilou1966

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 1869
  •   
    • Mon Job
    • E-mail
Réponse #2331 le: 10 November 2018 à 17:15
 :hello:

ça tente quelqu'un un petit challenge interne sur Primegrid ?

Pas un challenge basé sur les crédits mais pour le fun (d'essayer) de trouver des nombres premiers.

GFN 17, 17MEGA voire 18 et PPS, PPSE ?, PMPS

Après avoir crunché à fonds sur RakeSearch et PPS Sieve, suis bien tenté faire tourner les 2 SHADOW et mes GTX la dessus.

 :hello: :jap: :kookoo:


« Modifié: 10 November 2018 à 17:17 par DocPhilou1966 »

 
13800346^131072+1   935,840 (decimal)   2019-01-27 Generalized Fermat Prime Search


Hors ligne GuL

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 2225
  •   
Réponse #2332 le: 10 November 2018 à 17:36
Alors pourquoi si je mets 99% CPU, Boinc stoppe immédiatement le 8ème calcul CPU, et mon GPU ayant besoin de 0.08CPU ne met pas plus de temps à faire sa tâche qu'avec 100% de CPU ? A cause du faible taux CPU dont il a besoin ?
Parce que dans les préférences locales, Boinc arrondit au thread inférieur, ce qui équivaut à 87.5% soit 7 threads. Dit autrement, il n'a pas le droit d'utiliser plus que 99 % et ne peut donc pas utiliser le dernier thread.



Hors ligne [AF>Libristes] Pascal

  • CàA
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 2413
  •   
    • Forum de la M-T Libristes de L'AF
    • E-mail
Réponse #2333 le: 10 November 2018 à 17:46
Alors pourquoi si je mets 99% CPU, Boinc stoppe immédiatement le 8ème calcul CPU, et mon GPU ayant besoin de 0.08CPU ne met pas plus de temps à faire sa tâche qu'avec 100% de CPU ? A cause du faible taux CPU dont il a besoin ?
GuL fait une généralité avec un OS particulier soit Win.

Sur GNU/Linux cela ne fonctionne pas comme expliqué.

Les tâches CPU BOINC ont une priorité la plus faible qui soit (NICE à 19) alors que les tâches GPU ont une priorité un peu plus élevée (NICE à 10). Un programme classique de bureautique, de musique ou autres a un NICE à 0.
Les interruptions, certaines tâches système ont une priorité maximale avec un NICE à -20.

Cela étant dit, lorsqu'une tâche GPU a besoin de ressources CPU elle le prend sur les tâches CPU si nécessaire. Afin que les tâches CPU tournent avec un maximum de ressources il est conseillé dans le app_config.xml du projet GPU de réserver pour le GPU plus ou moins de cores CPU en fonction du nombre de tâches GPU qu'on veut faire exécuter simultanément.


PC ; GNU/Linux ubuntu-mate 20.04 LTS (focal) - AMD FX8350 x8 - 32Go DDR3 - GTX 1060 et GTX 1080 Ti
Raspberry Pi : RaspBian (dérivé de Debian Wheezy) - ARMv6 - carte flash SD 8Go


Hors ligne JeromeC

  • CàA
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 31106
  •   
Réponse #2334 le: 10 November 2018 à 18:34
Bcp de super explications que j'ai pas le temps de lire maintenant ! Un modo peut-il créer un nouveau sujet dans la section des tuto appelé  "cohabitation multi-CPU et GPU" ou quelque chose du genre et déplacer le super post de Gul et les réponses s'y rattachant dessous (mais attention pas tout ça reparle de PG), car ça serait vraiment dommage de laisser ça se noyer dans le topic PG...

:jap:

A quoi bon prendre la vie au sérieux, puisque de toute façon nous n’en sortirons pas vivants ? (Alphonse Allais)



Hors ligne Maeda

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 2470
  •   
Réponse #2335 le: 10 November 2018 à 19:41
:hello:

ça tente quelqu'un un petit challenge interne sur Primegrid ?

Pas un challenge basé sur les crédits mais pour le fun (d'essayer) de trouver des nombres premiers.

GFN 17, 17MEGA voire 18 et PPS, PPSE ?, PMPS

Après avoir crunché à fonds sur RakeSearch et PPS Sieve, suis bien tenté faire tourner les 2 SHADOW et mes GTX la dessus.

 :hello: :jap: :kookoo:
Pourquoi pas, n'ayant jamais trouvé de nombre premier, ce serait l'occasion (même si "petit GPU"), on se sait jamais, il suffit d'une fois (comme au Loto) ! Il faudrait vérifier sur les forums PG, je crois qu'il y a des sous-projets qui ont plus de facilité à en trouver. Ce serait sur combien de temps ?

[AF>Libristes] Pascal> Compris !
« Modifié: 10 November 2018 à 19:43 par Maeda »



Hors ligne Matt11

  • Boinc'eur Respectable
  • ****
  • Messages: 686
  •   
Réponse #2336 le: 10 November 2018 à 20:27
Sur primegrid on trouve des "grands" nombres premiers uniquement avec les appli CPU (ou alors avec les GFN) et plus les UT sont courtes plus la proba de trouver un nombre premier est grand. Donc les projets PPS, PPSE, MEGA et SGS sont les plus susceptibles de "générer" des découvertes de nombres premiers.

Pour info j'avais écrit ça il y a quelques temps : https://forum.boinc-af.org/index.php/topic,6270.msg396082.html#msg396082

La partie "Probabilité de trouver un nombre premier" explique qu'on a, à peu près, autant de chance de trouver un grands nombre premier que de gagner au loto (sauf qu'avec primegrid ça coûte moins cher de jouer).


Ubuntu Mate 18.04  Intel core i7 6700K 4x4.0GHz 16Gb Nvidia Geforce GTX 1070


Hors ligne Maeda

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 2470
  •   
Réponse #2337 le: 10 November 2018 à 21:25
J'ai fait une bonne estimation :siflotte:.
Au passage, merci pour les infos, en français ça reste plus simple à comprendre :jap:


Hors ligne DocPhilou1966

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 1869
  •   
    • Mon Job
    • E-mail
Réponse #2338 le: 10 November 2018 à 21:27
Sur primegrid on trouve des "grands" nombres premiers uniquement avec les appli CPU (ou alors avec les GFN) et plus les UT sont courtes plus la proba de trouver un nombre premier est grand. Donc les projets PPS, PPSE, MEGA et SGS sont les plus susceptibles de "générer" des découvertes de nombres premiers.

Pour info j'avais écrit ça il y a quelques temps : https://forum.boinc-af.org/index.php/topic,6270.msg396082.html#msg396082

La partie "Probabilité de trouver un nombre premier" explique qu'on a, à peu près, autant de chance de trouver un grands nombre premier que de gagner au loto (sauf qu'avec primegrid ça coûte moins cher de jouer).
:plusun:

Perso je ne ferai pas de SGS qui n'est malheureusement plus dans le TOP5000 ...
Et en GPU, GFN 17 et 17MEGA
CPU : PPSE : j'en ai "trouvé" 1 seul => tenté par PPSE et PPS. Peut-être MEGA.

Par contre, il faut mieux les faire tourner en MultiThreads. Ça va plus vite et le CPU chauffe un peu moins.
Je regrette qu'ils ne laissent pas les utilisateur choisir entre SSE2, SSE3, AVX, AVX2, FMA3, ...

P.ex:

<app_config>


   <app>
      <name>llrPPSE</name>
      <fraction_done_exact/>
      <max_concurrent>1</max_concurrent>
    </app>
   <app_version>
       <app_name>llrPPSE</app_name>
       <cmdline>-t 7</cmdline>
       <avg_ncpus>7</avg_ncpus>
   </app_version>

<app>
      <name>llrPPS</name>
      <fraction_done_exact/>
      <max_concurrent>1</max_concurrent>
    </app>
   <app_version>
       <app_name>llrPPS</app_name>
       <cmdline>-t 7</cmdline>
       <avg_ncpus>7</avg_ncpus>
   </app_version>

<app>
      <name>llrMEGA</name>
      <fraction_done_exact/>
      <max_concurrent>1</max_concurrent>
    </app>
   <app_version>
       <app_name>llrMEGA</app_name>
       <cmdline>-t 7</cmdline>
       <avg_ncpus>7</avg_ncpus>
   </app_version>
</app_config>

 
13800346^131072+1   935,840 (decimal)   2019-01-27 Generalized Fermat Prime Search


naz

  • Invité
Réponse #2339 le: 10 November 2018 à 22:30
Sur primegrid on trouve des "grands" nombres premiers uniquement avec les appli CPU (ou alors avec les GFN) et plus les UT sont courtes plus la proba de trouver un nombre premier est grand. Donc les projets PPS, PPSE, MEGA et SGS sont les plus susceptibles de "générer" des découvertes de nombres premiers.

Pour info j'avais écrit ça il y a quelques temps : https://forum.boinc-af.org/index.php/topic,6270.msg396082.html#msg396082

La partie "Probabilité de trouver un nombre premier" explique qu'on a, à peu près, autant de chance de trouver un grands nombre premier que de gagner au loto (sauf qu'avec primegrid ça coûte moins cher de jouer).


Super boulot ton topic Matt11  :jap:



Hors ligne GuL

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 2225
  •   
Réponse #2340 le: 11 November 2018 à 10:45
Sur GNU/Linux cela ne fonctionne pas comme expliqué.

Les tâches CPU BOINC ont une priorité la plus faible qui soit (NICE à 19) alors que les tâches GPU ont une priorité un peu plus élevée (NICE à 10). Un programme classique de bureautique, de musique ou autres a un NICE à 0.
Les interruptions, certaines tâches système ont une priorité maximale avec un NICE à -20.
Merci pour ces précisions sur les niveaux de priorité sous linux.

@Matt11
Très intéressant

@DocPhilou
Merci pour l'astuce sur le multithreads. Du coup, je propose ci-dessous un fichier app_config qui configure à la fois les tâches GPU deux par deux et les tâches CPU multithreads, pour une machine avec 7 threads CPU et un thread réservé pour le GPU, dans les préférences locales.
<app_config>
    <!-- GPU applications -->
    <app>
        <name>pps_sr2sieve</name>
        <gpu_versions>
            <gpu_usage>0.5</gpu_usage>
            <cpu_usage>0.05</cpu_usage>
        </gpu_versions>
    </app>
    <app>
        <name>genefer15</name>
        <gpu_versions>
            <gpu_usage>0.5</gpu_usage>
            <cpu_usage>0.05</cpu_usage>
        </gpu_versions>
    </app>
   
    <!-- CPU multithreaded applications -->
    <app_version>
        <app_name>llr321</app_name>
        <cmdline>-t 7</cmdline>
        <avg_ncpus>7</avg_ncpus>
    </app_version>
    <app_version>
        <app_name>llrCUL</app_name>
        <cmdline>-t 7</cmdline>
        <avg_ncpus>7</avg_ncpus>
    </app_version>
    <app_version>
        <app_name>llrESP</app_name>
        <cmdline>-t 7</cmdline>
        <avg_ncpus>7</avg_ncpus>
    </app_version>
    <app_version>
        <app_name>llrGCW</app_name>
        <cmdline>-t 7</cmdline>
        <avg_ncpus>7</avg_ncpus>
    </app_version>
    <app_version>
        <app_name>llrMEGA</app_name>
        <cmdline>-t 7</cmdline>
        <avg_ncpus>7</avg_ncpus>
    </app_version>
    <app_version>
        <app_name>llrPPS</app_name>
        <cmdline>-t 7</cmdline>
        <avg_ncpus>7</avg_ncpus>
    </app_version>
    <app_version>
        <app_name>llrPPSE</app_name>
        <cmdline>-t 7</cmdline>
        <avg_ncpus>7</avg_ncpus>
    </app_version>
    <app_version>
        <app_name>llrPSP</app_name>
        <cmdline>-t 7</cmdline>
        <avg_ncpus>7</avg_ncpus>
    </app_version>
    <app_version>
        <app_name>llrSOB</app_name>
        <cmdline>-t 7</cmdline>
        <avg_ncpus>7</avg_ncpus>
    </app_version>
    <app_version>
        <app_name>llrSR5</app_name>
        <cmdline>-t 7</cmdline>
        <avg_ncpus>7</avg_ncpus>
    </app_version>
    <app_version>
        <app_name>llrTPS</app_name>
        <cmdline>-t 7</cmdline>
        <avg_ncpus>7</avg_ncpus>
    </app_version>
    <app_version>
        <app_name>llrTRP</app_name>
        <cmdline>-t 7</cmdline>
        <avg_ncpus>7</avg_ncpus>
    </app_version>
    <app_version>
        <app_name>llrWOO</app_name>
        <cmdline>-t 7</cmdline>
        <avg_ncpus>7</avg_ncpus>
    </app_version>
</app_config>

edit : 4-->7 threads
« Modifié: 11 November 2018 à 19:11 par GuL »



Hors ligne DocPhilou1966

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 1869
  •   
    • Mon Job
    • E-mail
Réponse #2341 le: 11 November 2018 à 11:48
 :plusun:

Je laisse PPS Sieve jusque ce soir, et après en route pour 2 ou 3 semaines de recherches GFN et PPSllr

 :hello: :kookoo:

 
13800346^131072+1   935,840 (decimal)   2019-01-27 Generalized Fermat Prime Search


Hors ligne DocPhilou1966

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 1869
  •   
    • Mon Job
    • E-mail
Réponse #2342 le: 11 November 2018 à 12:23
@GuL : me suis décidé à essayer 2 UT's en //
Et ben en fait ... c'est plutôt pas mal !

Quadro P5000 SHADOW : 1 UT = 310 secs - 2 UT's en // = 485 secs
GTX 1080 SHADOW : 1 UT = 315 secs - 2 UT's en // = 460 secs
GTX 1080 Physique chez moi : 1 UT = 290 secs - 2 UT's en // = 440 secs

Pas loin de 20 % de mieux  :hyperbon:

 :hello: :kookoo:

 
13800346^131072+1   935,840 (decimal)   2019-01-27 Generalized Fermat Prime Search


Hors ligne toTOW

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 4518
  •   
    • FAH-Addict.net
    • E-mail
Réponse #2343 le: 11 November 2018 à 13:42
Il faudrait comparer les fréquences de fonctionnement réelles de chaque carte dans chaque cas ...

FAH-Addict, première source d'information francophone sur le projet Folding@Home.


Hors ligne zelandonii

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 5123
  •   
Réponse #2344 le: 11 November 2018 à 15:16
Suis-je le seul a avoir des tas d'UT en erreur depuis quelques jours?





"Le monde est trop dangereux pour qu'on y vive, non pas à cause des gens qui font le mal, mais à cause de ceux qui les laissent faire sans réagir."  Albert Einstein.


Hors ligne DocPhilou1966

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 1869
  •   
    • Mon Job
    • E-mail
Réponse #2345 le: 11 November 2018 à 15:30
Suis-je le seul a avoir des tas d'UT en erreur depuis quelques jours?
Sur quelle(s) appli(s) ?

 
13800346^131072+1   935,840 (decimal)   2019-01-27 Generalized Fermat Prime Search


Hors ligne Oncle Bob

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 5342
  •   
Réponse #2346 le: 11 November 2018 à 17:52
C'est quoi le fichier à modifier pour app_config et faire tourner 2 UT en même temps ? account_www.primegrid.com.xml ?

Edith : Ah non, c'est un fichier à créer ex-nihilo dans le dossier primegrid :o
« Modifié: 11 November 2018 à 17:58 par Oncle Bob »

Boincstat
Projets du moment
Config principale : i7 2600K@4,2 GHz / 32 Go@1333 MHz / GTX 970 (Win 10)
Crunchbox passives : i7-4785T / 8 Go@1600 MHz / Akasa Euler S (Debian) || i3-4130T / 4 Go@1600 MHz / Akasa Euler (Debian)
ARM : 1*S922 + 1*H3
Boinc@Raspberry Pi | Boinc et Linux | Date fin de projets


Hors ligne GuL

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 2225
  •   
Réponse #2347 le: 11 November 2018 à 18:52
@GuL : me suis décidé à essayer 2 UT's en //
Et ben en fait ... c'est plutôt pas mal !
Pas loin de 20 % de mieux  :hyperbon:
Cool !  :hyperbon:

C'est quoi le fichier à modifier pour app_config et faire tourner 2 UT en même temps ? account_www.primegrid.com.xml ?

Edith : Ah non, c'est un fichier à créer ex-nihilo dans le dossier primegrid :o
Oui c'est ça, c'est un fichier à créer dans le répertoire primegrid, avec le contenu mis plus haut, en faisant bien attention à ce que notepad n'ait pas conservé l'extension .txt.



Hors ligne [AF>Libristes] Pascal

  • CàA
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 2413
  •   
    • Forum de la M-T Libristes de L'AF
    • E-mail
Réponse #2348 le: 11 November 2018 à 19:21
C'est quoi le fichier à modifier pour app_config et faire tourner 2 UT en même temps ? account_www.primegrid.com.xml ?

Edith : Ah non, c'est un fichier à créer ex-nihilo dans le dossier primegrid :o
C'est un fichier à créer dans le répertoire du projet.
Il doit s'appeler app_config.xml et contenir les lignes citées par DocPhilou.

N'efface surtout pas ton fichier account_www.primegrid.com.xml


PC ; GNU/Linux ubuntu-mate 20.04 LTS (focal) - AMD FX8350 x8 - 32Go DDR3 - GTX 1060 et GTX 1080 Ti
Raspberry Pi : RaspBian (dérivé de Debian Wheezy) - ARMv6 - carte flash SD 8Go


Hors ligne zelandonii

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 5123
  •   
Réponse #2349 le: 11 November 2018 à 20:26
Suis-je le seul a avoir des tas d'UT en erreur depuis quelques jours?
Sur quelle(s) appli(s) ?

Je te dirai ça demain.





"Le monde est trop dangereux pour qu'on y vive, non pas à cause des gens qui font le mal, mais à cause de ceux qui les laissent faire sans réagir."  Albert Einstein.