benoar a écrit 4229 commentaires

J'adore les gens qui parlent du WiMax en France : peux-tu me citer une carte wimax disponible à la vente pas trop difficilement en France ?

Bon, c'est vrai que pour le fonctionnement de TCP je me suis un peu trompé, même si la deuxième partie de ton explication correspond à ce que je décrivais : on pousse jusqu'au max possible avant de perdre des paquets, et là on diminue un peu.

Sinon :
une perte d'un paquet entraîne toujours un ralentissement de l'émission (en plus de la ré-émission du paquet).
Bah oui que ça ralentit l'émission, puisque le client n'a pas reçu les paquets. Mais le serveur, lui, ne voit pas que t'as perdu des paquets magiquement : il le voit en fonction de ton émission des ACKs. C'est pour ça que j'en couclue que c'est bien l'upload qui détermine la vitesse de download (quand on shape, hein, et dans la limite de la taille de connexion en download bien sûr)...

Cf mon lien au dessus, ça paraît un peu bizarre à l'esprit au départ, mais ce n'est pas si illogique que ça.

Bon, c'est vrai que je ne maîtrise peut-être pas tout bien, mais je suis d'accord avec le fait que si des paquets se perdent, TCP va diminuer la fenêtre. Mais, en me basant sur :
http://web.archive.org/web/20071101114640/www.digriz.org.uk/(...)
que j'avais utilisé à l'époque et qui marchait très bien, il dit :
N.B.
shaping only works for OUTGOING packets simply so think which interface to use
when you apply shaping to incoming packets you really are saying which ones
are safe to drop (without generating more traffic, FTP data) and which are
unsafe (UDP as it will not slow down the data transfer and has already
consumed your bandwidth and TCP ACK's are examples).
Ce qui n'est pas bête : dropper des paquets qu'on a déjà reçu, ça ne sert à rien d'autre que de perdre de la BP ... donc au final, le shapping se fait toujours sur l'egress ...

D'une part la transition vers des secteurs de 4K est en cours.
Oui, c'est plus pratique aujourd'hui pour s'aligner à la taille des pages en RAM, et s'adapter plus facilement aux FS, et pour les grandes tailles de disque. Mais ça ne change rien pour les SSD qui ont des tailles de page différentes. À moins qu'il y ait un effort d'unification à 4ko ? Mais je n'en ai jamais entendu parler. Et puis ça ne règle pas le problème de la taille des erase-block, ni même des "zones" si on passe par une FTL bas de gamme.

des commandes ATA spécifiques aux SSD apparaissent (voir TRIM/Discard)
Oui enfin encore une fois, c'est une adaptation aux FTL, pour qu'elles soient utilisées un peu mieux (enfin, pour qu'elles ne soient pas complètement nazes ... ce qui est mieux que rien, mais pas top). Et ça existait déjà dans les specs CompactFlash (en mode ATA), même si à priori ça n'a jamais été implémenté par personne ... Et puis surtout ça devient assez drôle au niveau des implications que ça a par rapport aux utilisations un peu inhabituelles comme l'accès direct (sans passer par le FS) ou la récupération de données, cf http://marc.info/?l=linux-ide&m=123266840917245&w=2 et suivants, j'ai le flemme d'expliquer pour l'instant.

Bref, ça n'améliore qu'un peu la situation, et surtout, c'est fait dans l'esprit de garder absolument les FTL, pas d'imaginer de travailler sans.

Le problème est que quand ils te vendent une licence OEM avec un ordinateur, ce n'est pas eux qui ont acheter la licence (contrairement à un achat seule de la licence) et je trouve normal qu'il y ait des économies d'échelles sur le prix de la licence.
Oui enfin là les magasins pourraient se retourner contre ce constructeur pour vente liée également, non ? (dans un monde idéal, bien sûr) C'est ça la recette de MS (et aussi pour d'autres cas en dehors de l'informatique) : faire remonter la responsabilité du problème le plus haut possible dans l'échelle pour que les petits acteurs d'en bas ne puissent rien y faire.

Par exemple si je commande un ordinateur avec plus de ram, je ne paye pas la ram au même prix que si je l'avais achetée à part.
BEEEEEP.
Erreur, comparaison avec du matériel, ce qui n'a rien à voir avec du logiciel.

C'est bizarre, je me suis toujours dit que ça se passait comme ça, merci pour la confirmation. Donc bref, rien n'a changé, c'est toujours la même merde.

Le truc c'est que quand on fait de la QoS, limiter le flux descendant ne sert quasiment à rien. C'est l'upload qui détermine tout.

Explications :
Si un téléchargement est en train d'occuper plein de BP qui fait que le surf sur le web va lentement, et qu'on choisit de "dropper" des paquets de ce gros flux (que ce soit au niveau du DSLAM ou du routeur/*box), l'ordi qui télécharge va juste ACKer les paquets bien arrivés et NACKer les autres, ce qui fait que le serveur en face va en envoyer encore plus pour compenser les paquets "perdus". Ce qui ne va pas arranger la situation.

Quand un serveur envoie du traffic à une machine (qui à priori dans notre cas a un débit plus faible), il va envoyer à bloc au départ et s'adapter en fonction du rythme des ACK de la machine cliente en face. Et c'est donc le rythme d'upload de la machine cliente qui va déterminer la vitesse d'envoi pour le serveur, que ce rythme soit limité parce que l'upload est saturé (genre, quand le client fait du P2P) ou parce que le download l'est (la ligne n'a pas un assez gros début descendant, les paquets font la queue avant le client (genre au DSLAM) et que donc le client ne peut pas ACKer des paquets qu'il n'a pas encore reçu).

Tout ça est géré par TCP, c'est le principe du protocole.
Par contre, pour la TV et le téléphone, je pense que c'est géré autrement car déjà ce n'est pas du TCP, mais par contre c'est du non-connecté donc avec potentielle perte de paquet, mais ça ne fait pas grand chose car ce sont des services "temps réel" donc où on ne renvoit rien si ça foire. De plus, ces débits sont souvent fixes, ce qui facilite le dimensionnage de la QoS descendante.

Jusqu'a faire un spot publicitaie ...
Tu parles bien de ça ?

http://www.youtube.com/watch?v=cE6fQwWggVM

Comme tous ces magasins ont l'air de proposer des Windows à des prix si bas, pourquoi ne pas essayer de leur en acheter un bon paquet à ce prix et voir leur réaction ?

Si on peut acheter une machine "sans" l'OS, on doit bien pouvoir faire le contraire, non ? Ou alors acheter une souris à 5€ avec chaque licence, pour voir.

Enfin bon, cette histoire d'OEM c'est bien une arnaque made in Microsoft pour faire semblant de respecter la loi sur la vente liée ...

Bon, qu'il n'y ait pas de mécompréhension : je suis complètement d'accord que ce système de bloc ne soit pas du tout adapté aux mémoires Flash (que ce soit SSD ou USB/SD), mais là je suis passé en mode "pragmatique" car aujourd'hui, aucun constructeur ne fait l'effort d'y remédier par un moyen -- même pas idéal -- un tant soit peu "pas mauvais". Tout le monde utilise un FTL, point. Les seuls qui ont un accès direct à la Flash, c'est dans l'embarqué, et encore, juste pour la Flash "de base" (par exemple, il me semble que dans l'iPhone/iPod Touch, le firmware est en accès MTD, mais le stockage de 8/16/32Go est en oneNand, soit le protocole SD, qui marche aussi par bloc de 512). Bref, rien a destination du grand public.

Ensuite, ce coté bloc de 512, quand je disais que c'était inhérant au système de bloc, ce n'est pas que ça, c'est aussi inhérant à la norme ATA ! (et donc SATA) Bref, ce n'est pas qu'un problème de soft, c'est aussi un problème de hard (enfin, moitié/moitié puisque la stack ATA c'est un bout de driver et un bout de hard). Donc ce n'est pas près, selon moi, de changer.

Comme personne n'a poussé pour un système de connexion spécifique aux mémoires Flash (on aurait peut-être pu faire quelque chose "au dessus" du protocole physique SATA, voire encore plus crade mais plus "facile", au dessus des commandes ATA ?) et bien tout le monde fait des FTL. Et effectivement, personne ne sait ce qu'il fait, garder des secrets ça arrange bien les industriels.

Enfin bref, pour les histoires de capacités, c'est peut-être facile aujourd'hui, mais j'ai entendu que pour simplifier le design des puces de grosses capacités, ils voulaient faire des erase block dont la taille se compte en Mb, ce qui ne va pas arranger les choses. D'ailleurs c'est peut-être déjà le cas, mais on n'en sait rien. Encore du secret.

Pour conclure, oui ce serait bien d'arriver à faire un truc adapté (et libre, en plus) mais je ne pense pas que ce soit faisable vu le comportement des industriels aujourd'hui.

Je pense que ce que tu décris, c'est la taille d'un secteur, qui n'est pas la même chose qu'un bloc : effectivement, des périphériques indiquent des tailles de secteur différents de 512 octets, mais les blocs gardent cette taille. À vérifier quand même, mais là il est tard ...

Holala, je n'ai pas de document "sérieux" à te fournir, mais c'est justement le manque de documents sur tous les périphériques de type bloc (Clés USB, carte SD, disque SSD) et puis pleins d'articles que j'ai lu qui me font dire que ça ne sert absolument à rien de vouloir contrer ce que fait la FTL. UBI et consort sont faits pour des périphériques MTD, et c'est tout.

Un périphérique bloc sous linux apparaît comme ayant des secteurs de 512 octets, ce n'est pas pour être "vaguement compatible" (comme écrit en dessous), c'est parce que c'est le _fondement_ même d'un périphérique de type bloc ! Tout le système des block io de linux et des autres OS est basé sur cette assomption.

Ensuite, tu n'as aucun contrôle sur comment est géré le cache, l'écriture, etc. de tes blocs derrière, à moins de tripatouiller dans le système de gestion de périphs bloc du kernel.

Pour tes valeurs d'erase block, de taille de page et autre, tu dis du "vachement souvent" ou "normalement" : déjà, la quasi totalité des constructeurs ne communiquent pas dessus, et les seuls que j'ai pu voir étaient tous différents.

Et de toute façon, comment sais-tu de quelle façon va gérer la FTL derrière ? Peut-être qu'elle flush tout à chaque écriture d'un bloc (= effacement d'un erase block qqpart, récriture du contenu en entier + tes nouvelles données .... super efficace ; je soupçonne les clés USB de faire ça, vu leur durée de vie), ou alors peut-être est-elle plus "intelligente", mais comment va se comporter ton algo avec ça ?

Bref, je ne comprend pas vraiment l'utilité du truc si vous (j'ai cru comprendre que tu faisais également partie du projet) n'avez pas au moins une connaissance solide de ce sur quoi vous bossez.

Voilà, tout ça sans parler du "problème", si votre objectif est de faire quelque chose qui marche partout (vu que vous faites du windows aussi, je suppose que c'est un peu votre objectif) d'arriver à avoir un format assez répandu pour être lu de manière pratique sur beaucoup de machines ...

Mince, je ne connaissais pas script ; j'aurais bien voulu la connaître du temps où j'étais étudiant.

Je pense qu'il voulais dire que le premier redimensionnement était pour remettre la taille du FS à la taille de la partition (qui n'avait pas bougée).

Sinon, pour l'"ordre", si vraiment tu veux en mettre un, ça dépend de l'opération : si on diminue la taille, on fait d'abord le FS et après la table, et si on agrandi, on fait d'abord la table, et après le FS.

Je me répète, et ça fait longtemps que du monde le dit (mais personne ne le code /o\) mais les news mises "en haut" de première page ne sont pas lisibles du tout. Ça fait une semaine qu'elle est publiée et je viens juste de la voir. Déjà, rien que mettre une fonte plus petite que le reste est débile. Je n'ai pas vraiment de solution, à part peut-être la laisser "en double", en haut mais également dans le fil normal des news, histoire de pas la louper.

Halala, les joies de l'esclav^Wexploita^W^Wla jeunesse qui fait des stages ... Si tu débutes en réseau, commence par quelque chose de plus simple que CARP, genre essaye de voir comment marchent les réseaux ensemble, puis regarde le filtrage, puis CARP. Ça fait du taf, mais sinon tu vas ne rien y comprendre, stresser et faire un truc complètement bancal (si ça marche ...).

Et puis si tu veux que les autres voient ton message, répond dans le thread.

Pas mal ton code. Quelques remarques (encore :-)) :
- Tu peux écrire la plupart des caractères de manière "lisible", pas besoin de mettre directement leur code ASCII : pour espace par exemple, met if (caractereActuel == ' ')
- Pour l'histoire du fgetc() et de l'int : dans le man de fgetc, tu vois que son type de retour est 'int'. Quand tu lis un peu plus loin, il est dit que cette fonction renvoie soit "un unsigned char transformé en int", soit "EOF". C'est parce qu'un caractère peut prendre la valeur 0 à 255 (ou -128 à 127 pour un non signé, mais c'est pareil), et que là tu n'as pas la "place" de caser une valeur pour EOF. Donc, fgetc() renvoit un int, qui vaudra soit -1 (pour EOF, mais t'es pas censé le savoir ; oublie le, mais en pratique ça dépanne des fois) soit de 0 à 255 (pour un caractère normal). Dans ton code, tu cast directement vers un char, donc tu ne "verras" pas la différence entre le caractère 0xff (ou 255)(ou -1) et EOF. Bon, tu vas me dire, au final, tu t'en fous, tu ne gère pas ce caractère. Mais pour une prochaine fois où tu liras des flux "binaires", fais-y attention. Dans ton code, il suffirait à priori de changer la déclaration de caractereActuel en int.
- Enfin, dans ta gestion de fin de fichier, je bouclerais simplement sur un while (caractereActuel != EOF) et je fermerait le fichier après. Bon, ça c'est vraiment pour le style, genre j'ai envie de raccourcir le code ; ton code reste tout à fait fonctionnel (juste que l'alternative à ton test sur EOF qui reteste sur != de EOF, ça fait un peu "moche").

Les seules fois où le réseau se met à "ralentir", c'est quand je sature mon upload. Tant qu'il n'est pas saturé, je peux télécharger 4 trucs en parallèles tout en surfant sans problème. Et depuis longtemps, sous Debian.

Peut-être voulais-tu donc parler de téléchargement en P2P, sale pirate ?

Et pourquoi t'as pas fait une mise à jour pour ta Kubuntu, pas hasard ?

Alors, en ce qui concerne la "qualité" de ton code (chacun a sa propre vision de ce qui est "bien", donc prend la suite avec des pincettes) :
- atoi() aurait pu servir, si tu avais des nombres qui tiennent sur plus d'un caractère (en fait, ce ne seraient plus des "chiffres"), mais comme il travaille sur des chaînes C, il aurait fallu lui fournir soit des chaînes terminées par \0. Bref, dans ton cas, c'est cool ça marche bien avec l'astuce c-'0'.
- Pour les boucles, avec l'expérience, j'ai appris à toujours commencer par 0 et à utiliser quasi uniquement des strictement inférieur. Pour moi c'est beaucoup plus lisible.
- fgetc() est un peu "bancal" dans le signalement d'EOF, et une utilisation correcte voudrait que tu récupères d'abord un int, le teste voir si ce n'est pas un EOF, et _après_ tu cast vers un _unsigned_ char, qui est la manière la plus "naturelle" de bosser sur des caractères ASCII (ton -38 pour le retour à la ligne je trouve ça moche par rapport à un '\n' ... d'ailleurs pourquoi -38 ? ça a l'air de correspondre à rien de très logique ...) et te permettera surtout de différencier un caractère 0xff dans ton fichier par rapport à la vraie fin du fichier.
- D'un autre coté, si tu sais que tu auras _exactement_ 6 caractères sur une ligne (5 chiffres + un LF), t'as pas besoin de faire de test du tout, juste un getc() dans le vide.
- Mais bon, on voit bien que t'essayes de te soucier un peu des cas d'erreurs possibles, mais il reste encore plein de "failles" si tu voulais faire un truc robuste. D'un côté, ce n'est peut-être pas ton objectif ...

Perso, je pense qu'une eeebox sera moins compliquée à mettre en place qu'un routeur, si c'est ce qui te fait peur.

Je dirais même que je crois que ça a déjà été documenté sur ce forum, si ma mémoire est bonne.

Bon, moi je te crois, mais bon, c'est vrai que c'est pas très malin de demander comment installer windows sur un forum de linuxiens ... tu trouveras des informations plus pertinentes sur un forum windows ?

Sinon, pour ton problème, pourrais-tu être plus spécifique, vu que tu parles de CD mais que ton ordi n'a pas l'air d'avoir de lecteur ...
Et je n'ai aucun conseil particulier à te donner pour effacer linux, vu que windows se démerde très bien pour le faire tout seul dès l'installation.

période.
Quel anglicisme de merde, quand même ...

J'ai bien dû lire les trois premières ligne de ton lien "argumenté" avant de cliquer sur inutile, et sans regrets ...