slow compiling on amd64

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

slow compiling on amd64

Stephen Schaff
this is my first post to the list - so please bear with me...

I have 2 amd64 machines that I plan on using in production, and 1  
amd64 machine at home for testing.
I tried installing the amd64 openbsd on both machines and discovered  
that doing a make on anything goes really, really slowly. I have the  
i386 openbsd installed on my test system and it does everything very  
quickly. So, I tried installing i386 on my 2 production machines.  
It's still slow on both of them!

When I say slow, here's what I mean. I'm compiling a new kernel with  
raid support. Just doing a make depend take roughly 30 seconds on my  
test machine and 30 minutes on the production machines.

# time make depend

TEST MACHINE:
0m31.36s real     0m20.64s user     0m6.32s system

PRODUCTION MACHINE:
36m8.08s real     5m32.17s user     1m37.57s system

Here's the hardware:
# sysctl hw

TEST MACHINE:
hw.machine=i386
hw.model=AMD Athlon(tm) 64 Processor 3000+ ("AuthenticAMD" 686-class,  
512KB L2 cache)
hw.ncpu=1
hw.byteorder=1234
hw.physmem=1073246208
hw.usermem=1072939008
hw.pagesize=4096
hw.disknames=wd0,cd0
hw.diskcount=2
hw.sensors.0=it0, Fan1, 5443 RPM
hw.sensors.3=it0, VCORE_A, 1.41 V DC
hw.sensors.4=it0, VCORE_B, 0.00 V DC
hw.sensors.5=it0, +3.3V, 3.28 V DC
hw.sensors.6=it0, +5V, 5.03 V DC
hw.sensors.7=it0, +12V, 11.78 V DC
hw.sensors.8=it0, Unused, 0.82 V DC
hw.sensors.9=it0, -12V, -17.00 V DC
hw.sensors.10=it0, +5VSB, 4.78 V DC
hw.sensors.11=it0, VBAT, 3.06 V DC
hw.sensors.12=it0, Temp 1, 35.00 degC
hw.sensors.13=it0, Temp 2, 37.00 degC
hw.sensors.14=it0, Temp 3, 25.00 degC
hw.cpuspeed=1810
hw.setperf=100
hw.vendor=ASUSTeK Computer INC.
hw.product=A8N-SLI DELUXE
hw.version=1.XX
hw.serialno=123456789000
hw.uuid=000fa389-5f1d-d711-9ec4-0011d84a06a8

PRODUCTION MACHINE:
hw.machine=i386
hw.model=AMD Athlon(tm) 64 Processor 3500+ ("AuthenticAMD" 686-class,  
512KB L2 cache)
hw.ncpu=1
hw.byteorder=1234
hw.physmem=1005940736
hw.usermem=1005699072
hw.pagesize=4096
hw.disknames=cd0,wd0,wd1,wd2,wd3
hw.diskcount=5
hw.sensors.0=lm0, VCore A, 2.96 V DC
hw.sensors.1=lm0, VCore B, 3.63 V DC
hw.sensors.2=lm0, +3.3V, 3.38 V DC
hw.sensors.3=lm0, +5V, 5.67 V DC
hw.sensors.4=lm0, +12V, 16.32 V DC
hw.sensors.5=lm0, -12V, -12.86 V DC
hw.sensors.6=lm0, -5V, -5.36 V DC
hw.sensors.7=lm0, Temp1, 33.00 degC
hw.sensors.10=lm0, Fan3, 4017 RPM
hw.cpuspeed=2211
hw.setperf=100
hw.vendor=ASUSTeK Computer INC.
hw.product=A8N-VM CSM
hw.uuid=c478ed80-74fe-d511-b068-749cdaa7f59a




ANY ideas? This one is stumping me completely and I've wasted a week  
trying to sort it out.
TIA!

Stephen

Reply | Threaded
Open this post in threaded view
|

Re: slow compiling on amd64

Stephen Schaff
Sorry - of course - here's my dmesg:


OpenBSD 4.0 (RAMDISK_CD) #39: Sat Sep 16 19:34:26 MDT 2006
     [hidden email]:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: AMD Athlon(tm) 64 Processor 3500+ ("AuthenticAMD" 686-class,  
512KB L2 cache) 2.22 GHz
cpu0:  
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
CFLUSH,MMX,FXSR,SSE,SSE2,SSE3
real mem  = 1005940736 (982364K)
avail mem = 910962688 (889612K)
using 4256 buffers containing 50401280 bytes (49220K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 10/05/05, BIOS32 rev. 0 @  
0xf0010, SMBIOS rev. 2.3 @ 0xf06d0 (66 entries)
bios0: ASUSTeK Computer INC. A8N-VM CSM
apm0 at bios0: Power Management spec V1.2
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 3.0 @ 0xf0000/0x10000
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf8b80/288 (16 entries)
pcibios0: no compatible PCI ICU found: ICU vendor 0x10de product 0x0260
pcibios0: Warning, unable to fix up PCI interrupt routing
pcibios0: PCI bus #4 is the last bus
bios0: ROM list: 0xc0000/0xec00 0xcf000/0x1000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
"NVIDIA C51 Host" rev 0xa2 at pci0 dev 0 function 0 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 1 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 2 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 3 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 4 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 5 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 6 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 7 not configured
ppb0 at pci0 dev 2 function 0 "NVIDIA C51 PCIE" rev 0xa1
pci1 at ppb0 bus 1
ppb1 at pci0 dev 3 function 0 "NVIDIA C51 PCIE" rev 0xa1
pci2 at ppb1 bus 2
ppb2 at pci0 dev 4 function 0 "NVIDIA C51 PCIE" rev 0xa1
pci3 at ppb2 bus 3
vga1 at pci0 dev 5 function 0 "NVIDIA GeForce 6150" rev 0xa2
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
"NVIDIA MCP51 Host" rev 0xa2 at pci0 dev 9 function 0 not configured
pcib0 at pci0 dev 10 function 0 "NVIDIA MCP51 ISA" rev 0xa2
"NVIDIA MCP51 SMBus" rev 0xa2 at pci0 dev 10 function 1 not configured
ohci0 at pci0 dev 11 function 0 "NVIDIA MCP51 USB" rev 0xa2: irq 5,  
version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: NVIDIA OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 8 ports with 8 removable, self powered
ehci0 at pci0 dev 11 function 1 "NVIDIA MCP51 USB" rev 0xa2: irq 3
usb1 at ehci0: USB revision 2.0
uhub1 at usb1
uhub1: NVIDIA EHCI root hub, rev 2.00/1.00, addr 1
uhub1: 8 ports with 8 removable, self powered
pciide0 at pci0 dev 13 function 0 "NVIDIA MCP51 IDE" rev 0xa1: DMA,  
channel 0 configured to compatibility, channel 1 configured to  
compatibility
atapiscsi0 at pciide0 channel 0 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: <HL-DT-ST, CD-ROM GCR-8525B, 1.02>  
SCSI0 5/cdrom removable
cd0(pciide0:0:0): using PIO mode 4, DMA mode 2
pciide0: channel 1 disabled (no drives)
pciide1 at pci0 dev 14 function 0 "NVIDIA MCP51 SATA" rev 0xa1: DMA
pciide1: using irq 5 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0: <ST3250823AS>
wd0: 16-sector PIO, LBA48, 238475MB, 488397168 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5
wd1 at pciide1 channel 1 drive 0: <ST3250823AS>
wd1: 16-sector PIO, LBA48, 238475MB, 488397168 sectors
wd1(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 5
pciide2 at pci0 dev 15 function 0 "NVIDIA MCP51 SATA" rev 0xa1: DMA
pciide2: using irq 5 for native-PCI interrupt
wd2 at pciide2 channel 0 drive 0: <ST3250823AS>
wd2: 16-sector PIO, LBA48, 238475MB, 488397168 sectors
wd2(pciide2:0:0): using PIO mode 4, Ultra-DMA mode 5
wd3 at pciide2 channel 1 drive 0: <ST3250824AS>
wd3: 16-sector PIO, LBA48, 238475MB, 488397168 sectors
wd3(pciide2:1:0): using PIO mode 4, Ultra-DMA mode 5
ppb3 at pci0 dev 16 function 0 "NVIDIA MCP51 PCI-PCI" rev 0xa2
pci4 at ppb3 bus 4
"VIA VT6306 FireWire" rev 0x80 at pci4 dev 5 function 0 not configured
em0 at pci4 dev 9 function 0 "Intel PRO/1000GT (82541GI)" rev 0x05:  
irq 5, address 00:0e:0c:a2:de:f6
"NVIDIA MCP51 HD Audio" rev 0xa2 at pci0 dev 16 function 1 not  
configured
nfe0 at pci0 dev 20 function 0 "NVIDIA MCP51 LAN" rev 0xa1: irq 5,  
address 00:13:d4:ff:0e:75
eephy0 at nfe0 phy 1: Marvell 88E1111 Gigabit PHY, rev. 2
pchb0 at pci0 dev 24 function 0 "AMD AMD64 HyperTransport" rev 0x00
pchb1 at pci0 dev 24 function 1 "AMD AMD64 Address Map" rev 0x00
pchb2 at pci0 dev 24 function 2 "AMD AMD64 DRAM Cfg" rev 0x00
pchb3 at pci0 dev 24 function 3 "AMD AMD64 Misc Cfg" rev 0x00
isa0 at pcib0
isadma0 at isa0
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
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
biomask ffed netmask ffed ttymask ffef
rd0: fixed, 3800 blocks
dkcsum: wd0 matches BIOS drive 0x80
dkcsum: wd1 matches BIOS drive 0x81
wd2: no disk label
dkcsum: wd2 matches BIOS drive 0x82
wd3: no disk label
dkcsum: wd3 matches BIOS drive 0x83
root on rd0a
rootdev=0x1100 rrootdev=0x2f00 rawdev=0x2f02
syncing disks...
OpenBSD 4.0 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 2006
     [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Athlon(tm) 64 Processor 3500+ ("AuthenticAMD" 686-class,  
512KB L2 cache) 2.22 GHz
cpu0:  
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
CFLUSH,MMX,FXSR,SSE,SSE2,SSE3
cpu0: Cool`n'Quiet K8 2211 Mhz: speeds: 2200 2000 1800 1000 Mhz
real mem  = 1005940736 (982364K)
avail mem = 909479936 (888164K)
using 4256 buffers containing 50401280 bytes (49220K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 10/05/05, BIOS32 rev. 0 @  
0xf0010, SMBIOS rev. 2.3 @ 0xf06d0 (66 entries)
bios0: ASUSTeK Computer INC. A8N-VM CSM
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 3.0 @ 0xf0000/0x10000
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf8b80/288 (16 entries)
pcibios0: no compatible PCI ICU found: ICU vendor 0x10de product 0x0260
pcibios0: Warning, unable to fix up PCI interrupt routing
pcibios0: PCI bus #4 is the last bus
bios0: ROM list: 0xc0000/0xec00 0xcf000/0x1000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
"NVIDIA C51 Host" rev 0xa2 at pci0 dev 0 function 0 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 1 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 2 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 3 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 4 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 5 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 6 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 7 not configured
ppb0 at pci0 dev 2 function 0 "NVIDIA C51 PCIE" rev 0xa1
pci1 at ppb0 bus 1
ppb1 at pci0 dev 3 function 0 "NVIDIA C51 PCIE" rev 0xa1
pci2 at ppb1 bus 2
ppb2 at pci0 dev 4 function 0 "NVIDIA C51 PCIE" rev 0xa1
pci3 at ppb2 bus 3
vga1 at pci0 dev 5 function 0 "NVIDIA GeForce 6150" rev 0xa2
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
"NVIDIA MCP51 Host" rev 0xa2 at pci0 dev 9 function 0 not configured
pcib0 at pci0 dev 10 function 0 "NVIDIA MCP51 ISA" rev 0xa2
nviic0 at pci0 dev 10 function 1 "NVIDIA MCP51 SMBus" rev 0xa2
iic0 at nviic0
iic1 at nviic0
ohci0 at pci0 dev 11 function 0 "NVIDIA MCP51 USB" rev 0xa2: irq 5,  
version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: NVIDIA OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 8 ports with 8 removable, self powered
ehci0 at pci0 dev 11 function 1 "NVIDIA MCP51 USB" rev 0xa2: irq 3
usb1 at ehci0: USB revision 2.0
uhub1 at usb1
uhub1: NVIDIA EHCI root hub, rev 2.00/1.00, addr 1
uhub1: 8 ports with 8 removable, self powered
pciide0 at pci0 dev 13 function 0 "NVIDIA MCP51 IDE" rev 0xa1: DMA,  
channel 0 configured to compatibility, channel 1 configured to  
compatibility
atapiscsi0 at pciide0 channel 0 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: <HL-DT-ST, CD-ROM GCR-8525B, 1.02>  
SCSI0 5/cdrom removable
cd0(pciide0:0:0): using PIO mode 4, DMA mode 2
pciide0: channel 1 disabled (no drives)
pciide1 at pci0 dev 14 function 0 "NVIDIA MCP51 SATA" rev 0xa1: DMA
pciide1: using irq 5 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0: <ST3250823AS>
wd0: 16-sector PIO, LBA48, 238475MB, 488397168 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5
wd1 at pciide1 channel 1 drive 0: <ST3250823AS>
wd1: 16-sector PIO, LBA48, 238475MB, 488397168 sectors
wd1(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 5
pciide2 at pci0 dev 15 function 0 "NVIDIA MCP51 SATA" rev 0xa1: DMA
pciide2: using irq 5 for native-PCI interrupt
wd2 at pciide2 channel 0 drive 0: <ST3250823AS>
wd2: 16-sector PIO, LBA48, 238475MB, 488397168 sectors
wd2(pciide2:0:0): using PIO mode 4, Ultra-DMA mode 5
wd3 at pciide2 channel 1 drive 0: <ST3250824AS>
wd3: 16-sector PIO, LBA48, 238475MB, 488397168 sectors
wd3(pciide2:1:0): using PIO mode 4, Ultra-DMA mode 5
ppb3 at pci0 dev 16 function 0 "NVIDIA MCP51 PCI-PCI" rev 0xa2
pci4 at ppb3 bus 4
"VIA VT6306 FireWire" rev 0x80 at pci4 dev 5 function 0 not configured
em0 at pci4 dev 9 function 0 "Intel PRO/1000GT (82541GI)" rev 0x05:  
irq 5, address 00:0e:0c:a2:de:f6
azalia0 at pci0 dev 16 function 1 "NVIDIA MCP51 HD Audio" rev 0xa2:  
irq 5
azalia0: host: High Definition Audio rev. 1.0
azalia0: codec: 0x04x/0x11d4 (rev. 5.0), HDA version 1.0
audio0 at azalia0
nfe0 at pci0 dev 20 function 0 "NVIDIA MCP51 LAN" rev 0xa1: irq 5,  
address 00:13:d4:ff:0e:75
eephy0 at nfe0 phy 1: Marvell 88E1111 Gigabit PHY, rev. 2
pchb0 at pci0 dev 24 function 0 "AMD AMD64 HyperTransport" rev 0x00
pchb1 at pci0 dev 24 function 1 "AMD AMD64 Address Map" rev 0x00
pchb2 at pci0 dev 24 function 2 "AMD AMD64 DRAM Cfg" rev 0x00
pchb3 at pci0 dev 24 function 3 "AMD AMD64 Misc Cfg" rev 0x00
isa0 at pcib0
isadma0 at isa0
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: <PC speaker>
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
lm0 at isa0 port 0x290/8: unknown Winbond chip (ID 0xa1)
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
biomask ff6d netmask ff6d ttymask ffef
pctr: user-level cycle counter enabled
dkcsum: wd0 matches BIOS drive 0x80
dkcsum: wd1 matches BIOS drive 0x81
wd2: no disk label
dkcsum: wd2 matches BIOS drive 0x82
wd3: no disk label
dkcsum: wd3 matches BIOS drive 0x83
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302





On 15-Nov-06, at 9:36 PM, Chris Kuethe wrote:

> Dmesg?
>
> Nvidia chipsets are dog-slow.
>
> On 11/15/06, Stephen Schaff <[hidden email]> wrote:
>> this is my first post to the list - so please bear with me...
>>
>> I have 2 amd64 machines that I plan on using in production, and 1
>> amd64 machine at home for testing.
>> I tried installing the amd64 openbsd on both machines and discovered
>> that doing a make on anything goes really, really slowly. I have the
>> i386 openbsd installed on my test system and it does everything very
>> quickly. So, I tried installing i386 on my 2 production machines.
>> It's still slow on both of them!
>>
>> When I say slow, here's what I mean. I'm compiling a new kernel with
>> raid support. Just doing a make depend take roughly 30 seconds on my
>> test machine and 30 minutes on the production machines.
>>
>> # time make depend
>>
>> TEST MACHINE:
>> 0m31.36s real     0m20.64s user     0m6.32s system
>>
>> PRODUCTION MACHINE:
>> 36m8.08s real     5m32.17s user     1m37.57s system
>>
>> Here's the hardware:
>> # sysctl hw
>>
>> TEST MACHINE:
>> hw.machine=i386
>> hw.model=AMD Athlon(tm) 64 Processor 3000+ ("AuthenticAMD" 686-class,
>> 512KB L2 cache)
>> hw.ncpu=1
>> hw.byteorder=1234
>> hw.physmem=1073246208
>> hw.usermem=1072939008
>> hw.pagesize=4096
>> hw.disknames=wd0,cd0
>> hw.diskcount=2
>> hw.sensors.0=it0, Fan1, 5443 RPM
>> hw.sensors.3=it0, VCORE_A, 1.41 V DC
>> hw.sensors.4=it0, VCORE_B, 0.00 V DC
>> hw.sensors.5=it0, +3.3V, 3.28 V DC
>> hw.sensors.6=it0, +5V, 5.03 V DC
>> hw.sensors.7=it0, +12V, 11.78 V DC
>> hw.sensors.8=it0, Unused, 0.82 V DC
>> hw.sensors.9=it0, -12V, -17.00 V DC
>> hw.sensors.10=it0, +5VSB, 4.78 V DC
>> hw.sensors.11=it0, VBAT, 3.06 V DC
>> hw.sensors.12=it0, Temp 1, 35.00 degC
>> hw.sensors.13=it0, Temp 2, 37.00 degC
>> hw.sensors.14=it0, Temp 3, 25.00 degC
>> hw.cpuspeed=1810
>> hw.setperf=100
>> hw.vendor=ASUSTeK Computer INC.
>> hw.product=A8N-SLI DELUXE
>> hw.version=1.XX
>> hw.serialno=123456789000
>> hw.uuid=000fa389-5f1d-d711-9ec4-0011d84a06a8
>>
>> PRODUCTION MACHINE:
>> hw.machine=i386
>> hw.model=AMD Athlon(tm) 64 Processor 3500+ ("AuthenticAMD" 686-class,
>> 512KB L2 cache)
>> hw.ncpu=1
>> hw.byteorder=1234
>> hw.physmem=1005940736
>> hw.usermem=1005699072
>> hw.pagesize=4096
>> hw.disknames=cd0,wd0,wd1,wd2,wd3
>> hw.diskcount=5
>> hw.sensors.0=lm0, VCore A, 2.96 V DC
>> hw.sensors.1=lm0, VCore B, 3.63 V DC
>> hw.sensors.2=lm0, +3.3V, 3.38 V DC
>> hw.sensors.3=lm0, +5V, 5.67 V DC
>> hw.sensors.4=lm0, +12V, 16.32 V DC
>> hw.sensors.5=lm0, -12V, -12.86 V DC
>> hw.sensors.6=lm0, -5V, -5.36 V DC
>> hw.sensors.7=lm0, Temp1, 33.00 degC
>> hw.sensors.10=lm0, Fan3, 4017 RPM
>> hw.cpuspeed=2211
>> hw.setperf=100
>> hw.vendor=ASUSTeK Computer INC.
>> hw.product=A8N-VM CSM
>> hw.uuid=c478ed80-74fe-d511-b068-749cdaa7f59a
>>
>>
>>
>>
>> ANY ideas? This one is stumping me completely and I've wasted a week
>> trying to sort it out.
>> TIA!
>>
>> Stephen
>>
>>
>
>
> --
> GDB has a 'break' feature; why doesn't it have 'fix' too?

Reply | Threaded
Open this post in threaded view
|

Re: slow compiling on amd64

Stephen Schaff
In reply to this post by Stephen Schaff
No - I haven't tried an older version. The oldest I would go on a  
production machine would be 3.9.

I could try 3.9, but to be honest I don't have time to test things  
out. I need these servers up, yesterday. I really don't want to use  
another OS, but might have to if I don't solve this problem quickly.

Regards,
Stephen


On 15-Nov-06, at 10:19 PM, Brian Keefer wrote:

>
> On Nov 15, 2006, at 8:17 PM, Stephen Schaff wrote:
>
>> this is my first post to the list - so please bear with me...
>>
>> I have 2 amd64 machines that I plan on using in production, and 1  
>> amd64 machine at home for testing.
>> I tried installing the amd64 openbsd on both machines and  
>> discovered that doing a make on anything goes really, really  
>> slowly. I have the i386 openbsd installed on my test system and it  
>> does everything very quickly. So, I tried installing i386 on my 2  
>> production machines. It's still slow on both of them!
>>
>> When I say slow, here's what I mean. I'm compiling a new kernel  
>> with raid support. Just doing a make depend take roughly 30  
>> seconds on my test machine and 30 minutes on the production machines.
>>
>> # time make depend
>>
>> TEST MACHINE:
>> 0m31.36s real     0m20.64s user     0m6.32s system
>>
>> PRODUCTION MACHINE:
>> 36m8.08s real     5m32.17s user     1m37.57s system
>
>
> Another poster and myself have been puzzling over amd64 performance  
> problems as well.  It seems that the OpenBSD/amd64 OS was fast back  
> in 3.5, but somewhere between then and now it has slowed down  
> dramatically.  Have you tried installing older versions of OpenBSD  
> to see if the performance is better?
>
> Brian Keefer
> www.Tumbleweed.com
> "The Experts in Secure Internet Communication"

Reply | Threaded
Open this post in threaded view
|

Re: slow compiling on amd64

Stephen Schaff
In reply to this post by Stephen Schaff
What strikes me as very bizarre is that my slower amd64 machine at  
home is just fine and runs really well. That one has an nvidia  
chipset on the A8N-SLI motherboard. The machines that aren't working  
properly have the A8N-VM CMS board which also uses the nvidia chipset.

I just don't understand how there can be a difference factor of 10.  
30 seconds for make depend on the A8N-SLI and 30 mins on the A8N-VM  
CMS (???)

I MUST be missing something simple - has nobody else seen this?


Regards,
Stephen


On 15-Nov-06, at 9:36 PM, Chris Kuethe wrote:

> Dmesg?
>
> Nvidia chipsets are dog-slow.
>
> On 11/15/06, Stephen Schaff <[hidden email]> wrote:
>> this is my first post to the list - so please bear with me...
>>
>> I have 2 amd64 machines that I plan on using in production, and 1
>> amd64 machine at home for testing.
>> I tried installing the amd64 openbsd on both machines and discovered
>> that doing a make on anything goes really, really slowly. I have the
>> i386 openbsd installed on my test system and it does everything very
>> quickly. So, I tried installing i386 on my 2 production machines.
>> It's still slow on both of them!
>>
>> When I say slow, here's what I mean. I'm compiling a new kernel with
>> raid support. Just doing a make depend take roughly 30 seconds on my
>> test machine and 30 minutes on the production machines.
>>
>> # time make depend
>>
>> TEST MACHINE:
>> 0m31.36s real     0m20.64s user     0m6.32s system
>>
>> PRODUCTION MACHINE:
>> 36m8.08s real     5m32.17s user     1m37.57s system
>>
>> Here's the hardware:
>> # sysctl hw
>>
>> TEST MACHINE:
>> hw.machine=i386
>> hw.model=AMD Athlon(tm) 64 Processor 3000+ ("AuthenticAMD" 686-class,
>> 512KB L2 cache)
>> hw.ncpu=1
>> hw.byteorder=1234
>> hw.physmem=1073246208
>> hw.usermem=1072939008
>> hw.pagesize=4096
>> hw.disknames=wd0,cd0
>> hw.diskcount=2
>> hw.sensors.0=it0, Fan1, 5443 RPM
>> hw.sensors.3=it0, VCORE_A, 1.41 V DC
>> hw.sensors.4=it0, VCORE_B, 0.00 V DC
>> hw.sensors.5=it0, +3.3V, 3.28 V DC
>> hw.sensors.6=it0, +5V, 5.03 V DC
>> hw.sensors.7=it0, +12V, 11.78 V DC
>> hw.sensors.8=it0, Unused, 0.82 V DC
>> hw.sensors.9=it0, -12V, -17.00 V DC
>> hw.sensors.10=it0, +5VSB, 4.78 V DC
>> hw.sensors.11=it0, VBAT, 3.06 V DC
>> hw.sensors.12=it0, Temp 1, 35.00 degC
>> hw.sensors.13=it0, Temp 2, 37.00 degC
>> hw.sensors.14=it0, Temp 3, 25.00 degC
>> hw.cpuspeed=1810
>> hw.setperf=100
>> hw.vendor=ASUSTeK Computer INC.
>> hw.product=A8N-SLI DELUXE
>> hw.version=1.XX
>> hw.serialno=123456789000
>> hw.uuid=000fa389-5f1d-d711-9ec4-0011d84a06a8
>>
>> PRODUCTION MACHINE:
>> hw.machine=i386
>> hw.model=AMD Athlon(tm) 64 Processor 3500+ ("AuthenticAMD" 686-class,
>> 512KB L2 cache)
>> hw.ncpu=1
>> hw.byteorder=1234
>> hw.physmem=1005940736
>> hw.usermem=1005699072
>> hw.pagesize=4096
>> hw.disknames=cd0,wd0,wd1,wd2,wd3
>> hw.diskcount=5
>> hw.sensors.0=lm0, VCore A, 2.96 V DC
>> hw.sensors.1=lm0, VCore B, 3.63 V DC
>> hw.sensors.2=lm0, +3.3V, 3.38 V DC
>> hw.sensors.3=lm0, +5V, 5.67 V DC
>> hw.sensors.4=lm0, +12V, 16.32 V DC
>> hw.sensors.5=lm0, -12V, -12.86 V DC
>> hw.sensors.6=lm0, -5V, -5.36 V DC
>> hw.sensors.7=lm0, Temp1, 33.00 degC
>> hw.sensors.10=lm0, Fan3, 4017 RPM
>> hw.cpuspeed=2211
>> hw.setperf=100
>> hw.vendor=ASUSTeK Computer INC.
>> hw.product=A8N-VM CSM
>> hw.uuid=c478ed80-74fe-d511-b068-749cdaa7f59a
>>
>>
>>
>>
>> ANY ideas? This one is stumping me completely and I've wasted a week
>> trying to sort it out.
>> TIA!
>>
>> Stephen
>>
>>
>
>
> --
> GDB has a 'break' feature; why doesn't it have 'fix' too?

Reply | Threaded
Open this post in threaded view
|

Re: slow compiling on amd64

Stuart Henderson
On 2006/11/16 01:02, Stephen Schaff wrote:
> I just don't understand how there can be a difference factor of 10.

factor of 100.

> 30 seconds for make depend on the A8N-SLI and 30 mins on the A8N-VM
> CMS (???)
>
> I MUST be missing something simple - has nobody else seen this?

softdep mount option? this will slow down creation/removal of
large numbers of files.

hard-drive write caching? (check under the 'Device has enabled...'
section of 'sudo atactl wd0') drive write speeds will be low if it's
not enabled (some drives normally enable it, some don't and you can
do so in rc.local).

Reply | Threaded
Open this post in threaded view
|

Re: slow compiling on amd64

Joachim Schipper
On Thu, Nov 16, 2006 at 10:53:10AM +0000, Stuart Henderson wrote:

> On 2006/11/16 01:02, Stephen Schaff wrote:
> > I just don't understand how there can be a difference factor of 10.
>
> factor of 100.
>
> > 30 seconds for make depend on the A8N-SLI and 30 mins on the A8N-VM
> > CMS (???)
> >
> > I MUST be missing something simple - has nobody else seen this?
>
> softdep mount option? this will slow down creation/removal of
> large numbers of files.
>
> hard-drive write caching? (check under the 'Device has enabled...'
> section of 'sudo atactl wd0') drive write speeds will be low if it's
> not enabled (some drives normally enable it, some don't and you can
> do so in rc.local).

To test this, how about finding a somewhat smaller program - like, some
port - and compiling it on a mfs? Provided you have enough memory to not
need swap, this should mean that the hard disk will not affect the
results. If the results are comparable on an mfs, tune the hard disk. If
not, I have no idea...

                Joachim

Reply | Threaded
Open this post in threaded view
|

Re: slow compiling on amd64

Stephen Schaff
In reply to this post by Stuart Henderson
Thank you for your suggestions. It looks like write caching is  
enabled. I've pasted the results below.

Stephen

On 16-Nov-06, at 3:53 AM, Stuart Henderson wrote:

> On 2006/11/16 01:02, Stephen Schaff wrote:
>> I just don't understand how there can be a difference factor of 10.
>
> factor of 100.
>

yes - guess I was tired when calculating that!

>> 30 seconds for make depend on the A8N-SLI and 30 mins on the A8N-VM
>> CMS (???)
>>
>> I MUST be missing something simple - has nobody else seen this?
>
> softdep mount option? this will slow down creation/removal of
> large numbers of files.
>
> hard-drive write caching? (check under the 'Device has enabled...'
> section of 'sudo atactl wd0') drive write speeds will be low if it's
> not enabled (some drives normally enable it, some don't and you can
> do so in rc.local).
>


sudo atactl wd0:
Model: ST3250823AS, Rev: 3.03, Serial #:             5ND2CD2Q
Device type: ATA, fixed
Cylinders: 16383, heads: 16, sec/track: 63, total sectors: 488397168
Device capabilities:
         ATA standby timer values
         IORDY operation
         IORDY disabling
Device supports the following standards:
ATA-1 ATA-2 ATA-3 ATA-4 ATA-5 ATA-6 ATA-7
Master password revision code 0xfffe
Device supports the following command sets:
         READ BUFFER command
         WRITE BUFFER command
         Host Protected Area feature set
         Read look-ahead
         Write cache
         Power Management feature set
         Security Mode feature set
         SMART feature set
         Flush Cache Ext command
         Flush Cache command
         Device Configuration Overlay feature set
         48bit address feature set
         Set Max security extension commands
         DOWNLOAD MICROCODE command
         SMART self-test
         SMART error logging
Device has enabled the following command sets/features:
         READ BUFFER command
         WRITE BUFFER command
         Host Protected Area feature set
         Read look-ahead
         Write cache
         Power Management feature set
         SMART feature set
         Flush Cache Ext command
         Flush Cache command
         Device Configuration Overlay feature set
         48bit address feature set
         DOWNLOAD MICROCODE command

Reply | Threaded
Open this post in threaded view
|

Re: slow compiling on amd64

Christian Weisgerber
In reply to this post by Stephen Schaff
Stephen Schaff <[hidden email]> wrote:

> I just don't understand how there can be a difference factor of 10.  
> 30 seconds for make depend on the A8N-SLI and 30 mins on the A8N-VM  
> CMS (???)

What do top and systat vmstat report where the CPU is going?

> I MUST be missing something simple - has nobody else seen this?

Ian Darwin has a laptop that is mostly busy handling an interrupt
storm.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slow compiling on amd64

Christian Weisgerber
In reply to this post by Stuart Henderson
Stuart Henderson <[hidden email]> wrote:

> > I just don't understand how there can be a difference factor of 10.
>
> factor of 100.

(Are you really sure a minute has 100 seconds?)

> softdep mount option? this will slow down creation/removal of
> large numbers of files.

Please, you are not a dog, that Pavlovian response is nonsense.

> hard-drive write caching? (check under the 'Device has enabled...'
> section of 'sudo atactl wd0') drive write speeds will be low if it's
> not enabled (some drives normally enable it, some don't and you can
> do so in rc.local).

Strictly speaking, you should DISABLE write caching when using
softupdates.

Anyway, none of this comes remotely close to explaining the problem.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slow compiling on amd64

Marcus Watts
In reply to this post by Christian Weisgerber
Various wrote:
> > I MUST be missing something simple - has nobody else seen this?
>
> Ian Darwin has a laptop that is mostly busy handling an interrupt
> storm.

Yup.  Lots of possibilities.  Before spending too much time diagnosing
any one theory, you need to come up with a way to triage theories.

Some possible causes:
        slow cpu -- wrong clock speed?
                broken cache?  bizarre bus problem?
        interrupt load
                serial?  network?  something else?
        disk subsystem
                many.  ata dma is a common culprit.
                but a ufs filesystem nearly out of space
                will perform pretty badly even on good hw.

So some early experiments you should try:

        vmstat 10
                On an idle system: should report 99-100% idle,
                low counts on interrupts, no paging, etc.  Run on
                both bad & good system, compare results.

        time openssl speed rc4
                this is a 100% cpu-bound case.  
                If it doesn't come up with similar numbers,
                you know it's not a disk problem.  If the user
                time isn't nearly equal to elapsed time,
                you know something is stealing cpu, otherwise,
                you know the cpu is doing something bizarre.

        time dd </dev/rwd0c >/dev/null bs=100k count=1000
                this should be fast, user & system time should
                be low, etc.  Significant system time means
                you should investigate dma options on your
                local disk.

        time tar xf ...
                (unpack something new; don't unpack over something
                that exists; you want to allocate directory entries, inodes,
                and filespace.)
                this will catch ufs weirdness.

Once you know which of these has problems, then you can start
chasing down that branch.

                                        -Marcus Watts

Reply | Threaded
Open this post in threaded view
|

Re: slow compiling on amd64

Stuart Henderson
In reply to this post by Christian Weisgerber
On 2006/11/16 16:25, Christian Weisgerber wrote:
> > > I just don't understand how there can be a difference factor of 10.
> > factor of 100.
> (Are you really sure a minute has 100 seconds?)

No I'm not, come to think of it...

> > softdep mount option? this will slow down creation/removal of
> > large numbers of files.
>
> Please, you are not a dog, that Pavlovian response is nonsense.

Ah, I didn't realise how little was written by 'make depend'.

For some operations, having WCE and softdep off does make a difference
approaching this of order of magnitude.

Knowing that some drives ship with WCE turned off (e.g. at least those
supplied with some HP DL385 and Fujitsu-Siemens servers), it's a quick
and simple thing to check which accounts for performance differences
on some operations of this sort of order of magnitude. I just tried
untarring ports.tar.gz on some F-S box:

WCE, softdep   no WCE, softdep   WCE, no softdep   no WCE, no softdep
0m49.29s       13m8.72s          1m51.58s          30m9.95s

> Strictly speaking, you should DISABLE write caching when using
> softupdates.

Surely this applies without softupdates too, though? It also relies
on the drive doing what you tell it, which isn't guaranteed, especially
with consumer drives optimised for performance in benchmarks (aiui
some drives always enable write-cache no matter what you tell them;
with these, providing they're ATA-6 compliant, you may force it with
READ VERIFY SECTOR/S).

Reply | Threaded
Open this post in threaded view
|

Re: slow compiling on amd64

Stephen Schaff
In reply to this post by Stephen Schaff
Okay, I sorted this one out.

The problem was with the motherboard - A8N-VM CMS. I had to update  
the BIOS to the latest version.
Now, OpenBSD runs as expected, fast, and spectacular. It now takes 4  
mins to compile the GENERIC kernel and not 400 mins like I was seeing.

But, your comments about nvidia chipsets, and IDE channels led me  
down all the right paths to rule out the obvious, and try everything  
under the sun. So, thanks for your suggestions. Valued, as always.

Best Regards,
Stephen


On 16-Nov-06, at 8:24 AM, Soner Tari wrote:

> I recall that once I installed OpenBSD on a HD on one system. Then I
> decided to remove that HD and insert it into another similar system.
> Having done that several times in the past, I was not worried. BUT the
> system became unbelievably slow.
>
> After a few hours of head scratching, I realized that I actually
> connected it to secondary IDE on the second system (OpenBSD did not
> complain, neither gave any clue in my case, it was just very slow).
> Switching to primary IDE solved my problems.
>
> I don't know how you installed OpenBSD, probably completely irrelevant
> but did you try to simply switch the connectors? Just a thought.
>
> On Wed, 2006-11-15 at 21:43 -0700, Stephen Schaff wrote:
>> Sorry - of course - here's my dmesg:
>>>>
>>>> ANY ideas? This one is stumping me completely and I've wasted a  
>>>> week
>>>> trying to sort it out.