Jump to content

Fuinril

INpactien
  • Content Count

    230
  • Joined

  • Last visited

  • Days Won

    1

About Fuinril

  • Rank
    Wookiee
  1. Fuinril

    OC 6600k

    Résultats complètements différents avec OCCT. Des erreurs sur les coeurs pour commencer. J'ai donc diminué un peu et suis passé à 4.3 core et cache pour (et c'est une bonne nouvelle) 1.26 vcore. Ensuite les résultats sous 15 min de stress test avec OCCT donnent un peu moins que toi mais c'est bien plus proche : 72°C max pour une moyenne d'environ 60°C (mais après une heure trente de stress test sous OCCT et avec un réglage des ventilos "équilibré") Après je ne sais pas trop quoi penser des résultats : au final OCCT soumet le CPU à un stress qu'il ne connaitra absolument jamais en conditions normales et je l'utilise OC comme ça depuis quelques jours sans aucun problème particulier. Mais dans tous les cas je ne pense pas que ce soit une bonne idée de prendre des risques pour gagner 300 bêtes MHz, les 800 déjà pris devraient suffire
  2. Fuinril

    OC 6600k

    Merci de l'avis éclairé ! Le stress test utilisé est celui intégré à intel extreme tuning utility (sur une durée de 8h). A noter que je retrouve ces résultats en usage intensif réel (c'est à dire fin de partie de crusader kings 2 ou stellaris... ce pour quoi je voulais OC le proc) Le ventirad c'est un corsair H100i. J'essaierai de diminuer un chouilla le vcore ce soir. Pour le base clock je n'y ai pas touché : j'ai fait un essai qui a provoqué un écran bleu immédiat
  3. Fuinril

    OC 6600k

    Bonjour, j'ai un 6600k sur une Z170A. Récemment j'ai voulu l'OC (pour limiter les ralentissements en end game sur Stellaris principalement). Je suis passé à 4.6GHz en core et 4.4 en cache (via intel extreme tuning utility). Par contre pour se faire j'ai du passer le core voltage à 1.38V. Le processeur est stable, la température plus qu'acceptable (45° en stress test), par contre j'ai lu qu'il était très déconseillé de monter le voltage au dessus de 1.3 au risque d'entamer la durée de vie du proc... et l'inverse, comme quoi ça ne posait aucun souci pour les i5. Donc la question est : je reste comme ça ou je baisse un peu ?
  4. Je pige pas bien votre conversation (qu'est ce que gmail à à voir la dedans ?) et je ne comprends pas en quoi le fait que les mx soient ceux d'ovh posent problème... Pour répondre à la question : le principe d'un champ SPF c'est d'identifier les expéditeurs autorisés d'une adresse email. Donc si tu ajoutes les IP de tes serveurs d'envoi (on parle bien du dernier relais ici) ça va fortement augmenter le score de tes mails (principe d'un serveur de réception : je reçois un message -> de qui il vient -> est ce que je connais cette ip comme etant un spammeur ? -> est ce que l'expéditeur est autorisé sur le domaine ? -> le domaine est il sécurisé ? -> le domaine de l'adresse d'expédition correspond-t-il ? le mail comporte-t-il une signature d'expédition ? ->le contenu du mail ressemble-t-il a du spam ? Tout ça va te calculer un "score" de confiance qui déterminera si tes mails passent en spam ou pas ; sachant que chaque hébergeur à ses propres règles et ses propres filtres plus ou moins sensible. Le fait pour un propriétaire de domaine de dire explicitement au niveau de la zone DNS quels sont les expéditeurs autorisés est certainement le plus gros boost possible pour un minimum d'effort. Le SPF c'est ça, et sur un SPF tu peux autoriser plusieurs serveurs, il y a un guide très bien fait qui traine sur OVH (d'ailleurs de mémoire ils ont assisté l'écriture du champ) - y compris les mx d'ovh ; sinon au pire wikipedia devrait te renseigner sur la syntaxe. Par contre ton screen ne sert à rien, ça se gère dans l'onglet zone DNS et non DNS (et ce n'est de toutes façons pas une bonne idée de l'afficher publiquement). PS : après avoir jouté ou modifié un SPF fais des tests. Pour le coup se planter et exclure explicitement l'expéditeur du mail c'est bien pire en terme de malus de score que de ne pas avoir de SPF
  5. C'est strictement la même chose à une différence près : en utilisant post() tu n'as pas besoin de passer "method:'post'" en paramètre pour avoir du post (et tu peux passer des paramètres pré-déterminés alors que ajax prend uniquement un objet en paramètre). Pour l'OP : sinon tu as jQuery(myElement).load() en plus simple qui va directement remplacer le contenu de myElement par la réponse du serveur
  6. Je te déconseille fortement l'usage des paramètres de la fonction post comme ça : c'est illisible au possible et ça te limite considérablement. Passe plutôt un objet. Et dans ta fonction retour, ton code php va renvoyer une string (echo "mon html que je veux insérer"), string que tu auras dans data. Il ne te reste plus qu'à faire quelque chose du genre $('monElementDontJeVeuxRemplacerLeContenu').html(data)
×
×
  • Create New...