Avec l'arrivée d'OpenBSD 3.7, pppoe(4) a été ajouté comme pseudo-device.
Est-ce que quelques-uns d'entre vous l'utilisent ?
Il est moins souple que le couple pppoe(8)/ppp(8) en matière de
configuration (timeout pour le dial on demand) mais doit donner de meilleurs
performances.
Si quelqu'un peut nous comparer les deux, merci d'avance.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Eric Masson
cplasschaert writes:
'Lut,
Avec l'arrivée d'OpenBSD 3.7, pppoe(4) a été ajouté comme pseudo-device. Est-ce que quelques-uns d'entre vous l'utilisent ?
Je l'utilise sur une tapée de soekris en 3.5 en production chez un client (le patch était dispo sur un site allemand depuis pas mal de temps).
Dans le cas présent, l'impact sur les performances est largement plus faible que celui de ppp(8), et sur une net4501, ça a son importance.
Cela a aussi permis la résolution d'un problème lors des reconnexions suite à la coupure de ligne journalière qui avait cours à l'époque pppoe(4) reconnectant sans souci, ce qui n'était pas le cas de ppp(8)
Mes 2 cents
Éric Masson
-- d'ailleurs ici c'est le seul forum ou vous voulez abolument qu'on ecrive en bas moi je prefere d'ailleurs quand c'est en haut -+- ELG in GNU: "Le chat rue avant Elbeuf" -+-
Avec l'arrivée d'OpenBSD 3.7, pppoe(4) a été ajouté comme pseudo-device.
Est-ce que quelques-uns d'entre vous l'utilisent ?
Je l'utilise sur une tapée de soekris en 3.5 en production chez un
client (le patch était dispo sur un site allemand depuis pas mal de
temps).
Dans le cas présent, l'impact sur les performances est largement plus
faible que celui de ppp(8), et sur une net4501, ça a son importance.
Cela a aussi permis la résolution d'un problème lors des reconnexions
suite à la coupure de ligne journalière qui avait cours à l'époque
pppoe(4) reconnectant sans souci, ce qui n'était pas le cas de ppp(8)
Mes 2 cents
Éric Masson
--
d'ailleurs ici c'est le seul forum ou vous voulez abolument qu'on
ecrive en bas moi je prefere d'ailleurs quand c'est en haut
-+- ELG in GNU: "Le chat rue avant Elbeuf" -+-
Avec l'arrivée d'OpenBSD 3.7, pppoe(4) a été ajouté comme pseudo-device. Est-ce que quelques-uns d'entre vous l'utilisent ?
Je l'utilise sur une tapée de soekris en 3.5 en production chez un client (le patch était dispo sur un site allemand depuis pas mal de temps).
Dans le cas présent, l'impact sur les performances est largement plus faible que celui de ppp(8), et sur une net4501, ça a son importance.
Cela a aussi permis la résolution d'un problème lors des reconnexions suite à la coupure de ligne journalière qui avait cours à l'époque pppoe(4) reconnectant sans souci, ce qui n'était pas le cas de ppp(8)
Mes 2 cents
Éric Masson
-- d'ailleurs ici c'est le seul forum ou vous voulez abolument qu'on ecrive en bas moi je prefere d'ailleurs quand c'est en haut -+- ELG in GNU: "Le chat rue avant Elbeuf" -+-
cplasschaert
Eric Masson writes:
cplasschaert writes:
Salut,
Avec l'arrivée d'OpenBSD 3.7, pppoe(4) a été ajouté comme pseudo-device. Est-ce que quelques-uns d'entre vous l'utilisent ?
Je l'utilise sur une tapée de soekris en 3.5 en production chez un client (le patch était dispo sur un site allemand depuis pas mal de temps).
Attention, la fin de vie de la 3.5 est proche ;-)
Dans le cas présent, l'impact sur les performances est largement plus faible que celui de ppp(8), et sur une net4501, ça a son importance.
Comme ce sera aussi sur du soekris, l'info a son importance.
Cela a aussi permis la résolution d'un problème lors des reconnexions suite à la coupure de ligne journalière qui avait cours à l'époque pppoe(4) reconnectant sans souci, ce qui n'était pas le cas de ppp(8)
Mes 2 cents
Je suis plus intéressé par la connexion à la demande mais d'autres seront intéressés par ceci.
C'est dommage que le timeout ne soit pas gérable via ioctl, je ne suis pas encore certain de où ce décide le timeout lorsqu'il n'y a plus de donnée à envoyer, si quelqu'un à une piste.
Avec l'arrivée d'OpenBSD 3.7, pppoe(4) a été ajouté comme pseudo-device.
Est-ce que quelques-uns d'entre vous l'utilisent ?
Je l'utilise sur une tapée de soekris en 3.5 en production chez un
client (le patch était dispo sur un site allemand depuis pas mal de
temps).
Attention, la fin de vie de la 3.5 est proche ;-)
Dans le cas présent, l'impact sur les performances est largement plus
faible que celui de ppp(8), et sur une net4501, ça a son importance.
Comme ce sera aussi sur du soekris, l'info a son importance.
Cela a aussi permis la résolution d'un problème lors des reconnexions
suite à la coupure de ligne journalière qui avait cours à l'époque
pppoe(4) reconnectant sans souci, ce qui n'était pas le cas de ppp(8)
Mes 2 cents
Je suis plus intéressé par la connexion à la demande mais d'autres seront
intéressés par ceci.
C'est dommage que le timeout ne soit pas gérable via ioctl, je ne suis pas
encore certain de où ce décide le timeout lorsqu'il n'y a plus de donnée à
envoyer, si quelqu'un à une piste.
Avec l'arrivée d'OpenBSD 3.7, pppoe(4) a été ajouté comme pseudo-device. Est-ce que quelques-uns d'entre vous l'utilisent ?
Je l'utilise sur une tapée de soekris en 3.5 en production chez un client (le patch était dispo sur un site allemand depuis pas mal de temps).
Attention, la fin de vie de la 3.5 est proche ;-)
Dans le cas présent, l'impact sur les performances est largement plus faible que celui de ppp(8), et sur une net4501, ça a son importance.
Comme ce sera aussi sur du soekris, l'info a son importance.
Cela a aussi permis la résolution d'un problème lors des reconnexions suite à la coupure de ligne journalière qui avait cours à l'époque pppoe(4) reconnectant sans souci, ce qui n'était pas le cas de ppp(8)
Mes 2 cents
Je suis plus intéressé par la connexion à la demande mais d'autres seront intéressés par ceci.
C'est dommage que le timeout ne soit pas gérable via ioctl, je ne suis pas encore certain de où ce décide le timeout lorsqu'il n'y a plus de donnée à envoyer, si quelqu'un à une piste.
Merci Mr Masson, Docteur Es Soekris
Eric Masson
cplasschaert writes:
Attention, la fin de vie de la 3.5 est proche ;-)
Oui, mais là, tant qu'un ospfd complet et débuggé ne sera pas disponible sur une release, il n'y a que très peu de chances que cela soit modifié. ça répond parfaitement aux attentes, ne fournit aucun service externe et ne laisse rien passer d'autre que du trafic ipsec de/vers des hôtes définis. Donc comme on dit, si ça fonctionne, tu ne touches pas :)
Comme ce sera aussi sur du soekris, l'info a son importance.
Je n'ai pas fait de stats de performance non plus hein...
Je suis plus intéressé par la connexion à la demande mais d'autres seront intéressés par ceci.
C'est dommage que le timeout ne soit pas gérable via ioctl, je ne suis pas encore certain de où ce décide le timeout lorsqu'il n'y a plus de donnée à envoyer, si quelqu'un à une piste.
J'suis allé voir dans /sys/net/if_pppoe.* et /sys/net/if_sppp* mais je n'ai rien vu de probant (je suis loin de comprendre tout le code, ce qui n'aide pas)
Docteur Es Soekris
Loin de là, j'ai juste eu le bol de faire quelque chose de concret avec ces petites bébêtes, rien de plus.
Éric Masson
-- Chalut la foule , ça veut dire regardez ce que je vais répondre à l'autre, déjà c'est une remarque méprisante envers quelqu'un qui ne t'a rien fait -+- Fr in GNU - Ch'est chcandaleux : che me chui fait inchulter ! -+-
Oui, mais là, tant qu'un ospfd complet et débuggé ne sera pas disponible
sur une release, il n'y a que très peu de chances que cela soit modifié.
ça répond parfaitement aux attentes, ne fournit aucun service externe et
ne laisse rien passer d'autre que du trafic ipsec de/vers des hôtes
définis. Donc comme on dit, si ça fonctionne, tu ne touches pas :)
Comme ce sera aussi sur du soekris, l'info a son importance.
Je n'ai pas fait de stats de performance non plus hein...
Je suis plus intéressé par la connexion à la demande mais d'autres seront
intéressés par ceci.
C'est dommage que le timeout ne soit pas gérable via ioctl, je ne suis pas
encore certain de où ce décide le timeout lorsqu'il n'y a plus de donnée à
envoyer, si quelqu'un à une piste.
J'suis allé voir dans /sys/net/if_pppoe.* et /sys/net/if_sppp* mais je
n'ai rien vu de probant (je suis loin de comprendre tout le code, ce qui
n'aide pas)
Docteur Es Soekris
Loin de là, j'ai juste eu le bol de faire quelque chose de concret avec
ces petites bébêtes, rien de plus.
Éric Masson
--
Chalut la foule , ça veut dire regardez ce que je vais répondre
à l'autre, déjà c'est une remarque méprisante envers quelqu'un qui ne
t'a rien fait
-+- Fr in GNU - Ch'est chcandaleux : che me chui fait inchulter ! -+-
Oui, mais là, tant qu'un ospfd complet et débuggé ne sera pas disponible sur une release, il n'y a que très peu de chances que cela soit modifié. ça répond parfaitement aux attentes, ne fournit aucun service externe et ne laisse rien passer d'autre que du trafic ipsec de/vers des hôtes définis. Donc comme on dit, si ça fonctionne, tu ne touches pas :)
Comme ce sera aussi sur du soekris, l'info a son importance.
Je n'ai pas fait de stats de performance non plus hein...
Je suis plus intéressé par la connexion à la demande mais d'autres seront intéressés par ceci.
C'est dommage que le timeout ne soit pas gérable via ioctl, je ne suis pas encore certain de où ce décide le timeout lorsqu'il n'y a plus de donnée à envoyer, si quelqu'un à une piste.
J'suis allé voir dans /sys/net/if_pppoe.* et /sys/net/if_sppp* mais je n'ai rien vu de probant (je suis loin de comprendre tout le code, ce qui n'aide pas)
Docteur Es Soekris
Loin de là, j'ai juste eu le bol de faire quelque chose de concret avec ces petites bébêtes, rien de plus.
Éric Masson
-- Chalut la foule , ça veut dire regardez ce que je vais répondre à l'autre, déjà c'est une remarque méprisante envers quelqu'un qui ne t'a rien fait -+- Fr in GNU - Ch'est chcandaleux : che me chui fait inchulter ! -+-
Miod Vallat
Attention, la fin de vie de la 3.5 est proche ;-)
Oui, mais là, tant qu'un ospfd complet et débuggé ne sera pas disponible sur une release, il n'y a que très peu de chances que cela soit modifié.
Tu n'as plus qu'à attendre 3.8 en novembre...
Attention, la fin de vie de la 3.5 est proche ;-)
Oui, mais là, tant qu'un ospfd complet et débuggé ne sera pas disponible
sur une release, il n'y a que très peu de chances que cela soit modifié.
Oui, mais là, tant qu'un ospfd complet et débuggé ne sera pas disponible sur une release, il n'y a que très peu de chances que cela soit modifié.
Tu n'as plus qu'à attendre 3.8 en novembre...
Eric Masson
Miod Vallat writes:
Tu n'as plus qu'à attendre 3.8 en novembre...
Bonne nouvelle, je n'ai pas trop suivi l'évolution d'ospfd ces derniers temps, mais si tu dis qu'il y a du progrès dans le domaine, ça vaudra le coup de faire des tests lors de la sortie de la 3.8.
Merci
Éric
-- Bonjour, je m'appelle lisa, j ai 35ans je fais des conversation erotiQUE AU TEL PAIEMMENT PAR CARTE BANCAIRE UNIQUEMENT Si cela t'interesse contacte moi au 04 91 XX 50 XX. Bisous. -+- Lisa in GNU : La morue qui avait embouché le porc de Marseille -+-
Miod Vallat <miod@online.fr> writes:
Tu n'as plus qu'à attendre 3.8 en novembre...
Bonne nouvelle, je n'ai pas trop suivi l'évolution d'ospfd ces derniers
temps, mais si tu dis qu'il y a du progrès dans le domaine, ça vaudra le
coup de faire des tests lors de la sortie de la 3.8.
Merci
Éric
--
Bonjour, je m'appelle lisa, j ai 35ans je fais des conversation erotiQUE
AU TEL PAIEMMENT PAR CARTE BANCAIRE UNIQUEMENT Si cela t'interesse
contacte moi au 04 91 XX 50 XX. Bisous.
-+- Lisa in GNU : La morue qui avait embouché le porc de Marseille -+-
Bonne nouvelle, je n'ai pas trop suivi l'évolution d'ospfd ces derniers temps, mais si tu dis qu'il y a du progrès dans le domaine, ça vaudra le coup de faire des tests lors de la sortie de la 3.8.
Merci
Éric
-- Bonjour, je m'appelle lisa, j ai 35ans je fais des conversation erotiQUE AU TEL PAIEMMENT PAR CARTE BANCAIRE UNIQUEMENT Si cela t'interesse contacte moi au 04 91 XX 50 XX. Bisous. -+- Lisa in GNU : La morue qui avait embouché le porc de Marseille -+-
Miod Vallat
Bonne nouvelle, je n'ai pas trop suivi l'évolution d'ospfd ces derniers temps, mais si tu dis qu'il y a du progrès dans le domaine, ça vaudra le coup de faire des tests lors de la sortie de la 3.8.
J'avoue ne pas l'avoir suivi de près non plus, mais il était clair qu'ospfd n'était pas mûr pour 3.7 ; depuis Esben Norby et Claudio Jeker ont fait pas mal de travail, et il n'y a aucune raison pour que d'ici 3.8 ospfd ne soit pas en excellente condition (à mon avis, c'est déjà chose faite).
Bonne nouvelle, je n'ai pas trop suivi l'évolution d'ospfd ces derniers
temps, mais si tu dis qu'il y a du progrès dans le domaine, ça vaudra le
coup de faire des tests lors de la sortie de la 3.8.
J'avoue ne pas l'avoir suivi de près non plus, mais il était clair
qu'ospfd n'était pas mûr pour 3.7 ; depuis Esben Norby et Claudio Jeker
ont fait pas mal de travail, et il n'y a aucune raison pour que d'ici
3.8 ospfd ne soit pas en excellente condition (à mon avis, c'est déjà
chose faite).
Bonne nouvelle, je n'ai pas trop suivi l'évolution d'ospfd ces derniers temps, mais si tu dis qu'il y a du progrès dans le domaine, ça vaudra le coup de faire des tests lors de la sortie de la 3.8.
J'avoue ne pas l'avoir suivi de près non plus, mais il était clair qu'ospfd n'était pas mûr pour 3.7 ; depuis Esben Norby et Claudio Jeker ont fait pas mal de travail, et il n'y a aucune raison pour que d'ici 3.8 ospfd ne soit pas en excellente condition (à mon avis, c'est déjà chose faite).
espie
In article , Eric Masson wrote:
cplasschaert writes:
'Lut,
Avec l'arrivée d'OpenBSD 3.7, pppoe(4) a été ajouté comme pseudo-device. Est-ce que quelques-uns d'entre vous l'utilisent ?
Je l'utilise sur une tapée de soekris en 3.5 en production chez un client (le patch était dispo sur un site allemand depuis pas mal de temps).
Je vais me farcir d'un `me-too'. Lorsque j'ai transfere ma ligne sur
la soekris, j'en ai profite pour passer sur pppoe-in-kernel.
J'en suis tres content. J'aime bien la simplicite de configuration, et ca marche nickel. En particulier, la sequence ifconfig pppoe0 down/ ifconfig pppoe0 up pour remonter la connexion est vachement cool.
Un soucis mineur vis-a-vis d'autres composants du systeme: le ifconfig pppoe0 up est asynchrone, ce qui a des consequences vis-a-vis d'autres sous-systemes.
- attention au demarrage de pf et a la distinction (pppoe0)/pppoe0. Perso, comme je suis en adresse IP fixe chez nerim, j'ai resolu le probleme bourrinement. - le DNS externe n'est pas disponible `assez' tot pour ntp, et donc le ntpdate ne se fait pas par defaut (mauvaise interaction entre les delais des divers schmurtz, j'en ai touche un mot a henning@, mais je n'ai pas suivi s'il avait corrige). Bref, rien de grave, j'ai rajoute un sleep au boot...
En fait, j'aurais tendance a dire que ca pourrait etre utile d'avoir un mode bloquant/synchrone cote interface. Sans doute une option dans ifconfig... mais je n'ai pas d'idee a quel point ca va etre simple ou complique a realiser.
Je ne me sens vraiment pas de faire des boucles ifconfig pppoe0 jusqu'a obtenir la bonne valeur de state, c'est trop beurk, on dirait du linux.
In article <867jiyzq8i.fsf@srvbsdnanssv.interne.kisoft-services.com>,
Eric Masson <emss@free.fr> wrote:
Avec l'arrivée d'OpenBSD 3.7, pppoe(4) a été ajouté comme pseudo-device.
Est-ce que quelques-uns d'entre vous l'utilisent ?
Je l'utilise sur une tapée de soekris en 3.5 en production chez un
client (le patch était dispo sur un site allemand depuis pas mal de
temps).
Je vais me farcir d'un `me-too'. Lorsque j'ai transfere ma ligne sur
la soekris, j'en ai profite pour passer sur pppoe-in-kernel.
J'en suis tres content. J'aime bien la simplicite de configuration,
et ca marche nickel. En particulier, la sequence ifconfig pppoe0 down/
ifconfig pppoe0 up pour remonter la connexion est vachement cool.
Un soucis mineur vis-a-vis d'autres composants du systeme: le
ifconfig pppoe0 up est asynchrone, ce qui a des consequences vis-a-vis
d'autres sous-systemes.
- attention au demarrage de pf et a la distinction (pppoe0)/pppoe0.
Perso, comme je suis en adresse IP fixe chez nerim, j'ai resolu le
probleme bourrinement.
- le DNS externe n'est pas disponible `assez' tot pour ntp, et donc le
ntpdate ne se fait pas par defaut (mauvaise interaction entre les delais
des divers schmurtz, j'en ai touche un mot a henning@, mais je n'ai pas
suivi s'il avait corrige). Bref, rien de grave, j'ai rajoute un sleep
au boot...
En fait, j'aurais tendance a dire que ca pourrait etre utile d'avoir un
mode bloquant/synchrone cote interface. Sans doute une option dans
ifconfig... mais je n'ai pas d'idee a quel point ca va etre simple ou
complique a realiser.
Je ne me sens vraiment pas de faire des boucles ifconfig pppoe0 jusqu'a
obtenir la bonne valeur de state, c'est trop beurk, on dirait du linux.
Avec l'arrivée d'OpenBSD 3.7, pppoe(4) a été ajouté comme pseudo-device. Est-ce que quelques-uns d'entre vous l'utilisent ?
Je l'utilise sur une tapée de soekris en 3.5 en production chez un client (le patch était dispo sur un site allemand depuis pas mal de temps).
Je vais me farcir d'un `me-too'. Lorsque j'ai transfere ma ligne sur
la soekris, j'en ai profite pour passer sur pppoe-in-kernel.
J'en suis tres content. J'aime bien la simplicite de configuration, et ca marche nickel. En particulier, la sequence ifconfig pppoe0 down/ ifconfig pppoe0 up pour remonter la connexion est vachement cool.
Un soucis mineur vis-a-vis d'autres composants du systeme: le ifconfig pppoe0 up est asynchrone, ce qui a des consequences vis-a-vis d'autres sous-systemes.
- attention au demarrage de pf et a la distinction (pppoe0)/pppoe0. Perso, comme je suis en adresse IP fixe chez nerim, j'ai resolu le probleme bourrinement. - le DNS externe n'est pas disponible `assez' tot pour ntp, et donc le ntpdate ne se fait pas par defaut (mauvaise interaction entre les delais des divers schmurtz, j'en ai touche un mot a henning@, mais je n'ai pas suivi s'il avait corrige). Bref, rien de grave, j'ai rajoute un sleep au boot...
En fait, j'aurais tendance a dire que ca pourrait etre utile d'avoir un mode bloquant/synchrone cote interface. Sans doute une option dans ifconfig... mais je n'ai pas d'idee a quel point ca va etre simple ou complique a realiser.
Je ne me sens vraiment pas de faire des boucles ifconfig pppoe0 jusqu'a obtenir la bonne valeur de state, c'est trop beurk, on dirait du linux.
Xav
Le 2005-04-20, Marc Espie a tapoté :
- le DNS externe n'est pas disponible `assez' tot pour ntp, et donc le ntpdate ne se fait pas par defaut (mauvaise interaction entre les delais des divers schmurtz, j'en ai touche un mot a henning@, mais je n'ai pas suivi s'il avait corrige). Bref, rien de grave, j'ai rajoute un sleep au boot...
À se sujet, rdate(8) n'est plus nécessaire au boot puisque l'option -s de ntpd(8) le fait. -s étant dans rc(8), ça m'a tout l'air d'être l'option par défaut, mais dans le man on a:
-S Do not set the time immediately at startup. This is the de- fault.
-s Set the time immediately at startup if the local clock is off by more than 180 seconds. Allows for a large time correc- tion, eliminating the need to run rdate(8) before starting ntpd. Currently, the -s option is added unconditionally in rc(8). Make sure to specify the -S option (add/edit ntpd_flags in rc.conf.local(8)) if this behaviour is not de- sired.
C'est une couille où j'ai la comprennette difficile ? xav
Le 2005-04-20, Marc Espie a tapoté :
- le DNS externe n'est pas disponible `assez' tot pour ntp, et donc le
ntpdate ne se fait pas par defaut (mauvaise interaction entre les delais
des divers schmurtz, j'en ai touche un mot a henning@, mais je n'ai pas
suivi s'il avait corrige). Bref, rien de grave, j'ai rajoute un sleep
au boot...
À se sujet, rdate(8) n'est plus nécessaire au boot puisque l'option -s
de ntpd(8) le fait. -s étant dans rc(8), ça m'a tout l'air d'être
l'option par défaut, mais dans le man on a:
-S Do not set the time immediately at startup. This is the de-
fault.
-s Set the time immediately at startup if the local clock is off
by more than 180 seconds. Allows for a large time correc-
tion, eliminating the need to run rdate(8) before starting
ntpd. Currently, the -s option is added unconditionally in
rc(8). Make sure to specify the -S option (add/edit
ntpd_flags in rc.conf.local(8)) if this behaviour is not de-
sired.
C'est une couille où j'ai la comprennette difficile ?
xav
- le DNS externe n'est pas disponible `assez' tot pour ntp, et donc le ntpdate ne se fait pas par defaut (mauvaise interaction entre les delais des divers schmurtz, j'en ai touche un mot a henning@, mais je n'ai pas suivi s'il avait corrige). Bref, rien de grave, j'ai rajoute un sleep au boot...
À se sujet, rdate(8) n'est plus nécessaire au boot puisque l'option -s de ntpd(8) le fait. -s étant dans rc(8), ça m'a tout l'air d'être l'option par défaut, mais dans le man on a:
-S Do not set the time immediately at startup. This is the de- fault.
-s Set the time immediately at startup if the local clock is off by more than 180 seconds. Allows for a large time correc- tion, eliminating the need to run rdate(8) before starting ntpd. Currently, the -s option is added unconditionally in rc(8). Make sure to specify the -S option (add/edit ntpd_flags in rc.conf.local(8)) if this behaviour is not de- sired.
C'est une couille où j'ai la comprennette difficile ? xav
raphael mazelier
cplasschaert wrote:
Bonjour à tous,
Avec l'arrivée d'OpenBSD 3.7, pppoe(4) a été ajouté comme pseudo-device. Est-ce que quelques-uns d'entre vous l'utilisent ?
Il est moins souple que le couple pppoe(8)/ppp(8) en matière de configuration (timeout pour le dial on demand) mais doit donner de meilleurs performances.
Si quelqu'un peut nous comparer les deux, merci d'avance.
C. Plasschaert
Oui je l'utilise sur ma 3.6; en ayant patché le kernel; le moins que l'on puisse dire c'est que le gain de performances est assez impressionnant. Sur mon vieux K6/200 qui me faisait office de passerelle j'etais à 80% de temps CPU en system à pleine charge (cad 8mbit de download) avec le pppoe userland. Avec le pppoe in kernel j etais descendu à 20% environ.
Bon depuis j ai changé de passerelle; mais ca marche toujours nickel!
-- raf
cplasschaert wrote:
Bonjour à tous,
Avec l'arrivée d'OpenBSD 3.7, pppoe(4) a été ajouté comme pseudo-device.
Est-ce que quelques-uns d'entre vous l'utilisent ?
Il est moins souple que le couple pppoe(8)/ppp(8) en matière de
configuration (timeout pour le dial on demand) mais doit donner de meilleurs
performances.
Si quelqu'un peut nous comparer les deux, merci d'avance.
C. Plasschaert
Oui je l'utilise sur ma 3.6; en ayant patché le kernel; le moins que
l'on puisse dire c'est que le gain de performances est assez
impressionnant. Sur mon vieux K6/200 qui me faisait office de passerelle
j'etais à 80% de temps CPU en system à pleine charge (cad 8mbit de
download) avec le pppoe userland. Avec le pppoe in kernel j etais
descendu à 20% environ.
Bon depuis j ai changé de passerelle; mais ca marche toujours nickel!
Avec l'arrivée d'OpenBSD 3.7, pppoe(4) a été ajouté comme pseudo-device. Est-ce que quelques-uns d'entre vous l'utilisent ?
Il est moins souple que le couple pppoe(8)/ppp(8) en matière de configuration (timeout pour le dial on demand) mais doit donner de meilleurs performances.
Si quelqu'un peut nous comparer les deux, merci d'avance.
C. Plasschaert
Oui je l'utilise sur ma 3.6; en ayant patché le kernel; le moins que l'on puisse dire c'est que le gain de performances est assez impressionnant. Sur mon vieux K6/200 qui me faisait office de passerelle j'etais à 80% de temps CPU en system à pleine charge (cad 8mbit de download) avec le pppoe userland. Avec le pppoe in kernel j etais descendu à 20% environ.
Bon depuis j ai changé de passerelle; mais ca marche toujours nickel!
-- raf
cplasschaert
Eric Masson writes:
cplasschaert writes:
C'est dommage que le timeout ne soit pas g+AOk-rable via ioctl, je ne suis pas encore certain de o+APk- ce d+AOk-cide le timeout lorsqu'il n'y a plus de donn+AOk-e +AOA- envoyer, si quelqu'un +AOA- une piste.
J'suis all+AOk- voir dans /sys/net/if_pppoe.* et /sys/net/if_sppp* mais je n'ai rien vu de probant (je suis loin de comprendre tout le code, ce qui n'aide pas)
Pareil, je pense que cela devrait se trouver dans /sys/net/if_spppsubr.c mais je n'arrive pas +AOA- trouver la focntion. La seule qui semble s'en approcher est sppp_keepalive mais cela resemble plus +AOA- une v+AOk-rification de d+AOk-lai sur les paquets lcp. Je dois encore v+AOk-rifier plusieurs fonctions de man9 (surtout tout ce qui est en timeout_*(9) qui pourrait m'amener au but.
C'est dommage que le timeout ne soit pas g+AOk-rable via ioctl, je ne suis pas
encore certain de o+APk- ce d+AOk-cide le timeout lorsqu'il n'y a plus de donn+AOk-e +AOA-
envoyer, si quelqu'un +AOA- une piste.
J'suis all+AOk- voir dans /sys/net/if_pppoe.* et /sys/net/if_sppp* mais je
n'ai rien vu de probant (je suis loin de comprendre tout le code, ce qui
n'aide pas)
Pareil, je pense que cela devrait se trouver dans /sys/net/if_spppsubr.c mais
je n'arrive pas +AOA- trouver la focntion. La seule qui semble s'en approcher est
sppp_keepalive mais cela resemble plus +AOA- une v+AOk-rification de d+AOk-lai sur les
paquets lcp. Je dois encore v+AOk-rifier plusieurs fonctions de man9 (surtout tout
ce qui est en timeout_*(9) qui pourrait m'amener au but.
C'est dommage que le timeout ne soit pas g+AOk-rable via ioctl, je ne suis pas encore certain de o+APk- ce d+AOk-cide le timeout lorsqu'il n'y a plus de donn+AOk-e +AOA- envoyer, si quelqu'un +AOA- une piste.
J'suis all+AOk- voir dans /sys/net/if_pppoe.* et /sys/net/if_sppp* mais je n'ai rien vu de probant (je suis loin de comprendre tout le code, ce qui n'aide pas)
Pareil, je pense que cela devrait se trouver dans /sys/net/if_spppsubr.c mais je n'arrive pas +AOA- trouver la focntion. La seule qui semble s'en approcher est sppp_keepalive mais cela resemble plus +AOA- une v+AOk-rification de d+AOk-lai sur les paquets lcp. Je dois encore v+AOk-rifier plusieurs fonctions de man9 (surtout tout ce qui est en timeout_*(9) qui pourrait m'amener au but.
