Ce papier compare les performances de NetBSD-2.0 et FreeBSD-5.3 http://www.feyrer.de/NetBSD/gmcgarry/
NetBSD sort gagnant, en attendant les réactions (le papier est il honnete?).
Sachant que McGarry est développeur NetBSD, on ne peut pas considérer son papier comme objectif... (-:
pornin
According to Emmanuel Dreyfus :
NetBSD sort gagnant, en attendant les réactions (le papier est il honnete?).
Les différents graphes qui montrent pour FreeBSD un temps linéaire en le nombre de processus existants (création et destruction de processus) sont probablement dûs au fait que FreeBSD 5.3 utilise le "vieux" scheduler (SCHED_4BSD) par défaut. Il existe aussi le "nouveau" scheduler (SCHED_ULE) qui devrait éviter cette linéarité, et donner quelque chose qui ressemble à ce que fait NetBSD.
Le papier est honnête en ce sens que FreeBSD 5.3 a effectivement SCHED_4BSD par défaut. Le papier est malhonnête en ce sens qu'il laisse fortement supposer que les benchs portent sur un nouveau scheduler ; cf l'introduction : « Indeed, the FreeBSD-5 branch has been plagued with problems from the very beginning. These problems have primarily centered round an ambitious new scheduler, a complicated threading model and fine-grained SMP architecture. »
Je serais assez curieux de savoir ce que donnent ces benchs avec SCHED_ULE, surtout que FreeBSD 5.4 l'utilisera probablement par défaut. De ce point de vue, ce papier est à obsolescence rapide.
--Thomas Pornin
According to Emmanuel Dreyfus <manu@netbsd.org>:
NetBSD sort gagnant, en attendant les réactions (le papier est il
honnete?).
Les différents graphes qui montrent pour FreeBSD un temps linéaire
en le nombre de processus existants (création et destruction de
processus) sont probablement dûs au fait que FreeBSD 5.3 utilise
le "vieux" scheduler (SCHED_4BSD) par défaut. Il existe aussi le
"nouveau" scheduler (SCHED_ULE) qui devrait éviter cette linéarité,
et donner quelque chose qui ressemble à ce que fait NetBSD.
Le papier est honnête en ce sens que FreeBSD 5.3 a effectivement
SCHED_4BSD par défaut. Le papier est malhonnête en ce sens qu'il laisse
fortement supposer que les benchs portent sur un nouveau scheduler ; cf
l'introduction : « Indeed, the FreeBSD-5 branch has been plagued with
problems from the very beginning. These problems have primarily centered
round an ambitious new scheduler, a complicated threading model and
fine-grained SMP architecture. »
Je serais assez curieux de savoir ce que donnent ces benchs avec
SCHED_ULE, surtout que FreeBSD 5.4 l'utilisera probablement par défaut.
De ce point de vue, ce papier est à obsolescence rapide.
NetBSD sort gagnant, en attendant les réactions (le papier est il honnete?).
Les différents graphes qui montrent pour FreeBSD un temps linéaire en le nombre de processus existants (création et destruction de processus) sont probablement dûs au fait que FreeBSD 5.3 utilise le "vieux" scheduler (SCHED_4BSD) par défaut. Il existe aussi le "nouveau" scheduler (SCHED_ULE) qui devrait éviter cette linéarité, et donner quelque chose qui ressemble à ce que fait NetBSD.
Le papier est honnête en ce sens que FreeBSD 5.3 a effectivement SCHED_4BSD par défaut. Le papier est malhonnête en ce sens qu'il laisse fortement supposer que les benchs portent sur un nouveau scheduler ; cf l'introduction : « Indeed, the FreeBSD-5 branch has been plagued with problems from the very beginning. These problems have primarily centered round an ambitious new scheduler, a complicated threading model and fine-grained SMP architecture. »
Je serais assez curieux de savoir ce que donnent ces benchs avec SCHED_ULE, surtout que FreeBSD 5.4 l'utilisera probablement par défaut. De ce point de vue, ce papier est à obsolescence rapide.
--Thomas Pornin
F. Senault
NetBSD sort gagnant, en attendant les réactions (le papier est il honnete?).
Sans avis expert, y'a au moins un truc qui m'a fait marrer : sur le graphe http://www.feyrer.de/NetBSD/gmcgarry/#fig:bind , la légende dit "The results show that both NetBSD and FreeBSD scale linearly with the number of bound sockets. For a small number of bound sockets, NetBSD has the better latency than FreeBSD. However, the linear gradient for NetBSD is significantly worse than FreeBSD."
La ligne rouge a l'air de progresser linéairement, pour vous ?
Fred -- Cron's disease: Symptoms include an obsessive-compulsive behaviour at regular intervals throughout the day, week, or month. (Clinton A. Pierce, in the SDM)
NetBSD sort gagnant, en attendant les réactions (le papier est il
honnete?).
Sans avis expert, y'a au moins un truc qui m'a fait marrer : sur le
graphe http://www.feyrer.de/NetBSD/gmcgarry/#fig:bind , la légende dit
"The results show that both NetBSD and FreeBSD scale linearly with the
number of bound sockets. For a small number of bound sockets, NetBSD has
the better latency than FreeBSD. However, the linear gradient for NetBSD
is significantly worse than FreeBSD."
La ligne rouge a l'air de progresser linéairement, pour vous ?
Fred
--
Cron's disease: Symptoms include an obsessive-compulsive behaviour at
regular intervals throughout the day, week, or month.
(Clinton A. Pierce, in the SDM)
NetBSD sort gagnant, en attendant les réactions (le papier est il honnete?).
Sans avis expert, y'a au moins un truc qui m'a fait marrer : sur le graphe http://www.feyrer.de/NetBSD/gmcgarry/#fig:bind , la légende dit "The results show that both NetBSD and FreeBSD scale linearly with the number of bound sockets. For a small number of bound sockets, NetBSD has the better latency than FreeBSD. However, the linear gradient for NetBSD is significantly worse than FreeBSD."
La ligne rouge a l'air de progresser linéairement, pour vous ?
Fred -- Cron's disease: Symptoms include an obsessive-compulsive behaviour at regular intervals throughout the day, week, or month. (Clinton A. Pierce, in the SDM)
Laurent Lefevre
(Thomas Pornin) writes:
Le papier est honnête en ce sens que FreeBSD 5.3 a effectivement SCHED_4BSD par défaut. Le papier est malhonnête en ce sens qu'il laisse fortement supposer que les benchs portent sur un nouveau scheduler ; cf l'introduction : « Indeed, the FreeBSD-5 branch has been plagued with problems from the very beginning. These problems have primarily centered round an ambitious new scheduler, a complicated threading model and fine-grained SMP architecture. »
Je serais assez curieux de savoir ce que donnent ces benchs avec SCHED_ULE, surtout que FreeBSD 5.4 l'utilisera probablement par défaut. De ce point de vue, ce papier est à obsolescence rapide.
Bof, bof, pas glop , sched_ule.c, ligne 60 : #error "The SCHED_ULE scheduler is broken. Please use SCHED_4BSD"
Et depuis un bout de temps, donc, oui, il est honnete.
-- Laurent
pornin@nerim.net (Thomas Pornin) writes:
Le papier est honnête en ce sens que FreeBSD 5.3 a effectivement
SCHED_4BSD par défaut. Le papier est malhonnête en ce sens qu'il laisse
fortement supposer que les benchs portent sur un nouveau scheduler ; cf
l'introduction : « Indeed, the FreeBSD-5 branch has been plagued with
problems from the very beginning. These problems have primarily centered
round an ambitious new scheduler, a complicated threading model and
fine-grained SMP architecture. »
Je serais assez curieux de savoir ce que donnent ces benchs avec
SCHED_ULE, surtout que FreeBSD 5.4 l'utilisera probablement par défaut.
De ce point de vue, ce papier est à obsolescence rapide.
Bof, bof, pas glop , sched_ule.c, ligne 60 :
#error "The SCHED_ULE scheduler is broken. Please use SCHED_4BSD"
Et depuis un bout de temps, donc, oui, il est honnete.
Le papier est honnête en ce sens que FreeBSD 5.3 a effectivement SCHED_4BSD par défaut. Le papier est malhonnête en ce sens qu'il laisse fortement supposer que les benchs portent sur un nouveau scheduler ; cf l'introduction : « Indeed, the FreeBSD-5 branch has been plagued with problems from the very beginning. These problems have primarily centered round an ambitious new scheduler, a complicated threading model and fine-grained SMP architecture. »
Je serais assez curieux de savoir ce que donnent ces benchs avec SCHED_ULE, surtout que FreeBSD 5.4 l'utilisera probablement par défaut. De ce point de vue, ce papier est à obsolescence rapide.
Bof, bof, pas glop , sched_ule.c, ligne 60 : #error "The SCHED_ULE scheduler is broken. Please use SCHED_4BSD"
Et depuis un bout de temps, donc, oui, il est honnete.
-- Laurent
Thomas van Oudenhove
bonjour,
À (at) Thu, 6 Jan 2005 08:23:20 +0000 (UTC), (Thomas Pornin) écrivait (wrote):
According to Emmanuel Dreyfus :
NetBSD sort gagnant, en attendant les réactions (le papier est il honnete?).
[...]
Je serais assez curieux de savoir ce que donnent ces benchs avec SCHED_ULE, surtout que FreeBSD 5.4 l'utilisera probablement par défaut. De ce point de vue, ce papier est à obsolescence rapide.
je précise tout d'abord que mon objectif n'est pas de déclencher un troll... j'ai juste une question assez naïve :
je n'ai lu qu'en diagonale ce papier, mais la question que je me pose est la suivante : quels sont les avantages à utiliser FreeBSD *si* les performances sur x86 passent en dessous de NetBSD ? le catalogue des ports ? ...
merci pour tout embryon de réponse,
-- Thomas vO - <http://www.enstimac.fr/~vanouden/>
bonjour,
À (at) Thu, 6 Jan 2005 08:23:20 +0000 (UTC),
pornin@nerim.net (Thomas Pornin) écrivait (wrote):
According to Emmanuel Dreyfus <manu@netbsd.org>:
NetBSD sort gagnant, en attendant les réactions (le papier est il
honnete?).
[...]
Je serais assez curieux de savoir ce que donnent ces benchs avec
SCHED_ULE, surtout que FreeBSD 5.4 l'utilisera probablement par défaut.
De ce point de vue, ce papier est à obsolescence rapide.
je précise tout d'abord que mon objectif n'est pas de déclencher un
troll... j'ai juste une question assez naïve :
je n'ai lu qu'en diagonale ce papier, mais la question que je me pose
est la suivante : quels sont les avantages à utiliser FreeBSD *si* les
performances sur x86 passent en dessous de NetBSD ? le catalogue des
ports ? ...
merci pour tout embryon de réponse,
--
Thomas vO - <http://www.enstimac.fr/~vanouden/>
À (at) Thu, 6 Jan 2005 08:23:20 +0000 (UTC), (Thomas Pornin) écrivait (wrote):
According to Emmanuel Dreyfus :
NetBSD sort gagnant, en attendant les réactions (le papier est il honnete?).
[...]
Je serais assez curieux de savoir ce que donnent ces benchs avec SCHED_ULE, surtout que FreeBSD 5.4 l'utilisera probablement par défaut. De ce point de vue, ce papier est à obsolescence rapide.
je précise tout d'abord que mon objectif n'est pas de déclencher un troll... j'ai juste une question assez naïve :
je n'ai lu qu'en diagonale ce papier, mais la question que je me pose est la suivante : quels sont les avantages à utiliser FreeBSD *si* les performances sur x86 passent en dessous de NetBSD ? le catalogue des ports ? ...
merci pour tout embryon de réponse,
-- Thomas vO - <http://www.enstimac.fr/~vanouden/>
pornin
According to Laurent Lefevre :
Bof, bof, pas glop , sched_ule.c, ligne 60 : #error "The SCHED_ULE scheduler is broken. Please use SCHED_4BSD"
Et depuis un bout de temps, donc, oui, il est honnete.
J'avais pas vu ça. J'avais utilisé SCHED_ULE fin septembre dernier.
--Thomas Pornin
According to Laurent Lefevre <llefevre@nerim.gov.spam.net>:
Bof, bof, pas glop , sched_ule.c, ligne 60 :
#error "The SCHED_ULE scheduler is broken. Please use SCHED_4BSD"
Et depuis un bout de temps, donc, oui, il est honnete.
J'avais pas vu ça. J'avais utilisé SCHED_ULE fin septembre dernier.
Bof, bof, pas glop , sched_ule.c, ligne 60 : #error "The SCHED_ULE scheduler is broken. Please use SCHED_4BSD"
Et depuis un bout de temps, donc, oui, il est honnete.
J'avais pas vu ça. J'avais utilisé SCHED_ULE fin septembre dernier.
--Thomas Pornin
F. Senault
je n'ai lu qu'en diagonale ce papier, mais la question que je me pose est la suivante : quels sont les avantages à utiliser FreeBSD *si* les performances sur x86 passent en dessous de NetBSD ? le catalogue des ports ? ...
Le support multi-processeurs est supposé meilleur, et le développement semble beaucoup s'orienter plateformes 64bits (AMD64 notamment).
En tout cas, c'est ce que quelqu'un vient de répondre au *gros troll* qui vient de pêter sur la mailing-list... :)
Fred -- Still feel it all slipping away but it doesn't matter anymore Everybody's still chipping away but it doesn't matter anymore Look through these blackened eyes You'll see ten thousand lies My lips may promise but my heart is a whore (Nine Inch Nails, Last)
je n'ai lu qu'en diagonale ce papier, mais la question que je me pose
est la suivante : quels sont les avantages à utiliser FreeBSD *si* les
performances sur x86 passent en dessous de NetBSD ? le catalogue des
ports ? ...
Le support multi-processeurs est supposé meilleur, et le développement
semble beaucoup s'orienter plateformes 64bits (AMD64 notamment).
En tout cas, c'est ce que quelqu'un vient de répondre au *gros troll*
qui vient de pêter sur la mailing-list... :)
Fred
--
Still feel it all slipping away but it doesn't matter anymore
Everybody's still chipping away but it doesn't matter anymore
Look through these blackened eyes You'll see ten thousand lies
My lips may promise but my heart is a whore (Nine Inch Nails, Last)
je n'ai lu qu'en diagonale ce papier, mais la question que je me pose est la suivante : quels sont les avantages à utiliser FreeBSD *si* les performances sur x86 passent en dessous de NetBSD ? le catalogue des ports ? ...
Le support multi-processeurs est supposé meilleur, et le développement semble beaucoup s'orienter plateformes 64bits (AMD64 notamment).
En tout cas, c'est ce que quelqu'un vient de répondre au *gros troll* qui vient de pêter sur la mailing-list... :)
Fred -- Still feel it all slipping away but it doesn't matter anymore Everybody's still chipping away but it doesn't matter anymore Look through these blackened eyes You'll see ten thousand lies My lips may promise but my heart is a whore (Nine Inch Nails, Last)
pornin
According to Thomas van Oudenhove <vanouden+:
je n'ai lu qu'en diagonale ce papier, mais la question que je me pose est la suivante : quels sont les avantages à utiliser FreeBSD *si* les performances sur x86 passent en dessous de NetBSD ? le catalogue des ports ? ...
Tout d'abord, précisons que les performances ne sont à estimer qu'en fonction d'un usage. Le papier fait attention à ne parler que pour des _serveurs_ et pour une forte montée en charge. C'est assez spécifique comme usage. Pour une utilisation en bête station de travail ou équivalent, on ne voit pas de différence de performances entre FreeBSD et NetBSD (ni avec Linux, OpenBSD ou Solaris, d'ailleurs).
Il y a plein de critères qui peuvent entrer en ligne de compte pour ce qui est de choisir entre deux OS, et l'importance de ces critères dépend de qui les évalue. Chacun fait son choix ici. Les raisons qui font que, personnellement, j'utilise FreeBSD plutôt que NetBSD sont, plus ou moins par ordre décroissant d'importance (pour moi) :
-- Mes machines étaient sous FreeBSD et donc continuent à être sous FreeBSD (l'installation la plus simple est celle qui est déjà faite, quel que soit l'OS).
-- J'ai plus l'habitude de l'administration des machines FreeBSD.
-- Geom (je l'utilise sur un serveur pour faire un miroir entre deux disques).
-- Port Java natif sous FreeBSD (contrairement à NetBSD, du moins il y a quelques mois / années)(le port natif est important pour avoir un plugin dans un Mozilla / Firefox natif).
-- Support des threads (sous FreeBSD 5.3, avec les KSE).
-- Netgraph (pour quelques essais de fabrication de carte ethernet virtuelle).
-- Meilleur support de la part des constructeurs de logiciels (par exemple, il y a un driver Nvidia binaire pour FreeBSD -- non que je l'utilise, mais je trouve agréable d'avoir un OS considéré comme "existant" par les constructeurs).
-- Je préfère la politique de release de FreeBSD.
Aucune de ces raisons n'est absolue. Je pourrais survivre avec du NetBSD ou de l'OpenBSD, ou du Linux. Il fût un temps où ma machine principale était sous Solaris, et je n'en étais pas mécontent non plus.
--Thomas Pornin
According to Thomas van Oudenhove <vanouden+news@enstimac.fr>:
je n'ai lu qu'en diagonale ce papier, mais la question que je me pose
est la suivante : quels sont les avantages à utiliser FreeBSD *si* les
performances sur x86 passent en dessous de NetBSD ? le catalogue des
ports ? ...
Tout d'abord, précisons que les performances ne sont à estimer qu'en
fonction d'un usage. Le papier fait attention à ne parler que pour des
_serveurs_ et pour une forte montée en charge. C'est assez spécifique
comme usage. Pour une utilisation en bête station de travail ou
équivalent, on ne voit pas de différence de performances entre FreeBSD
et NetBSD (ni avec Linux, OpenBSD ou Solaris, d'ailleurs).
Il y a plein de critères qui peuvent entrer en ligne de compte pour ce
qui est de choisir entre deux OS, et l'importance de ces critères dépend
de qui les évalue. Chacun fait son choix ici. Les raisons qui font que,
personnellement, j'utilise FreeBSD plutôt que NetBSD sont, plus ou moins
par ordre décroissant d'importance (pour moi) :
-- Mes machines étaient sous FreeBSD et donc continuent à être sous
FreeBSD (l'installation la plus simple est celle qui est déjà faite,
quel que soit l'OS).
-- J'ai plus l'habitude de l'administration des machines FreeBSD.
-- Geom (je l'utilise sur un serveur pour faire un miroir entre deux
disques).
-- Port Java natif sous FreeBSD (contrairement à NetBSD, du moins il y a
quelques mois / années)(le port natif est important pour avoir un plugin
dans un Mozilla / Firefox natif).
-- Support des threads (sous FreeBSD 5.3, avec les KSE).
-- Netgraph (pour quelques essais de fabrication de carte ethernet
virtuelle).
-- Meilleur support de la part des constructeurs de logiciels (par
exemple, il y a un driver Nvidia binaire pour FreeBSD -- non que je
l'utilise, mais je trouve agréable d'avoir un OS considéré comme
"existant" par les constructeurs).
-- Je préfère la politique de release de FreeBSD.
Aucune de ces raisons n'est absolue. Je pourrais survivre avec du NetBSD
ou de l'OpenBSD, ou du Linux. Il fût un temps où ma machine principale
était sous Solaris, et je n'en étais pas mécontent non plus.
je n'ai lu qu'en diagonale ce papier, mais la question que je me pose est la suivante : quels sont les avantages à utiliser FreeBSD *si* les performances sur x86 passent en dessous de NetBSD ? le catalogue des ports ? ...
Tout d'abord, précisons que les performances ne sont à estimer qu'en fonction d'un usage. Le papier fait attention à ne parler que pour des _serveurs_ et pour une forte montée en charge. C'est assez spécifique comme usage. Pour une utilisation en bête station de travail ou équivalent, on ne voit pas de différence de performances entre FreeBSD et NetBSD (ni avec Linux, OpenBSD ou Solaris, d'ailleurs).
Il y a plein de critères qui peuvent entrer en ligne de compte pour ce qui est de choisir entre deux OS, et l'importance de ces critères dépend de qui les évalue. Chacun fait son choix ici. Les raisons qui font que, personnellement, j'utilise FreeBSD plutôt que NetBSD sont, plus ou moins par ordre décroissant d'importance (pour moi) :
-- Mes machines étaient sous FreeBSD et donc continuent à être sous FreeBSD (l'installation la plus simple est celle qui est déjà faite, quel que soit l'OS).
-- J'ai plus l'habitude de l'administration des machines FreeBSD.
-- Geom (je l'utilise sur un serveur pour faire un miroir entre deux disques).
-- Port Java natif sous FreeBSD (contrairement à NetBSD, du moins il y a quelques mois / années)(le port natif est important pour avoir un plugin dans un Mozilla / Firefox natif).
-- Support des threads (sous FreeBSD 5.3, avec les KSE).
-- Netgraph (pour quelques essais de fabrication de carte ethernet virtuelle).
-- Meilleur support de la part des constructeurs de logiciels (par exemple, il y a un driver Nvidia binaire pour FreeBSD -- non que je l'utilise, mais je trouve agréable d'avoir un OS considéré comme "existant" par les constructeurs).
-- Je préfère la politique de release de FreeBSD.
Aucune de ces raisons n'est absolue. Je pourrais survivre avec du NetBSD ou de l'OpenBSD, ou du Linux. Il fût un temps où ma machine principale était sous Solaris, et je n'en étais pas mécontent non plus.
--Thomas Pornin
Olivier Tharan
* Thomas van Oudenhove (Thu, 06 Jan 2005 13:28:21 +0100):
je n'ai lu qu'en diagonale ce papier, mais la question que je me pose est la suivante : quels sont les avantages à utiliser FreeBSD *si* les performances sur x86 passent en dessous de NetBSD ? le catalogue des ports ? ...
Aucun, bien sûr.
Au fait, quelle sera l'utilisation réelle de _votre_ machine au final ? Ce benchmark ne semble pas s'intéresser aux interactions avec le disque, mais ce n'est peut-être pas si important que ça finalement.
-- olive
* Thomas van Oudenhove <vanouden@cf.webpage.invalid> (Thu, 06 Jan 2005 13:28:21 +0100):
je n'ai lu qu'en diagonale ce papier, mais la question que je me pose
est la suivante : quels sont les avantages à utiliser FreeBSD *si* les
performances sur x86 passent en dessous de NetBSD ? le catalogue des
ports ? ...
Aucun, bien sûr.
Au fait, quelle sera l'utilisation réelle de _votre_ machine au final ?
Ce benchmark ne semble pas s'intéresser aux interactions avec le disque,
mais ce n'est peut-être pas si important que ça finalement.
* Thomas van Oudenhove (Thu, 06 Jan 2005 13:28:21 +0100):
je n'ai lu qu'en diagonale ce papier, mais la question que je me pose est la suivante : quels sont les avantages à utiliser FreeBSD *si* les performances sur x86 passent en dessous de NetBSD ? le catalogue des ports ? ...
Aucun, bien sûr.
Au fait, quelle sera l'utilisation réelle de _votre_ machine au final ? Ce benchmark ne semble pas s'intéresser aux interactions avec le disque, mais ce n'est peut-être pas si important que ça finalement.
-- olive
Nicolas Le Scouarnec
#error "The SCHED_ULE scheduler is broken. Please use SCHED_4BSD" Et depuis un bout de temps, donc, oui, il est honnete. J'avais pas vu ça. J'avais utilisé SCHED_ULE fin septembre dernier.
Il plante(ait) très très rapidement sur SMP, mais se comportait bien sur mono-processeur. Il a été "vérouillé" pour que les gens n'essaient pas de l'utiliser en 5.3.
-- Nicolas Le Scouarnec
#error "The SCHED_ULE scheduler is broken. Please use SCHED_4BSD"
Et depuis un bout de temps, donc, oui, il est honnete.
J'avais pas vu ça. J'avais utilisé SCHED_ULE fin septembre dernier.
Il plante(ait) très très rapidement sur SMP, mais se comportait bien
sur mono-processeur. Il a été "vérouillé" pour que les gens n'essaient
pas de l'utiliser en 5.3.
#error "The SCHED_ULE scheduler is broken. Please use SCHED_4BSD" Et depuis un bout de temps, donc, oui, il est honnete. J'avais pas vu ça. J'avais utilisé SCHED_ULE fin septembre dernier.
Il plante(ait) très très rapidement sur SMP, mais se comportait bien sur mono-processeur. Il a été "vérouillé" pour que les gens n'essaient pas de l'utiliser en 5.3.
