--- Eric Anderson <[EMAIL PROTECTED]> wrote:
> Arne Wörner wrote:
> > --- Robert Watson <[EMAIL PROTECTED]> wrote:
> >>On Sat, 30 Apr 2005, Arne Wörner wrote:
> >>
> >>>3. The man page geom(4) of R5.3 says "The GEOM framework
> >>> provides an infrastructure in which "classes" can per-
> >>> form transformations on disk I/O requests on their path
> >>> from the upper kernel to the device drivers and back.
> >>>
> >>>Could it be, that geom slows something down (in some boxes
> >>>the reading
> >>>ops are very slow; in my box the writing ops are very slow)?
> >>
> >>[...]
> >>against a further offset region of ad0. If they're against
> >>the same bits of disk, the main difference here will be the
> >>additional processing of the layers in the stack. A little
> >>bit of math is required to figure out the offset, but dd
> >>should be usable to figure out the incremental cost.
> >
> > I used the following commands:
> > 1. dd if=/dev/ad0s2a bs=16k count=10000 of=/dev/null
> > 2. dd if=/dev/ad0 iseek=2100357 bs=16k count=10000
> > of=/dev/null
> > (I think I did the math correctly; indeed the read speed of my
> > ad0 varies between 45MB/sec (iseek=0) and 25MB/sec (in the
> > end) with bs=128k).
> > The results were nearly the same (both between 26MB/sec and
> > 28MB/sec). Maybe I should have done it in single user mode.
> >
> > My other hard disc ad1 (it is newer and bigger and faster and
> > more furious) behaves better (but I can just try writing via
> > the file system (ufs+s) and a final sync): The sync just
> > needs .24sec of 18.28 seconds; the read and write speed
> > is nearly the same (about 37MB/sec+/-1MB/sec).
> >
> > Is there anything else, that could help to find the reason for
> > the difference between ad0's speed in R4.11 and R5.3?
>
> I'll be honest here, I don't care much if the speed difference
> between 4.X and 5.X is measureable, or whatever.
>
I understand that. I believe, that it is very interesting, that
thinks might have been better before (some years ago I learned of
evolutionary algorithms; the development of an operating system
could be seen as a big evolutionary algorithm, that is executed in
human brains...). At least those comparisons could help to find
evidence, that it could be better than it is, because it was
better already before... :-) Does somebody feel me?
> What I find is a little telling of an issue somewhere, is
> that READS are slower than WRITES!
>
In my case it is vice versa (at least ad0). In ad1 it is like I
would expect it. And Mr. Watson found another case, where read AND
write throughput looked reasonable (I do not know the thread
anymore; it was last year maybe...).
> This is totally bogusto me - dd'ing a file to a filesystem,
> then umounting should take longer than dd'ing from the disk
> to /dev/null, it nearly every config I can dream up.
>
Yup! I agree.
> Maybe it's the speed at which /dev/null can gobble bits
> (seems highly unlikely!), or maybe GEOM is busy doing a
> check or some routine to data being accessed directly from
> the disk device instead of through a filesystem?
>
Maybe. But why are the symptoms are so different? The symptoms
seem to depend on the hard disc/controller manufacturer... Maybe
there are different reasons for the suboptimal behaviour.
SEAGATE ST340015A/3.01
R4.11 reads and writes at same speed from/to /dev/ad0s2e
R5.3 reads 5x faster than it writes from/to /dev/ad0s2e
R4.11+R5.3 read at same speed from /dev/ad0
R5.3 writes 5 times slower than it reads from ufs+s filesystem
SAMSUNG SP1604N/TM100-24
R4.11+R5.3 read at same speed from /dev/ad1 (appr. 60MB/sec)
(although 80MB/sec is what the disc can do?)
R5.3 writes and reads at or about at the same rate from
ufs+s filesystem (read is 10% slower; write needs a long
(256MB bs=128k) read from /dev/ad1 in order to reach the
maximum fs-write-speed of 66% of the /dev/ad1-write-speed)
So there are the following questions in my setting:
1. Why does my filesystems on /dev/ad1 need a long read before
they perform with 66% of the "max" (initially they just perform
with 20% of the "max")?
2. Why does the Seagate disc write 5 times slower than it reads
(but just with R5.3)?
Did you ever try
dd if=/dev/zero of=/dev/null bs=1m count=10000
?
My slightly busy system is done with it after 38secs (appr.
270MBytes/sec.
> I don't know, but it is an issue, and I'm sure we'll get
> nailed up to a fence in some benchmark somewhere if we
> don't fix it..
>
Yup!
-Arne
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
