Je me pose une question depuis un moment, on sait que le compteur de bytes transmis/reçus va jusqu'à 4 Go puis repasse à 0. Mais ça fait un bon moment que c'est comme ça, sachant la place que ça prend ce compteur ( ridicule ) et les débits actuels, pourquoi ne pas avoir étendu cette limite ( doublé la taille du champ par exemple ) sur les kernel plus récents ? Est ce qu'on sort là des définitions du kernel pour entrer dans celles de la norme TCP/IP ? Est-ce un problème de compatibilité ? De norme spéciale ? Je ne vois pas trop ce qui utiliserait de manière si critique cette donnée en fait...
 
( j'ai un peu envie monter la limite dans le source du kernel mais je sens que si le cast est mis partout je vais en avoir pour un moment à tout étendre )

Sly Angel a écrit a écrit : Je me pose une question depuis un moment, on sait que le compteur de bytes transmis/reçus va jusqu'à 4 Go puis repasse à 0. Mais ça fait un bon moment que c'est comme ça, sachant la place que ça prend ce compteur ( ridicule ) et les débits actuels, pourquoi ne pas avoir étendu cette limite ( doublé la taille du champ par exemple ) sur les kernel plus récents ? Est ce qu'on sort là des définitions du kernel pour entrer dans celles de la norme TCP/IP ? Est-ce un problème de compatibilité ? De norme spéciale ? Je ne vois pas trop ce qui utiliserait de manière si critique cette donnée en fait...   ( j'ai un peu envie monter la limite dans le source du kernel mais je sens que si le cast est mis partout je vais en avoir pour un moment à tout étendre )

Je pense pas que ce soit propre à TCP/IP ... à mon avis cé juste un choix d'implémentation qui a été fait il y a un peu de temps déjà ... on l'a oublié ... entre temps les débits et l'utilisation de Linux en tant que serveur (en prod) ont bien changés, et du coup cette limite est "vite" franchie ... Certains ont pe déjà essayé de regarder mais ils ont du s'apercevoir que s'ils touchaient ca, ca risquait de faire péter à d'autres endroits du kernel ... et comme y'a pas mort d'homme à le laisser à 4 Go, ils se sont dit que le jeu en valait pas la chandelle ...
Enfin c'est ma facon de voir les choses, voilou ...

Zzozo a écrit a écrit :   Je pense pas que ce soit propre à TCP/IP ... à mon avis cé juste un choix d'implémentation qui a été fait il y a un peu de temps déjà ... on l'a oublié ... entre temps les débits et l'utilisation de Linux en tant que serveur (en prod) ont bien changés, et du coup cette limite est "vite" franchie ... Certains ont pe déjà essayé de regarder mais ils ont du s'apercevoir que s'ils touchaient ca, ca risquait de faire péter à d'autres endroits du kernel ... et comme y'a pas mort d'homme à le laisser à 4 Go, ils se sont dit que le jeu en valait pas la chandelle ... Enfin c'est ma facon de voir les choses, voilou ...

 
C'est un peu ce que je pense, c'est pour ça que ça me fait un peu peur d'y toucher C'est juste pour le fun et par curiosité en fait

Sly Angel a écrit a écrit :     C'est un peu ce que je pense, c'est pour ça que ça me fait un peu peur d'y toucher C'est juste pour le fun et par curiosité en fait

Je suis pas allé voir ... il est typé comment ce champ actuellement ? (cé bien un champ dans une structure cé ca ?)

J'ai un peu regardé, je suis tombé sur un champ en unsigned int ( logique 32 bits -> 4G ) dans une structure qui regroupe en fait exactement les infos dans /proc/net/dev . Je me demandais si c'était parce que le int est mieux géré que le long int en rapidité, mais bon si c'est un proce 32 bits ok mais pourquoi pas gérer du 64 bits selon l'architecture ( genre un alpha ) ?
 
Je vais peut etre voir à changer la structure, je pense qu'il va le recaster ensuite donc que ce sera peine perdue, mais bon, ça me coute rien de faire mumuse

excellente idée !

Sly Angel a écrit a écrit : J'ai un peu regardé, je suis tombé sur un champ en signed int ( logique 32 bits -> 4G ) dans une structure qui regroupe en fait exactement les infos dans /proc/net/dev . Je me demandais si c'était parce que le int est mieux géré que le long int en rapidité, mais bon si c'est un proce 32 bits ok mais pourquoi pas gérer du 64 bits selon l'architecture ( genre un alpha ) ?   Je vais peut etre voir à changer la structure, je pense qu'il va le recaster ensuite donc que ce sera peine perdue, mais bon, ça me coute rien de faire mumuse

Et pourquoi pas un unsigned int ?    
Enfin bon cé pas pour ce qu'on va récupérer ...
Ben sinon le int sur 32 bits viens se mapper pile poile sur les registres des procs 32 bits je pense ...

Zzozo a écrit a écrit :   Et pourquoi pas un unsigned int ?     Enfin bon cé pas pour ce qu'on va récupérer ... Ben sinon le int sur 32 bits viens se mapper pile poile sur les registres des procs 32 bits je pense ...

 
euh je voulais dire un unsigned int pardon ( j'ai pas écrit ce que je pensais )
 
oui c'est clair que c'est carrément plus optimisé en 32 bits, ça doit être la raison ( mais bon sur d'autres archis que i386 ça pourrait être plus )
 
SuperX : Ouais, mais je sais pas si je vais tenter si faut que je change plein de cast partout ( c'est stats->rx_bytes et tx_bytes avec une struture net_device_stats qui est concerné, mais je pense qu'ils sont régulièrement recastés ailleurs )
 
Je ferai des tests demain si j'ai un peu de temps, là j'ai plus de neurones pour ce soir ( je vous tiens au courant si ça semble tenir la route, sinon je vous poste le crash )

Sly Angel a écrit a écrit :     euh je voulais dire un unsigned int pardon ( j'ai pas écrit ce que je pensais )   oui c'est clair que c'est carrément plus optimisé en 32 bits, ça doit être la raison ( mais bon sur d'autres archis que i386 ça pourrait être plus )

Et moi j'ai pas fait attention qu'un signed int c'est pas 4 Go mais moins ...