Re: My kernel panics sucked, but they seem to be gone now.

[Bob Bishop]

Hi,

On 13 Aug 2010, at 04:33, William D. Colburn (Schlake) wrote:

> A rehash of the problem:
> 
> If my computer was plugged into the UPS and sitting on my metal desk
> the drive controllers would fail and cause a panic almost immediately
> when booted.  If my computer was plugged into wall power and sitting
> on a wooden table, the machine ran flawlessly.
> 
> New information:
> 
> Removing the UPS, but leaving the computer on the metal desk make the
> panics happen a lot less, about every four to seven days.  Sometimes
> after a crash it couldn't boot because no hard drives could be found
> at all, but that always went away with a few power cycles.

Is your metal desk earthed?

> One of my SATA cards has been with me since 2005.  It was a rock solid
> card on my old FreBSD install...as long as I didn't plug anything into
> SATA port 2.  I always had this feeling that something wasn't quite
> right with port 2 and that I should avoid it.  But I'm running FreeBSD
> 8 now, and having strange problems.  So I removed the card completely
> and my system hasn't crashed since.  Which still doesn't prove it was
> the card.  Removing the card could just have made it even more
> intermittent.
> 
> In summary: I hate hardware almost as much as I hate linux.

:-)

> -- 
> -- Schlake

--
Bob Bishop
r...@gid.co.uk




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[releng_8_0 tinderbox] failure on i386/pc98

[FreeBSD Tinderbox]

TB --- 2010-08-13 10:37:53 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-08-13 10:37:53 - starting RELENG_8_0 tinderbox run for i386/pc98
TB --- 2010-08-13 10:37:53 - cleaning the object tree
TB --- 2010-08-13 10:38:12 - cvsupping the source tree
TB --- 2010-08-13 10:38:12 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/RELENG_8_0/i386/pc98/supfile
TB --- 2010-08-13 11:16:57 - WARNING: /usr/bin/csup returned exit code  1 
TB --- 2010-08-13 11:16:57 - ERROR: unable to cvsup the source tree
TB --- 2010-08-13 11:16:57 - 0.87 user 10.83 system 2344.48 real


http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-i386-pc98.full
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zpool - low speed write

[Boris Samorodov]

Hi!

I'm not sure if the problem was solved, so...

On Thu, 5 Aug 2010 18:49:14 +0800 Alex V. Petrov wrote:

> smartctl -a /dev/ad8

> Device Model: WDC WD10EADS-00M2B0
> Firmware Version: 01.00A01

> 193 Load_Cycle_Count0x0032   184   184   000Old_age   Always  
>  
> -   49237

> smartctl -a /dev/ad10

> Device Model: WDC WD10EADS-00L5B1
> Firmware Version: 01.01A01

> 193 Load_Cycle_Count0x0032   200   200   000Old_age   Always  
>  
> -   24

> smartctl -a /dev/ad12

> Device Model: WDC WD10EADS-00M2B0
> Firmware Version: 01.00A01

> 193 Load_Cycle_Count0x0032   200   200   000Old_age   Always  
>  
> -   91

>From the above info I'd say that you may try to play with load
cycles (set a bigger delay, etc.) with /dev/ad8.

-- 
WBR, Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: My kernel panics sucked, but they seem to be gone now.

[William D. Colburn (Schlake)]

On Fri, Aug 13, 2010 at 4:10 AM, Bob Bishop  wrote:

> Is your metal desk earthed?

No, but the computer has been sitting on it since 2004 with remarkable
uptime.  The UPS does appear to be really dead (it beeps now, and has
a red light), but that didn't fix all of the problems.


-- 
-- Schlake
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

zfs destroy snapshot doesn't free space

[Andreas Mayer]

Hi,

I have a problem with my ZFS storage: some application filled a
certain directory in /var completely up with data and the server runs
a script which takes a snapshot every night. So, ~650 GB of the
available 700 GB were filled up.

Then I destroyed the last two snapshots (each referencing about 300
GB) and the files on the live system so that now there are no
snapshots for
/var and "du -hs /var" reports a size of 2 GB.

However, zfs still reports that 623G are referenced:

# zfs list rpool/var
NAMEUSED  AVAIL  REFER  MOUNTPOINT
rpool/var   623G  48.4G   623G  /var

# zfs get all rpool/var
...
rpool/var  usedbysnapshots   0  -
rpool/var  usedbydataset 623G   -
rpool/var  usedbychildren0  -
rpool/var  usedbyrefreservation  0  -
...

If I take a snapshot again, this snapshot also references 623G.

What can I do to reclaim this space? I have to do this before I can
set a quota (I have set quotas for all other file systems now :) ).

-- 
Best regards,
Andreas
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs destroy snapshot doesn't free space

[Jeremy Chadwick]

On Fri, Aug 13, 2010 at 04:51:24PM +0200, Andreas Mayer wrote:
> I have a problem with my ZFS storage: some application filled a
> certain directory in /var completely up with data and the server runs
> a script which takes a snapshot every night. So, ~650 GB of the
> available 700 GB were filled up.
> 
> Then I destroyed the last two snapshots (each referencing about 300
> GB) and the files on the live system so that now there are no
> snapshots for
> /var and "du -hs /var" reports a size of 2 GB.
> 
> However, zfs still reports that 623G are referenced:
> 
> # zfs list rpool/var
> NAMEUSED  AVAIL  REFER  MOUNTPOINT
> rpool/var   623G  48.4G   623G  /var
> 
> # zfs get all rpool/var
> ...
> rpool/var  usedbysnapshots   0  -
> rpool/var  usedbydataset 623G   -
> rpool/var  usedbychildren0  -
> rpool/var  usedbyrefreservation  0  -
> ...
> 
> If I take a snapshot again, this snapshot also references 623G.
> 
> What can I do to reclaim this space? I have to do this before I can
> set a quota (I have set quotas for all other file systems now :) ).

Can you provide uname -a output please?  Thanks.

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Inconsistent IO performance

[Kevin Oberman]

For some time I have seen very odd issues with IO performance on
8-Stable. Going back to November of last year when 8.0 was released, I
see variations of up to 22% in identical operations. This is not a
degradation as the performance moves up and down.

This is a very simplistic case. I have two identical disks (Fujitsu 80G)
on a ThinkPad T43 with a 2 GHz CPU and 2G RAM. I run the command:
dd bs=516096 if=/dev/ad0 of=/dev/ad2

I do this in single user mode immediately after a boot with no disks
mounted for write. Just a 'boot -s', ,Enter> to start the shell, and the
dd. I would expect very consistent performance from run to run, but I
don't get it. Here are the results since 8.0 was released:
 Date   Xfer rate   Kernel date
12/4/09 19,242,573  Nov. 26 kernel (8.0-stable)
12/9/09 18,304,565  Dec. 6 kernel
12/17/0923,676,086  
1/5/10  18,648,609  
1/14/10 23,488,540  Jan. 6 kernel
1/21/10 19,551,680  Jan. 15 kernel
1/27/10 21,176,385  Jan. 21 kernel
2/5/10  22,387,745  
2/11/10 23,387,894  
2/17/10 20,412,172  Feb. 16 kernel
2/25/10 22,049,128  
3/4/10  22,099,624  Mar. 3 kernel
3/17/10 20,334,896  Mar. 3 kernel
3/31/10 21,655,213  Mar. 25 kernel
4/8/10  19,673,170  
4/14/10 22,235,518  
4/30/10 21,262,223  Apr. 14 kernel
6/3/10  22,838,125  May 24 kernel
6/17/10 18,481,270  
6/28/10 20,958,356  
7/8/10  19,698,282  June 28 kernel
7/21/10 23,330,556  
7/28/10 20,544,392  July 24 kernel (8.1-stable)
8/13/10 22,093,259  Aug. 9 kernel

Note the dramatic differences even on the same kernel. For the December
6 kernel, for example, I see a maximum of 23,676,086 and a minimum of
just 18,304,565. 

Can anyone explain what might be causing such a dramatic difference?

I should also note that the system was consistent back in V6 and V7
days. Consistently slow, but consistent. 17.5M was the norm in V6 and
18.0M in V7. The performance jumped to about 19M in March of 09 and jumped
to its current speeds with 8.0. So performance has greatly improved to
where the slowest times are better than the fastest prior to March of
09. Just very inconsistent.

I don't know that anything is wrong, but I'd love to understand why this
is happening.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs destroy snapshot doesn't free space

[Andreas Mayer]

$ uname -a
FreeBSD wurd.dev001.net 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19
02:36:49 UTC 2010
r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

2010/8/13 Malcolm Waltz :
> Have you tried "zfs list -t all" ?

I have, it produces this output:
$ zfs list -t all
NAME   USED  AVAIL  REFER  MOUNTPOINT
rpool  637G  48,4G18K  none
rpool/root 245M  1,76G   209M  legacy
... rpool/root backup snapshots ...
rpool/srv 5,31G  48,4G  4,94G  /srv
... rpool/srv backup snapshots ...
rpool/tmp 90,2M  1,91G  90,2M  /tmp
... rpool/tmp backup snapshots ...
rpool/usr 7,91G  48,4G  6,83G  /usr
... rpool/usr backup snapshots ...
rpool/var  623G  48,4G   623G  /var

-- 
Best regards
Andreas
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs destroy snapshot doesn't free space

[Henri Hennebert]

On 08/13/2010 20:02, Andreas Mayer wrote:
> $ uname -a
> FreeBSD wurd.dev001.net 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19
> 02:36:49 UTC 2010
> r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> 2010/8/13 Malcolm Waltz :
>> Have you tried "zfs list -t all" ?
> 
> I have, it produces this output:
> $ zfs list -t all
> NAME   USED  AVAIL  REFER  MOUNTPOINT
> rpool  637G  48,4G18K  none
> rpool/root 245M  1,76G   209M  legacy
> .. rpool/root backup snapshots ...
> rpool/srv 5,31G  48,4G  4,94G  /srv
> .. rpool/srv backup snapshots ...
> rpool/tmp 90,2M  1,91G  90,2M  /tmp
> .. rpool/tmp backup snapshots ...
> rpool/usr 7,91G  48,4G  6,83G  /usr
> .. rpool/usr backup snapshots ...
> rpool/var  623G  48,4G   623G  /var
> 
Just to be sure that a process is not still hogging space:

fstat |grep /var

Henri
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Inconsistent IO performance

[Stefan Bethke]

Am 13.08.2010 um 18:01 schrieb Kevin Oberman:

> Note the dramatic differences even on the same kernel. For the December
> 6 kernel, for example, I see a maximum of 23,676,086 and a minimum of
> just 18,304,565. 

Are the disks still OK?  If any sectors have been remapped between runs, 
additional seeks would be needed.  I think it's unlikely, but checking with 
smartmontools should only take a few minutes.


Stefan

-- 
Stefan BethkeFon +49 151 14070811



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Problem with mxge on RELENG_8_1

[Robert Healey]

Hello.

I recently updated the central file server/router systems for a pair of 
research clusters from RELENG_8_0 to RELENG_8_1.  After following the 
proper procedures, the network throughput when pulling files from both 
machines via mxge0 is 200KB/s or less.  Before the update, 50MB/s was 
the normal rate.


Doing some testing, with the 8.1 kernel booted, I can upload files to 
the server over the 10G link with scp or NFS at the expected rates.  I 
can fetch files from the Internet using this server as the NAT gateway 
also at the expected rates.  Retrieving files from the server over mxge, 
the throughput falls to 200KB/s.  Retrieving files from the server from 
the onboard Broadcom NIC, rates are as to be expected from gigabit. 
With 8.0, everything works as expected.


Hardware Config 1:
Dell Poweredge R610 with 2 Xeon E5530 @ 2.4 GHz, hyperthreading disabled 
and 24GB RAM.  Onboard interface is bce. Disk is attached via a PERC 
6/E. Internal cluster switch is Dell Powerconnect 6248P.  This switch 
sees excessive large packets on the 10G connection on 8.1, but not 8.0.


Hardware Config 2:
HP Proliant DL 320G6 with 1 Xeon  E5540 @ 2.53GHz, hyperthreading 
enabled and 8GB RAM.  Onboard interface is bge.  Disk is attached via a 
HP Smart Array P212.  Internal cluster switch is an HP Procurve 2910al. 
 It does not see any packet errors from the 10G link.


If anyone could point me in the general direction of a solution, I would 
 be very appreciative.  Thank you.


--
Bob Healey
Systems Administrator
Biocomputation and Bioinformatics Constellation
and Molecularium
hea...@rpi.edu
(518) 276-4407
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Inconsistent IO performance

[Kevin Oberman]

> From: Stefan Bethke 
> Date: Fri, 13 Aug 2010 22:23:08 +0200
> 
> Am 13.08.2010 um 18:01 schrieb Kevin Oberman:
> 
> > Note the dramatic differences even on the same kernel. For the December
> > 6 kernel, for example, I see a maximum of 23,676,086 and a minimum of
> > just 18,304,565. 
> 
> Are the disks still OK?  If any sectors have been remapped between
> runs, additional seeks would be needed.  I think it's unlikely, but
> checking with smartmontools should only take a few minutes.
 
I should have mentioned that I have smartmontools installed on all of my
systems and I had already looked at the results. The data shows both
working well and having no errors of late. Also,  the speeds
jump up and down rather randomly makes this rather unlikely as the
redirected blocks only increase and the likelihood of files being
created and deleted frequently enough for this to have such a large
impact seems pretty unlikely.

Thanks for taking a look, though.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Inconsistent IO performance

[Roland Smith]

On Fri, Aug 13, 2010 at 09:01:09AM -0700, Kevin Oberman wrote:
> For some time I have seen very odd issues with IO performance on
> 8-Stable. Going back to November of last year when 8.0 was released, I
> see variations of up to 22% in identical operations. This is not a
> degradation as the performance moves up and down.
> 
> This is a very simplistic case. I have two identical disks (Fujitsu 80G)
> on a ThinkPad T43 with a 2 GHz CPU and 2G RAM. I run the command:
> dd bs=516096 if=/dev/ad0 of=/dev/ad2

Why are you using this peculiar block size?

> Note the dramatic differences even on the same kernel. For the December
> 6 kernel, for example, I see a maximum of 23,676,086 and a minimum of
> just 18,304,565. 

Both figures seem quite low to me? I cannot exactly reproduce your test,
because I don't have an empty second disk handy, but doing

dd if=/dev/zero bs=1m count=100 of=/tmp/foo

yields the following writing speed on 8.1-RELEASE amd64, 
WDC WD5001ABYS SATA harddisk @ 7200 rpm.:

1) 87263174 bytes/sec
2) 87878728 bytes/sec
3) 86397125 bytes/sec
4) 86550094 bytes/sec
5) 86524741 bytes/sec

Th maximum variation in write speed is (87878728-86397125)/86397125*100% =
1.7%, which doesn't seem that much to me.

This is in multi-user, with X11 running but on an otherwise idling machine,
and with filesystem overhead to boot. Still the numbers are a lot higher than
yours, which puzzles me. 

Trying only reading does yield very inconsistent results because of caching, I
think;

dd if=/tmp/foo bs=1m count=100 of=/dev/null

1) 1454216957 bytes/sec
2) 1003691691 bytes/sec
3) 1429956761 bytes/sec
4) 2324794646 bytes/sec
5) 1804563681 bytes/sec

This is a (2324794646-1003691691)/1003691691*100% = 132% difference. OTOH,
your data set should be big enough to negate caching effects, I guess. :-)

What this does show is that writing seems to be the bottleneck.

If I both read from and write to a file (on the same disk & partition);

dd if=/tmp/foo bs=1m count=100 of=/tmp/bar

gives

1) 85161534 bytes/sec
2) 84978770 bytes/sec
3) 87966613 bytes/sec
4) 83036312 bytes/sec
5) 86536879 bytes/sec

This is a (87966613-83036312)/83036312*100% = 5.9% difference between largest
and smallest. The speed seems to be dictated by the writing.

> Can anyone explain what might be causing such a dramatic difference?

Maybe there is a hardware component here? Are both disks on the same
controller? Or if not are both controllers using the same interrupt line?

You should have a look at 'systat -vmstat' with dd running in the
background. That might give a clue as to where the bottleneck is.

Roland
-- 
R.F.Smith   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)


pgpCIiJJ5RBhs.pgp
Description: PGP signature

Re: zfs destroy snapshot doesn't free space

[Andreas Mayer]

In the meanwhile, some Web applications (they don't even access /var
but only /srv) don't work anymore because of very strange "file not
accessible" and "file not found" errors although I haven't changed
anything and the file system isn't full or something like that. I
think the whole pool or serveral file systems are corrupted... can
that be true or am I panicking? Is there any chance that I can repair
it without reinstalling the whole system?

2010/8/13 Andreas Mayer :
> There are only the normal services as they always run and access to
> /var. I don't think that they are hogging space as I rebooted and
> tried to disable them, but the REFER value in zlist stays 623 GB.
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

ts_to_ct flood on 8.1-STABLE

[Andrew J. Caines]

Since installing 8.1-RC2 and now on up-to-date RELENG_8 I am frequently
getting kern.crit messages like

ts_to_ct(1281661818.743348859) = [2010-08-13 01:10:18]

and have been unable so far to determine their origin or purpose. I saw
no such messages while running 7.x or earlier releases.

AFAICT the system[1] is running fine. Athlon XP, 2GB, nVidia mobo and
GPU, Intel and Realtek NICs, various ATA and USB disks all in a custom
kernel. I've posted details of the system configuration[2].

Advice would be appreciated.


[1] http://halplant.com:2001/systems.html#HAL1
[2] http://halplant.com:2001/server/config/HAL1/

--
-Andrew J. Caines-   Unix Systems Engineer   a.j.cai...@halplant.com
FreeBSD/Linux/Solaris, Web/Mail/Proxy/...   http://halplant.com:2001/
  "Machines take me by surprise with great frequency" - Alan Turing
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ts_to_ct flood on 8.1-STABLE

[Jeremy Chadwick]

On Fri, Aug 13, 2010 at 06:16:01PM -0400, Andrew J. Caines wrote:
> Since installing 8.1-RC2 and now on up-to-date RELENG_8 I am frequently
> getting kern.crit messages like
> 
> ts_to_ct(1281661818.743348859) = [2010-08-13 01:10:18]
> 
> and have been unable so far to determine their origin or purpose. I saw
> no such messages while running 7.x or earlier releases.
> 
> AFAICT the system[1] is running fine. Athlon XP, 2GB, nVidia mobo and
> GPU, Intel and Realtek NICs, various ATA and USB disks all in a custom
> kernel. I've posted details of the system configuration[2].
> 
> Advice would be appreciated.
> 
> 
> [1] http://halplant.com:2001/systems.html#HAL1
> [2] http://halplant.com:2001/server/config/HAL1/

The source/responsible code for the printing is in function
clock_ts_to_ct() in:

src/sys/kern/subr_clock.c


181 void
182 clock_ts_to_ct(struct timespec *ts, struct clocktime *ct)
183 {
...
214 if (ct_debug) {
215 printf("ts_to_ct(%ld.%09ld) = ",
216 (long)ts->tv_sec, (long)ts->tv_nsec);
217 print_ct(ct);
218 printf("\n");
219 }

So what's ct_debug?

 52 #define ct_debug bootverbose

Are your systems booting verbosely?

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ts_to_ct flood on 8.1-STABLE

[Andrew J. Caines]

Jeremy,

Thanks for the quick response.


The source/responsible code for the printing is in function
clock_ts_to_ct() in: src/sys/kern/subr_clock.c


I took a look at the code in an attempt to divine the reason for the
frequent messages, without success.

Any idea why I see so many? I'm not aware of any special timing related
configuration. I do run ntpd, of course. In examples I've found, others
seem to get just the one ts_to_ct message.


52 #define ct_debug bootverbose Are your systems booting verbosely?


By default, yes. I'd like to keep it that way without having to hack the
source. Is there another option?


--
-Andrew J. Caines-   Unix Systems Engineer   a.j.cai...@halplant.com
FreeBSD/Linux/Solaris, Web/Mail/Proxy/...   http://halplant.com:2001/
  "Machines take me by surprise with great frequency" - Alan Turing
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ts_to_ct flood on 8.1-STABLE

[Jung-uk Kim]

On Friday 13 August 2010 06:50 pm, Andrew J. Caines wrote:
> Jeremy,
>
> Thanks for the quick response.
>
> > The source/responsible code for the printing is in function
> > clock_ts_to_ct() in: src/sys/kern/subr_clock.c
>
> I took a look at the code in an attempt to divine the reason for
> the frequent messages, without success.
>
> Any idea why I see so many? I'm not aware of any special timing
> related configuration. I do run ntpd, of course. In examples I've
> found, others seem to get just the one ts_to_ct message.
>
> > 52 #define ct_debug bootverbose Are your systems booting
> > verbosely?
>
> By default, yes. I'd like to keep it that way without having to
> hack the source. Is there another option?

If you are really annoyed by the messages, you may increase 
'machdep.rtc_save_period' sysctl value to something larger.  Default 
is 1,800 seconds or 30 minutes.  Also, you can completely disable it 
by setting it to zero or 'machdep.disable_rtc_set' to non-zero value 
but I would not recommend it.  Still, it doesn't explain why you are 
seeing the message more often, however. :-(

Jung-uk Kim
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Inconsistent IO performance

[Jeremy Chadwick]

On Fri, Aug 13, 2010 at 09:01:09AM -0700, Kevin Oberman wrote:
> For some time I have seen very odd issues with IO performance on
> 8-Stable. Going back to November of last year when 8.0 was released, I
> see variations of up to 22% in identical operations. This is not a
> degradation as the performance moves up and down.
> 
> This is a very simplistic case. I have two identical disks (Fujitsu 80G)
> on a ThinkPad T43 with a 2 GHz CPU and 2G RAM. I run the command:
> dd bs=516096 if=/dev/ad0 of=/dev/ad2
> 
> I do this in single user mode immediately after a boot with no disks
> mounted for write. Just a 'boot -s', ,Enter> to start the shell, and the
> dd. I would expect very consistent performance from run to run, but I
> don't get it. Here are the results since 8.0 was released:
>  Date   Xfer rate   Kernel date
> 12/4/09   19,242,573  Nov. 26 kernel (8.0-stable)
> 12/9/09   18,304,565  Dec. 6 kernel
> 12/17/0923,676,086
> 1/5/1018,648,609  
> 1/14/10   23,488,540  Jan. 6 kernel
> 1/21/10   19,551,680  Jan. 15 kernel
> 1/27/10   21,176,385  Jan. 21 kernel
> 2/5/1022,387,745  
> 2/11/10   23,387,894  
> 2/17/10   20,412,172  Feb. 16 kernel
> 2/25/10   22,049,128  
> 3/4/1022,099,624  Mar. 3 kernel
> 3/17/10   20,334,896  Mar. 3 kernel
> 3/31/10   21,655,213  Mar. 25 kernel
> 4/8/1019,673,170  
> 4/14/10   22,235,518  
> 4/30/10   21,262,223  Apr. 14 kernel
> 6/3/1022,838,125  May 24 kernel
> 6/17/10   18,481,270  
> 6/28/10   20,958,356  
> 7/8/1019,698,282  June 28 kernel
> 7/21/10   23,330,556  
> 7/28/10   20,544,392  July 24 kernel (8.1-stable)
> 8/13/10   22,093,259  Aug. 9 kernel
> 
> Note the dramatic differences even on the same kernel. For the December
> 6 kernel, for example, I see a maximum of 23,676,086 and a minimum of
> just 18,304,565. 
> 
> Can anyone explain what might be causing such a dramatic difference?
> 
> I should also note that the system was consistent back in V6 and V7
> days. Consistently slow, but consistent. 17.5M was the norm in V6 and
> 18.0M in V7. The performance jumped to about 19M in March of 09 and jumped
> to its current speeds with 8.0. So performance has greatly improved to
> where the slowest times are better than the fastest prior to March of
> 09. Just very inconsistent.
> 
> I don't know that anything is wrong, but I'd love to understand why this
> is happening.

The system in question is a Thinkpad T43 laptop[1], which is from circa
2005 and uses an ICH6-M southbridge (note the -M).  We don't know the
exact model of Fujitsu hard disk used, but since it's a laptop my guess
is that it's 5400rpm, and PATA.

System drastically differs on laptops if being powered off the battery
vs. AC.  Were the tests performed consistently with the exact same setup
(which: battery or AC?) every time?  Given that the system role is a
laptop, I imagine not.

Can you also provide output from these commands?

- atacontrol list
- atacontrol info ataX  (where X is the channel number the ad0 drive
  is connected to)
- atacontrol cap ad0

Anyway, I would expect the system to be seeing 50-60MB/sec, but I'm
pulling those numbers out of thin air.  An ICH6-M may be "old", but keep
reading for a comparison system that's even older...

The deviation in your disk I/O isn't a major surprise (to me anyway),
given the system specs.  What *does* surprise me is your abysmal I/O
speeds in general.  18MB/sec min, 24MB/sec max?!  ICH6-M can do a lot
more than that.  Something isn't right.

It sounds to me like the disk itself has some kind of internal problem
(cache that's gone bad, something mechanical that isn't audible, etc.);
even for a 5400rpm drive those numbers are very low.  Other
possibilities include a southbridge that's going bad, or some kind of
power-related problem that's causing the drive to spin at a lower speed
than 5400rpm (though SMART sometimes can notice this).  I'm grasping at
straws with this one, but excessive dust can slow a system down (from
what I'm told by EE folks; something about more electricity being
required to push voltage across a trace...)

Now the comparison -- here's a system that's way older than yours.

- FreeBSD 6.4-STABLE, i386
- Supermicro SuperServer 5010E [2]
- Intel Pentium 3 (not sure of speed)
- 1GB RAM
- Intel ICH2 southbridge
- ad0: Maxtor STM3160815A disk (160GB, 8MB cache, 7200rpm, ATA133)
- ad1: Maxtor STM3160815A disk (160GB, 8MB cache, 7200rpm, ATA133)
- Disk connected via ICH2
- System in multi-user with some light load
- Command #1: dd if=/dev/ad0 of=/dev/null bs=64k count=10
- Command #2: dd if=/dev/ad1 of=/dev/null bs=64k count=10
- Commands run 4 times in succession

Result for command #1:

655360 bytes transferred in 84.110282 secs (77916752 bytes/sec)
655360 bytes transferred in 84.197506 secs (77836035 bytes/se

Re: Inconsistent IO performance

[Clifton Royston]

On Fri, Aug 13, 2010 at 11:32:05PM +0200, Roland Smith wrote:
> On Fri, Aug 13, 2010 at 09:01:09AM -0700, Kevin Oberman wrote:
> > For some time I have seen very odd issues with IO performance on
> > 8-Stable. Going back to November of last year when 8.0 was released, I
> > see variations of up to 22% in identical operations. This is not a
> > degradation as the performance moves up and down.
> > 
> > This is a very simplistic case. I have two identical disks (Fujitsu 80G)
> > on a ThinkPad T43 with a 2 GHz CPU and 2G RAM. I run the command:
> > dd bs=516096 if=/dev/ad0 of=/dev/ad2
> 
> Why are you using this peculiar block size?
> 
> > Note the dramatic differences even on the same kernel. For the December
> > 6 kernel, for example, I see a maximum of 23,676,086 and a minimum of
> > just 18,304,565. 
> 
> Both figures seem quite low to me? I cannot exactly reproduce your test,
> because I don't have an empty second disk handy, but doing
> 
> dd if=/dev/zero bs=1m count=100 of=/tmp/foo
 
  With a total write size of 100MB, aren't you just testing speed of
writing into cache RAM this way?  I think you need to write amounts
dramatically greater than the total size of the RAM to get values which
appropriately measure disk speed.

> yields the following writing speed on 8.1-RELEASE amd64, 
> WDC WD5001ABYS SATA harddisk @ 7200 rpm.:
> 
> 1) 87263174 bytes/sec
> 2) 87878728 bytes/sec
> 3) 86397125 bytes/sec
> 4) 86550094 bytes/sec
> 5) 86524741 bytes/sec

  This also supports that theory - off the top of my head, maximum
theoretical possible write throughput to a similarly sized 7200rpm
drive should be 70MB/s (buffer to disk data transfer rate according to
WDC's specs.) 

  -- Clifton

-- 
Clifton Royston  --  clift...@iandicomputing.com / clift...@lava.net
   President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Inconsistent IO performance

[Roland Smith]

On Fri, Aug 13, 2010 at 01:36:12PM -1000, Clifton Royston wrote:
> > Both figures seem quite low to me? I cannot exactly reproduce your test,
> > because I don't have an empty second disk handy, but doing
> > 
> > dd if=/dev/zero bs=1m count=100 of=/tmp/foo
>  
>   With a total write size of 100MB, aren't you just testing speed of
> writing into cache RAM this way?  I think you need to write amounts
> dramatically greater than the total size of the RAM to get values which
> appropriately measure disk speed.

>   This also supports that theory - off the top of my head, maximum
> theoretical possible write throughput to a similarly sized 7200rpm
> drive should be 70MB/s (buffer to disk data transfer rate according to
> WDC's specs.) 

Ok, so I tried this;

 dd if=/dev/zero of=/tmp/foo bs=10M count=1000

1048576 bytes transferred in 138.304953 secs (75816229 bytes/sec)
1048576 bytes transferred in 139.125501 secs (75369073 bytes/sec)
1048576 bytes transferred in 136.149871 secs (77016305 bytes/sec)

Which is around 72 MiB/s with filesystem overhead, which sounds about
right. The drive was making plenty of noise. The point is that it is _way_
more than the 18-22 MiB/s on a raw disk that Kevin is getting.

I'll try the same on my laptop topmorrow and see what that gets me. This desktop
machine is ICH7 with ata(4), laptop is ICH9 with ahci(4).

Roland
-- 
R.F.Smith   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)


pgpQcBgNGLEyA.pgp
Description: PGP signature

Re: Inconsistent IO performance

[Kevin Oberman]

> Date: Fri, 13 Aug 2010 23:32:05 +0200
> From: Roland Smith 
> 
> On Fri, Aug 13, 2010 at 09:01:09AM -0700, Kevin Oberman wrote:
> > For some time I have seen very odd issues with IO performance on
> > 8-Stable. Going back to November of last year when 8.0 was released, I
> > see variations of up to 22% in identical operations. This is not a
> > degradation as the performance moves up and down.
> > 
> > This is a very simplistic case. I have two identical disks (Fujitsu 80G)
> > on a ThinkPad T43 with a 2 GHz CPU and 2G RAM. I run the command:
> > dd bs=516096 if=/dev/ad0 of=/dev/ad2
> 
> Why are you using this peculiar block size?

It was suggested by a co-worker with a similar system, but I have tried
larger values with no clear difference. It is the size of one cylinder
based on disk geometry. I was (and remain) sceptical since CHS has
nothing to do with real geometry in modern disks.

> > Note the dramatic differences even on the same kernel. For the December
> > 6 kernel, for example, I see a maximum of 23,676,086 and a minimum of
> > just 18,304,565. 
> 
> Both figures seem quite low to me? I cannot exactly reproduce your test,
> because I don't have an empty second disk handy, but doing
> 
> dd if=/dev/zero bs=1m count=100 of=/tmp/foo
> 
> yields the following writing speed on 8.1-RELEASE amd64, 
> WDC WD5001ABYS SATA harddisk @ 7200 rpm.:
> 
> 1) 87263174 bytes/sec
> 2) 87878728 bytes/sec
> 3) 86397125 bytes/sec
> 4) 86550094 bytes/sec
> 5) 86524741 bytes/sec
> 
> Th maximum variation in write speed is (87878728-86397125)/86397125*100% =
> 1.7%, which doesn't seem that much to me.
> 
> This is in multi-user, with X11 running but on an otherwise idling machine,
> and with filesystem overhead to boot. Still the numbers are a lot higher than
> yours, which puzzles me. 
> 
> Trying only reading does yield very inconsistent results because of caching, I
> think;
> 
> dd if=/tmp/foo bs=1m count=100 of=/dev/null
> 
> 1) 1454216957 bytes/sec
> 2) 1003691691 bytes/sec
> 3) 1429956761 bytes/sec
> 4) 2324794646 bytes/sec
> 5) 1804563681 bytes/sec
> 
> This is a (2324794646-1003691691)/1003691691*100% = 132% difference. OTOH,
> your data set should be big enough to negate caching effects, I guess. :-)
> 
> What this does show is that writing seems to be the bottleneck.
> 
> If I both read from and write to a file (on the same disk & partition);
> 
> dd if=/tmp/foo bs=1m count=100 of=/tmp/bar
> 
> gives
> 
> 1) 85161534 bytes/sec
> 2) 84978770 bytes/sec
> 3) 87966613 bytes/sec
> 4) 83036312 bytes/sec
> 5) 86536879 bytes/sec
> 
> This is a (87966613-83036312)/83036312*100% = 5.9% difference between largest
> and smallest. The speed seems to be dictated by the writing.
> 
> > Can anyone explain what might be causing such a dramatic difference?
> 
> Maybe there is a hardware component here? Are both disks on the same
> controller? Or if not are both controllers using the same interrupt line?

No. Each is on its one controller and is the only disk on that
controller. 

> You should have a look at 'systat -vmstat' with dd running in the
> background. That might give a clue as to where the bottleneck is.

I guess I can give this a try.

Thanks!
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Inconsistent IO performance

[Kevin Oberman]

> Date: Fri, 13 Aug 2010 16:29:54 -0700
> From: Jeremy Chadwick 
> 
> On Fri, Aug 13, 2010 at 09:01:09AM -0700, Kevin Oberman wrote:
> > For some time I have seen very odd issues with IO performance on
> > 8-Stable. Going back to November of last year when 8.0 was released, I
> > see variations of up to 22% in identical operations. This is not a
> > degradation as the performance moves up and down.
> > 
> > This is a very simplistic case. I have two identical disks (Fujitsu 80G)
> > on a ThinkPad T43 with a 2 GHz CPU and 2G RAM. I run the command:
> > dd bs=516096 if=/dev/ad0 of=/dev/ad2
> > 
> > I do this in single user mode immediately after a boot with no disks
> > mounted for write. Just a 'boot -s', ,Enter> to start the shell, and the
> > dd. I would expect very consistent performance from run to run, but I
> > don't get it. Here are the results since 8.0 was released:
> >  Date   Xfer rate   Kernel date
> > 12/4/09 19,242,573  Nov. 26 kernel (8.0-stable)
> > 12/9/09 18,304,565  Dec. 6 kernel
> > 12/17/0923,676,086  
> > 1/5/10  18,648,609  
> > 1/14/10 23,488,540  Jan. 6 kernel
> > 1/21/10 19,551,680  Jan. 15 kernel
> > 1/27/10 21,176,385  Jan. 21 kernel
> > 2/5/10  22,387,745  
> > 2/11/10 23,387,894  
> > 2/17/10 20,412,172  Feb. 16 kernel
> > 2/25/10 22,049,128  
> > 3/4/10  22,099,624  Mar. 3 kernel
> > 3/17/10 20,334,896  Mar. 3 kernel
> > 3/31/10 21,655,213  Mar. 25 kernel
> > 4/8/10  19,673,170  
> > 4/14/10 22,235,518  
> > 4/30/10 21,262,223  Apr. 14 kernel
> > 6/3/10  22,838,125  May 24 kernel
> > 6/17/10 18,481,270  
> > 6/28/10 20,958,356  
> > 7/8/10  19,698,282  June 28 kernel
> > 7/21/10 23,330,556  
> > 7/28/10 20,544,392  July 24 kernel (8.1-stable)
> > 8/13/10 22,093,259  Aug. 9 kernel
> > 
> > Note the dramatic differences even on the same kernel. For the December
> > 6 kernel, for example, I see a maximum of 23,676,086 and a minimum of
> > just 18,304,565. 
> > 
> > Can anyone explain what might be causing such a dramatic difference?
> > 
> > I should also note that the system was consistent back in V6 and V7
> > days. Consistently slow, but consistent. 17.5M was the norm in V6 and
> > 18.0M in V7. The performance jumped to about 19M in March of 09 and jumped
> > to its current speeds with 8.0. So performance has greatly improved to
> > where the slowest times are better than the fastest prior to March of
> > 09. Just very inconsistent.
> > 
> > I don't know that anything is wrong, but I'd love to understand why this
> > is happening.
> 
> The system in question is a Thinkpad T43 laptop[1], which is from circa
> 2005 and uses an ICH6-M southbridge (note the -M).  We don't know the
> exact model of Fujitsu hard disk used, but since it's a laptop my guess
> is that it's 5400rpm, and PATA.

They are Fujitsu MHV2080AH drives. 80G PATA.
> 
> System drastically differs on laptops if being powered off the battery
> vs. AC.  Were the tests performed consistently with the exact same setup
> (which: battery or AC?) every time?  Given that the system role is a
> laptop, I imagine not.

I usually do my backups on battery, but there does not seem to be any
correlation between power source and performance. In single user mode
powerd. I have had fast times and slow times with both power sources.

> 
> Can you also provide output from these commands?
> 
> - atacontrol list
ATA channel 0:
Master:  ad0  ATA/ATAPI revision 6
Slave:   no device present
ATA channel 1:
Master:  ad2  ATA/ATAPI revision 6
Slave:   no device present

> - atacontrol info ataX  (where X is the channel number the ad0 drive
>   is connected to)
Master:  ad0  ATA/ATAPI revision 6
Slave:   no device present
Master:  ad2  ATA/ATAPI revision 6
Slave:   no device present

> - atacontrol cap ad0
Protocol  ATA/ATAPI revision 6
device model  FUJITSU MHV2080AH
serial number NT02T53258D4
firmware revision 0096
cylinders 16383
heads 16
sectors/track 63
lba supported 156301488 sectors
lba48 not supported   
dma supported
overlap not supported

Feature  Support  EnableValue   Vendor
write cacheyes  yes
read ahead yes  yes
Tagged Command Queuing (TCQ)   no   no  0/0x00
SMART  yes  yes
microcode download yes  yes
security   yes  no
power management   yes  yes
advanced power management  yes  yes 16512/0x4080
automatic acoustic management  yes  yes 254/0xFE254/0xFE

Oh, crap! I could have sworn I had turned off acoustic management. I'll
do this ASAP and see if it helps. (I can't try tonight.)

> Anyway, I would expect the system to be seeing 50

Re: Inconsistent IO performance

[TJ Varghese]

>

> > Maybe there is a hardware component here? Are both disks on the same
> > controller? Or if not are both controllers using the same interrupt line?
>
> No. Each is on its one controller and is the only disk on that
> controller.
>
> > You should have a look at 'systat -vmstat' with dd running in the
> > background. That might give a clue as to where the bottleneck is.
>
>
>
You're using a laptop with 2 HDDs, so does that mean you're using the
Ultrabay for the 2nd HDD?
Perhaps anything connected to that drops down to ATA33 (pure speculation on
my part) since it was designed for optical drives ...dmesg/atacontrol logs
would be useful here.

You may want to try dd with the of=/dev/null instead to remove the 2nd
variable and benchmark solely the read speed of the 1st hdd.

regards,
TJ
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Inconsistent IO performance

[TJ Varghese]

> The deviation in your disk I/O isn't a major surprise (to me anyway),
> given the system specs.  What *does* surprise me is your abysmal I/O
> speeds in general.  18MB/sec min, 24MB/sec max?!  ICH6-M can do a lot
> more than that.  Something isn't right.
>
>
it's possible that the hw is...suboptimal. From a 2005 post,

http://forum.thinkpads.com/viewtopic.php?f=2&t=13036&start=0

Check out the link to the hddbenchmark,
http://img57.imageshack.us/img57/6430/hddbenchmark1no.jpg

regards,
TJ
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Inconsistent IO performance

[Kevin Oberman]

> Date: Sat, 14 Aug 2010 11:06:58 +0800
> From: TJ Varghese 
> 
> >
> 
> > > Maybe there is a hardware component here? Are both disks on the same
> > > controller? Or if not are both controllers using the same interrupt line?
> >
> > No. Each is on its one controller and is the only disk on that
> > controller.
> >
> > > You should have a look at 'systat -vmstat' with dd running in the
> > > background. That might give a clue as to where the bottleneck is.
> >
> >
> >
> You're using a laptop with 2 HDDs, so does that mean you're using the
> Ultrabay for the 2nd HDD?
> Perhaps anything connected to that drops down to ATA33 (pure speculation on
> my part) since it was designed for optical drives ...dmesg/atacontrol logs
> would be useful here.
> 
> You may want to try dd with the of=/dev/null instead to remove the 2nd
> variable and benchmark solely the read speed of the 1st hdd.

For this test I get a very consistent 34.75 MB. (1000 10M
blocks). Distressingly low when there is almost no seek activity.

Nope, it is running at UDMA100 using a SATA-PATA converter. (The ICH6
controller is SATA.) But that was a good idea.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Inconsistent IO performance

[Erik Trulsson]

On Fri, Aug 13, 2010 at 01:36:12PM -1000, Clifton Royston wrote:
> On Fri, Aug 13, 2010 at 11:32:05PM +0200, Roland Smith wrote:
> > On Fri, Aug 13, 2010 at 09:01:09AM -0700, Kevin Oberman wrote:
> > > For some time I have seen very odd issues with IO performance on
> > > 8-Stable. Going back to November of last year when 8.0 was released, I
> > > see variations of up to 22% in identical operations. This is not a
> > > degradation as the performance moves up and down.
> > > 
> > > This is a very simplistic case. I have two identical disks (Fujitsu 80G)
> > > on a ThinkPad T43 with a 2 GHz CPU and 2G RAM. I run the command:
> > > dd bs=516096 if=/dev/ad0 of=/dev/ad2
> > 
> > Why are you using this peculiar block size?
> > 
> > > Note the dramatic differences even on the same kernel. For the December
> > > 6 kernel, for example, I see a maximum of 23,676,086 and a minimum of
> > > just 18,304,565. 
> > 
> > Both figures seem quite low to me? I cannot exactly reproduce your test,
> > because I don't have an empty second disk handy, but doing
> > 
> > dd if=/dev/zero bs=1m count=100 of=/tmp/foo
>  
>   With a total write size of 100MB, aren't you just testing speed of
> writing into cache RAM this way?  I think you need to write amounts
> dramatically greater than the total size of the RAM to get values which
> appropriately measure disk speed.

One should get much higher speeds if it was just writes into RAM.

> 
> > yields the following writing speed on 8.1-RELEASE amd64, 
> > WDC WD5001ABYS SATA harddisk @ 7200 rpm.:
> > 
> > 1) 87263174 bytes/sec
> > 2) 87878728 bytes/sec
> > 3) 86397125 bytes/sec
> > 4) 86550094 bytes/sec
> > 5) 86524741 bytes/sec
> 
>   This also supports that theory - off the top of my head, maximum
> theoretical possible write throughput to a similarly sized 7200rpm
> drive should be 70MB/s (buffer to disk data transfer rate according to
> WDC's specs.) 

That the disks are the same size and RPM is fairly irrelevant for max
transfer rate.  Bit density on the platters is far more importtant.  If
you look at the data sheet for that particular model

the transfer rate is actually specified as 98MB/s.  (Presumably along
the outer tracks of the disk -- on the inner tracks you probably can't
get more than around 50 MB/s)





-- 

Erik Trulsson
ertr1...@student.uu.se
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Inconsistent IO performance

[Kevin Oberman]

> Date: Sat, 14 Aug 2010 11:33:57 +0800
> From: TJ Varghese 
> 
> > The deviation in your disk I/O isn't a major surprise (to me anyway),
> > given the system specs.  What *does* surprise me is your abysmal I/O
> > speeds in general.  18MB/sec min, 24MB/sec max?!  ICH6-M can do a lot
> > more than that.  Something isn't right.
> >
> >
> it's possible that the hw is...suboptimal. From a 2005 post,
> 
> http://forum.thinkpads.com/viewtopic.php?f=2&t=13036&start=0
> 
> Check out the link to the hddbenchmark,
> http://img57.imageshack.us/img57/6430/hddbenchmark1no.jpg

Thanks, TJ! I guess the disk IO on these boxes simply sucks. Looks like
the 34.75MB/sec sequential read speed is all I can hope for. I'm
guessing the SATA-PATA converter is to blame. Oh, well.

But all of this does not address my real question, why is performance so
inconsistent? I agree that it sucks, but that does not explain why it
suck so much worse on one run than another. I'm still baffled.

My backup disk normally odes not leave my office storage cabinet except
when it is in the computer being written, so I don't have it handy
ATM. I will try a couple of things on Monday, though.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"