Re: slow untar during installation
On Mon, Aug 03, 2009 at 09:32:32AM +, Stuart Henderson wrote: > On 2009-08-03, Jan Stary wrote: > > On Jul 30 22:06:41, Stuart Henderson wrote: > >> On 2009-07-30, Jan Stary wrote: > >> > is 128M, that's why I use xserv45.tgz and not base45.tgz; > >> > and it should have been tar xzpf I guess - does it make > >> > a difference? And it shloud be done in single user - but > >> > the machine is almost idle, really.) > >> > >> xserv has a small number of large files, whereas base has a mixture, > >> but it has a lot of small files in it. xzpf won't matter for this test, > >> but if my theory is right, you will need to write lots of small files > >> to see a difference. > > > > I just repeated the same test ten times with xfont45.tgz (is that > > a lot of small files?) - with 'async' it consistently takes between > > 4:00 and 4:10. With 'softdep', it consistently takes between 4:40 > > and 4:50. > > interesting, I don't know why that is, then. > > > Which leaves the original question unanswered: why is the untaring > > during an install so slow when it's async, which I just found to > > perform better than softdep on a running system? > > > >> > For some reason (no reason), I have always thought that nothing can > >> > be faster than async. What is the rationale for mounting the target > >> > filesystems async mounts during an install, anyway? > >> > >> It's a lot faster than mounting them sync. (ramdisks don't have softdep, > >> and also softdep on OpenBSD doesn't free up space from pending deletes > >> quickly enough to be a good choice for untarring new OS file sets). > > > > Again I am confused: how much pending deletes are there during an install > > when untaring the OS sets? > > when you update an already-installed system, loads. > And keep in mind that the ramdisk kernels don't come with softdep. So on updates the filesystem is mounted sync whereas on installs it is async. -- :wq Claudio
Re: slow untar during installation
On 2009-08-03, Jan Stary wrote: > On Jul 30 22:06:41, Stuart Henderson wrote: >> On 2009-07-30, Jan Stary wrote: >> > is 128M, that's why I use xserv45.tgz and not base45.tgz; >> > and it should have been tar xzpf I guess - does it make >> > a difference? And it shloud be done in single user - but >> > the machine is almost idle, really.) >> >> xserv has a small number of large files, whereas base has a mixture, >> but it has a lot of small files in it. xzpf won't matter for this test, >> but if my theory is right, you will need to write lots of small files >> to see a difference. > > I just repeated the same test ten times with xfont45.tgz (is that > a lot of small files?) - with 'async' it consistently takes between > 4:00 and 4:10. With 'softdep', it consistently takes between 4:40 > and 4:50. interesting, I don't know why that is, then. > Which leaves the original question unanswered: why is the untaring > during an install so slow when it's async, which I just found to > perform better than softdep on a running system? > >> > For some reason (no reason), I have always thought that nothing can >> > be faster than async. What is the rationale for mounting the target >> > filesystems async mounts during an install, anyway? >> >> It's a lot faster than mounting them sync. (ramdisks don't have softdep, >> and also softdep on OpenBSD doesn't free up space from pending deletes >> quickly enough to be a good choice for untarring new OS file sets). > > Again I am confused: how much pending deletes are there during an install > when untaring the OS sets? when you update an already-installed system, loads.
Re: slow untar during installation
On Jul 30 22:06:41, Stuart Henderson wrote: > On 2009-07-30, Jan Stary wrote: > > is 128M, that's why I use xserv45.tgz and not base45.tgz; > > and it should have been tar xzpf I guess - does it make > > a difference? And it shloud be done in single user - but > > the machine is almost idle, really.) > > xserv has a small number of large files, whereas base has a mixture, > but it has a lot of small files in it. xzpf won't matter for this test, > but if my theory is right, you will need to write lots of small files > to see a difference. I just repeated the same test ten times with xfont45.tgz (is that a lot of small files?) - with 'async' it consistently takes between 4:00 and 4:10. With 'softdep', it consistently takes between 4:40 and 4:50. Which leaves the original question unanswered: why is the untaring during an install so slow when it's async, which I just found to perform better than softdep on a running system? > > For some reason (no reason), I have always thought that nothing can > > be faster than async. What is the rationale for mounting the target > > filesystems async mounts during an install, anyway? > > It's a lot faster than mounting them sync. (ramdisks don't have softdep, > and also softdep on OpenBSD doesn't free up space from pending deletes > quickly enough to be a good choice for untarring new OS file sets). Again I am confused: how much pending deletes are there during an install when untaring the OS sets? Jan
Re: slow untar during installation
On 2009-07-30, Jan Stary wrote: > is 128M, that's why I use xserv45.tgz and not base45.tgz; > and it should have been tar xzpf I guess - does it make > a difference? And it shloud be done in single user - but > the machine is almost idle, really.) xserv has a small number of large files, whereas base has a mixture, but it has a lot of small files in it. xzpf won't matter for this test, but if my theory is right, you will need to write lots of small files to see a difference. > For some reason (no reason), I have always thought that nothing can > be faster than async. What is the rationale for mounting the target > filesystems async mounts during an install, anyway? It's a lot faster than mounting them sync. (ramdisks don't have softdep, and also softdep on OpenBSD doesn't free up space from pending deletes quickly enough to be a good choice for untarring new OS file sets). >> I have a feeling softdep may be faster in this case, but it has > >> drawbacks too. > > Meaning, a slow IO? > What's specific about async vs. softdep in this case? Making many small updates to a single area of disk (like a directory entry) means a lot of read/write/erase cycles. You can't just update a few bytes in the middle with flash; the controller must read a whole flash block (not related to filesystem block sizes; much larger), make the change, write out the whole block to a new flash block, and erase the old one. Softdep and async do totally different things. Softdep collects metadata updates over a period of time and writes them out together. AIUI this means you skip a huge number of directory writes in this use case. >> The speed rating by itself isn't very useful. The random-access write >> speed has the biggest effect when used on a computer and since it is >> hardly relevant to use with a camera, doesn't usually get mentioned. > > This confuses me: isn't the write speed very relevant when > making shots in quick succession, for example? The key word is *random*, cameras don't do random-access writes, they buffer to RAM then write sequentially, mostly to blank areas of the card rather than making small changes to existing stored data.
Re: slow untar during installation
On Jul 30 11:25:23, Stuart Henderson wrote: > >> it was even async, which makes me curious about the install slowness. > >> Could the card or the exact mount options be the cause of that? > > Well, you already noticed the main difference; one is async, the > other uses softdep. That should suggest a simple test you can make; > untarring on a running system with async vs softdep... Here's what I just did: - downloaded xserv45.tgz onto /home - (re)mounted /tmp with 'async' or 'softdep' respectively - cd /tmp ; time tar xzf /home/hans/xserv45.tgz - rm -rf what came out of it ; umount /tmp - repeat several times, toggling the mount option (I am using /tmp because that's the only filesystem whose options I can fool around with now; and my /tmp is 128M, that's why I use xserv45.tgz and not base45.tgz; and it should have been tar xzpf I guess - does it make a difference? And it shloud be done in single user - but the machine is almost idle, really.) With async, the untar took anywhere between 1:25 and 1:40. With softdep, the untar took anywhere between 1:16 and 1:36. So they are not that much different, and neither of them shows the ultraslow behaviour I was experiencing during the install. What else could it be? For some reason (no reason), I have always thought that nothing can be faster than async. What is the rationale for mounting the target filesystems async mounts during an install, anyway? > I have a feeling softdep may be faster in this case, but it has > drawbacks too. Meaning, a slow IO? What's specific about async vs. softdep in this case? > > I suppose you use an CF-card with about x133 speed. I had the same problem. > > After using a card with at least x233 speed I didn't have that problem when > > untaring anymore. If buying a 'faster' card solves my problem, so be it. But I would like to know, anyway. > The speed rating by itself isn't very useful. The random-access write > speed has the biggest effect when used on a computer and since it is > hardly relevant to use with a camera, doesn't usually get mentioned. This confuses me: isn't the write speed very relevant when making shots in quick succession, for example? Or is it that the write speed is high enough for any camera, and therefore not relevant in a camera, as opposed to computer use, where data could be generated much more quickly? > In particular look for cards which do multisector transfers (i.e. > they /don't/ say "1-sector PIO" in the attach line in dmesg), e.g. > almost all recent sandisk, some innodisk cards, and not many others. Thanks for the tip. $ grep 'sector PIO' dmesg/* dmesg/alix1c:wd0: 1-sector PIO, LBA, 3847MB, 7880544 sectors dmesg/alix2c1:wd0: 1-sector PIO, LBA, 3871MB, 7928928 sectors dmesg/alz:wd0: 16-sector PIO, LBA, 19092MB, 39102336 sectors dmesg/armada:wd0: 16-sector PIO, LBA, 14403MB, 29498112 sectors dmesg/fjfi:wd0: 16-sector PIO, LBA48, 239371MB, 490232639 sectors dmesg/gw:wd0: 1-sector PIO, LBA, 3871MB, 7928928 sectors dmesg/vlada:wd0: 16-sector PIO, LBA, 38166MB, 78165360 sectors dmesg/vlada:wd1: 16-sector PIO, LBA, 78167MB, 160086528 sectors dmesg/wind:wd0: 1-sector PIO, LBA, 7647MB, 15662304 sectors dmesg/wind:wd1: 16-sector PIO, LBA48, 476940MB, 976773168 sectors dmesg/www:wd0: 1-sector PIO, LBA, 3847MB, 7880544 sectors Damn. Seems all of my CF cards are '1-sector PIO' (and all of my hard disks use '16-sector PIO'). > Also on the Alix systems note that there's a UDMA option you can > enable in tinyBIOS that defaults to Off. I don't remember whether I set this, but wd0 at pciide0 channel 0 drive 0: wd0: 1-sector PIO, LBA, 3847MB, 7880544 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 makes me think I have DMA enabled. Thanks for your time Jan
Re: slow untar during installation
On Jul 30 14:29:06, Tobias Walkowiak wrote: > On Thu, Jul 30, 2009 at 11:25:23AM +, Stuart Henderson wrote: > > > > > I suppose you use an CF-card with about x133 speed. I had the same > > > problem. > > > After using a card with at least x233 speed I didn't have that problem > > > when > > > untaring anymore. > > > > The speed rating by itself isn't very useful. The random-access write > > speed has the biggest effect when used on a computer and since it is > > hardly relevant to use with a camera, doesn't usually get mentioned. > > In particular look for cards which do multisector transfers (i.e. > > they /don't/ say "1-sector PIO" in the attach line in dmesg), e.g. > > almost all recent sandisk, some innodisk cards, and not many others. > > I'm using a 2 GB Transcend x300 which says > > # dmesg | grep wd0 > wd0 at pciide0 channel 0 drive 0: > wd0: 1-sector PIO, LBA, 1943MB, 3980592 sectors > wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 > > The speed is absolutely OK and sufficient -- no stalling and nothing that > slows anything down. Repeat: my system, once installed, is absolutely fast enough - it's just during_the_installation the untaring is slow.
Re: slow untar during installation
On Thu, Jul 30, 2009 at 11:25:23AM +, Stuart Henderson wrote: > > > I suppose you use an CF-card with about x133 speed. I had the same problem. > > After using a card with at least x233 speed I didn't have that problem when > > untaring anymore. > > The speed rating by itself isn't very useful. The random-access write > speed has the biggest effect when used on a computer and since it is > hardly relevant to use with a camera, doesn't usually get mentioned. > In particular look for cards which do multisector transfers (i.e. > they /don't/ say "1-sector PIO" in the attach line in dmesg), e.g. > almost all recent sandisk, some innodisk cards, and not many others. I'm using a 2 GB Transcend x300 which says # dmesg | grep wd0 wd0 at pciide0 channel 0 drive 0: wd0: 1-sector PIO, LBA, 1943MB, 3980592 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 The speed is absolutely OK and sufficient -- no stalling and nothing that slows anything down. > Also on the Alix systems note that there's a UDMA option you can > enable in tinyBIOS that defaults to Off. Didn't know that. Thanks for the hint :) -- t.walkow...@wallstreet-online.de
Re: slow untar during installation
>> it was even async, which makes me curious about the install slowness. >> Could the card or the exact mount options be the cause of that? Well, you already noticed the main difference; one is async, the other uses softdep. That should suggest a simple test you can make; untarring on a running system with async vs softdep... I have a feeling softdep may be faster in this case, but it has drawbacks too. > I suppose you use an CF-card with about x133 speed. I had the same problem. > After using a card with at least x233 speed I didn't have that problem when > untaring anymore. The speed rating by itself isn't very useful. The random-access write speed has the biggest effect when used on a computer and since it is hardly relevant to use with a camera, doesn't usually get mentioned. In particular look for cards which do multisector transfers (i.e. they /don't/ say "1-sector PIO" in the attach line in dmesg), e.g. almost all recent sandisk, some innodisk cards, and not many others. Also on the Alix systems note that there's a UDMA option you can enable in tinyBIOS that defaults to Off.
Re: slow untar during installation
On Wed, Jul 29, 2009 at 06:14:18PM +0200, Jan Stary wrote: > When installing 4.5 on an ALIX (see dmesg below) the ALIX is a good choice! > phase of actually untar'ing the tgz sets was very slow: > sets became -stalled- even if untared from local disk (pre-downloaded). I suppose you use an CF-card with about x133 speed. I had the same problem. After using a card with at least x233 speed I didn't have that problem when untaring anymore. > The installation (sans X) took about an hour because of that. And you will wait ages when untaring and compiling the kernel ... > it was even async, which makes me curious about the install slowness. > Could the card or the exact mount options be the cause of that? The card. > I am not trying to tweak the machine in any way to become 'faster'; > once installed, it runs just fine. I just don't want to spend an hour > waiting for the tgz's to untar on the next reinstall. The hardware in itself is fast enogh -- it's only the poor I/O that slows everything down. > wd0 at pciide0 channel 0 drive 0: Better spend your money for a fast 2 GB card than for a slow 4 GB. -- t.walkow...@wallstreet-online.de
slow untar during installation
When installing 4.5 on an ALIX (see dmesg below) the
phase of actually untar'ing the tgz sets was very slow:
sets became -stalled- even if untared from local disk (pre-downloaded).
The installation (sans X) took about an hour because of that.
The local disk is a (not very fast) CF card. So I tried untaring
the very same sets after the installation, on a running system,
to see if that's what's slow. Now, it was very much faster than
during the installation. (Sorry, I don't have any measurements of that.)
On the installed, running system, I use noatime and softdep.
How exactly are the 'target' filesystems mounted during installation?
Last time I looked (ctrl-z during an install, mount -v, then continuing),
it was even async, which makes me curious about the install slowness.
Could the card or the exact mount options be the cause of that?
I am not trying to tweak the machine in any way to become 'faster';
once installed, it runs just fine. I just don't want to spend an hour
waiting for the tgz's to untar on the next reinstall.
Thanks for your time
Jan
(wd0 is the CF card on which the system was installed;
sd0 and sd1 are USB disks that were added later)
OpenBSD 4.5 (GENERIC) #1749: Sat Feb 28 14:51:18 MST 2009
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 499
MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX
real mem = 259284992 (247MB)
avail mem = 242405376 (231MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 08/21/07, BIOS32 rev. 0 @ 0xfa960
apm0 at bios0: Power Management spec V1.2 (slowidle)
apm0: AC on, battery charge unknown
pcibios0 at bios0: rev 2.1 @ 0xf/0xdfb4
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf40/112 (5 entries)
pcibios0: bad IRQ table checksum
pcibios0: PCI BIOS has 5 Interrupt Routing table entries
pcibios0: PCI Exclusive IRQs: 5 10 11
pcibios0: no compatible PCI ICU found
pcibios0: Warning, unable to fix up PCI interrupt routing
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0xa800 0xef000/0x1000!
cpu0 at mainbus0: (uniprocessor)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31
vga1 at pci0 dev 1 function 1 "AMD Geode LX Video" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 13 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address
00:0d:b9:0c:e1:40
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 0, 32-bit
3579545Hz timer, watchdog, gpio
gpio0 at glxpcib0: 32 pins
pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 1-sector PIO, LBA, 3847MB, 7880544 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
auglx0 at pci0 dev 15 function 3 "AMD CS5536 Audio" rev 0x01: irq 11, CS5536
AC97
ac97: codec id 0x414c4770 (Avance Logic ALC203 rev 0)
ac97: codec features headphone, 20 bit DAC, 18 bit ADC, No 3D Stereo
audio0 at auglx0
ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 5, version 1.0,
legacy support
ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 5
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x41
lm1 at wbsio0 port 0x290/8: W83627HF
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 "AMD OHCI root hub" rev 1.00/1.00 addr 1
biomask f765 netmask ff65 ttymask
mtrr: K6-family MTRR support (2 registers)
umass0 at uhub0 port 3 configuration 1 interface 0 "JMicron USB to ATA/ATAPI
Bridge" rev 2.00/1.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0: SCSI2 0/direct fixed
sd0: 305245MB, 512 bytes/sec, 625142448 sec total
umass1 at uhub0 port 4 configuration 1 interface 0 "Prolific Technology Inc.
Mass Storage Device" rev 2.00/1.00 addr 3
umass1: using SCSI over Bulk-Only
scsibus1 at umass1: 2 targets, initiator 0
sd1 at scsibus1 targ 1 lun 0: SCSI0 0/direct fixed
sd1: 76319MB, 512 bytes/sec, 156301488 sec total
softraid0 at root
root on wd0a swap on wd0b dump on wd0b
sd1 detached
scs
