From: "Rich"
This is a multi-part message in MIME format.
------=_NextPart_000_010F_01C316EE.E70ECC00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
It's so funny how you repeatedly demonstrate that as an investigative =
reporter you are so bad at both investigation and reporting. The =
following is from the report discussed in your "article" at =
http://www.veritest.com/clients/reports/microsoft/ms_netbench.pdf.
Note: Our initial tests showed that using the TcpAckFrequency registry =
value on the testbed clients running
Windows XP Professional resulted in lower File server performance when =
testing with Red Hat Linux
Advanced Server 2.1 and Red Hat Linux 8.0 Professional. As a result, =
we removed the TcpAckFrequency
registry setting from the testbed client systems running Windows XP =
Professional when testing the Linux
configurations. With the exception of TcpAckFrequency, all other =
client registry changes listed above were in
effect during testing with the Linux configurations.
As for your continued rigging claims, are you really accusing redhat of =
rigging the tests by using ext3 as the default filesystem in redhat 9 =
installs? That is a stretch even for you and there isn't much that I =
don't think you would claim.
Rich
"Joe Barr" wrote in message =
news:pan.2003.05.10.18.14.15.105846{at}austin.rr.com...
So you are admitting that the benchmarks were rigged. Good. That's a
step in the right direction. At that pace and direction, you will =
achieve
credibility by the year 2222.
For one side you go to the extreme length of tuning the TCP stack on =
the
frigging clients, for the other you say "whatever the default =
provides.":
Do you see why people think you are a twofaced lying sack of shit, =
Shupack?
On Sat, 10 May 2003 10:59:18 -0700, wrote:
> I think it is significant to note that a clean install of redhat =
9 will
> use ext3. If people think that this is wrong they should ask =
redhat.
>=20
> Rich
>=20
> "Geo." wrote in message =
news:3ebd20e9{at}w3.nls.net...
> "Adam Flinton" wrote in message
> news:3ebcc745$1{at}w3.nls.net...
>=20
> > > I can't agree on this point, ext2 isn't suitable since it's so =
easy
> > > to
> wipe
> > > out with a simple power failure. In a fileserver you have to =
be able
> > > to count
> > > on the file system coming back up after a hard poweroff. =
Fileservers
> > > are where everyone stores their data, the file system is =
critical.
> > > ext3 is
> the
> > > only choice.
> > >
> > >
> > Why? I've tried (on a variety of work PC'es) the other 3 jfs'es =
& we
> > did
> > "turn off while buzy" tests. ReiserFS, XFS &
IBM JFS all =
seemed to
> > handle it fine. I think (but I'd have to check our test docs) =
that for
> > us on that machinery XFS was the fastest.
>=20
> the filesystem that was suggested was ext2, that was what I was
> disagreeing with, not RFS or XFS or JFS but ext2.
>=20
> Geo.
>
>
>
> =
>
>
> I
think it is =
significant to
> note that a clean install of redhat 9 will use ext3. If people =
think
> that this is wrong they should ask redhat.
face=3DArial size=3D2>
size=3D2>Rich
> style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px;
> BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
> "Geo." <georger{at}nls.net>">mailto:georger{at}nls.net">georger{at}nls.net>
> wrote in message =
href=3D"news:3ebd20e9{at}w3.nls.net">news:3ebd20e9{at}w3.nls.net..."A=
dam
> Flinton" < =
href=3D"adam{at}NOSPAM_softfab.com>">mailto:adam{at}NOSPAM_softfab.com">adam{at}NOSPAM_softfab.com>
> wrote in message =
href=3D"news:3ebcc745$1{at}w3.nls.net">news:3ebcc745$1{at}w3.nls.net...=
>
> > I can't agree on this point, ext2 isn't suitable since it's =
so easy
> towipe> > out with a simple
power failure. In a =
fileserver
> you have to be able to> >
count> > on the file
> system coming back up after a hard poweroff. Fileservers =
are>
> > where everyone stores their data, the file system is =
critical. ext3
> isthe> > only
choice.> >>> =
Why?
> I've tried (on a variety of work PC'es) the other 3 jfs'es & =
we
> did> "turn off while
buzy" tests. ReiserFS, XFS =
&
> IBM JFS all seemed to> handle it fine. I think (but I'd =
have to
> check our test docs) that for> us on that
machinery XFS was =
the
> fastest.the filesystem that was suggested was
ext2, that =
was
> what I was disagreeingwith, not RFS or XFS or JFS but
>
ext2.Geo.
--=20
------=_NextPart_000_010F_01C316EE.E70ECC00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
It's so
funny how you =
repeatedly=20
demonstrate that as an investigative reporter you are so bad at both=20
investigation and reporting. The following is from the report =
discussed in=20
your "article" at http://www.veritest.com/clients/reports/microsoft/ms_netbench.pdf=
">.<" target="new">http://www.veritest.com/clients/reports/microsoft/ms_netbench.pdf.<=
/FONT>
Note: Our=20
initial tests showed that using the TcpAckFrequency registry value on =
the=20
testbed clients running
Windows XP Professional resulted in lower File server=20
performance when testing with Red Hat Linux
Advanced Server 2.1 and Red Hat Linux 8.0 =
Professional. As a=20
result, we removed the TcpAckFrequency
registry setting from the testbed client systems =
running Windows=20
XP Professional when testing the Linux
configurations. With the exception of TcpAckFrequency, =
all other=20
client registry changes listed above were in
effect during testing with the Linux=20
configurations.
As for your continued rigging claims, =
are you=20
really accusing redhat of rigging the tests by using ext3 as the default =
filesystem in redhat 9 installs? That is a stretch even for you =
and there=20
isn't much that I don't think you would claim.
Rich
"Joe Barr" <warthawg{at}austin.rr.com>">mailto:warthawg{at}austin.rr.com">warthawg{at}austin.rr.com>
=
wrote in=20
message news:pan.2003.=
05.10.18.14.15.105846{at}austin.rr.com...So=20
you are admitting that the benchmarks were rigged. Good. =
That's=20
astep in the right direction. At that pace and direction, =
you will=20
achievecredibility by the year 2222.For one
side you go to =
the=20
extreme length of tuning the TCP stack on thefrigging clients, for =
the=20
other you say "whatever the default
provides.":Do you see why =
people=20
think you are a twofaced lying sack of shit, =
Shupack?On=20
Sat, 10 May 2003 10:59:18 -0700, =
wrote:> I=20
think it is significant to note that a clean install of redhat 9=20
will> use ext3.
If people think that =
this is=20
wrong they should ask redhat.> >
Rich>=20
> "Geo." <georger{at}nls.net>">mailto:georger{at}nls.net">georger{at}nls.net>
wrote in =
message news:3ebd20e9{at}w3.nls.net...>=
=20
"Adam Flinton" <adam{at}NOSPAM_softfab.com>">mailto:adam{at}NOSPAM_softfab.com">adam{at}NOSPAM_softfab.com>
= wrote in=20
message> news:3ebcc745$1{at}w3.nls.net...=
>=20
> > > I can't agree on
this point, ext2 isn't =
suitable since it's so easy>
> >=20
to>
wipe> > > out with a =
simple=20
power failure. In a fileserver you have to be
able> =
>=20
> to count> > >
on the file system coming =
back up=20
after a hard poweroff. Fileservers>
> > are =
where=20
everyone stores their data, the file system is =
critical.> =20
> > ext3 is>
the> > =
> only=20
choice.> >
>> >=20
>> > Why? I've tried
(on a variety of work =
PC'es) the=20
other 3 jfs'es & we> > =
did> =20
> "turn off while buzy" tests.
ReiserFS, XFS & IBM =
JFS all=20
seemed to> > handle it fine.
I think (but I'd =
have to=20
check our test docs) that for>
> us on that =
machinery=20
XFS was the fastest.>
> the filesystem that =
was=20
suggested was ext2, that was what I was> =
disagreeing with,=20
not RFS or XFS or JFS but ext2.>
> =
Geo.>=20
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 =
Transitional//EN">>=20
<HTML><HEAD>> <META
http-equiv=3DContent-Type=20
content=3D"text/html;
charset=3Diso-8859-1">> <META =
content=3D"MSHTML=20
6.00.3790.0" name=3DGENERATOR>
<STYLE></STYLE>>=20
</HEAD>> <BODY
bgColor=3D#ffffff>> =
<DIV><FONT=20
face=3DArial size=3D2> I think it is =
significant to>=20
note that a clean install of redhat 9 will use ext3. If =
people=20
think> that this is wrong they should ask=20
redhat.</FONT></DIV>
<DIV><FONT> =
face=3DArial=20
size=3D2></FONT> </DIV>
<DIV><FONT=20
face=3DArial>
size=3D2>Rich</FONT></DIV>=20
<DIV> </DIV>>
<BLOCKQUOTE>=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: =
5px;>=20
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: =
0px">> =20
<DIV>"Geo." <<A href=3D"georger{at}nls.net>'>mailto:george=">mailto:georger{at}nls.net">georger{at}nls.net>'>mailto:george=
r{at}nls.net">georger{at}nls.net</A>>> =20
wrote in message <A>
href=3D"news:3ebd20e9{at}w3.nls.net..."A=
dam'>news:3ebd20e9{at}w3.nls.net">news:3ebd20e9{at}w3.nls.net</A>...&l=
t;/DIV>"Adam> =20
Flinton" <<A>
href=3D"adam{at}NOSPAM_softfab.com&g=">mailto:adam{at}NOSPAM_softfab.com">adam{at}NOSPAM_softfab.com&g=
t'>mailto:adam{at}NOSPAM_softfab.com">adam{at}NOSPAM_softfab.com</A>&a=
mp;gt;> =20
wrote in
message<BR><A>
href=3D"news:3ebcc745$1{at}w3.nls.net...=
>'>news:3ebcc745$1{at}w3.nls.net">news:3ebcc745$1{at}w3.nls.net<=
;/A>...<BR><BR>>> =20
> I can't agree on this point, ext2 isn't suitable since it's =
so=20
easy>
to<BR>wipe<BR>> > =
out with=20
a simple power failure. In a
fileserver> you have =
to be=20
able to<BR>> >
count<BR>> > on =
the=20
file> system coming back up after a
hard poweroff.=20
Fileservers
are<BR>>>
> where =
everyone=20
stores their data, the file system is critical. =
ext3> =20
is<BR>the<BR>> > only =
choice.<BR>>=20
><BR>><BR>>
Why?> =
I've=20
tried (on a variety of work PC'es) the other 3 jfs'es &=20
we>
did<BR>> "turn =
off=20
while buzy" tests. ReiserFS, XFS
&> IBM JFS =
all=20
seemed to<BR>> handle it fine. I think (but I'd have=20
to> check our test docs) that
for<BR>> =
us on=20
that machinery XFS was the> =
fastest.<BR><BR>the=20
filesystem that was suggested was ext2, that
was> =
what I=20
was disagreeing<BR>with, not RFS or XFS or JFS =
but> =20
=
ext2.<BR><BR>Geo.<BR><BR></BLOCKQUOTE></=
BODY></HTML>--=20
------=_NextPart_000_010F_01C316EE.E70ECC00--
--- BBBS/NT v4.01 Flag-4
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/1.45)
SEEN-BY: 633/267 270
@PATH: 379/1 106/1 2000 633/267
|