Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 03 Apr 2001 04:05:31 -0700
From:      Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
To:        Bert Driehuis <driehuis@playbeing.org>
Cc:        "Jason T. Luttgens" <lucky@lansters.com>, freebsd-stable@FreeBSD.ORG
Subject:   Re: Network performance question 
Message-ID:  <200104031106.f33B6PA02869@cwsys.cwsent.com>
In-Reply-To: Your message of "Tue, 03 Apr 2001 01:18:42 %2B0200." <Pine.BSI.4.21.0104030111410.5679-100000@c1111.nl.compuware.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSI.4.21.0104030111410.5679-100000@c1111.nl.compuware.c
om>, Be
rt Driehuis writes:
> On Mon, 2 Apr 2001, Jason T. Luttgens wrote:
> 
> > However - I noticed something while testing. Linux 2.4.3 did not access the
> > drive as much as FreeBSD was. I guess Linux is caching the file more or
> > something...who knows. So I re-performed the tests with output going to
> > /dev/null and looking at the tcpdump and interface counters (I know, it's
> > not the best way, but at this point I was thinking it's the disk I/O that's
> > causing the drops/loss).
> 
> You could try enabling softupdates if you haven't done so yet. For
> benchmarking purposes, you could also try async mount (but note that
> async can screw up your disk real bad in case of a system crash).

If you want to make all things as equal as possible, you will have to 
mount async.  According to Kirk's paper on Softupdates, Softupdates was 
about 3% slower than async mounts and a lot faster than SMD mounts.

Does anyone on this list have a pointer to the paper so I could reread 
it?  Would it be possible to include it in /usr/share/doc/papers?

> 
> I would not expect either to have much effect if the machine is
> otherwise quiescent, but if you are being hit because of any synchronous
> activity going on it would be nice if this could be eliminated from the
> equation.

Depending on how heavy the traffic was at the time you were capturing 
packets I would think that softupdates or async mounts would have made 
a big difference.

> 
> Note that you really are entering a grey area here -- it may well be
> that the respective kernels have different priorities or strategies that
> have little to do with Ethernet performance, e.g. FreeBSD's insistence
> (by default) that file systems remain consistent in case of a system
> crash might cause some packets to be lost in this flat out. worst case
> scenario. It is unlikely that you will prove what happens unless you
> stumble upon something that eliminates the difference.

Until we have a level playing field, it's a comparison between apples 
and oranges.


Regards,                         Phone:  (250)387-8437
Cy Schubert                        Fax:  (250)387-5766
Team Leader, Sun/Alpha Team   Internet:  Cy.Schubert@osg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104031106.f33B6PA02869>