Ca doit faire... 4 ou 3 ans que j'entends dire que l'implémentation du NFS
par Linux est... mauvaise.
Il y a une raison pour qu'en 4 ans rien n'ait avancé depuis?
Je ne ma plains pas hein, je me demande juste pourquoi. Dans la mesre ou
sur certaines features c'est allé assez vite mais sur celui-ci, c'est
anormalement lent... n'est-ce pas?
--
A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL).
Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads & documentation.
Free hosting of CPS groupware: http://www.objectis.org.
Le Fri, 11 Nov 2005 17:50:28 +0000, Michel Talon a écrit :
Si tu fais tourner sur une machine 4 fois plus rapide, avec 4 fois plus de mémoire, une carte réseau 10 fois plus rapide, des disques 4 fois plus rapides et que tu viens annoncer triomphalement que ton NFS est 4 fois plus rapide que chez le voisin, tu as démontré quoi exactement?
Rien, par contre dans mon cas j'ai démontré que sur un serveur donné, NFS donne une performance similaire à Samba, et pas énormément inférieure à FTP. Bien entendu, NFS consomme nettement plus de CPU que Samba et FTP pour le même débit mais le résultat est là. Si ça peut te faire plaisir je ferai le test sur une config de test que j'ai (PII450 avec 128Mo de RAM) et je pense que le résultat sera le même : performance de NFS équivalente aux autres systèmes de partage réseau.
-- Quidquid latine dictum sit, altum sonatur
Le Fri, 11 Nov 2005 17:50:28 +0000, Michel Talon a écrit :
Si tu fais tourner sur une machine 4 fois plus rapide, avec 4 fois plus de
mémoire, une carte réseau 10 fois plus rapide, des disques 4 fois plus
rapides et que tu viens annoncer triomphalement que ton NFS est 4 fois
plus rapide que chez le voisin, tu as démontré quoi exactement?
Rien, par contre dans mon cas j'ai démontré que sur un serveur donné,
NFS donne une performance similaire à Samba, et pas énormément
inférieure à FTP. Bien entendu, NFS consomme nettement plus de CPU que
Samba et FTP pour le même débit mais le résultat est là. Si ça peut
te faire plaisir je ferai le test sur une config de test que j'ai (PII450
avec 128Mo de RAM) et je pense que le résultat sera le même :
performance de NFS équivalente aux autres systèmes de partage réseau.
Le Fri, 11 Nov 2005 17:50:28 +0000, Michel Talon a écrit :
Si tu fais tourner sur une machine 4 fois plus rapide, avec 4 fois plus de mémoire, une carte réseau 10 fois plus rapide, des disques 4 fois plus rapides et que tu viens annoncer triomphalement que ton NFS est 4 fois plus rapide que chez le voisin, tu as démontré quoi exactement?
Rien, par contre dans mon cas j'ai démontré que sur un serveur donné, NFS donne une performance similaire à Samba, et pas énormément inférieure à FTP. Bien entendu, NFS consomme nettement plus de CPU que Samba et FTP pour le même débit mais le résultat est là. Si ça peut te faire plaisir je ferai le test sur une config de test que j'ai (PII450 avec 128Mo de RAM) et je pense que le résultat sera le même : performance de NFS équivalente aux autres systèmes de partage réseau.
-- Quidquid latine dictum sit, altum sonatur
stephane
On 2005-11-11, Michel Talon wrote:
À partir de quels indices tu as réussi à deviner quel type de disques il a?
Certes, mais des disques qui écrivent en continu à 80 Mo/s ça ne court pas les rues. En moyenne la moitié est déjà pas mal. Par contre il est notoire que Linux te donne des informations complètement fausses et optimistes sur les taux de transfert, parceque le noyau retourne de l'appel système avant que le transfert ait été effectué. Il est bien connu qu'il faut utiliser raw-io pour obtenir des benchs fiables.
De toutes facons, il veut pas tester ses disques durs, mais le NFS.
-- http://www.unices.org Photos, humour et autres blogueries
On 2005-11-11, Michel Talon <talon@lpthe.jussieu.fr> wrote:
À partir de quels indices tu as réussi à deviner quel type de disques
il a?
Certes, mais des disques qui écrivent en continu à 80 Mo/s ça ne court pas les
rues. En moyenne la moitié est déjà pas mal. Par contre il est notoire que
Linux te donne des informations complètement fausses et optimistes sur les
taux de transfert, parceque le noyau retourne de l'appel système avant que
le transfert ait été effectué. Il est bien connu qu'il faut utiliser raw-io
pour obtenir des benchs fiables.
De toutes facons, il veut pas tester ses disques durs, mais le NFS.
--
http://www.unices.org Photos, humour et autres blogueries
À partir de quels indices tu as réussi à deviner quel type de disques il a?
Certes, mais des disques qui écrivent en continu à 80 Mo/s ça ne court pas les rues. En moyenne la moitié est déjà pas mal. Par contre il est notoire que Linux te donne des informations complètement fausses et optimistes sur les taux de transfert, parceque le noyau retourne de l'appel système avant que le transfert ait été effectué. Il est bien connu qu'il faut utiliser raw-io pour obtenir des benchs fiables.
De toutes facons, il veut pas tester ses disques durs, mais le NFS.
-- http://www.unices.org Photos, humour et autres blogueries
stephane
On 2005-11-11, Michel Talon wrote:
Là encore, dans mon labo il n'y a aucun PC à 5000 euros. Il faudrait arrêter un peu l'élitisme des fois.
Ce qui explique sans doute les problemes de perfs en NFS.
-- http://www.unices.org Photos, humour et autres blogueries
On 2005-11-11, Michel Talon <talon@lpthe.jussieu.fr> wrote:
Là encore, dans mon labo il n'y a aucun PC à 5000 euros. Il faudrait
arrêter un peu l'élitisme des fois.
Ce qui explique sans doute les problemes de perfs en NFS.
--
http://www.unices.org Photos, humour et autres blogueries
Là encore, dans mon labo il n'y a aucun PC à 5000 euros. Il faudrait arrêter un peu l'élitisme des fois.
Ce qui explique sans doute les problemes de perfs en NFS.
-- http://www.unices.org Photos, humour et autres blogueries
talon
Emmanuel Florac wrote:
Le Fri, 11 Nov 2005 17:50:28 +0000, Michel Talon a écrit :
Si tu fais tourner sur une machine 4 fois plus rapide, avec 4 fois plus de mémoire, une carte réseau 10 fois plus rapide, des disques 4 fois plus rapides et que tu viens annoncer triomphalement que ton NFS est 4 fois plus rapide que chez le voisin, tu as démontré quoi exactement?
Rien, par contre dans mon cas j'ai démontré que sur un serveur donné, NFS donne une performance similaire à Samba, et pas énormément inférieure à FTP. Bien entendu, NFS consomme nettement plus de CPU que Samba et FTP pour le même débit mais le résultat est là. Si ça peut te faire plaisir je ferai le test sur une config de test que j'ai (PII450 avec 128Mo de RAM) et je pense que le résultat sera le même : performance de NFS équivalente aux autres systèmes de partage réseau.
Est-ce que je t'ai dit le contraire? En fait voici un exemple, les deux cp que je fais sont de disque local à disque NFS. Le premier est de Linux à Linux, le deuxième de Linux à FreeBSD. Le tout sur du réseau 100Mb/s. -rw-r--r-- 1 talon lpthe 36M Oct 21 2004 RIP-11.1.fbsd.iso horus% time (cp RIP-11.1.fbsd.iso ~;sync) (; cp -i RIP-11.1.fbsd.iso ~; sync; ) 0.01s user 0.32s system 6% cpu 4.735 total niobe% time (cp RIP-11.1.fbsd.iso ~;sync) (; cp RIP-11.1.fbsd.iso ~; sync; ) 0,00s user 0,30s system 9% cpu 3,248 total Le transfer sur FreeBSD est même un peu plus rapide. On est grosso modo à 9MB/s soit 72Mb/s ce qui est raisonnable par rapport aux 100Mb/s. Ce n'est pas de la vitesse que je me plains, c'est des problèmes. Et c'est toujours pareil avec Linux, dans tous les domaines, ils choisissent la solution de facilité qui donne des performances éblouissantes à première vue mais cause des problèmes dans tous les coins. Un exemple récent, les gens de FreeBSD se demandaient pourquoi MySQL tourne beaucoup plus vite sous Linux que sous FreeBSD. Ils ont fini par trouver que Mysql fait une quantité phénoménale d'appels à gettimeofday(), et que cet appel est 5 fois plus long sous FreeBSD que sous Linux. Et pourquoi? Linux utilise une horloge rapide mais fausse. En particulier sur un multiprocesseur les temps donnés peuvent être désynchronisés et donc le futur et le passé mélangés. Clairement c'est le genre de choses à mettre le souk.
--
Michel TALON
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Le Fri, 11 Nov 2005 17:50:28 +0000, Michel Talon a écrit :
Si tu fais tourner sur une machine 4 fois plus rapide, avec 4 fois plus de
mémoire, une carte réseau 10 fois plus rapide, des disques 4 fois plus
rapides et que tu viens annoncer triomphalement que ton NFS est 4 fois
plus rapide que chez le voisin, tu as démontré quoi exactement?
Rien, par contre dans mon cas j'ai démontré que sur un serveur donné,
NFS donne une performance similaire à Samba, et pas énormément
inférieure à FTP. Bien entendu, NFS consomme nettement plus de CPU que
Samba et FTP pour le même débit mais le résultat est là. Si ça peut
te faire plaisir je ferai le test sur une config de test que j'ai (PII450
avec 128Mo de RAM) et je pense que le résultat sera le même :
performance de NFS équivalente aux autres systèmes de partage réseau.
Est-ce que je t'ai dit le contraire? En fait voici un exemple, les deux cp
que je fais sont de disque local à disque NFS. Le premier est de Linux
à Linux, le deuxième de Linux à FreeBSD. Le tout sur du réseau 100Mb/s.
-rw-r--r-- 1 talon lpthe 36M Oct 21 2004 RIP-11.1.fbsd.iso
horus% time (cp RIP-11.1.fbsd.iso ~;sync)
(; cp -i RIP-11.1.fbsd.iso ~; sync; ) 0.01s user 0.32s system 6% cpu 4.735
total
niobe% time (cp RIP-11.1.fbsd.iso ~;sync)
(; cp RIP-11.1.fbsd.iso ~; sync; ) 0,00s user 0,30s system 9% cpu 3,248 total
Le transfer sur FreeBSD est même un peu plus rapide. On est grosso modo à
9MB/s soit 72Mb/s ce qui est raisonnable par rapport aux 100Mb/s.
Ce n'est pas de la vitesse que je me plains, c'est des problèmes. Et c'est
toujours pareil avec Linux, dans tous les domaines, ils choisissent la
solution de facilité qui donne des performances éblouissantes à première vue
mais cause des problèmes dans tous les coins.
Un exemple récent, les gens de FreeBSD se demandaient pourquoi MySQL tourne
beaucoup plus vite sous Linux que sous FreeBSD. Ils ont fini par trouver que
Mysql fait une quantité phénoménale d'appels à gettimeofday(), et que cet
appel est 5 fois plus long sous FreeBSD que sous Linux. Et pourquoi? Linux
utilise une horloge rapide mais fausse. En particulier sur un multiprocesseur
les temps donnés peuvent être désynchronisés et donc le futur et le passé
mélangés. Clairement c'est le genre de choses à mettre le souk.
Le Fri, 11 Nov 2005 17:50:28 +0000, Michel Talon a écrit :
Si tu fais tourner sur une machine 4 fois plus rapide, avec 4 fois plus de mémoire, une carte réseau 10 fois plus rapide, des disques 4 fois plus rapides et que tu viens annoncer triomphalement que ton NFS est 4 fois plus rapide que chez le voisin, tu as démontré quoi exactement?
Rien, par contre dans mon cas j'ai démontré que sur un serveur donné, NFS donne une performance similaire à Samba, et pas énormément inférieure à FTP. Bien entendu, NFS consomme nettement plus de CPU que Samba et FTP pour le même débit mais le résultat est là. Si ça peut te faire plaisir je ferai le test sur une config de test que j'ai (PII450 avec 128Mo de RAM) et je pense que le résultat sera le même : performance de NFS équivalente aux autres systèmes de partage réseau.
Est-ce que je t'ai dit le contraire? En fait voici un exemple, les deux cp que je fais sont de disque local à disque NFS. Le premier est de Linux à Linux, le deuxième de Linux à FreeBSD. Le tout sur du réseau 100Mb/s. -rw-r--r-- 1 talon lpthe 36M Oct 21 2004 RIP-11.1.fbsd.iso horus% time (cp RIP-11.1.fbsd.iso ~;sync) (; cp -i RIP-11.1.fbsd.iso ~; sync; ) 0.01s user 0.32s system 6% cpu 4.735 total niobe% time (cp RIP-11.1.fbsd.iso ~;sync) (; cp RIP-11.1.fbsd.iso ~; sync; ) 0,00s user 0,30s system 9% cpu 3,248 total Le transfer sur FreeBSD est même un peu plus rapide. On est grosso modo à 9MB/s soit 72Mb/s ce qui est raisonnable par rapport aux 100Mb/s. Ce n'est pas de la vitesse que je me plains, c'est des problèmes. Et c'est toujours pareil avec Linux, dans tous les domaines, ils choisissent la solution de facilité qui donne des performances éblouissantes à première vue mais cause des problèmes dans tous les coins. Un exemple récent, les gens de FreeBSD se demandaient pourquoi MySQL tourne beaucoup plus vite sous Linux que sous FreeBSD. Ils ont fini par trouver que Mysql fait une quantité phénoménale d'appels à gettimeofday(), et que cet appel est 5 fois plus long sous FreeBSD que sous Linux. Et pourquoi? Linux utilise une horloge rapide mais fausse. En particulier sur un multiprocesseur les temps donnés peuvent être désynchronisés et donc le futur et le passé mélangés. Clairement c'est le genre de choses à mettre le souk.
--
Michel TALON
Emmanuel Florac
Le Sat, 12 Nov 2005 09:30:27 +0000, Michel Talon a écrit :
Ce n'est pas de la vitesse que je me plains, c'est des problèmes. Et c'est toujours pareil avec Linux, dans tous les domaines, ils choisissent la solution de facilité qui donne des performances éblouissantes à première vue mais cause des problèmes dans tous les coins.
Je n'ai pas de problèmes avec NFS, désolé pour toi... Pourtant dans ma boîte presque toutes les machines sont sous Linux (il y a un windows, un IRIX, un Solaris et un Mac OS X).
Un exemple récent, les gens de FreeBSD se demandaient pourquoi MySQL tourne beaucoup plus vite sous Linux que sous FreeBSD. Ils ont fini par trouver que Mysql fait une quantité phénoménale d'appels à gettimeofday(), et que cet appel est 5 fois plus long sous FreeBSD que sous Linux. Et pourquoi? Linux utilise une horloge rapide mais fausse. En particulier sur un multiprocesseur les temps donnés peuvent être désynchronisés et donc le futur et le passé mélangés. Clairement c'est le genre de choses à mettre le souk.
Et ce serait la faute de Linux et pas de MySQL? Hum. De toute façon ton hsitoire d'horloge, c'est la fameuse approche "worse is better", donc rien de nouveau sous le soleil :)
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Le Sat, 12 Nov 2005 09:30:27 +0000, Michel Talon a écrit :
Ce n'est pas de la vitesse que je me plains, c'est des problèmes. Et c'est
toujours pareil avec Linux, dans tous les domaines, ils choisissent la
solution de facilité qui donne des performances éblouissantes à première vue
mais cause des problèmes dans tous les coins.
Je n'ai pas de problèmes avec NFS, désolé pour toi... Pourtant dans ma
boîte presque toutes les machines sont sous Linux (il y a un windows, un
IRIX, un Solaris et un Mac OS X).
Un exemple récent, les gens de FreeBSD se demandaient pourquoi MySQL tourne
beaucoup plus vite sous Linux que sous FreeBSD. Ils ont fini par trouver que
Mysql fait une quantité phénoménale d'appels à gettimeofday(), et que cet
appel est 5 fois plus long sous FreeBSD que sous Linux. Et pourquoi? Linux
utilise une horloge rapide mais fausse. En particulier sur un multiprocesseur
les temps donnés peuvent être désynchronisés et donc le futur et le passé
mélangés. Clairement c'est le genre de choses à mettre le souk.
Et ce serait la faute de Linux et pas de MySQL? Hum. De toute façon ton
hsitoire d'horloge, c'est la fameuse approche "worse is better", donc rien
de nouveau sous le soleil :)
--
Mais monsieur, voudriez-vous que je me l'écorchasse?
Barbey d'Aurevilly.
Le Sat, 12 Nov 2005 09:30:27 +0000, Michel Talon a écrit :
Ce n'est pas de la vitesse que je me plains, c'est des problèmes. Et c'est toujours pareil avec Linux, dans tous les domaines, ils choisissent la solution de facilité qui donne des performances éblouissantes à première vue mais cause des problèmes dans tous les coins.
Je n'ai pas de problèmes avec NFS, désolé pour toi... Pourtant dans ma boîte presque toutes les machines sont sous Linux (il y a un windows, un IRIX, un Solaris et un Mac OS X).
Un exemple récent, les gens de FreeBSD se demandaient pourquoi MySQL tourne beaucoup plus vite sous Linux que sous FreeBSD. Ils ont fini par trouver que Mysql fait une quantité phénoménale d'appels à gettimeofday(), et que cet appel est 5 fois plus long sous FreeBSD que sous Linux. Et pourquoi? Linux utilise une horloge rapide mais fausse. En particulier sur un multiprocesseur les temps donnés peuvent être désynchronisés et donc le futur et le passé mélangés. Clairement c'est le genre de choses à mettre le souk.
Et ce serait la faute de Linux et pas de MySQL? Hum. De toute façon ton hsitoire d'horloge, c'est la fameuse approche "worse is better", donc rien de nouveau sous le soleil :)
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Nicolas George
Michel Talon, dans le message <dl4cnj$lt1$, a écrit :
Et pourquoi? Linux utilise une horloge rapide mais fausse. En particulier sur un multiprocesseur les temps donnés peuvent être désynchronisés
Je ne sais pas si c'est le problème dont j'ai entendu parler, mais si c'est ça, c'est dit de manière extrêmement simpliste. Ce que je connais est ceci : le noyau utilise le TSC du processeur. En multi-processeur, il y a deux TSC indépendants, en monoprocesseur, un seul évidemment. En dual-core, il avait été fait l'hypothèse que les deux cores verraient un même TSC, ce qui n'était pas le cas ; ça a été corrigé depuis.
Michel Talon, dans le message <dl4cnj$lt1$2@asmodee.lpthe.jussieu.fr>, a
écrit :
Et pourquoi? Linux
utilise une horloge rapide mais fausse. En particulier sur un multiprocesseur
les temps donnés peuvent être désynchronisés
Je ne sais pas si c'est le problème dont j'ai entendu parler, mais si c'est
ça, c'est dit de manière extrêmement simpliste. Ce que je connais est ceci :
le noyau utilise le TSC du processeur. En multi-processeur, il y a deux TSC
indépendants, en monoprocesseur, un seul évidemment. En dual-core, il avait
été fait l'hypothèse que les deux cores verraient un même TSC, ce qui
n'était pas le cas ; ça a été corrigé depuis.
Michel Talon, dans le message <dl4cnj$lt1$, a écrit :
Et pourquoi? Linux utilise une horloge rapide mais fausse. En particulier sur un multiprocesseur les temps donnés peuvent être désynchronisés
Je ne sais pas si c'est le problème dont j'ai entendu parler, mais si c'est ça, c'est dit de manière extrêmement simpliste. Ce que je connais est ceci : le noyau utilise le TSC du processeur. En multi-processeur, il y a deux TSC indépendants, en monoprocesseur, un seul évidemment. En dual-core, il avait été fait l'hypothèse que les deux cores verraient un même TSC, ce qui n'était pas le cas ; ça a été corrigé depuis.
talon
Nicolas George <nicolas$ wrote:
Michel Talon, dans le message <dl4cnj$lt1$, a écrit :
Et pourquoi? Linux utilise une horloge rapide mais fausse. En particulier sur un multiprocesseur les temps donnés peuvent être désynchronisés
Je ne sais pas si c'est le problème dont j'ai entendu parler, mais si c'est ça, c'est dit de manière extrêmement simpliste. Ce que je connais est ceci : le noyau utilise le TSC du processeur. En multi-processeur, il y a deux TSC indépendants, en monoprocesseur, un seul évidemment. En dual-core, il avait été fait l'hypothèse que les deux cores verraient un même TSC, ce qui n'était pas le cas ; ça a été corrigé depuis.
C'est effectivement ça, Linux utilise le TSC du processeur, qui est une horloge de mauvaise qualité, et qui n'est pas synchronisée d'un processeur à l'autre sur un multiproc. FreeBSD utilise quand elle est disponible l'horloge acpi-fast qui est beaucoup plus précise, et qui est unique dans la machine. On peut lui demander d'utiliser l'horloge TSC et alors comme par miracle on retombe sur les mêmes temps d'execution que Linux. Comme toujours il n'y a pas de miracle.
--
Michel TALON
Nicolas George <nicolas$george@salle-s.org> wrote:
Michel Talon, dans le message <dl4cnj$lt1$2@asmodee.lpthe.jussieu.fr>, a
écrit :
Et pourquoi? Linux
utilise une horloge rapide mais fausse. En particulier sur un multiprocesseur
les temps donnés peuvent être désynchronisés
Je ne sais pas si c'est le problème dont j'ai entendu parler, mais si c'est
ça, c'est dit de manière extrêmement simpliste. Ce que je connais est ceci :
le noyau utilise le TSC du processeur. En multi-processeur, il y a deux TSC
indépendants, en monoprocesseur, un seul évidemment. En dual-core, il avait
été fait l'hypothèse que les deux cores verraient un même TSC, ce qui
n'était pas le cas ; ça a été corrigé depuis.
C'est effectivement ça, Linux utilise le TSC du processeur, qui est une
horloge de mauvaise qualité, et qui n'est pas synchronisée d'un processeur
à l'autre sur un multiproc. FreeBSD utilise quand elle est disponible
l'horloge acpi-fast qui est beaucoup plus précise, et qui est unique dans la
machine. On peut lui demander d'utiliser l'horloge TSC et alors comme par
miracle on retombe sur les mêmes temps d'execution que Linux. Comme toujours
il n'y a pas de miracle.
Michel Talon, dans le message <dl4cnj$lt1$, a écrit :
Et pourquoi? Linux utilise une horloge rapide mais fausse. En particulier sur un multiprocesseur les temps donnés peuvent être désynchronisés
Je ne sais pas si c'est le problème dont j'ai entendu parler, mais si c'est ça, c'est dit de manière extrêmement simpliste. Ce que je connais est ceci : le noyau utilise le TSC du processeur. En multi-processeur, il y a deux TSC indépendants, en monoprocesseur, un seul évidemment. En dual-core, il avait été fait l'hypothèse que les deux cores verraient un même TSC, ce qui n'était pas le cas ; ça a été corrigé depuis.
C'est effectivement ça, Linux utilise le TSC du processeur, qui est une horloge de mauvaise qualité, et qui n'est pas synchronisée d'un processeur à l'autre sur un multiproc. FreeBSD utilise quand elle est disponible l'horloge acpi-fast qui est beaucoup plus précise, et qui est unique dans la machine. On peut lui demander d'utiliser l'horloge TSC et alors comme par miracle on retombe sur les mêmes temps d'execution que Linux. Comme toujours il n'y a pas de miracle.
--
Michel TALON
Emmanuel Florac
Le Sat, 12 Nov 2005 11:14:45 +0100, Thierry Herbelot a écrit :
Y aurait-il des bugs dans le NFS du kernel 2.4 (pourtant c'est du bien rassis, non ?), corrigé au moins dans les versions 2.6 "patchées" ?
Peut-être un bins dans les versions de protocole ?
-- Je suis riche des biens dont je sais me passer. Louis-Jean-Baptiste Etienne Vigée.
Le Sat, 12 Nov 2005 11:14:45 +0100, Thierry Herbelot a écrit :
Y aurait-il des bugs dans le NFS du kernel 2.4 (pourtant c'est du bien
rassis, non ?), corrigé au moins dans les versions 2.6 "patchées" ?
Peut-être un bins dans les versions de protocole ?
--
Je suis riche des biens dont je sais me passer.
Louis-Jean-Baptiste Etienne Vigée.
Le Sat, 12 Nov 2005 11:14:45 +0100, Thierry Herbelot a écrit :
Y aurait-il des bugs dans le NFS du kernel 2.4 (pourtant c'est du bien rassis, non ?), corrigé au moins dans les versions 2.6 "patchées" ?
Peut-être un bins dans les versions de protocole ?
-- Je suis riche des biens dont je sais me passer. Louis-Jean-Baptiste Etienne Vigée.
Nicolas George
Michel Talon, dans le message <dl4ov8$pll$, a écrit :
horloge de mauvaise qualité
Cette affirmation m'a l'air complètement pipo. Que le TSC soit plus dur à utiliser comme source de temps précise qu'une horloge prévue pour, c'est assez évident. Mais une fois correctement utilisée, avec les bonnes corrections des facteurs perturbateurs, il n'y a aucune raison que ce soit moins précis, au contraire.
Et, soit dit en passant, si FreeBSD a des options pour utiliser le TSC, Linux a tout autant d'options pour ne pas l'utiliser, donc bon.
Michel Talon, dans le message <dl4ov8$pll$1@asmodee.lpthe.jussieu.fr>, a
écrit :
horloge de mauvaise qualité
Cette affirmation m'a l'air complètement pipo. Que le TSC soit plus dur à
utiliser comme source de temps précise qu'une horloge prévue pour, c'est
assez évident. Mais une fois correctement utilisée, avec les bonnes
corrections des facteurs perturbateurs, il n'y a aucune raison que ce soit
moins précis, au contraire.
Et, soit dit en passant, si FreeBSD a des options pour utiliser le TSC,
Linux a tout autant d'options pour ne pas l'utiliser, donc bon.
Michel Talon, dans le message <dl4ov8$pll$, a écrit :
horloge de mauvaise qualité
Cette affirmation m'a l'air complètement pipo. Que le TSC soit plus dur à utiliser comme source de temps précise qu'une horloge prévue pour, c'est assez évident. Mais une fois correctement utilisée, avec les bonnes corrections des facteurs perturbateurs, il n'y a aucune raison que ce soit moins précis, au contraire.
Et, soit dit en passant, si FreeBSD a des options pour utiliser le TSC, Linux a tout autant d'options pour ne pas l'utiliser, donc bon.
Deux grands gourous des horloges sont aussi des développeurs principaux pour FreeBSD (phk et imp). Les deux disent que Linux a une gestion du temps épouvantable.
Des p'tits gars de FreeBSD - le BSD qui tente de singer Linux - trouvent que Linux, ça pue ?
Deux grands gourous des horloges sont aussi des développeurs principaux pour
FreeBSD (phk et imp). Les deux disent que Linux a une gestion du temps
épouvantable.
Des p'tits gars de FreeBSD - le BSD qui tente de singer Linux -
trouvent que Linux, ça pue ?
Deux grands gourous des horloges sont aussi des développeurs principaux pour FreeBSD (phk et imp). Les deux disent que Linux a une gestion du temps épouvantable.
Des p'tits gars de FreeBSD - le BSD qui tente de singer Linux - trouvent que Linux, ça pue ?
