votre avatar

fry

est avec nous depuis le 11 avril 2017 ❤️

1298 commentaires

Le 17/09/2020 à 15h 48


OlivierJ a dit:


Je ne comprends pas comment il peut connaître correctement certains aspects techniques du SSD et ne pas connaître la façon dont les cellules sont effacées et écrites (par page effectivement).


“il” … c’est moi ?
XD
y’a des concepts de je peux comprendre / mémoriser et oublier certain points pour d’autres



on parle bien de l’usure des ssd
le contrôleur ne peut donc écrire que par page si je te suis bien (je savais plus si c’était page ou bloc, mais bref), là on est d’accord
à chaque écriture sur le ssd, c’est donc une page complète qui va être écrite quelque part, et donc “user” les cellules de cette page
pour 2 ssd de capacité identique, il y aura 4 pages en slc, pour une seule en qlc, donc hors écriture “consécutive” (j’ai un trou, c’est quoi l’opposé d”écriture aléatoire déjà ?) il y a 4x moins des pages sur lesquelles répartir l’usure

Le 17/09/2020 à 07h 43

merci :)



il me semble quand même que l’écriture se fait par bloc ou page sur la slc, donc effectivement si un bit change c’est pas une unique cellule qui est usée mais quand même le nombre de cellule qui forme un bloc (ou une page)
j’aime beaucoup l’analogie de la porte, très parlant et bien trouvé

Le 16/09/2020 à 12h 43

pour l’histoire des disques “qui le faisaient déjà”, y’a plusieurs choses, les SMR qui écrivent dans un cache CMR puis déplacent les données quand ils ont le temps, et les systèmes de fichiers qui font du “copy on write” comme par exemple le btrfs.
c’est au moins 2 cas où on a un comportement vaguement similaire de pas écrire à l’emplacement lu



effectivement mon exemple était un cas théorique pas super optimiste, mais le principe reste valable :
si un bloc est un regroupement de 8 cellules, en slc on va se retrouver à écrire dans un nouveau bloc (donc “user” 8 cellules”) à chaque fois qu’un bit d’un octet change, si c’est de la qlc, le même nombre de cellules va être usé, mais ça sera à chaque fois qu’un bit change parmi 4 octets



dit autrement, en slc on va avoir 4 blocs au lieu d’un seul en qlc pour stocker 4 octets, donc si on fait plusieurs changements d’un bit aléatoire dans nos 4 octets, en slc on aura moins d’usure des cellules individuelles vu qu’il ne faudra réécrire qu’un seul des 4 blocs, en qlc c’est le même bloc qui sera sollicité à chaque fois pour la même quantité de données stockées et modifiées.



tilt
en fait voila le souci :
pour “user” la totalité des cellules d’un ssd il “suffit” d’écrire 1 bit dans chacun des blocs, donc avec des blocs (pour l’exemple, j’ai pas les bonnes valeurs, exemple pour simplifier) de 8 cellules (1 octet), sur un ssd de 8Mo, il faudrait modifier 1Mo de données.
en qlc, 0.25Mo suffisent a déclencher l’écriture dans chacun des blocs, vu qu’un bloc ne contient pas 1 octet, mais 4 …



je sais pas si c’est plus parlant pour exprimer les défauts de la qlc par rapport à la slc

Le 16/09/2020 à 09h 55


OlivierJ a dit:


Je ne te suis pas non plus ici. On accède à un disque par secteur, historiquement 512 octets, maintenant 4 k ; on ne s’amuse jamais à changer quelques bits comme ça. Avec le SLC ça modifie (au moins) 512 cellules, avec le QLC ça modifie (au moins) 128 cellules. Ça ne change pas ce qu’on appelle l’amplification en écriture.



Sinon pour tes explications générales rien à redire. La lecture est en effet plus délicate quand il y a 16 niveaux à détecter, mais pas sûr que ça soit un phénomène plus lent. On lit un voltage, ce qui prend un temps donné (idem SLC ou autre me semble), après c’est l’interprétation (par le contrôleur) qui est plus délicate. L’écriture surtout doit être plus compliquée pour s’assurer que le bon niveau est atteint précisément (enfin de mémoire - sans jeu de mot :-) ).


l’histoire de 512 octets / 4k, c’est pour les disques à plateaux, c’est plus fin sur les ssd
cela dit il y a une histoire d’accès par “page” et par “bloc” pour la flash, je sais plus si une page contient des blocs ou l’inverse, et il me semble qu’on peut écrire par l’un et lire par l’autre, et/ou “effacer” par l’un de ces regroupements (c’est là que le trim intervient, pour éviter de réécrire le tout à chaque modification, on écrit ailleurs le bloc ou la page, et le trim vient effacer de temps en temps quand toutes les données ont été réécrites dans d’autres pages / blocs au fur et a mesure des modification, quelque chose dans ce goût la de mémoire)
par contre je sais plus si une page / un bloc c’est un regroupement qui se compte en bit ou en cellule (probablement cellules, ce qui participe à ces soucis d’amplification d’écriture)



edit : je guettais ta modification, je pensais pas que tu referai 2 message à la suite, tes 128k et 8k / 16k ça doit etre les page et blocs dont je parle

Le 16/09/2020 à 07h 57


OlivierJ a dit:


non non tu te trompes, car en SLC un octet prends 8 cellules, et 4 cellules en MLC, et 2 cellules en QLC. Donc sur de la QLC, on use moins de cellules.


cf également la réponse de fofo9012
on use peut-être moins de cellules, mais on les use 4* plus en qlc qu’en slc
imaginons que sur notre octet précédent on change tous les bits en 8 étapes :
en slc, chaque cellule aura été écrite 2 fois (enregistrement initial, puis modification de chacun des bits
en qlc, chacune des 2 cellules aura été écrite 5 fois (et encore, en considérant que l’écriture initiale ait été faite en un seul coup car les 4 bits auraient été regroupés par le contrôleur), donc l’écriture initiale, puis chaque modification d’un des bits de la cellule

Le 15/09/2020 à 12h 07


OlivierJ a dit:



En fait ce serait plutôt l’inverse.


nan c’est bien ça, une cellule mlc est écrite bien plus souvent qu’une cellule slc :
en slc, si 1 bit d’un fichier change, on récrit la cellule
en mlc, si n’importe lequel des x bits change, on réécrit la cellule
sur 1 octets maintenant :
8 cellules en slc vs 2 cellules en qlc
si on change 1 bit, chaque cellule slc à une chance sur 8 d’être réécrite, c’est une chance sur 2 pour les deux cellules de qlc

Le 17/09/2020 à 10h 07

bah il a pas tort en fait
un calcul c’est quoi ? des électrons qui ont été déplacés, comment ? en les excitant
la chaleur c’est quoi ? une excitation de la matière
donc un calcul informatique n’est au final que de la génération de chaleur.
le seul truc c’est que le calcul en lui-même n’est à l’origine que d’une fraction de la chaleur générée par l’ordi, les courants de fuite et autres pertes sont largement plus générateurs de chaleur à priori.



ça doit pouvoir se calculer l’énergie nécessaire pour faire un calcul via des transistors “parfaits”, et donc on devait pouvoir en déduire le rendement des processeurs (si pour 1TFlop à une gravure de 10nm il faut 10w, et qu’un processeur à besoin d’un radiateur pouvant dissiper 100w, …)

Le 16/09/2020 à 16h 18

Dans l’article, il disent avoir eu 18 du taux de pannes qu’il aurai sur un datacenter sur terre ferme, il y a donc des pannes.



Et personnellement, je pense que la panne est prise en compte dans l’exploitation de la capsule. C’est certainement calculé pour qu’elle reste globalement fonctionnelle pour toutes la durée de vie de l’exploitation.



Après, je ne pense pas que le matos informatique soit exploité pendant 20ans : au bout de 10ans il va peut être être intéressant de le remplacer entièrement pour quelque chose de plus récent.

à priori, ils ont mis dans la capsule la même chose que dans un DC “normal” et ont eu moins de panne.
soit le taux est acceptable sans maintenance, soit comme le dit Nozalys, on sait faire des choses plus robustes et il “suffira” de spécialiser un poil le matos pour qu’il atteigne des taux acceptables

Le 10/09/2020 à 15h 20


(quote:50069:brice.wernet)
On est pas plutôt sur du 80-95% de rendement?


il parle du taux de charge où le rendement est le meilleur, pas du rendement lui-même
par ex : une alim 400w fournira 200w @ 95% de rendement, mais pour fournir 50w ou 350w, le rendement sera plus faible du genre 85% au mieux, 50% au pire (si on tombe sous les 50%, on doit pouvoir parler de chauffage d’appoint plutôt que d’alimentation XD)

Le 09/09/2020 à 07h 57


Soraphirot a dit:


…Alors euh je suis pas doué en mécanique mais là faut pas dire de bêtise. Ta voiture avec plus de chevaux (à cylindrée équivalente comme tu le dis) consommera forcément plus que le moteur moins puissant. D’où elle vient la puissance supplémentaire à ton avis ? C’est pas uniquement parce que tu les fais les yeux doux qu’elle décide de faire un effort supplémentaire.Bah si ton moteur tourne plus vite il s’abime plus vite de facto. Les supercars auront beau être construites avec le plus grand soin possible, je te défie de trouver un modèle avec +100k bornes au compteur là où les voitures classiques peuvent aligner les centaines de milliers sans sourciller je grossi le trait mais tu vois l’idée).Mais de toute façon ces comparaisons sont claqués. Un moteur électrique ça a une consommation relativement linéaire/légèrement croissante pour les bons, tu pourras jamais faire tourner un moteur plus vite que son équivalent d’en dessous pour la même conso.


alors sur certain points si, un petit gain de puissance peut améliorer la conso sur une voiture, mais juste parce qu’on n’utilise jamais toute la puissance du moteur, et que le réglage plus agressif du turbo qui permet de gagner 15 poney @4500tr/m fait qu’a 1800 le moteur a un peu plus d’air, donc brûle mieux une quantité de carburant légèrement inférieure pour avoir la même puissance qu’avant à ce régime etc … pas de quoi dire “+ de puissance = - de conso” pour autant
(je pinaille mais je suis d’accord avec toi cependant ;) )

Le 08/09/2020 à 09h 54


(quote:49781:skankhunt42 )
Ont va dire que dans l’absolu c’est possible de monter un marché de l’occaz même avec du dématérialisé mais ceux qui vont en prendre pleins la tronche c’est les boutiques de JV. C’est également possible de faire un système de prêts comme le fait steam. Si le jeu est prêté et lancé alors tu ne pourra pas le lancer chez toi.Le seul problème la dedans c’est pour les jeux “plug and play” ou ton pote ce ramène chez toi. Car même en utilisant son compte il faudra télécharger le jeu. Mais peut être qu’il sera possible de balourder les jeux sur un dd externe et hop ?


à moins qu’ils supprime quelque chose qui fonctionne déjà (c’est pas impossible) ça me semble déjà être le cas : j’ai des jeux installés sur un ssd branché en usb(3 ? je sais plus si c’est du 3 sur la console, il me semble vu que j’ai eu des DL @300mb/s), si le disque est branché, j’ai leu jeu, sinon tant pis, et j’ai pas eu a réinstaller quand la console est partie en garantie et qu’elle avait été entièrement formatée (avec changement de disque j’espère, il semblait HS et je suis pas sur qu’un formatage bas niveau aurait suffi, mais depuis plus de souci)



au pire, dans les menus y’a une option pour que la console puisse servir de “cache” pour installer le jeu sur une autre sur le réseau local, donc au pire tu embarque ta console chez un pote et au lieu de charger depuis la connexion adsl @12.354mb/s, il récupère le jeu depuis ta console



ok, une console complète c’est moins simple à trimbaler qu’une clef usb ou un dd externe, mais c’est possible :)

Le 03/09/2020 à 08h 52

je pense plus a des “supercondensateurs” qui seraient capables de tenir l’alim pendant les quelques ms nécessaires pour écrire le go de ram qui sert de cache vers les cellules de flash, c’était mis en avant à une époque sur certains ssd il me semble.



bon bah, grilled :)

Le 21/08/2020 à 16h 34


Pour mémoire, la copie privée est fixée selon des études d’usages. Plus les personnes sondées affirment copier des œuvres, plus les ayants droit sont en droit de réclamer des sommes importantes, au titre de cette compensation à l’exception pour copie privée. Dans un système cartésien, lorsque le panel est ridiculement petit, l’issue aurait dû être une très forte réduction des montants prélevés pour ne pas dire sa suppression. Rue de Valois, le choix a été fait de maintenir ces prélèvements, calculés à une époque d’or pour ces supports aujourd’hui dépassés.


Je ne comprends pas bien ce paragraphe.

Les barèmes étant ‘à l’appareil’, le fait d’avoir un panel ridiculement petit n’a pas de lien direct avec les pratiques de copie privée, et donc avec le montant qui serait adéquat.

Bien sûr, on peu suspecter que les usages sur ces supports aient changé (ie que les rares personnes qui continuent à les utiliser n’aient pas des pratiques soumises à la copie privée), mais en l’absence d’étude, ça ne me semble pas plus prouvé que l’inverse.



.



Je vais me faire un peu l’avocat du diable, c’est pas ça qui est dit. Ce qui est dit c’est que comme c’est une petite somme, ça ne vaut pas le coup d’investir dans une étude qui réévaluerait le juste montant de la RCP sur ces supports.
Très critiquable, certes, mais il n’est absolument pas crédible que plus rien ne justifie la RCP sur ces produits (sauf à considérer que la RCP est globalement illégitime, mais c’est un autre débat)

panel petit = potentiellement totalement biaisé, si tu tombe sur une niche de “copieurs compulsifs”, ou à l’opposé de gens qui ne stockent que leurs propres photos / enregistrements persos, établir un barème pour le reste de la population est totalement foireux.
le paragraphe dit qu’on sait que le style de consommation à changé (bonjour deezer et autre streaming) sans avoir fait de nouvelle étude sérieuse permettant de chiffrer, seulement la dernière étude date d’une autre époque et on conserve le taux qui en avait découlé

Le 18/08/2020 à 15h 57

merci du retour, je voulais éviter de passer par un cron pour re-scanner tout les dossiers en effet.



j’avais pas pensé que ça pouvait être la conf’ php de base qui pouvait limiter le webdav de nextcloud
vu que c’est 99% du mono-utilisateur, sur un pi4 4go, je devrait pouvoir laisser un peu plus de souplesse à la conf’ sans trop de souci

Le 18/08/2020 à 11h 26

me viendrait une question : est-il plus performant que le client natif pour nextcloud (via webdav donc)? sous mac et/ou windows ?
j’ai un nextcloud sur un pi, un rsync via samba doit dépasser les 20 Mo/s (peut-etre même 40, je sais plus), le client natif sous windows tourne à 4Mo/s, le montage “natif” proposé par ubuntu m’a déjà indiqué 6Mo/s
un pote a testé depuis son mac : 4Mo/s
c’est peut-être une mauvaise conf sur le pi, mais j’ai pas vu de client natif super performant (et c’est pas le réseau autour du pi qui pose pb, cf le rsync via samba)

Le 15/07/2020 à 15h 14

complètement au pif :




  • "avant" on avait l‘ECC qui était géré par la carte mère / chipset / processeur, fallait de la ram qui le supportait

  • "après" l’ECC est directement géré par la ram, donc que les barrettes soient "ECC" ou pas ne change rien au signal reçu par la cm / chipset / proc …
    (je suppose, si qqn à une réponse sourcée ça m‘intéressera aussi par curiosité :p )

Le 13/07/2020 à 07h 38


fofo9012 a dit:


En "veille" les SFP+ de mon Mikrotik sont à 65°, il est assez évident que ça consomme beaucoup plus y compris en veille. Le green ethernet c‘est assez basique : Si rien n’est branché le port se met en veille, et la puissance s‘adapte à la résistance du câble (un câble de mauvaise qualité ou très long nécessite plus de courant qu’un câble court de bonne qualité). Ça ne va pas plus loin ! Le lien doit rester connecté quand le périphérique est connecté.La théorie "le port se met en veille quand aucune donnée n‘y transite" n’est, je pense, pas possible :Premièrement il faut rester en veille assez active pour recevoir un éventuel packet pour se réveiller, rien à voir avec une bête mesure de la continuité électrique pour savoir si le câble est branché ou non,Secondo quand on branche un câble le port consomme pas mal de courant (détecter le nombre de paires connectées, tester le type de câble (croisé / droit) tester la résistance de chaque paire pour évaluer la longueur du câble et ajuster la puissance, synchroniser les différents modes pour trouver le meilleur possible (10mb,100mn half/full, 1gb…). Tout ça ne prend que quelques ms, mais consomme pas mal, si tu mets en veille ton port trop rapidement tu génères ce pic de conso plus régulièrement et il est probable que ton port consomme au final plus de courants : Le réveil consommant plus de courant que celui économisé pendant la veille.


65 Oo, et ben, c‘est triste pour de la "veille"
tout le protocole et l’énergie "perdue" pour les "tests de réveil" qui est supérieure à l’économie d‘une éventuelle veille, c’est bien dommage, donc même si j‘étais loin du coup dans mes approximations qui se concentraient sur le "temps", ça confirme mes "craintes" sur le fait que se mettre en veille puisse être moins intéressant que rester "allumé" :(

Le 13/07/2020 à 07h 34


hwti a dit:


en.wikipedia.org WikipediaEncore faut-il que les équipements soient compatibles, et avec la fonctionnalité activée (ce qui n‘est pas forcément le cas à cause des incompatibilités potentielles).En cherchant, je trouve une durée de 16µs maximum pour se réveiller sur du 1000BASE-T (1Gbps Ethernet classique).


pas cool que ça soit pas toujours activé pour les incompatibilités potentielles

Le 10/07/2020 à 10h 27


Soraphirot a dit:


Moi j‘ai compris son message comme "0Ko ou 1G ou 10G". Après Je suis d’accord dans l‘idée que si le port va 10 fois plus vite il est pas déconnant qu’il consomme 10 fois plus et donc passe plus de temps en veille mais avec tout les logiciels de chat, mise à jour en background, synchro temps réel… je ne suis pas sûr que le temps en veille change radicalement.Relis mon message plus lentement, t‘as lu des mots que je n’y ai pas mis.


boarf, je suppose qu‘une veille bien implémentée permettrait que ce soit transparent : si le port peut dormir 99ms et envoyer une trame en 1ms, au lieu d’être en veille 90ms et d’envoyer la trame en 10ms …
mais ça voudrait dire qu‘il faut que le port soit capable de se mettre en veille en moins d’1 ms, si le process de mise en veille prend 10ms (et autant en sortie), en considérant qu‘il est à 50% de conso pendant cette période (transmission = 100%, veille = 0%, réveil / endormissement = 50% de 2.5w en arbitraire histoire de voir ce que ça donne) => sur 100ms on se retrouverait avec 79ms @0%, 20ms@50%, 1ms@100%



c’est des chiffres arbitraire pour imaginer la situation, mais c‘est vrai que suivant comment c’est géré, une faible utilisation de bande passante sur un port avec de grosses capacités pourrait aboutir à une surconsommation importante et inutile :(



ça demande peut-être des changements importants dans le matériel, mais j‘imagine que si les cartes / switch (routeur) et OS le gérait bien on pourrait "brider" la carte au niveau le plus faible suffisant, genre une "veille" en mode "10Mb" (ça doit suffire pour de la messagerie instantanée quand même), et si la bp utilisée dépasse 70% sur 2s ou 100% sur 0.5s on passe au niveau au-dessus : 100Mb, puis idem pour éventuellement 1Gb et 10Gb



je me dit que coté matériel y’a peut-être ce genre de mécanique déjà en place, mais je suis presque sûr que windows serait pas tout à fait à l‘aise avec un port qui passe de 10Mb à 10Gb dynamiquement :s



edit : je viens de relire et c’est moi qui avait mal lu en effet, un switch en veille ou en pleine charge va pas consommer pareil (du moins à mon sens il devrait pas)

Le 10/07/2020 à 09h 19


Soraphirot a dit:


Bah euh non justement. Le 10G amène une problématique de consommation qui explose en cuivre (entre 5 et 10 fois la conso d‘une connexion 10G en fibre, à peu près pareil vis à vis du 1G cuivre). y’a eu de l‘amélioration depuis les débuts du 10G mais y’a encore du travail à faire assurément.Certes on parle de conso pour un port (pour des valeurs oscillant entre 0.5W et 2.5W) mais si on commence à les multiplier, ça devient important.


port "en fonctionnement", SI il se mettent correctement "en veille" quand y‘a pas de communication, y’a pas de raison qu‘ils consomment autant, mais 1) c’est peut-être mal implémenté, 2) il y a peut-être quand même une communication minimale pour conserver le port "branché"



cela dit je rejoins refuznik sur la théorie : faire passer 0ko ne devrait rien consommer, que ce soit en 1g ou 10g, et faire passer 50mo devrait avoir la même conso totale, mais "étalée" sur 10 fois plus de temps en 1G (chiffres au pif pour illustrer : ce qui va prendre 2.5w pendant 10s en 10g, prendrait en toute logique 0.25w pendant 100s en 1g)

Le 09/07/2020 à 16h 12


kgersen a dit:


Le tableau est imprécis. Le 10G passe sur du Cat5e jusqu‘a 20 a 30m, j’ai trois connexions comme ca devant les yeux.En multigig il faut souvent faire attention a la distance max non pas qu‘en fonction du câble utilisé mais aussi des cartes/interfaces, certains composants n’ont pas la puissance pour aller jusqu’à 100m même si le câble lui le peut.bien lire les specs des produits donc et pas forcement besoin de recâbler un bureau sous prétexte qu‘il n’y a que du Cat5e.


ça dépend peut-être aussi en partie de la qualité des câbles pour le coup, j‘imagine que pour une même catégorie, celui dont les conducteurs ont la plus grande section vont mieux se comporter avec des cartes qui ont moins de patate car il y aura moins de perte / résistance du câble lui-même.



en fait je sais pas si les normes rj45 précisent la section des conducteurs.



je sais juste que le cat 7 que j’ai est assez gros et c‘est une galère à sertir dans une prise mâle (par contre à brancher dans les prises legrand c’est presque confortable pour le coup)

Le 09/07/2020 à 15h 23


David_L a dit:


Oui c‘est une partie du problème. Mais bon la taille des données à transférer/sauvegarder est de toutes façons en croissance, ce qui augmente les besoins. Et pour rappel, on parle là de standards qui ont déjà quelques années, pensés pour un usage grand public, pas d’un 400GbE


tout à fait, je me contentais de donner un exemple concret, un cas particulier certes, mais pas si isolé pour autant, sans parler des xbox series x et ps5 qui annoncent des ssd ultra rapides, ma one (x) n‘a jamais dépassé les 300Mbps (sur ma connexion free 1Gbps), je suis monté à 60Mo (oui, "Mo" et pas "Mb") sur steam mais c’est le processeurs qui plafonnait en décompression,
s‘il faut une semaine malgré la fibre pour récupérer gears 8 / FF 20 à cause d’un lan vieillissant il va y avoir des déçus

Le 09/07/2020 à 14h 00


David_L a dit:


Oui comme dit la vague était visible, mais pour autant pas prise par tout le monde pour autant. Pour le Multi-Gig, côté "Pro" j‘ai quand même régulièrement des retours assez différents, avec le monde du réseau "pur" qui considère 802.3bz comme une sorte de truc bâtard qui n’a pas lieu d‘être :D C’est aussi pour ça qu‘on en trouve ici ou là mais souvent par petite touches mais rien de plus.


je dois avouer que la première fois que j’ai vu "2.5" ou "5" Gbps je me suis demandé de quel cerveau malade ça sortait XD



puis quand le 10G à été trouvable pour les particuliers (c‘est à dire hors labo ou datacenter) et que j’ai vu les prix, j‘ai compris :(



cool pour le switch 5*2.5vivement que les concurrents se réveillent que les prix baissent



ça fait déjà pas loin de 10 ans que j’avais été bluffé par un transfert d‘1Go (dossier steam) de ssd vers ssd qui avait duré à peine 10s



maintenant les jeux qui font > 50Go, c’est pas rare, si on veut se faire une petite lan entre potes et qu‘on n’a pas tous chargé le jeu en avance, ça peut être long pour juste commencer à jouer, et là on est content d‘avoir un lan (et des ssd) qui tartinent

Le 10/07/2020 à 10h 33

je me suis fait le même genre de réflexion, ça me semblait peu pour un ancien ndd de google

Le 08/07/2020 à 16h 50

si t’as du cat 6 ou 7 et les cartes réseau qui vont bien, ton lan devrait supporter > 1Gbps.

si t’as du cat 4 qui se faufile entre des enceintes, une machine à laver triphasée et un vieil halogène là c’est pas garanti …

Le 08/07/2020 à 15h 07

j’ai la chance d’avoir la fibre (free en l’occurence, via mini 4k)



ben quand j’allume la xbox pour jouer, et qu’il y a un m-à-j de 3 Go (pas plus tard qu’hier soir sur forza), ben je suis bien content de pas avoir a attendre 4h pour pouvoir lancer le jeu, et je dois quand même pas etre le seul à apprécier les haut débit dans ce genre de cas, surtout que c’est le genre de connerie (merci microsoft au passage) ou tu peux pas zapper la m-à-j.

là je parle bien de m-à-j non “anticipable”, si j’avais une connexion adsl et que je veuille installer un jeu à 100 Go, je lance la box le matin et la laisse tourner 2 jours pour que ça s’installe, ça on peut l’anticiper, même si c’est moins confortable qu’allumer la box et charger un jeu en 30 minutes.



la c’est sur xbox, mais avec steam / origin / epic ou même playstation c’est très probablement le même genre.



oui il faut la fibre partout, mais c’est pas une raison pour cracher sur la moindre augmentation de débit qui n’implique pas d’intervention humaine (s’il fallait envoyer des tech sur tous les nro je te l’accorde que ce serait une gestion discutable des priorités)

Le 08/07/2020 à 16h 46


David_L a dit:


AMD n‘a pas communiqué là dessus. On verra pour Zen 3 mais je pense que ce sera trop tôt pour USB4, plutôt Zen 4 qui aura une update côté "nouvelles techs".


c’est un peu ce que je "craignais"
quitte à changer de machine, j‘aimerai bien profiter des "nouvelles techno", et pas rester sur celles en "fin de vie" (même si la ddr4 à encore quelques années devant elle je pense par exemple), si ça arrivait en 2021 plutôt que 2022 ça serait pas mal :p

Le 08/07/2020 à 15h 22

on a une idée de l‘intégration de l’usb 4 / tb 4 sur plateforme amd ?
j‘ai cru comprendre que l’usb 4 était prévu plutôt pour 2022, mais est-ce que ça sera du tb 4 ? est-ce qu‘il y a une licence pour le tb 4 ?



note : l’intérêt que je vois dans le tb 4 c’est le minimum requis, c‘est casse bonbon de voir juste "usb 3", et de galérer à trouver l’info (si elle existe) qui indique si le port en question supporte le power delivery dans un sens ou dans l‘autre (pour un ordi portable par exemple), ou si on peut brancher un écran …



on peut pester contre le prix des adaptateurs pour les macbook pro (usb-c vers hdmi / rj45 / usb-a ..), mais on peut brancher un écran ou l’alim sur n‘importe lequel des 4 ports au moins

Le 07/07/2020 à 12h 02

bon, visiblement là c’est toi qui cherche la petite bête dans ce que je n’ai pas dit.



 je savais pas que youtube était un organisme d’archivage de video, et je n’ai jamais parlé de se substituer à un tel service.



 si les vidéos supprimées étaient sur le compte de l’ong, il aurait été totalement logique de les mettre en “quarantaine” et / ou de communiquer avec le gestionnaire du compte avant suppression pure et simple.

par contre comment tu veux que youtube demande à l’ong “est-ce que je peux supprimer la video suspecte postée par [nom-du-témoin] depuis [pays-en-guerre]”, comment youtube est censé faire la différence entre une vidéo “à soumettre à l’ong” et une autre si c’est pas sur son compte (cas probable des videos “en attente”).







la SEULE chose que je dit depuis le début, c’est que SI y’a des vidéos TRAITÉES et ARCHIVÉES par l’ONG sur youtube qui ont été supprimées et qui ont été définitivement PERDUES, c’est qu’il y avait un mauvais process coté de l’ong qui n’avait visiblement pas de sauvegarde et là c’est con.

 



toute les suppression brutales qui ont pu être faites par youtube, c’est un traitement radical mal pensé de la part de youtube, on est d’accord, il aurait été largement plus logique de bloquer la video et de contacter le gestionnaire du compte sur lequel le dépôt a été fait avant toute opération irreversible.



la suppression pure et simple depuis un algo est une connerie sans nom.



sur ce, j’arrête ce dialogue de sourd où visiblement tu me prête des raisonnements / pensées que je n’ai pas.

Le 06/07/2020 à 12h 04

arghl



je dis pas que youtube doit pas être utilisé pour les échanges, car effectivement censurer tout youtube pour empêcher qqn de déposer une vidéo qui dénonce / prouve un fait est plus compliqué que bloquer “www.deposezvospreuves.com”



mais on ne m’ôtera pas de l”idée que si c’était “archivé” sur youtube, et pas ailleurs (comprendre “en plus” de youtube) sur un disque de 20To hors réseau, au siège de l’ONG par exemple (et minimum aussi chez 3 membres de l’ONG) c’était mal pensé comme système d’“archivage”



 je dis pas non plus que c’est “normal” que les algo youtube aient supprimés les vidéo, mais youtube propose une possibilité, sans garantir sa pérennité, c’est une utilisation “à vos risques et périls” que tout le monde semble ignorer (idem avec facebook et toutes ces autres plateformes hein)



la bêtise humaine explique un bon paquet de choses, y voir une malveillance volontaire, pourquoi pas, mais pour le moment je suis naïf et ne crois pas à la théorie du complot dans le cas présent

Le 06/07/2020 à 08h 45

nan, je disais juste que se servir de youtube comme espace d’échange n’était pas une idée pérenne à la base, et c’est pas la fonction de youtube, c’est un détournement qui a un coté pratique certes, mais des risques (la preuve).



que l’ONG n’ait pas les ressources pour faire autrement est un autre problème en soi



que manque de bol les process automatiques de youtube aient flingué les documents non encore archivés c’est dramatique je le concède



par contre, en lisant l’article j’ai pas vraiment compris que c’était “juste” des documents pas encore traités qui avaient été dégommés, j’avais l’impression que l’ONG bosse avec les video sur youtube et c’est tout, comme s’ils ne sauvegardaient rien de leur coté, d’où ma première analyse et le coté “ils ont mal fait leur boulot” qui t’a fait tiquer :)

Le 02/07/2020 à 11h 36

tout à fait, mais j’y crois pas trop malheureusement

Le 02/07/2020 à 11h 36

yep pour le coté “invisibilisation”

Le 02/07/2020 à 11h 35







Dj a écrit :



Faut avoir accès a d’autres plateformes aussi



Youtube est facile à utiliser pour des amateurs et surtout il est rarement bloqué en Syrie



Le stockage et l’encodage de vidéo ça demande des moyens







y’a une ONG dans l’histoire, que les civils uploadant des trucs n’aient pas les compétences / moyens ok, mais ça me semble être du ressort de l’ONG de regrouper / archiver les preuves pour pouvoir monter un dossier à charge ou organiser la communication autours.


Le 02/07/2020 à 09h 14

hum

autant la perte des données est malheureuse dans le contexte (crime de guerre = grave)

autant utiliser youtube, facebook, twitter et compagnie comme lieu d’archivage des données en question est une pure bêtise.

utiliser ces plateformes comme moyen de communication correspond a une certaine logique, mais s’en servir comme stockage franchement …

Le 06/07/2020 à 09h 17

cette fois j’ai ouvert le lien, ben j’avais visiblement pas lu cet article :)

c’était le cas de Mijoux que j’avais en tête je crois

Le 06/07/2020 à 08h 33

ah

ce n’est donc pas le même qu’il y a quelques temps (mois ? zut ça passe vite)

y’avait eu une news sur un brouillage y’a pas si longtemps non ?

Le 02/07/2020 à 09h 07

là l’auteur s’est plaint (le new york times)

en prime y’a le décret qui accentue la responsabilité de l’hebergeur

je vois pas d’acharnement, un juste retour de bâton à la rigueur si on cherche la petite bête

Le 01/07/2020 à 16h 19







GuiTheGuy a écrit :





attention en plus sauf erreur la série 4000 pour les portables c’est du “zen 2”, alors que la série 4000 pour les fixes c’est du zen 3 si je me trompe pas, y’a eu un décalage à un moment qui traîne encore et prête à confusion …


Le 25/06/2020 à 11h 39







David_L a écrit :



Faut les manger avant les oiseaux <img data-src=" />





faut manger les oiseaux avant les cerises.


Le 25/06/2020 à 09h 05


patos a dit:


…Pour information, pour avoir comparé avec d‘autres disques, Seagate donne 110^15 secteurs (512/4K) irrécupérable…


que veux-tu dire par là ? seagate est meilleur que WD ? ou pire ? ou similaire ?



en relisant j’ai vu que tu indique 110^14 pour un raid, donc 1 seul disque seagate a, officiellement, 10 fois moins de chance d‘avoir un secteur défectueux (pour un volume de stockage identique)



j’ai bien compris ou j‘ai rien compris ? :)

Le 24/06/2020 à 14h 04


KP2 a dit:


J‘ai fait pire et j’ai un peu la haine : j‘ai migré un NAS 2 baies en RAID1 vers un NAS 4 baies en RAID 6 -> 5j de resync pour le 1er disque ajouté, 13j pour le 2e Les 2 nouveaux disques ont été acheté 1 ou 2 semaines avant ce scandale…


déjà si t’as pas perdu un disque dans l‘opération c’est pas si mal, :)
(dans le sens le DD qui lâche au mauvais moment car il est fortement sollicité …)

Le 15/06/2020 à 16h 18

boarf, pas besoin de cookie pour un défilement continu, c’est juste du JS

Le 11/06/2020 à 08h 44

merci pour cette analyse / résumé / infos :)

Le 10/06/2020 à 22h 15

grmblh, touché

d’un autre coté, le streaming est assez récent (bon ok on dépasse les 10 ans quand même, mais c’était quand même laborieux au début il me semble)

pour les images, “normalement” sur le web on évite les images trop lourdes, donc même si le http est / était moins performant, c’est presque pas visible.

du moins dans le sens serveur =&gt; client



quand on dépose des fichier, donc dans le sens client =&gt; serveur, faut toujours des trucs spécifiques (manipuler des fichiers “reçus” (du point de vue du serveur) en php est une plaie, surtout si on s’attaque à des gros fichiers, faut jouer avec les max_upload et autres conf, si on veut avoir un retour sur la progression faut jouer avec du js/ajax etc …)

ça sort du protocole c’est sur, mais au moins en php, qui me semble quand même le plus accessible pour faire des choses avec du http, c’est pas génial

Le 10/06/2020 à 12h 56







David_L a écrit :



j’ai toujours l’impression qu’utiliser http pour autre chose que du texte c’est “contre nature” et pas optimisé

par “texte” j’entends tout ce qui est web, le html, css, javascript, json …

dès qu’il faut jouer avec des fichiers je trouve ça suspect, même un simple champ “file” dans un formulaire j’ai l’impression que c’est de la bidouille sur un truc qui le prévoyait pas au début, et qui est pas vraiment prévu pour des grosses volumétries

y’a qu’a voir les valeurs par défaut quand on installe apache, php et compagnie, 2Mo, en texte c’est bien, en fichier “media” on va pas super loin



cela dit, ayant constaté que mon montage à base de pi tenait les 50Mo/s, vraisemblablement via webdav, c’est pas si mal, mais je me demandais si avec le même matos du samba “de base” fournirait du 95Mo/s ou du 55Mo/s



y’a peut-être des configurations à faire, mais je sais pas si c’est nextcloud, webdav, ou le pi (raspbian/raspberry pi os / nextcloudpi) qui va être le plus compliqué





note que j’ai constaté tardivement, l’image nextcloudpi est basée sur raspbian, donc en 32bits, y’a peut-etre moyen de tirer mieux parti du matos si ça tournait sur la version arm64 au lieu de armhf, et j’ai un souci qui fait qu’en upload les fichiers sont tronqués à 2.1Go (alors que les rsync de fichiers &gt;4Go ne posent aucun pb, et que je peux les récupérer)


Le 10/06/2020 à 12h 42

ça ressemble aux vagues impressions qui me faisaient penser que webdav était pas top (l’histoire de l’implémentation windows)

Le 10/06/2020 à 12h 41

c’est sur un pi 4, le réseau n’est plus un bridge (ou je sais plus le terme) sur un port usb, c’est un vrai gigabit qui peut tartiner



idem pour les usb, j’ai pu transférer (rsync) entre 2 DD en usb3 à 70Mo/s en lecture sur l’un et 70 en écriture sur l’autre tout du long (sur des sessions de plusieurs centaines de Go au total)

Le 09/06/2020 à 16h 46

ça donne quoi coté perfs par rapport à du samba ?



j’ai un petit nextcloudpi qui tourne, le “client lourd” (officiel nextcloud) de synchro me semble pas super rapide (et j’avais cru comprendre qu’il tournait sur l’api webdav présentée par nextcloud)

alors que le même pi, via un montage samba du disque ou nextcloud stocke ses données, m’avait l’air largement plus rapide (depuis la même machine sous windows 7)





ubuntu 20.04 intègre directement la connexion à un compte nextcloud, qui apparaît comme un lecteur réseau dans le navigateurs de fichiers, est-ce que ça passe bien par webdav du coup (je vois pas trop ce que ça serait d’autre cela dit)

petit test d’hier soir : ~1015 Mo/s en wifi, dans les 50Mo/s en rj45 (via l’intégration native d’ubuntu 20.04), j’ai pas testé en samba par contre, d’où la question initiale

Le 20/05/2020 à 15h 17

dans ubuntu 20.04 y’a directement de quoi se connecter à un nextcloud, qui apparaît comme un montage (idem samba ou une clef usb quoi), bien pratique en tout cas :)

je sais pas en quelle version tu es, mais si tu migre t’aura même plus besoin de configurer le montage toi-même :)