sur un LAN d'une quinzaine de postes, j'ai peut-être des micro-coupures
de réseau.
Hors, comme ce serait des *micro*-coupures, un simple monitoring SNMP ne
révèle rien.
Comment procéder pour savoir si ces coupures existent vraiment (en
considérant qu'il y a quelques coupures/heure)?
J'ai pensé à acheter un bon testeur de câble avec reflectomètre, mais ça
coûte dans les 400 euros (voire bcp plus).
Donc déjà, est-ce que ce serait utile et, si oui, quel testeur prendre ?
Sinon comme savoir s'il y a ce problème ? (en fait, il s'agit d'une
application qui crash en indiquant qu'il y a eu un problème de liaison,
alors que tout fonctionne bien.)
On Mon, 22 Jan 2007 22:01:48 +0100, Olivier Masson wrote:
où (à part à Paris) ? J'ai un répit d'Alzheimer, ça m'est revenu :
locamesure.fr :-)
Merci bien.
Pour le développeur, je sais bien : j'ai déjà été accusé (moi, admin réseau&système) de la lenteur de ce même logiciel qui, à fort d'insistance, est devenu plus rapide grâce à un patch. Mais là, tout le monde me tape dessus et c'est difficile à gérer (je ne suis pas salarié, donc c'est plus délicat). On peut comprendre : je passe d'un PC XP tout flasque à un super serveur sous 2K3R2 et ça ne fonctionne plus aussi bien !
On Mon, 22 Jan 2007 22:01:48 +0100, Olivier Masson
<sisemen@laposte.net> wrote:
où (à part à Paris) ?
J'ai un répit d'Alzheimer, ça m'est revenu :
locamesure.fr
:-)
Merci bien.
Pour le développeur, je sais bien : j'ai déjà été accusé (moi, admin
réseau&système) de la lenteur de ce même logiciel qui, à fort
d'insistance, est devenu plus rapide grâce à un patch.
Mais là, tout le monde me tape dessus et c'est difficile à gérer (je ne
suis pas salarié, donc c'est plus délicat).
On peut comprendre : je passe d'un PC XP tout flasque à un super serveur
sous 2K3R2 et ça ne fonctionne plus aussi bien !
On Mon, 22 Jan 2007 22:01:48 +0100, Olivier Masson wrote:
où (à part à Paris) ? J'ai un répit d'Alzheimer, ça m'est revenu :
locamesure.fr :-)
Merci bien.
Pour le développeur, je sais bien : j'ai déjà été accusé (moi, admin réseau&système) de la lenteur de ce même logiciel qui, à fort d'insistance, est devenu plus rapide grâce à un patch. Mais là, tout le monde me tape dessus et c'est difficile à gérer (je ne suis pas salarié, donc c'est plus délicat). On peut comprendre : je passe d'un PC XP tout flasque à un super serveur sous 2K3R2 et ça ne fonctionne plus aussi bien !
Nina Popravka
On Tue, 23 Jan 2007 09:37:28 +0100, Olivier Masson wrote:
On peut comprendre : je passe d'un PC XP tout flasque à un super serveur sous 2K3R2 et ça ne fonctionne plus aussi bien !
Donc le réseau n'y est pour rien :-) C'est quel genre d'appli, et écrite en quoi ? Un Win2K3R2 tout seul, ou un SBS ? -- Nina
On Tue, 23 Jan 2007 09:37:28 +0100, Olivier Masson
<sisemen@laposte.net> wrote:
On peut comprendre : je passe d'un PC XP tout flasque à un super serveur
sous 2K3R2 et ça ne fonctionne plus aussi bien !
Donc le réseau n'y est pour rien :-)
C'est quel genre d'appli, et écrite en quoi ?
Un Win2K3R2 tout seul, ou un SBS ?
--
Nina
On Tue, 23 Jan 2007 09:37:28 +0100, Olivier Masson wrote:
On peut comprendre : je passe d'un PC XP tout flasque à un super serveur sous 2K3R2 et ça ne fonctionne plus aussi bien !
Donc le réseau n'y est pour rien :-) C'est quel genre d'appli, et écrite en quoi ? Un Win2K3R2 tout seul, ou un SBS ? -- Nina
Olivier Masson
Donc le réseau n'y est pour rien :-) C'est quel genre d'appli, et écrite en quoi ? Un Win2K3R2 tout seul, ou un SBS ?
C'est écrit en Delphi. L'appli client utilise une base sur le serveur. Le serveur est neuf, tourne parfaitement, pas le moindre évènement dans les journaux, pas le moindre paquet perdu. Tous les clients ont tout à fait accès à la base (que j'ai même tenté de mettre en accès total 'tout le monde').
Donc le réseau n'y est pour rien :-)
C'est quel genre d'appli, et écrite en quoi ?
Un Win2K3R2 tout seul, ou un SBS ?
C'est écrit en Delphi. L'appli client utilise une base sur le serveur.
Le serveur est neuf, tourne parfaitement, pas le moindre évènement dans
les journaux, pas le moindre paquet perdu. Tous les clients ont tout à
fait accès à la base (que j'ai même tenté de mettre en accès total 'tout
le monde').
Donc le réseau n'y est pour rien :-) C'est quel genre d'appli, et écrite en quoi ? Un Win2K3R2 tout seul, ou un SBS ?
C'est écrit en Delphi. L'appli client utilise une base sur le serveur. Le serveur est neuf, tourne parfaitement, pas le moindre évènement dans les journaux, pas le moindre paquet perdu. Tous les clients ont tout à fait accès à la base (que j'ai même tenté de mettre en accès total 'tout le monde').
kurtz le pirate
In article , Nina Popravka wrote:
Il ne faut jamais croire un développeur qui incrimine le réseau ;->>>>
+1
mais j'ajouterais : le mode tcp est un protocole en mode connecté. de ce fait, le protocole lui même prend en charge certains problèmes réseaux.
entre autres (je ne me souviens plus de tout...) : - la remise en ordre des paquets reçus (oui, le paquet 36 peut arriver avec le 17). - la gestion des paquets perdus : hé...ho... il me manque le paquet 51 ! - la gestion des paquets corrompus. - ...
de par ces simples règles, une micro-coupure ne peut pas entraver le fonctionnement d'une application. tout au plus un léger ralentissement dû à la re-émission du paquet perdu ou corrompu pendant la micro-coupure... disons 0.1-0.5 micro seconde.
-- klp
In article <id9ar2hjs44bo8ohr80ds9srj9f6e7s2ai@4ax.com>,
Nina Popravka <Nina@nospam> wrote:
Il ne faut jamais croire un développeur qui incrimine le réseau ;->>>>
+1
mais j'ajouterais : le mode tcp est un protocole en mode connecté. de ce
fait, le protocole lui même prend en charge certains problèmes réseaux.
entre autres (je ne me souviens plus de tout...) :
- la remise en ordre des paquets reçus (oui, le paquet 36 peut arriver
avec le 17).
- la gestion des paquets perdus : hé...ho... il me manque le paquet 51 !
- la gestion des paquets corrompus.
- ...
de par ces simples règles, une micro-coupure ne peut pas entraver le
fonctionnement d'une application. tout au plus un léger ralentissement
dû à la re-émission du paquet perdu ou corrompu pendant la
micro-coupure... disons 0.1-0.5 micro seconde.
Il ne faut jamais croire un développeur qui incrimine le réseau ;->>>>
+1
mais j'ajouterais : le mode tcp est un protocole en mode connecté. de ce fait, le protocole lui même prend en charge certains problèmes réseaux.
entre autres (je ne me souviens plus de tout...) : - la remise en ordre des paquets reçus (oui, le paquet 36 peut arriver avec le 17). - la gestion des paquets perdus : hé...ho... il me manque le paquet 51 ! - la gestion des paquets corrompus. - ...
de par ces simples règles, une micro-coupure ne peut pas entraver le fonctionnement d'une application. tout au plus un léger ralentissement dû à la re-émission du paquet perdu ou corrompu pendant la micro-coupure... disons 0.1-0.5 micro seconde.
-- klp
Nina Popravka
On Tue, 23 Jan 2007 11:03:20 +0100, Olivier Masson wrote:
C'est écrit en Delphi. L'appli client utilise une base sur le serveur. Le serveur est neuf, tourne parfaitement, pas le moindre évènement dans les journaux, pas le moindre paquet perdu. Tous les clients ont tout à fait accès à la base (que j'ai même tenté de mettre en accès total 'tout le monde').
J'ai eu il y a quelques années des problèmes surréalistes de lock de fichiers sur du Delphi, justement, et le coupable était... le serveur Saari qui tournait sur la même machine. Il a fallu des semaines pour mettre le doigt dessus :-( -- Nina
On Tue, 23 Jan 2007 11:03:20 +0100, Olivier Masson
<sisemen@laposte.net> wrote:
C'est écrit en Delphi. L'appli client utilise une base sur le serveur.
Le serveur est neuf, tourne parfaitement, pas le moindre évènement dans
les journaux, pas le moindre paquet perdu. Tous les clients ont tout à
fait accès à la base (que j'ai même tenté de mettre en accès total 'tout
le monde').
J'ai eu il y a quelques années des problèmes surréalistes de lock de
fichiers sur du Delphi, justement, et le coupable était... le serveur
Saari qui tournait sur la même machine. Il a fallu des semaines pour
mettre le doigt dessus :-(
--
Nina
On Tue, 23 Jan 2007 11:03:20 +0100, Olivier Masson wrote:
C'est écrit en Delphi. L'appli client utilise une base sur le serveur. Le serveur est neuf, tourne parfaitement, pas le moindre évènement dans les journaux, pas le moindre paquet perdu. Tous les clients ont tout à fait accès à la base (que j'ai même tenté de mettre en accès total 'tout le monde').
J'ai eu il y a quelques années des problèmes surréalistes de lock de fichiers sur du Delphi, justement, et le coupable était... le serveur Saari qui tournait sur la même machine. Il a fallu des semaines pour mettre le doigt dessus :-( -- Nina
Zythum
On Tue, 23 Jan 2007 09:37:28 +0100, Olivier Masson wrote:
On peut comprendre : je passe d'un PC XP tout flasque à un super serveur sous 2K3R2 et ça ne fonctionne plus aussi bien !
un grand classique ;-)
Donc le réseau n'y est pour rien :-)
pas forcément, un élément majeur du réseau vient d'être changé : la carte réseau du serveur.
Donc une mauvaise entente avec le switch est possible.
En premier s'assurer que le port du switch et de la carte sont bien dans le même mode. Généralement on laisse en auto-négociation des deux cotés et le lien a du monter en full-duplex des deux cotés (si ce n'est pas le cas il y a un pb). Sinon, comme le switch n'est pas manageable, il faut forcer en half-duplex sur le serveur (le switch devant se replier alors en half-duplex s'il respecte la norme).
Ensuite faire des test de débit entre les stations et le serveur pour lever le doute (netcps est parfait pour ça)
Sinon, en milieu professionnel, un switch non manageable c'est être sourd et aveugle sur un réseau. Il aurait été bien d'en changer en même temps que de serveur.
-- Zythum
On Tue, 23 Jan 2007 09:37:28 +0100, Olivier Masson
<sisemen@laposte.net> wrote:
On peut comprendre : je passe d'un PC XP tout flasque à un super serveur
sous 2K3R2 et ça ne fonctionne plus aussi bien !
un grand classique ;-)
Donc le réseau n'y est pour rien :-)
pas forcément, un élément majeur du réseau vient d'être changé : la
carte réseau du serveur.
Donc une mauvaise entente avec le switch est possible.
En premier s'assurer que le port du switch et de la carte sont bien dans
le même mode.
Généralement on laisse en auto-négociation des deux cotés et le lien a
du monter en full-duplex des deux cotés (si ce n'est pas le cas il y a
un pb).
Sinon, comme le switch n'est pas manageable, il faut forcer en
half-duplex sur le serveur (le switch devant se replier alors en
half-duplex s'il respecte la norme).
Ensuite faire des test de débit entre les stations et le serveur pour
lever le doute (netcps est parfait pour ça)
Sinon, en milieu professionnel, un switch non manageable c'est être
sourd et aveugle sur un réseau. Il aurait été bien d'en changer en même
temps que de serveur.
On Tue, 23 Jan 2007 09:37:28 +0100, Olivier Masson wrote:
On peut comprendre : je passe d'un PC XP tout flasque à un super serveur sous 2K3R2 et ça ne fonctionne plus aussi bien !
un grand classique ;-)
Donc le réseau n'y est pour rien :-)
pas forcément, un élément majeur du réseau vient d'être changé : la carte réseau du serveur.
Donc une mauvaise entente avec le switch est possible.
En premier s'assurer que le port du switch et de la carte sont bien dans le même mode. Généralement on laisse en auto-négociation des deux cotés et le lien a du monter en full-duplex des deux cotés (si ce n'est pas le cas il y a un pb). Sinon, comme le switch n'est pas manageable, il faut forcer en half-duplex sur le serveur (le switch devant se replier alors en half-duplex s'il respecte la norme).
Ensuite faire des test de débit entre les stations et le serveur pour lever le doute (netcps est parfait pour ça)
Sinon, en milieu professionnel, un switch non manageable c'est être sourd et aveugle sur un réseau. Il aurait été bien d'en changer en même temps que de serveur.
-- Zythum
Eric Masson
Zythum writes:
'Lut,
Sinon, en milieu professionnel, un switch non manageable c'est être sourd et aveugle sur un réseau. Il aurait été bien d'en changer en même temps que de serveur.
Va faire comprendre ce genre de considération dans une pme... Souvent on va te répondre qu'un switch ça coute 30 ¤ dans le supermarché du coin, et que la justification d'un ton truc hors de prix est sujette à caution.
-- Je me suis achté un modem US-Robotics 56K Message. Lorsque je suis connecté (que à 32000bps) et que je décroche mon combiné il y alors un bruit"ggrrrrr" tout le temps. Est ce normal? -+- FM in <http://www.le-gnu.net> : Démodule et des hommes -+-
Zythum <x@x.x> writes:
'Lut,
Sinon, en milieu professionnel, un switch non manageable c'est être
sourd et aveugle sur un réseau. Il aurait été bien d'en changer en même
temps que de serveur.
Va faire comprendre ce genre de considération dans une pme...
Souvent on va te répondre qu'un switch ça coute 30 ¤ dans le supermarché
du coin, et que la justification d'un ton truc hors de prix est sujette
à caution.
--
Je me suis achté un modem US-Robotics 56K Message. Lorsque je suis
connecté (que à 32000bps) et que je décroche mon combiné il y alors un
bruit"ggrrrrr" tout le temps. Est ce normal?
-+- FM in <http://www.le-gnu.net> : Démodule et des hommes -+-
Sinon, en milieu professionnel, un switch non manageable c'est être sourd et aveugle sur un réseau. Il aurait été bien d'en changer en même temps que de serveur.
Va faire comprendre ce genre de considération dans une pme... Souvent on va te répondre qu'un switch ça coute 30 ¤ dans le supermarché du coin, et que la justification d'un ton truc hors de prix est sujette à caution.
-- Je me suis achté un modem US-Robotics 56K Message. Lorsque je suis connecté (que à 32000bps) et que je décroche mon combiné il y alors un bruit"ggrrrrr" tout le temps. Est ce normal? -+- FM in <http://www.le-gnu.net> : Démodule et des hommes -+-
Olivier Masson
Va faire comprendre ce genre de considération dans une pme... Souvent on va te répondre qu'un switch ça coute 30 ¤ dans le supermarché du coin, et que la justification d'un ton truc hors de prix est sujette à caution.
Ca a exactement été mon soucis : il y avait plusieurs switches 4 ou 8 ports grand public chainés et j'ai dit qu'il sera bien d'en avoir 1 seul de 24 ports. Après le "on a pas de sous" et dérivés, je me suis replié sur un simple 24 ports non manageable. Mon amour pour le SNMP ne sera pas satisfait.
Va faire comprendre ce genre de considération dans une pme...
Souvent on va te répondre qu'un switch ça coute 30 ¤ dans le supermarché
du coin, et que la justification d'un ton truc hors de prix est sujette
à caution.
Ca a exactement été mon soucis : il y avait plusieurs switches 4 ou 8
ports grand public chainés et j'ai dit qu'il sera bien d'en avoir 1 seul
de 24 ports.
Après le "on a pas de sous" et dérivés, je me suis replié sur un simple
24 ports non manageable. Mon amour pour le SNMP ne sera pas satisfait.
Va faire comprendre ce genre de considération dans une pme... Souvent on va te répondre qu'un switch ça coute 30 ¤ dans le supermarché du coin, et que la justification d'un ton truc hors de prix est sujette à caution.
Ca a exactement été mon soucis : il y avait plusieurs switches 4 ou 8 ports grand public chainés et j'ai dit qu'il sera bien d'en avoir 1 seul de 24 ports. Après le "on a pas de sous" et dérivés, je me suis replié sur un simple 24 ports non manageable. Mon amour pour le SNMP ne sera pas satisfait.
Olivier Masson
de par ces simples règles, une micro-coupure ne peut pas entraver le fonctionnement d'une application. tout au plus un léger ralentissement dû à la re-émission du paquet perdu ou corrompu pendant la micro-coupure... disons 0.1-0.5 micro seconde.
Tu as raison. C'aurait pu être de l'UDP, mais ce serait crétin d'utiliser ça pour une connection qui, justement, a besoin de ne pas être cassée.
de par ces simples règles, une micro-coupure ne peut pas entraver le
fonctionnement d'une application. tout au plus un léger ralentissement
dû à la re-émission du paquet perdu ou corrompu pendant la
micro-coupure... disons 0.1-0.5 micro seconde.
Tu as raison. C'aurait pu être de l'UDP, mais ce serait crétin
d'utiliser ça pour une connection qui, justement, a besoin de ne pas
être cassée.
de par ces simples règles, une micro-coupure ne peut pas entraver le fonctionnement d'une application. tout au plus un léger ralentissement dû à la re-émission du paquet perdu ou corrompu pendant la micro-coupure... disons 0.1-0.5 micro seconde.
Tu as raison. C'aurait pu être de l'UDP, mais ce serait crétin d'utiliser ça pour une connection qui, justement, a besoin de ne pas être cassée.
Pascal Hambourg
Salut,
mais j'ajouterais : le mode tcp est un protocole en mode connecté. de ce fait, le protocole lui même prend en charge certains problèmes réseaux.
entre autres (je ne me souviens plus de tout...) : - la remise en ordre des paquets reçus (oui, le paquet 36 peut arriver avec le 17). - la gestion des paquets perdus : hé...ho... il me manque le paquet 51 ! - la gestion des paquets corrompus. - ...
de par ces simples règles, une micro-coupure ne peut pas entraver le fonctionnement d'une application. tout au plus un léger ralentissement dû à la re-émission du paquet perdu ou corrompu pendant la micro-coupure... disons 0.1-0.5 micro seconde.
Je doute de cette valeur. Même en gigabit ethernet, la seule transmission physique d'une trame de 1500 octets prend plus de 10 µs, sans compter le temps de traitement par les OS, les cartes et les switches intermédiaires ni le temps de propagation le long des câbles. D'autre part, je n'ai jamais été très calé sur le protocole TCP, mais il me semble qu'il n'y a pas de mécanisme positif de signalisation par le destinataire à l'expéditeur de paquet perdu ou corrompu par la couche de liaison. La détection est réalisée par l'émetteur, par l'absence d'acquittement après un délai d'attente. Le temps de retransmission est donc plus ou moins lié à ce délai, qui est largement supérieur à la microseconde.
[Crosspost et suivi dans fr.comp.reseaux.ip]
Salut,
mais j'ajouterais : le mode tcp est un protocole en mode connecté. de ce
fait, le protocole lui même prend en charge certains problèmes réseaux.
entre autres (je ne me souviens plus de tout...) :
- la remise en ordre des paquets reçus (oui, le paquet 36 peut arriver
avec le 17).
- la gestion des paquets perdus : hé...ho... il me manque le paquet 51 !
- la gestion des paquets corrompus.
- ...
de par ces simples règles, une micro-coupure ne peut pas entraver le
fonctionnement d'une application. tout au plus un léger ralentissement
dû à la re-émission du paquet perdu ou corrompu pendant la
micro-coupure... disons 0.1-0.5 micro seconde.
Je doute de cette valeur. Même en gigabit ethernet, la seule
transmission physique d'une trame de 1500 octets prend plus de 10 µs,
sans compter le temps de traitement par les OS, les cartes et les
switches intermédiaires ni le temps de propagation le long des câbles.
D'autre part, je n'ai jamais été très calé sur le protocole TCP, mais il
me semble qu'il n'y a pas de mécanisme positif de signalisation par le
destinataire à l'expéditeur de paquet perdu ou corrompu par la couche de
liaison. La détection est réalisée par l'émetteur, par l'absence
d'acquittement après un délai d'attente. Le temps de retransmission est
donc plus ou moins lié à ce délai, qui est largement supérieur à la
microseconde.
mais j'ajouterais : le mode tcp est un protocole en mode connecté. de ce fait, le protocole lui même prend en charge certains problèmes réseaux.
entre autres (je ne me souviens plus de tout...) : - la remise en ordre des paquets reçus (oui, le paquet 36 peut arriver avec le 17). - la gestion des paquets perdus : hé...ho... il me manque le paquet 51 ! - la gestion des paquets corrompus. - ...
de par ces simples règles, une micro-coupure ne peut pas entraver le fonctionnement d'une application. tout au plus un léger ralentissement dû à la re-émission du paquet perdu ou corrompu pendant la micro-coupure... disons 0.1-0.5 micro seconde.
Je doute de cette valeur. Même en gigabit ethernet, la seule transmission physique d'une trame de 1500 octets prend plus de 10 µs, sans compter le temps de traitement par les OS, les cartes et les switches intermédiaires ni le temps de propagation le long des câbles. D'autre part, je n'ai jamais été très calé sur le protocole TCP, mais il me semble qu'il n'y a pas de mécanisme positif de signalisation par le destinataire à l'expéditeur de paquet perdu ou corrompu par la couche de liaison. La détection est réalisée par l'émetteur, par l'absence d'acquittement après un délai d'attente. Le temps de retransmission est donc plus ou moins lié à ce délai, qui est largement supérieur à la microseconde.
