* Abysmal disk performance, how to debug?
@ 2007-01-20 17:20 Ismail Dönmez
2007-01-20 17:45 ` Willy Tarreau
0 siblings, 1 reply; 27+ messages in thread
From: Ismail Dönmez @ 2007-01-20 17:20 UTC (permalink / raw)
To: linux-kernel
Hi all,
I own a Sony Vaio VGN-FS285B and disk performance to say at least is very very
slow. Writing 1 GB data makes the laptop unresponsive. Here is some data
identifying the drive. Hope someone can tell me how to debug and find out
whats the problem.
FWIW since 2.6.16 the problem is same and I didn't test with 2.4 kernels. Here
is some data. And I tested with xfs & ext3. Both slow slow disk writes.
vaio cartman # hdparm /dev/hda
/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 156301488, start = 0
vaio cartman # hdparm -i /dev/hda
/dev/hda:
Model=FUJITSU MHV2080AT, FwRev=00000096, SerialNo=NS56T58270LE
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
IORDY=yes, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma3 udma4 *udma5
AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a: ATA/ATAPI-2
ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6
* signifies the current active mode
vaio cartman # hdparm -tT /dev/hda
/dev/hda:
Timing cached reads: 1576 MB in 2.00 seconds = 788.18 MB/sec
Timing buffered disk reads: 74 MB in 3.01 seconds = 24.55 MB/sec
[~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB) copied, 77,2809 s, 13,9 MB/s
real 1m17.482s
user 0m0.003s
sys 0m2.350s
dmesg follows:
PTL 0x0000005f) @ 0x1f6e9e78
ACPI: FADT (v002 Sony J1 0x20050311 PTL 0x0000005f) @ 0x1f6e9ee0
ACPI: BOOT (v001 Sony J1 0x20050311 PTL 0x00000001) @ 0x1f6e9fd8
ACPI: MCFG (v001 Sony J1 0x20050311 PTL 0x0000005f) @ 0x1f6e9f9c
ACPI: SSDT (v001 Sony J1 0x20050311 PTL 0x20030224) @ 0x1f6e618f
ACPI: SSDT (v001 Sony J1 0x20050311 PTL 0x20030224) @ 0x1f6e5d4a
ACPI: SSDT (v001 Sony J1 0x20050311 PTL 0x20030224) @ 0x1f6e5b2f
ACPI: SSDT (v001 Sony J1 0x20050311 PTL 0x20030224) @ 0x1f6e5916
ACPI: DSDT (v001 Sony J1 0x20050311 PTL 0x20030224) @ 0x00000000
ACPI: PM-Timer IO Port: 0x1008
Allocating PCI resources starting at 30000000 (gap: 20000000:c0000000)
Detected 1792.955 MHz processor.
Built 1 zonelists. Total pages: 127731
Kernel command line: root=/dev/hda1 vga=791 mudur=language:tr
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 506696k/514944k available (2242k kernel code, 7824k reserved, 734k
data, 176k init, 0k highmem)
virtual kernel memory layout:
fixmap : 0xfffeb000 - 0xfffff000 ( 80 kB)
pkmap : 0xff800000 - 0xffc00000 (4096 kB)
vmalloc : 0xe0000000 - 0xff7fe000 ( 503 MB)
lowmem : 0xc0000000 - 0xdf6e0000 ( 502 MB)
.init : 0xc03ec000 - 0xc0418000 ( 176 kB)
.data : 0xc033099f - 0xc03e850c ( 734 kB)
.text : 0xc0100000 - 0xc033099f (2242 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3462.00 BogoMIPS
(lpj=5768004)
Security Framework v1.0.0 initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: afe9fbff 00100000 00000000 00000000
00000180 00000000 00000000
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: After all inits, caps: afe9fbff 00100000 00000000 00002040 00000180
00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Compat vDSO mapped to ffffe000.
CPU: Intel(R) Pentium(R) M processor 1.73GHz stepping 08
Checking 'hlt' instruction... OK.
ACPI: Core revision 20060707
ACPI: setting ELCR to 0200 (from 0cb8)
NET: Registered protocol family 16
No dock devices found.
ACPI: bus type pci registered
PCI: Using MMCONFIG
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
Boot video device is 0000:00:02.0
PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
PCI quirk: region 1180-11bf claimed by ICH6 GPIO
PCI: Firmware left 0000:06:08.0 e100 interrupts enabled, disabling
PCI: Transparent bridge - 0000:00:1e.0
PCI: Bus #07 (-#0a) is hidden behind transparent bridge #06 (-#07)
(try 'pci=assign-busses')
Please report the result to linux-kernel to fix this permanently
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 12 14 15) *11
ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 *4 5 6 7 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 1 *3 4 5 6 7 10 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 11 12 14 15) *10
ACPI: PCI Interrupt Link [LNKE] (IRQs 1 3 4 5 6 *7 10 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 1 3 4 5 6 7 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 1 3 4 5 6 7 10 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 1 3 4 *5 6 7 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 8 devices
PnPBIOS: Disabled by ACPI PNP
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
PCI: Bus 7, cardbus bridge: 0000:06:03.0
IO window: 00002400-000024ff
IO window: 00002800-000028ff
PREFETCH window: 30000000-33ffffff
MEM window: 38000000-3bffffff
PCI: Bridge: 0000:00:1e.0
IO window: 2000-2fff
MEM window: b0100000-b01fffff
PREFETCH window: 30000000-33ffffff
PCI: Setting latency timer of device 0000:00:1e.0 to 64
PCI: Enabling device 0000:06:03.0 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:06:03.0[A] -> Link [LNKA] -> GSI 10 (level, low) ->
IRQ 10
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
Simple Boot Flag at 0x36 set to 0x1
Machine check exception polling timer started.
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
apm: overridden by ACPI.
audit: initializing netlink socket (disabled)
audit(1169299806.936:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
SGI XFS with ACLs, security attributes, no debug enabled
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
vesafb: framebuffer at 0xc0000000, mapped to 0xe0080000, using 3072k, total
7872k
vesafb: mode is 1024x768x16, linelength=2048, pages=4
vesafb: protected mode interface info at 00ff:44f0
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
ACPI: AC Adapter [ADP1] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
input: Lid Switch as /class/input/input1
ACPI: Lid Switch [LID0]
input: Power Button (CM) as /class/input/input2
ACPI: Power Button (CM) [PWRB]
ACPI: Video Device [NGFX] (multi-head: yes rom: no post: no)
ACPI: Video Device [GFX0] (multi-head: yes rom: yes post: no)
Using specific hotkey driver
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI: Thermal Zone [THRM] (54 C)
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12ac
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
floppy0: no floppy controllers found
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH6: IDE controller at PCI slot 0000:00:1f.1
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 3
PCI: setting IRQ 3 as level-triggered
ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKC] -> GSI 3 (level, low) ->
IRQ 3
ICH6: chipset revision 3
ICH6: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x1810-0x1817, BIOS settings: hda:DMA, hdb:DMA
Probing IDE interface ide0...
hda: FUJITSU MHV2080AT, ATA DISK drive
hdb: MATSHITAUJ-840D, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hda: max request size: 128KiB
hda: 156301488 sectors (80026 MB) w/8192KiB Cache, CHS=65535/16/63, UDMA(100)
hda: cache flushes supported
hda: hda1
hdb: ATAPI 24X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
i8042.c: Detected active multiplexing controller, rev 1.1.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX0 port at 0x60,0x64 irq 12
serio: i8042 AUX1 port at 0x60,0x64 irq 12
serio: i8042 AUX2 port at 0x60,0x64 irq 12
serio: i8042 AUX3 port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input3
input: PS/2 Mouse as /class/input/input4
input: AlpsPS/2 ALPS GlidePoint as /class/input/input5
input: PC Speaker as /class/input/input6
NET: Registered protocol family 1
Using IPI Shortcut mode
ACPI: (supports S0 S3 S4 S5)
Time: tsc clocksource has been installed.
Time: acpi_pm clocksource has been installed.
UDF-fs: No VRS found
XFS mounting filesystem hda1
Ending clean XFS mount for filesystem: hda1
VFS: Mounted root (xfs filesystem) readonly.
Freeing unused kernel memory: 176k freed
ACPI Sony Notebook Control Driver successfully installed
fuse init (API version 7.8)
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Adding 614392k swap on /.swap. Priority:-1 extents:1 across:614392k
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: CHECK for good STATUS
ieee1394: Initialized config rom entry `ip1394'
ACPI: PCI Interrupt 0000:06:03.2[C] -> Link [LNKC] -> GSI 3 (level, low) ->
IRQ 3
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[3] MMIO=[b0104000-b01047ff]
Max Packet=[2048] IR/IT contexts=[4/8]
e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 7
PCI: setting IRQ 7 as level-triggered
ACPI: PCI Interrupt 0000:06:08.0[A] -> Link [LNKE] -> GSI 7 (level, low) ->
IRQ 7
e100: eth0: e100_probe: addr 0xb0107000, irq 7, MAC addr 00:01:4A:C0:6C:0C
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI Interrupt 0000:00:1d.7[A] -> Link [LNKH] -> GSI 5 (level, low) ->
IRQ 5
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 5, io mem 0xb0004000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected an Intel 915GM Chipset.
agpgart: Detected 7932K stolen memory.
agpgart: AGP aperture is 256M @ 0xc0000000
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKH] -> GSI 5 (level, low) ->
IRQ 5
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 5, io base 0x00001820
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [LNKD] -> GSI 11 (level, low) ->
IRQ 11
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 11, io base 0x00001840
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKC] -> GSI 3 (level, low) ->
IRQ 3
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 3, io base 0x00001860
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.3[D] -> Link [LNKA] -> GSI 10 (level, low) ->
IRQ 10
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 10, io base 0x00001880
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usb 2-1: new low speed USB device using uhci_hcd and address 2
speedstep-centrino with X86_SPEEDSTEP_CENTRINO_ACPI config is deprecated.
Use X86_ACPI_CPUFREQ (acpi-cpufreq) instead.
intel_rng: FWH not detected
usb 2-1: configuration #1 chosen from 1 choice
usbcore: registered new interface driver hiddev
input: Logitech USB Receiver as /class/input/input7
input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:1d.0-1
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
ieee1394: Host added: ID:BUS[0-00:1023] GUID[0800460301e6fd1a]
eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Yenta: CardBus bridge found at 0000:06:03.0 [104d:818f]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:06:03.0, mfunc 0x01001b22, devctl 0x64
Yenta: ISA IRQ mask 0x0050, PCI irq 10
Socket status: 30000006
Yenta: Raising subordinate bus# of parent bus (#06) from #07 to #0a
pcmcia: parent PCI bridge I/O window: 0x2000 - 0x2fff
cs: IO port probe 0x2000-0x2fff: clean.
pcmcia: parent PCI bridge Memory window: 0xb0100000 - 0xb01fffff
pcmcia: parent PCI bridge Memory window: 0x30000000 - 0x33ffffff
ieee80211_crypt: registered algorithm 'NULL'
ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation
<jketreno@linux.intel.com>
ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.0kmprq
ipw2200: Copyright(c) 2003-2006 Intel Corporation
ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 10
ACPI: PCI Interrupt 0000:06:04.0[A] -> Link [LNKG] -> GSI 10 (level, low) ->
IRQ 10
ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
ipw2200: Detected geography ZZD (13 802.11bg channels, 0 802.11a channels)
cs: IO port probe 0x100-0x3af: clean.
cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7
cs: IO port probe 0x820-0x8ff: clean.
cs: IO port probe 0xc00-0xcf7: clean.
cs: IO port probe 0xa00-0xaff: clean.
ACPI: PCI Interrupt 0000:00:1b.0[A] -> Link [LNKA] -> GSI 10 (level, low) ->
IRQ 10
PCI: Setting latency timer of device 0000:00:1b.0 to 64
ACPI: PCI Interrupt 0000:00:1f.3[B] -> Link [LNKD] -> GSI 11 (level, low) ->
IRQ 11
NET: Registered protocol family 17
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
[drm] Initialized drm 1.1.0 20060810
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKA] -> GSI 10 (level, low) ->
IRQ 10
[drm] Initialized i915 1.6.0 20060119 on minor 0
usb 2-1: USB disconnect, address 2
usb 2-1: new low speed USB device using uhci_hcd and address 3
usb 2-1: configuration #1 chosen from 1 choice
input: Logitech USB Receiver as /class/input/input8
input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:1d.0-1
usb 2-1: USB disconnect, address 3
usb 3-1: new low speed USB device using uhci_hcd and address 2
usb 3-1: configuration #1 chosen from 1 choice
input: Logitech USB Receiver as /class/input/input9
input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:1d.1-1
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 17:20 Abysmal disk performance, how to debug? Ismail Dönmez
@ 2007-01-20 17:45 ` Willy Tarreau
2007-01-20 17:52 ` Ismail Dönmez
0 siblings, 1 reply; 27+ messages in thread
From: Willy Tarreau @ 2007-01-20 17:45 UTC (permalink / raw)
To: Ismail Dönmez; +Cc: linux-kernel
Hi,
On Sat, Jan 20, 2007 at 07:20:53PM +0200, Ismail Dönmez wrote:
> Hi all,
>
> I own a Sony Vaio VGN-FS285B and disk performance to say at least is very very
> slow. Writing 1 GB data makes the laptop unresponsive. Here is some data
> identifying the drive. Hope someone can tell me how to debug and find out
> whats the problem.
>
> FWIW since 2.6.16 the problem is same and I didn't test with 2.4 kernels. Here
> is some data. And I tested with xfs & ext3. Both slow slow disk writes.
>
> vaio cartman # hdparm /dev/hda
>
> /dev/hda:
> multcount = 16 (on)
> IO_support = 1 (32-bit)
> unmaskirq = 1 (on)
> using_dma = 1 (on)
> keepsettings = 0 (off)
> readonly = 0 (off)
> readahead = 256 (on)
> geometry = 65535/16/63, sectors = 156301488, start = 0
> vaio cartman # hdparm -i /dev/hda
>
> /dev/hda:
>
> Model=FUJITSU MHV2080AT, FwRev=00000096, SerialNo=NS56T58270LE
> Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
> BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16
> CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
> IORDY=yes, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
> PIO modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: mdma0 mdma1 mdma2
> UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma3 udma4 *udma5
> AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
> Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a: ATA/ATAPI-2
> ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6
>
> * signifies the current active mode
>
>
> vaio cartman # hdparm -tT /dev/hda
>
> /dev/hda:
> Timing cached reads: 1576 MB in 2.00 seconds = 788.18 MB/sec
> Timing buffered disk reads: 74 MB in 3.01 seconds = 24.55 MB/sec
>
>
> [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1,1 GB) copied, 77,2809 s, 13,9 MB/s
>
> real 1m17.482s
> user 0m0.003s
> sys 0m2.350s
That's not bad at all ! I suspect that if your system becomes unresponsive,
it's because real writes start when the cache is full. And if you fill
512 MB of RAM with data that you then need to flush on disk at 14 MB/s, it
can take about 40 seconds during which it might be difficult to do anything.
Try lowering the cache flush starting point to about 10 MB if you want
(2% of 512 MB) :
# echo 2 >/proc/sys/vm/dirty_ratio
# echo 2 >/proc/sys/vm/dirty_background_ratio
I see nothing wrong in your measures nor messages.
Regards,
Willy
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 17:45 ` Willy Tarreau
@ 2007-01-20 17:52 ` Ismail Dönmez
2007-01-20 18:03 ` Willy Tarreau
2007-01-20 20:10 ` Tim Schmielau
0 siblings, 2 replies; 27+ messages in thread
From: Ismail Dönmez @ 2007-01-20 17:52 UTC (permalink / raw)
To: Willy Tarreau; +Cc: linux-kernel
20 Oca 2007 Cts 19:45 tarihinde şunları yazmıştınız:
[...]
> > vaio cartman # hdparm -tT /dev/hda
> >
> > /dev/hda:
> > Timing cached reads: 1576 MB in 2.00 seconds = 788.18 MB/sec
> > Timing buffered disk reads: 74 MB in 3.01 seconds = 24.55 MB/sec
> >
> >
> > [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> > 1024+0 records in
> > 1024+0 records out
> > 1073741824 bytes (1,1 GB) copied, 77,2809 s, 13,9 MB/s
> >
> > real 1m17.482s
> > user 0m0.003s
> > sys 0m2.350s
>
> That's not bad at all ! I suspect that if your system becomes unresponsive,
> it's because real writes start when the cache is full. And if you fill
> 512 MB of RAM with data that you then need to flush on disk at 14 MB/s, it
> can take about 40 seconds during which it might be difficult to do
> anything.
>
> Try lowering the cache flush starting point to about 10 MB if you want
> (2% of 512 MB) :
>
> # echo 2 >/proc/sys/vm/dirty_ratio
> # echo 2 >/proc/sys/vm/dirty_background_ratio
After that I get,
[~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB) copied, 41,7005 s, 25,7 MB/s
real 0m41.926s
user 0m0.007s
sys 0m2.500s
not bad! thanks :)
Regards,
ismail
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 17:52 ` Ismail Dönmez
@ 2007-01-20 18:03 ` Willy Tarreau
2007-01-20 18:06 ` Ismail Dönmez
2007-01-20 19:44 ` Sunil Naidu
2007-01-20 20:10 ` Tim Schmielau
1 sibling, 2 replies; 27+ messages in thread
From: Willy Tarreau @ 2007-01-20 18:03 UTC (permalink / raw)
To: Ismail Dönmez; +Cc: linux-kernel
On Sat, Jan 20, 2007 at 07:52:53PM +0200, Ismail Dönmez wrote:
> 20 Oca 2007 Cts 19:45 tarihinde ??unlar?? yazm????t??n??z:
> [...]
> > > vaio cartman # hdparm -tT /dev/hda
> > >
> > > /dev/hda:
> > > Timing cached reads: 1576 MB in 2.00 seconds = 788.18 MB/sec
> > > Timing buffered disk reads: 74 MB in 3.01 seconds = 24.55 MB/sec
> > >
> > >
> > > [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> > > 1024+0 records in
> > > 1024+0 records out
> > > 1073741824 bytes (1,1 GB) copied, 77,2809 s, 13,9 MB/s
> > >
> > > real 1m17.482s
> > > user 0m0.003s
> > > sys 0m2.350s
> >
> > That's not bad at all ! I suspect that if your system becomes unresponsive,
> > it's because real writes start when the cache is full. And if you fill
> > 512 MB of RAM with data that you then need to flush on disk at 14 MB/s, it
> > can take about 40 seconds during which it might be difficult to do
> > anything.
> >
> > Try lowering the cache flush starting point to about 10 MB if you want
> > (2% of 512 MB) :
> >
> > # echo 2 >/proc/sys/vm/dirty_ratio
> > # echo 2 >/proc/sys/vm/dirty_background_ratio
>
> After that I get,
>
> [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1,1 GB) copied, 41,7005 s, 25,7 MB/s
>
> real 0m41.926s
> user 0m0.007s
> sys 0m2.500s
>
>
> not bad! thanks :)
It is not expected to increase write performance, but it should help
you do something else during that time, or also give more responsiveness
to Ctrl-C. It is possible that you have fast and slow RAM, or that your
video card uses shared memory which slows down some parts of memory
which are not used anymore with those parameters.
Regards,
Willy
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 18:03 ` Willy Tarreau
@ 2007-01-20 18:06 ` Ismail Dönmez
2007-01-20 19:44 ` Sunil Naidu
1 sibling, 0 replies; 27+ messages in thread
From: Ismail Dönmez @ 2007-01-20 18:06 UTC (permalink / raw)
To: Willy Tarreau; +Cc: linux-kernel
20 Oca 2007 Cts 20:03 tarihinde şunları yazmıştınız:
> On Sat, Jan 20, 2007 at 07:52:53PM +0200, Ismail Dönmez wrote:
> > 20 Oca 2007 Cts 19:45 tarihinde ??unlar?? yazm????t??n??z:
> > [...]
> >
> > > > vaio cartman # hdparm -tT /dev/hda
> > > >
> > > > /dev/hda:
> > > > Timing cached reads: 1576 MB in 2.00 seconds = 788.18 MB/sec
> > > > Timing buffered disk reads: 74 MB in 3.01 seconds = 24.55 MB/sec
> > > >
> > > >
> > > > [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> > > > 1024+0 records in
> > > > 1024+0 records out
> > > > 1073741824 bytes (1,1 GB) copied, 77,2809 s, 13,9 MB/s
> > > >
> > > > real 1m17.482s
> > > > user 0m0.003s
> > > > sys 0m2.350s
> > >
> > > That's not bad at all ! I suspect that if your system becomes
> > > unresponsive, it's because real writes start when the cache is full.
> > > And if you fill 512 MB of RAM with data that you then need to flush on
> > > disk at 14 MB/s, it can take about 40 seconds during which it might be
> > > difficult to do anything.
> > >
> > > Try lowering the cache flush starting point to about 10 MB if you want
> > > (2% of 512 MB) :
> > >
> > > # echo 2 >/proc/sys/vm/dirty_ratio
> > > # echo 2 >/proc/sys/vm/dirty_background_ratio
> >
> > After that I get,
> >
> > [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> > 1024+0 records in
> > 1024+0 records out
> > 1073741824 bytes (1,1 GB) copied, 41,7005 s, 25,7 MB/s
> >
> > real 0m41.926s
> > user 0m0.007s
> > sys 0m2.500s
> >
> >
> > not bad! thanks :)
>
> It is not expected to increase write performance, but it should help
> you do something else during that time, or also give more responsiveness
> to Ctrl-C. It is possible that you have fast and slow RAM, or that your
> video card uses shared memory which slows down some parts of memory
> which are not used anymore with those parameters.
Thanks I will try to upgrade RAM but for now at least responsiveness seems to
be better.
Regards,
ismail
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 18:03 ` Willy Tarreau
2007-01-20 18:06 ` Ismail Dönmez
@ 2007-01-20 19:44 ` Sunil Naidu
2007-01-20 19:56 ` Stephen Clark
2007-01-20 20:05 ` Willy Tarreau
1 sibling, 2 replies; 27+ messages in thread
From: Sunil Naidu @ 2007-01-20 19:44 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Ismail Dönmez, linux-kernel
On 1/20/07, Willy Tarreau <w@1wt.eu> wrote:
> > > >
>
> It is not expected to increase write performance, but it should help
> you do something else during that time, or also give more responsiveness
> to Ctrl-C. It is possible that you have fast and slow RAM, or that your
> video card uses shared memory which slows down some parts of memory
> which are not used anymore with those parameters.
I did test some SATA drives, am getting these value for 2.6.20-rc5:-
[sukhoi@Typhoon ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 21.0962 seconds, 50.9 MB/s
What can you suggest here w.r.t my RAM & disk?
> Willy
Thanks,
~Akula2
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 19:44 ` Sunil Naidu
@ 2007-01-20 19:56 ` Stephen Clark
2007-01-20 20:09 ` Willy Tarreau
2007-01-20 20:05 ` Willy Tarreau
1 sibling, 1 reply; 27+ messages in thread
From: Stephen Clark @ 2007-01-20 19:56 UTC (permalink / raw)
To: Sunil Naidu; +Cc: Willy Tarreau, Ismail Dönmez, linux-kernel
Sunil Naidu wrote:
>On 1/20/07, Willy Tarreau <w@1wt.eu> wrote:
>
>
>>It is not expected to increase write performance, but it should help
>>you do something else during that time, or also give more responsiveness
>>to Ctrl-C. It is possible that you have fast and slow RAM, or that your
>>video card uses shared memory which slows down some parts of memory
>>which are not used anymore with those parameters.
>>
>>
>
>I did test some SATA drives, am getting these value for 2.6.20-rc5:-
>
>[sukhoi@Typhoon ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
>1024+0 records in
>1024+0 records out
>1073741824 bytes (1.1 GB) copied, 21.0962 seconds, 50.9 MB/s
>
>What can you suggest here w.r.t my RAM & disk?
>
>
>
>>Willy
>>
>>
>
>Thanks,
>
>~Akula2
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
Hi,
whitebook vbi s96f core 2 duo t5600 2gb hitachi ATA HTS721060G9AT00
using libata
time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 10.0092 seconds, 107 MB/s
real 0m10.196s
user 0m0.004s
sys 0m3.440s
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 19:44 ` Sunil Naidu
2007-01-20 19:56 ` Stephen Clark
@ 2007-01-20 20:05 ` Willy Tarreau
2007-01-20 20:11 ` Ismail Dönmez
1 sibling, 1 reply; 27+ messages in thread
From: Willy Tarreau @ 2007-01-20 20:05 UTC (permalink / raw)
To: Sunil Naidu; +Cc: Ismail Dönmez, linux-kernel
On Sun, Jan 21, 2007 at 01:14:41AM +0530, Sunil Naidu wrote:
> On 1/20/07, Willy Tarreau <w@1wt.eu> wrote:
> >> > >
> >
> >It is not expected to increase write performance, but it should help
> >you do something else during that time, or also give more responsiveness
> >to Ctrl-C. It is possible that you have fast and slow RAM, or that your
> >video card uses shared memory which slows down some parts of memory
> >which are not used anymore with those parameters.
>
> I did test some SATA drives, am getting these value for 2.6.20-rc5:-
>
> [sukhoi@Typhoon ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1.1 GB) copied, 21.0962 seconds, 50.9 MB/s
>
> What can you suggest here w.r.t my RAM & disk?
I don't suggest anything, this is already very good. The only goal of
reducing memory write cache is to get a more responsive system when
dumping massive amounts of data to disks, like above, because when
the system starts flushing the caches, you can only wait for it to
finish. But those tests are not realistic loads. A desktop and most
servers will benefit from large caches. But *some* workloads will
benefit from smaller caches if they consist in writing continuous
streams (eg: tcpdump or video recorders). What I suggested to the
user above was a way to get the system more responsive during his
test. It should not have changed the throughput at all if the
hardware was not a bit strange (well, it's a VAIO after all, I've
had one too, fortunately it died one month after the warranty,
putting an end to all my problems...).
Regards,
Willy
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 19:56 ` Stephen Clark
@ 2007-01-20 20:09 ` Willy Tarreau
2007-01-21 3:41 ` Stephen Clark
2007-01-27 19:43 ` Bill Davidsen
0 siblings, 2 replies; 27+ messages in thread
From: Willy Tarreau @ 2007-01-20 20:09 UTC (permalink / raw)
To: Stephen Clark; +Cc: Sunil Naidu, Ismail Dönmez, linux-kernel
On Sat, Jan 20, 2007 at 02:56:20PM -0500, Stephen Clark wrote:
> Sunil Naidu wrote:
>
> >On 1/20/07, Willy Tarreau <w@1wt.eu> wrote:
> >
> >
> >>It is not expected to increase write performance, but it should help
> >>you do something else during that time, or also give more responsiveness
> >>to Ctrl-C. It is possible that you have fast and slow RAM, or that your
> >>video card uses shared memory which slows down some parts of memory
> >>which are not used anymore with those parameters.
> >>
> >>
> >
> >I did test some SATA drives, am getting these value for 2.6.20-rc5:-
> >
> >[sukhoi@Typhoon ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> >1024+0 records in
> >1024+0 records out
> >1073741824 bytes (1.1 GB) copied, 21.0962 seconds, 50.9 MB/s
> >
> >What can you suggest here w.r.t my RAM & disk?
> >
> >
> >
> >>Willy
> >>
> >>
> >
> >Thanks,
> >
> >~Akula2
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at http://vger.kernel.org/majordomo-info.html
> >Please read the FAQ at http://www.tux.org/lkml/
> >
> >
> >
> Hi,
> whitebook vbi s96f core 2 duo t5600 2gb hitachi ATA HTS721060G9AT00
> using libata
> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1.1 GB) copied, 10.0092 seconds, 107 MB/s
>
> real 0m10.196s
> user 0m0.004s
> sys 0m3.440s
You have too much RAM, it's possible that writes did not complete before
the end of your measurement. Try this instead :
$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 | sync
Willy
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 17:52 ` Ismail Dönmez
2007-01-20 18:03 ` Willy Tarreau
@ 2007-01-20 20:10 ` Tim Schmielau
2007-01-20 20:16 ` Ismail Dönmez
` (2 more replies)
1 sibling, 3 replies; 27+ messages in thread
From: Tim Schmielau @ 2007-01-20 20:10 UTC (permalink / raw)
To: Ismail Dönmez; +Cc: Willy Tarreau, linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1859 bytes --]
On Sat, 20 Jan 2007, Ismail Dönmez wrote:
> 20 Oca 2007 Cts 19:45 tarihinde şunları yazmıştınız:
> [...]
> > > vaio cartman # hdparm -tT /dev/hda
> > >
> > > /dev/hda:
> > > Timing cached reads: 1576 MB in 2.00 seconds = 788.18 MB/sec
> > > Timing buffered disk reads: 74 MB in 3.01 seconds = 24.55 MB/sec
> > >
> > >
> > > [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> > > 1024+0 records in
> > > 1024+0 records out
> > > 1073741824 bytes (1,1 GB) copied, 77,2809 s, 13,9 MB/s
> > >
> > > real 1m17.482s
> > > user 0m0.003s
> > > sys 0m2.350s
> >
> > That's not bad at all ! I suspect that if your system becomes unresponsive,
> > it's because real writes start when the cache is full. And if you fill
> > 512 MB of RAM with data that you then need to flush on disk at 14 MB/s, it
> > can take about 40 seconds during which it might be difficult to do
> > anything.
> >
> > Try lowering the cache flush starting point to about 10 MB if you want
> > (2% of 512 MB) :
> >
> > # echo 2 >/proc/sys/vm/dirty_ratio
> > # echo 2 >/proc/sys/vm/dirty_background_ratio
>
> After that I get,
>
> [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1,1 GB) copied, 41,7005 s, 25,7 MB/s
>
> real 0m41.926s
> user 0m0.007s
> sys 0m2.500s
>
>
> not bad! thanks :)
Note that these dd "benchmarks" are completely bogus, because the data
doesn't actually get written to disk in that time. For some enlightening
data, try
time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; time sync
The dd returns as soon as all data could be buffered in RAM. Only sync
will show how long it takes to actually write out the data to disk.
also explains why you see better results is writeout starts earlier.
Tim
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 20:05 ` Willy Tarreau
@ 2007-01-20 20:11 ` Ismail Dönmez
0 siblings, 0 replies; 27+ messages in thread
From: Ismail Dönmez @ 2007-01-20 20:11 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Sunil Naidu, linux-kernel
20 Oca 2007 Cts 22:05 tarihinde, Willy Tarreau şunları yazmıştı:
> On Sun, Jan 21, 2007 at 01:14:41AM +0530, Sunil Naidu wrote:
> > On 1/20/07, Willy Tarreau <w@1wt.eu> wrote:
[...]
> It should not have changed the throughput at all if the
> hardware was not a bit strange (well, it's a VAIO after all, I've
> had one too, fortunately it died one month after the warranty,
> putting an end to all my problems...).
How true is this, VAIO sucks on Linux :'(
Regards,
ismail
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 20:10 ` Tim Schmielau
@ 2007-01-20 20:16 ` Ismail Dönmez
2007-01-20 20:19 ` Willy Tarreau
2007-01-20 20:21 ` Tim Schmielau
2007-01-20 20:28 ` Willy Tarreau
2007-01-20 21:12 ` Sunil Naidu
2 siblings, 2 replies; 27+ messages in thread
From: Ismail Dönmez @ 2007-01-20 20:16 UTC (permalink / raw)
To: Tim Schmielau; +Cc: Willy Tarreau, linux-kernel
20 Oca 2007 Cts 22:10 tarihinde, Tim Schmielau şunları yazmıştı:
[...]
>
> Note that these dd "benchmarks" are completely bogus, because the data=20
> doesn't actually get written to disk in that time. For some enlightening=20
> data, try
>
> time dd if=3D/dev/zero of=3D/tmp/1GB bs=3D1M count=3D1024; time sync
>
> The dd returns as soon as all data could be buffered in RAM. Only sync=20
> will show how long it takes to actually write out the data to disk.
> also explains why you see better results is writeout starts earlier.
Still not that bad:
[~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024;sync
1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB) copied, 53,3194 s, 20,1 MB/s
real 0m53.517s
user 0m0.003s
sys 0m3.193s
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 20:16 ` Ismail Dönmez
@ 2007-01-20 20:19 ` Willy Tarreau
2007-01-20 20:28 ` Tim Schmielau
2007-01-20 20:21 ` Tim Schmielau
1 sibling, 1 reply; 27+ messages in thread
From: Willy Tarreau @ 2007-01-20 20:19 UTC (permalink / raw)
To: Ismail Dönmez; +Cc: Tim Schmielau, linux-kernel
On Sat, Jan 20, 2007 at 10:16:15PM +0200, Ismail Dönmez wrote:
> 20 Oca 2007 Cts 22:10 tarihinde, Tim Schmielau ??unlar?? yazm????t??:
> [...]
> >
> > Note that these dd "benchmarks" are completely bogus, because the data=20
> > doesn't actually get written to disk in that time. For some enlightening=20
> > data, try
> >
> > time dd if=3D/dev/zero of=3D/tmp/1GB bs=3D1M count=3D1024; time sync
> >
> > The dd returns as soon as all data could be buffered in RAM. Only sync=20
> > will show how long it takes to actually write out the data to disk.
> > also explains why you see better results is writeout starts earlier.
>
> Still not that bad:
>
> [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024;sync
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1,1 GB) copied, 53,3194 s, 20,1 MB/s
>
> real 0m53.517s
> user 0m0.003s
> sys 0m3.193s
No, your measure is wrong because time measures "dd" and sync is done
after. Either use Tim's method (time sync) or the one I proposed in
previous mail (time dd | sync). Anyway, in your situation with a very
small buffer, this should not change by more than half a second or so.
Willy
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 20:16 ` Ismail Dönmez
2007-01-20 20:19 ` Willy Tarreau
@ 2007-01-20 20:21 ` Tim Schmielau
1 sibling, 0 replies; 27+ messages in thread
From: Tim Schmielau @ 2007-01-20 20:21 UTC (permalink / raw)
To: Ismail Dönmez; +Cc: Willy Tarreau, linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1290 bytes --]
On Sat, 20 Jan 2007, Ismail Dönmez wrote:
> 20 Oca 2007 Cts 22:10 tarihinde, Tim Schmielau şunları yazmıştı:
> >
> > Note that these dd "benchmarks" are completely bogus, because the data=20
> > doesn't actually get written to disk in that time. For some enlightening=20
> > data, try
> >
> > time dd if=3D/dev/zero of=3D/tmp/1GB bs=3D1M count=3D1024; time sync
^^^^
> >
> > The dd returns as soon as all data could be buffered in RAM. Only sync=20
> > will show how long it takes to actually write out the data to disk.
> > also explains why you see better results is writeout starts earlier.
>
> Still not that bad:
>
> [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024;sync
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1,1 GB) copied, 53,3194 s, 20,1 MB/s
>
> real 0m53.517s
> user 0m0.003s
> sys 0m3.193s
>
That's not the point, you still measured the same as before (but you might
have noticed that, after printing the results, the shell prompt took some
time to appear). I appended "time sync" to the command to show that
(depending on the amount of available memory) actually most of the time
is spent in the "sync", not the "dd".
Tim
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 20:10 ` Tim Schmielau
2007-01-20 20:16 ` Ismail Dönmez
@ 2007-01-20 20:28 ` Willy Tarreau
2007-01-20 20:39 ` Tim Schmielau
2007-01-20 21:12 ` Sunil Naidu
2 siblings, 1 reply; 27+ messages in thread
From: Willy Tarreau @ 2007-01-20 20:28 UTC (permalink / raw)
To: Tim Schmielau; +Cc: Ismail Dönmez, linux-kernel
Hi Tim,
On Sat, Jan 20, 2007 at 09:10:22PM +0100, Tim Schmielau wrote:
> On Sat, 20 Jan 2007, Ismail Dönmez wrote:
>
> > 20 Oca 2007 Cts 19:45 tarihinde ??unlar?? yazm????t??n??z:
> > [...]
> > > > vaio cartman # hdparm -tT /dev/hda
> > > >
> > > > /dev/hda:
> > > > Timing cached reads: 1576 MB in 2.00 seconds = 788.18 MB/sec
> > > > Timing buffered disk reads: 74 MB in 3.01 seconds = 24.55 MB/sec
> > > >
> > > >
> > > > [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> > > > 1024+0 records in
> > > > 1024+0 records out
> > > > 1073741824 bytes (1,1 GB) copied, 77,2809 s, 13,9 MB/s
> > > >
> > > > real 1m17.482s
> > > > user 0m0.003s
> > > > sys 0m2.350s
> > >
> > > That's not bad at all ! I suspect that if your system becomes unresponsive,
> > > it's because real writes start when the cache is full. And if you fill
> > > 512 MB of RAM with data that you then need to flush on disk at 14 MB/s, it
> > > can take about 40 seconds during which it might be difficult to do
> > > anything.
> > >
> > > Try lowering the cache flush starting point to about 10 MB if you want
> > > (2% of 512 MB) :
> > >
> > > # echo 2 >/proc/sys/vm/dirty_ratio
> > > # echo 2 >/proc/sys/vm/dirty_background_ratio
> >
> > After that I get,
> >
> > [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> > 1024+0 records in
> > 1024+0 records out
> > 1073741824 bytes (1,1 GB) copied, 41,7005 s, 25,7 MB/s
> >
> > real 0m41.926s
> > user 0m0.007s
> > sys 0m2.500s
> >
> >
> > not bad! thanks :)
>
> Note that these dd "benchmarks" are completely bogus, because the data
> doesn't actually get written to disk in that time. For some enlightening
> data, try
>
> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; time sync
>
> The dd returns as soon as all data could be buffered in RAM. Only sync
> will show how long it takes to actually write out the data to disk.
While I 100% agree with you on this, I'd like to note that I don't agree
with the following statement :
> also explains why you see better results is writeout starts earlier.
The results should be better when writeout starts later since most of
the transfer will have been performed at RAM speed. That's what happens
with the user above with 2 GB RAM. But in case of the VAIO with 512 MB,
there's really something strange IMHO. I suspect it has two RAM areas,
one fast and one slow (probably one two large non-cacheable area for a
shared video or such a crap, which can be avoided when reducing the
cache size).
Best regards,
Willy
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 20:19 ` Willy Tarreau
@ 2007-01-20 20:28 ` Tim Schmielau
2007-01-20 20:31 ` Willy Tarreau
0 siblings, 1 reply; 27+ messages in thread
From: Tim Schmielau @ 2007-01-20 20:28 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Ismail Dönmez, linux-kernel
On Sat, 20 Jan 2007, Willy Tarreau wrote:
> Anyway, in your situation with a very small buffer, this should not
> change by more than half a second or so.
Well, his buffer is not small. He has half a GB of RAM, so when
writing 1 GB the buffer would roughly double the dd speed, exactly as he
has shown us.
Anyways, instead of always just posting similar answers to yours, I'll
have dinner now. :-)
Tim
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 20:28 ` Tim Schmielau
@ 2007-01-20 20:31 ` Willy Tarreau
0 siblings, 0 replies; 27+ messages in thread
From: Willy Tarreau @ 2007-01-20 20:31 UTC (permalink / raw)
To: Tim Schmielau; +Cc: Ismail Dönmez, linux-kernel
On Sat, Jan 20, 2007 at 09:28:57PM +0100, Tim Schmielau wrote:
> On Sat, 20 Jan 2007, Willy Tarreau wrote:
>
> > Anyway, in your situation with a very small buffer, this should not
> > change by more than half a second or so.
>
> Well, his buffer is not small. He has half a GB of RAM, so when
> writing 1 GB the buffer would roughly double the dd speed, exactly as he
> has shown us.
yes, but he sees the opposite : when using half of the memory for the
buffer, he has low speed. When shorting cache size to 2% only, he doubles
his speed.
> Anyways, instead of always just posting similar answers to yours, I'll
> have dinner now. :-)
:-)
Willy
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 20:28 ` Willy Tarreau
@ 2007-01-20 20:39 ` Tim Schmielau
2007-01-20 21:24 ` Willy Tarreau
0 siblings, 1 reply; 27+ messages in thread
From: Tim Schmielau @ 2007-01-20 20:39 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Ismail Dönm, lkml
On Sat, 20 Jan 2007, Willy Tarreau wrote:
> On Sat, Jan 20, 2007 at 09:10:22PM +0100, Tim Schmielau wrote:
> >
> > Note that these dd "benchmarks" are completely bogus, because the data
> > doesn't actually get written to disk in that time. For some enlightening
> > data, try
> >
> > time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; time sync
> >
> > The dd returns as soon as all data could be buffered in RAM. Only sync
> > will show how long it takes to actually write out the data to disk.
>
> While I 100% agree with you on this, I'd like to note that I don't agree
> with the following statement :
>
> > also explains why you see better results is writeout starts earlier.
>
> The results should be better when writeout starts later since most of
> the transfer will have been performed at RAM speed. That's what happens
> with the user above with 2 GB RAM. But in case of the VAIO with 512 MB,
> there's really something strange IMHO. I suspect it has two RAM areas,
> one fast and one slow (probably one two large non-cacheable area for a
> shared video or such a crap, which can be avoided when reducing the
> cache size).
No - the earlier the writeout starts, the earlier he will have enough free
RAM to finish the dd command by buffering the remaining data.
Note that we did not cap the amount of buffers, just started to write out
earlier.
Tim
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 20:10 ` Tim Schmielau
2007-01-20 20:16 ` Ismail Dönmez
2007-01-20 20:28 ` Willy Tarreau
@ 2007-01-20 21:12 ` Sunil Naidu
2007-01-20 22:00 ` Tim Schmielau
2 siblings, 1 reply; 27+ messages in thread
From: Sunil Naidu @ 2007-01-20 21:12 UTC (permalink / raw)
To: Tim Schmielau; +Cc: Ismail Dönmez, Willy Tarreau, linux-kernel
On 1/21/07, Tim Schmielau <tim@physik3.uni-rostock.de> wrote:
>
> Note that these dd "benchmarks" are completely bogus, because the data
> doesn't actually get written to disk in that time. For some enlightening
> data, try
>
> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; time sync
>
> The dd returns as soon as all data could be buffered in RAM. Only sync
> will show how long it takes to actually write out the data to disk.
> also explains why you see better results is writeout starts earlier.
I am still getting better I feel:
[sukhoi@Typhoon ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; time sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 19.5007 seconds, 55.1 MB/s
real 0m20.439s
user 0m0.004s
sys 0m4.535s
real 0m4.625s
user 0m0.000s
sys 0m0.125s
[sukhoi@Typhoon ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 | sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 20.8707 seconds, 51.4 MB/s
real 0m22.449s
user 0m0.002s
sys 0m4.922s
Linux used here is not 2.6.20-rc5, but it's a FC6 2.6.19 binary. Shall
post the results with 2.6.20-rc5.
BTW, does the results vary with a customized kernel (configured w.r.t
Processor & Hardware) than a generic kernel like FC6?
Are there any other such test cases?
>
> Tim
>
Thanks,
~Akula2
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 20:39 ` Tim Schmielau
@ 2007-01-20 21:24 ` Willy Tarreau
2007-01-20 21:41 ` Tim Schmielau
0 siblings, 1 reply; 27+ messages in thread
From: Willy Tarreau @ 2007-01-20 21:24 UTC (permalink / raw)
To: Tim Schmielau; +Cc: Ismail Dönm, lkml
On Sat, Jan 20, 2007 at 09:39:25PM +0100, Tim Schmielau wrote:
> On Sat, 20 Jan 2007, Willy Tarreau wrote:
> > On Sat, Jan 20, 2007 at 09:10:22PM +0100, Tim Schmielau wrote:
> > >
> > > Note that these dd "benchmarks" are completely bogus, because the data
> > > doesn't actually get written to disk in that time. For some enlightening
> > > data, try
> > >
> > > time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; time sync
> > >
> > > The dd returns as soon as all data could be buffered in RAM. Only sync
> > > will show how long it takes to actually write out the data to disk.
> >
> > While I 100% agree with you on this, I'd like to note that I don't agree
> > with the following statement :
> >
> > > also explains why you see better results is writeout starts earlier.
> >
> > The results should be better when writeout starts later since most of
> > the transfer will have been performed at RAM speed. That's what happens
> > with the user above with 2 GB RAM. But in case of the VAIO with 512 MB,
> > there's really something strange IMHO. I suspect it has two RAM areas,
> > one fast and one slow (probably one two large non-cacheable area for a
> > shared video or such a crap, which can be avoided when reducing the
> > cache size).
>
> No - the earlier the writeout starts, the earlier he will have enough free
> RAM to finish the dd command by buffering the remaining data.
OK I see your point. While trying to show why I got you wrong, I in fact
demonstrated to myself that you were right :-)
For instance, let's say we have 500 MB cache at 1000 MB/s and a write out
threshold of 80% with a disk at 100 MB/s. Writing 1000 MB would produce
this pattern :
time data sent written dirty data
in sec from dd to disk in cache
0.0 0 MB 0 MB 0 MB
0.4 400 MB 0 MB 400 MB -> writeout starts
1.0 560 MB 60 MB 500 MB
5.4 1000 MB 500 MB 500 MB -> dd leaves.
10.4 1000 MB 1000 MB 0 MB -> write terminated.
-> avg dd speed = 1000/5.4 = 185 MB/s
avg disk speed = 1000/10.4 = 96 MB/s
Now with a lower writeout threshold of 2% (10 MB) :
time data sent written dirty data
in sec from dd to disk in cache
0.0 0 MB 0 MB 0 MB
0.01 10 MB 0 MB 10 MB -> writeout starts
1.0 599 MB 99 MB 500 MB
5.01 1000 MB 500 MB 500 MB -> dd leaves.
10.01 1000 MB 1000 MB 0 MB -> write terminated.
-> avg dd speed = 1000/5.01 = 199.6 MB/s
avg disk speed = 1000/10.01 = 99.9 MB/s
At least, numbers are not that much different to justify a one to two speed
ratio on the VAIO. The difference being caused by cache speed, it's clearly
possible that his RAM is definitely very very slow which would then explain
the difference.
----
> Note that we did not cap the amount of buffers, just started to write out
> earlier.
----
Indeed, that's what makes the whole difference. I was used to cap the amount
of buffers, but the behaviour here is different.
Thanks for your insight !
Willy
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 21:24 ` Willy Tarreau
@ 2007-01-20 21:41 ` Tim Schmielau
0 siblings, 0 replies; 27+ messages in thread
From: Tim Schmielau @ 2007-01-20 21:41 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Ismail Dönm, lkml
On Sat, 20 Jan 2007, Willy Tarreau wrote:
> On Sat, Jan 20, 2007 at 09:39:25PM +0100, Tim Schmielau wrote:
> > On Sat, 20 Jan 2007, Willy Tarreau wrote:
> > > On Sat, Jan 20, 2007 at 09:10:22PM +0100, Tim Schmielau wrote:
> > >
> > > > also explains why you see better results is writeout starts earlier.
> > >
> > > The results should be better when writeout starts later since most of
> > > the transfer will have been performed at RAM speed. That's what happens
> > > with the user above with 2 GB RAM. But in case of the VAIO with 512 MB,
> > > there's really something strange IMHO. I suspect it has two RAM areas,
> > > one fast and one slow (probably one two large non-cacheable area for a
> > > shared video or such a crap, which can be avoided when reducing the
> > > cache size).
> >
> > No - the earlier the writeout starts, the earlier he will have enough free
> > RAM to finish the dd command by buffering the remaining data.
>
> OK I see your point. While trying to show why I got you wrong, I in fact
> demonstrated to myself that you were right :-)
>
> For instance, let's say we have 500 MB cache at 1000 MB/s and a write out
> threshold of 80% with a disk at 100 MB/s. Writing 1000 MB would produce
> this pattern :
>
> time data sent written dirty data
> in sec from dd to disk in cache
> 0.0 0 MB 0 MB 0 MB
> 0.4 400 MB 0 MB 400 MB -> writeout starts
> 1.0 560 MB 60 MB 500 MB
> 5.4 1000 MB 500 MB 500 MB -> dd leaves.
> 10.4 1000 MB 1000 MB 0 MB -> write terminated.
>
> -> avg dd speed = 1000/5.4 = 185 MB/s
> avg disk speed = 1000/10.4 = 96 MB/s
>
>
> Now with a lower writeout threshold of 2% (10 MB) :
>
> time data sent written dirty data
> in sec from dd to disk in cache
> 0.0 0 MB 0 MB 0 MB
> 0.01 10 MB 0 MB 10 MB -> writeout starts
> 1.0 599 MB 99 MB 500 MB
> 5.01 1000 MB 500 MB 500 MB -> dd leaves.
> 10.01 1000 MB 1000 MB 0 MB -> write terminated.
>
> -> avg dd speed = 1000/5.01 = 199.6 MB/s
> avg disk speed = 1000/10.01 = 99.9 MB/s
>
> At least, numbers are not that much different to justify a one to two speed
> ratio on the VAIO. The difference being caused by cache speed, it's clearly
> possible that his RAM is definitely very very slow which would then explain
> the difference.
>
> ----
> > Note that we did not cap the amount of buffers, just started to write out
> > earlier.
> ----
>
> Indeed, that's what makes the whole difference. I was used to cap the amount
> of buffers, but the behaviour here is different.
>
> Thanks for your insight !
Thanks for being so humble in pointing out my logic is flawed. While the
Vaio certainly cannot write 1000GB/s to its RAM, it's disk is also quite
slow and the ratio of 10:1 for RAM:disk speed is presumably correct.
So we don't quite understand why dd in RAM is so slow for him.
Thanks,
Tim
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 21:12 ` Sunil Naidu
@ 2007-01-20 22:00 ` Tim Schmielau
2007-01-20 23:47 ` Sunil Naidu
0 siblings, 1 reply; 27+ messages in thread
From: Tim Schmielau @ 2007-01-20 22:00 UTC (permalink / raw)
To: Sunil Naidu; +Cc: Ismail Dönm, Willy Tarreau, lkml
On Sun, 21 Jan 2007, Sunil Naidu wrote:
> On 1/21/07, Tim Schmielau <tim@physik3.uni-rostock.de> wrote:
> >
> > Note that these dd "benchmarks" are completely bogus, because the data
> > doesn't actually get written to disk in that time. For some enlightening
> > data, try
> >
> > time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; time sync
> >
> > The dd returns as soon as all data could be buffered in RAM. Only sync
> > will show how long it takes to actually write out the data to disk.
> > also explains why you see better results is writeout starts earlier.
>
> I am still getting better I feel:
Yes. You have a faster Disk that writes about 45 MB/s. But I am not sure I
understand what you want to know?
> [sukhoi@Typhoon ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; time
> sync
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1.1 GB) copied, 19.5007 seconds, 55.1 MB/s
>
> real 0m20.439s
> user 0m0.004s
> sys 0m4.535s
>
> real 0m4.625s
> user 0m0.000s
> sys 0m0.125s
>
>
> [sukhoi@Typhoon ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 | sync
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1.1 GB) copied, 20.8707 seconds, 51.4 MB/s
>
> real 0m22.449s
> user 0m0.002s
> sys 0m4.922s
>
>
> Linux used here is not 2.6.20-rc5, but it's a FC6 2.6.19 binary. Shall
> post the results with 2.6.20-rc5.
>
> BTW, does the results vary with a customized kernel (configured w.r.t
> Processor & Hardware) than a generic kernel like FC6?
I'd guess the kernel won't make much of a difference as the time is
mostly determined by RAM and disk speeds.
> Are there any other such test cases?
Well, what do you want to find out? Anyways, I am in no way expert in the
field of benchmarking.
Note to Willy:
I finally noticed my logic actually was not flawed. I stated why dd would
report approximately doubled throughputs with buffering, while you argued
why the total elapsed time would not change much.
Time to go to bed now...
Tim
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 22:00 ` Tim Schmielau
@ 2007-01-20 23:47 ` Sunil Naidu
0 siblings, 0 replies; 27+ messages in thread
From: Sunil Naidu @ 2007-01-20 23:47 UTC (permalink / raw)
To: Tim Schmielau; +Cc: Ismail Dönm, Willy Tarreau, lkml
On 1/21/07, Tim Schmielau <tim@physik3.uni-rostock.de> wrote:
> Yes. You have a faster Disk that writes about 45 MB/s. But I am not sure I
> understand what you want to know?
I got these results with a customized 2.6.20-rc5.
[sukhoi@Typhoon kernel]$ uname -a
Linux Typhoon 2.6.20-rc5-Topol-M #1 SMP Sun Jan 21 04:35:28 IST 2007
i686 i686 i386 GNU/Linux
> > [sukhoi@Typhoon ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; time
> > sync
> > 1024+0 records in
> > 1024+0 records out
> > 1073741824 bytes (1.1 GB) copied, 19.5007 seconds, 55.1 MB/s
> >
> > real 0m20.439s
> > user 0m0.004s
> > sys 0m4.535s
> >
> > real 0m4.625s
> > user 0m0.000s
> > sys 0m0.125s
[sukhoi@Typhoon kernel]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; time
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 22.7749 seconds, 47.1 MB/s
real 0m24.541s
user 0m0.005s
sys 0m3.899s
real 0m0.000s
user 0m0.000s
sys 0m0.000s
> >
> > [sukhoi@Typhoon ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 | sync
> > 1024+0 records in
> > 1024+0 records out
> > 1073741824 bytes (1.1 GB) copied, 20.8707 seconds, 51.4 MB/s
> >
> > real 0m22.449s
> > user 0m0.002s
> > sys 0m4.922s
[sukhoi@Typhoon kernel]$ time dd if=/dev/zero of=/tmp/1GB bs=1M
count=1024 | sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 19.8685 seconds, 54.0 MB/s
real 0m21.373s
user 0m0.003s
sys 0m3.859s
> > Linux used here is not 2.6.20-rc5, but it's a FC6 2.6.19 binary. Shall
> > post the results with 2.6.20-rc5.
> >
> > BTW, does the results vary with a customized kernel (configured w.r.t
> > Processor & Hardware) than a generic kernel like FC6?
>
> I'd guess the kernel won't make much of a difference as the time is
> mostly determined by RAM and disk speeds.
There is some deviation in the results between these 2 kernels. Is
this acceptable?
> > Are there any other such test cases?
>
> Well, what do you want to find out? Anyways, I am in no way expert in the
> field of benchmarking.
I would be trying to benchmark the results on my machines in this
fashion (overclocking experiment):-
Disk Types Machine
RAM
SATA 1.5 GBPS - 160 GB P4-HT-3.0 GHz
2x1GB Corsair
SATA 3.0 GBPS - 320 GB P4-HT-3.0 GHz
2x1GB Corsair
SATA 1.5 GBPS - 160 GB P4-HT-3.0 GHz
2x1GB OCZ
SATA 3.0 GBPS - 320 GB P4-HT-3.0 GHz
2x1GB OCZ
SATA 1.5 GBPS - 160 GB P4-HT-3.0 GHz
2x1GB Supertalent
SATA 3.0 GBPS - 320 GB P4-HT-3.0 GHz
2x1GB Supertalent
SATA 1.5 GBPS - 160 GB P4-HT-3.0 GHz
2x1GB Hynix
SATA 3.0 GBPS - 320 GB P4-HT-3.0 GHz
2x1GB Hynix
Boards here would be used are Intel based 915, 965, and 975.
Would be happy to know more test cases - for RAM/Disk/Processor Frequency
And, I don't work for any magazine, writing a review ;-)
>
> Tim
Thanks,
~Akula2
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 20:09 ` Willy Tarreau
@ 2007-01-21 3:41 ` Stephen Clark
2007-01-21 4:06 ` Gene Heskett
2007-01-27 19:43 ` Bill Davidsen
1 sibling, 1 reply; 27+ messages in thread
From: Stephen Clark @ 2007-01-21 3:41 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Sunil Naidu, Ismail Dönmez, linux-kernel
Willy Tarreau wrote:
>On Sat, Jan 20, 2007 at 02:56:20PM -0500, Stephen Clark wrote:
>
>
>>Sunil Naidu wrote:
>>
>>
>>
>>>On 1/20/07, Willy Tarreau <w@1wt.eu> wrote:
>>>
>>>
>>>
>>>
>>>>It is not expected to increase write performance, but it should help
>>>>you do something else during that time, or also give more responsiveness
>>>>to Ctrl-C. It is possible that you have fast and slow RAM, or that your
>>>>video card uses shared memory which slows down some parts of memory
>>>>which are not used anymore with those parameters.
>>>>
>>>>
>>>>
>>>>
>>>I did test some SATA drives, am getting these value for 2.6.20-rc5:-
>>>
>>>[sukhoi@Typhoon ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
>>>1024+0 records in
>>>1024+0 records out
>>>1073741824 bytes (1.1 GB) copied, 21.0962 seconds, 50.9 MB/s
>>>
>>>What can you suggest here w.r.t my RAM & disk?
>>>
>>>
>>>
>>>
>>>
>>>>Willy
>>>>
>>>>
>>>>
>>>>
>>>Thanks,
>>>
>>>~Akula2
>>>-
>>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>the body of a message to majordomo@vger.kernel.org
>>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>Please read the FAQ at http://www.tux.org/lkml/
>>>
>>>
>>>
>>>
>>>
>>Hi,
>>whitebook vbi s96f core 2 duo t5600 2gb hitachi ATA HTS721060G9AT00
>>using libata
>>time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
>>1024+0 records in
>>1024+0 records out
>>1073741824 bytes (1.1 GB) copied, 10.0092 seconds, 107 MB/s
>>
>>real 0m10.196s
>>user 0m0.004s
>>sys 0m3.440s
>>
>>
>
>You have too much RAM, it's possible that writes did not complete before
>the end of your measurement. Try this instead :
>
>$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 | sync
>
>Willy
>
>
>
>
Yeah that make a difference:
time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 | sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 8.86719 seconds, 121 MB/s
real 0m43.601s
user 0m0.004s
sys 0m3.912s
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-21 3:41 ` Stephen Clark
@ 2007-01-21 4:06 ` Gene Heskett
0 siblings, 0 replies; 27+ messages in thread
From: Gene Heskett @ 2007-01-21 4:06 UTC (permalink / raw)
To: linux-kernel, Stephen.Clark
Cc: Willy Tarreau, Sunil Naidu, Ismail Dönmez
On Saturday 20 January 2007 22:41, Stephen Clark wrote:
>Willy Tarreau wrote:
>>On Sat, Jan 20, 2007 at 02:56:20PM -0500, Stephen Clark wrote:
>>>Sunil Naidu wrote:
>>>>On 1/20/07, Willy Tarreau <w@1wt.eu> wrote:
>>>>>It is not expected to increase write performance, but it should help
>>>>>you do something else during that time, or also give more
>>>>> responsiveness to Ctrl-C. It is possible that you have fast and
>>>>> slow RAM, or that your video card uses shared memory which slows
>>>>> down some parts of memory which are not used anymore with those
>>>>> parameters.
>>>>
>>>>I did test some SATA drives, am getting these value for 2.6.20-rc5:-
>>>>
>>>>[sukhoi@Typhoon ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
>>>>1024+0 records in
>>>>1024+0 records out
>>>>1073741824 bytes (1.1 GB) copied, 21.0962 seconds, 50.9 MB/s
>>>>
>>>>What can you suggest here w.r.t my RAM & disk?
>>>>
>>>>>Willy
>>>>
>>>>Thanks,
>>>>
>>>>~Akula2
>>>>-
>>>>To unsubscribe from this list: send the line "unsubscribe
>>>> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>>>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>Please read the FAQ at http://www.tux.org/lkml/
>>>
>>>Hi,
>>>whitebook vbi s96f core 2 duo t5600 2gb hitachi ATA
>>> HTS721060G9AT00 using libata
>>>time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
>>>1024+0 records in
>>>1024+0 records out
>>>1073741824 bytes (1.1 GB) copied, 10.0092 seconds, 107 MB/s
>>>
>>>real 0m10.196s
>>>user 0m0.004s
>>>sys 0m3.440s
>>
>>You have too much RAM, it's possible that writes did not complete
>> before the end of your measurement. Try this instead :
>>
>>$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 | sync
>>
>>Willy
>
>Yeah that make a difference:
> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 | sync
>1024+0 records in
>1024+0 records out
>1073741824 bytes (1.1 GB) copied, 8.86719 seconds, 121 MB/s
>
>real 0m43.601s
>user 0m0.004s
>sys 0m3.912s
I'd reconsider my new years resolutions for figures like that:
#> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 | sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 24.1455 seconds, 44.5 MB/s
real 0m25.218s
user 0m0.009s
sys 0m5.763s
but then I also have only a gig of ram. So does this look normal?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-20 20:09 ` Willy Tarreau
2007-01-21 3:41 ` Stephen Clark
@ 2007-01-27 19:43 ` Bill Davidsen
2007-02-03 17:22 ` Elladan
1 sibling, 1 reply; 27+ messages in thread
From: Bill Davidsen @ 2007-01-27 19:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Sunil Naidu, Ismail Dönmez, linux-kernel
Willy Tarreau wrote:
> On Sat, Jan 20, 2007 at 02:56:20PM -0500, Stephen Clark wrote:
>> Sunil Naidu wrote:
>>
>>> On 1/20/07, Willy Tarreau <w@1wt.eu> wrote:
>>>
>>>
>>>> It is not expected to increase write performance, but it should help
>>>> you do something else during that time, or also give more responsiveness
>>>> to Ctrl-C. It is possible that you have fast and slow RAM, or that your
>>>> video card uses shared memory which slows down some parts of memory
>>>> which are not used anymore with those parameters.
>>>>
>>>>
>>> I did test some SATA drives, am getting these value for 2.6.20-rc5:-
>>>
>>> [sukhoi@Typhoon ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
>>> 1024+0 records in
>>> 1024+0 records out
>>> 1073741824 bytes (1.1 GB) copied, 21.0962 seconds, 50.9 MB/s
>>>
>>> What can you suggest here w.r.t my RAM & disk?
>>>
>>>
>>>
>>>> Willy
>>>>
>>>>
>>> Thanks,
>>>
>>> ~Akula2
>>> -
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>>
>>>
>> Hi,
>> whitebook vbi s96f core 2 duo t5600 2gb hitachi ATA HTS721060G9AT00
>> using libata
>> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
>> 1024+0 records in
>> 1024+0 records out
>> 1073741824 bytes (1.1 GB) copied, 10.0092 seconds, 107 MB/s
>>
>> real 0m10.196s
>> user 0m0.004s
>> sys 0m3.440s
>
> You have too much RAM, it's possible that writes did not complete before
> the end of your measurement. Try this instead :
>
> $ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 | sync
>
I'm not sure that does what you think it does, the sync runs first, and
data is still in the cache. Replace sync with "/bin/echo RAN" if you
doubt me.
What you want is this:
sync;
time bash -c "dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; sync"
which will actually time the write with the time command.
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Abysmal disk performance, how to debug?
2007-01-27 19:43 ` Bill Davidsen
@ 2007-02-03 17:22 ` Elladan
0 siblings, 0 replies; 27+ messages in thread
From: Elladan @ 2007-02-03 17:22 UTC (permalink / raw)
To: Bill Davidsen; +Cc: linux-kernel, Sunil Naidu, Ismail Dönmez
You guys are making this harder than it needs to be. Try this:
sync # To make sure nothing else is writing
dd if=/dev/zero of=file bs=1M count=1024 oflag=dsync
You'll get reasonable numbers this way out of dd.
-J
On Sat, Jan 27, 2007 at 02:43:04PM -0500, Bill Davidsen wrote:
> What you want is this:
> sync;
> time bash -c "dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; sync"
> which will actually time the write with the time command.
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2007-02-03 17:35 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-01-20 17:20 Abysmal disk performance, how to debug? Ismail Dönmez
2007-01-20 17:45 ` Willy Tarreau
2007-01-20 17:52 ` Ismail Dönmez
2007-01-20 18:03 ` Willy Tarreau
2007-01-20 18:06 ` Ismail Dönmez
2007-01-20 19:44 ` Sunil Naidu
2007-01-20 19:56 ` Stephen Clark
2007-01-20 20:09 ` Willy Tarreau
2007-01-21 3:41 ` Stephen Clark
2007-01-21 4:06 ` Gene Heskett
2007-01-27 19:43 ` Bill Davidsen
2007-02-03 17:22 ` Elladan
2007-01-20 20:05 ` Willy Tarreau
2007-01-20 20:11 ` Ismail Dönmez
2007-01-20 20:10 ` Tim Schmielau
2007-01-20 20:16 ` Ismail Dönmez
2007-01-20 20:19 ` Willy Tarreau
2007-01-20 20:28 ` Tim Schmielau
2007-01-20 20:31 ` Willy Tarreau
2007-01-20 20:21 ` Tim Schmielau
2007-01-20 20:28 ` Willy Tarreau
2007-01-20 20:39 ` Tim Schmielau
2007-01-20 21:24 ` Willy Tarreau
2007-01-20 21:41 ` Tim Schmielau
2007-01-20 21:12 ` Sunil Naidu
2007-01-20 22:00 ` Tim Schmielau
2007-01-20 23:47 ` Sunil Naidu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.