Re: Performance issues as KVM guest?

[Tom Smyth]

Hello,

Just to clarify  Todds / Stefans Email earlier in the chain, (Thanks
Stefan and Todd,)


disable kvm_intel.preemption_timer on the host (see \
> /sys/module/kvm_intel/parameters/preemption_timer ) This seems to be buggy in 
> linux \
> 4.10 and newer

disabling intel-kvm preemption_timer worked for me and it resolved the
timer drift issue
in openbsd on Proxmox 5.1

so in debian / proxmox  I ran the following command

echo options kvm-intel preemption_timer=N >>/etc/modprobe.d/kvm-intel.conf

then reboot the host,  (the open BSD guest vm default settings seemed
to work fine )


disable kvm_intel.preemption_timer on the host (see \
> /sys/module/kvm_intel/parameters/preemption_timer ) This seems to be buggy in 
> linux \
> 4.10 and newer






On 12 January 2018 at 13:11, Tom Smyth  wrote:
> Hello Todd,
>
> This issue (Virtual hardware issue happens on latest proxmox5.x  but
> not on Proxmox 4.4 ) with 6.2 (and 6.1 for that matter)
> It is discussed here
> https://marc.info/?l=openbsd-misc=151472854021947=2
>
> but in recent versions of Proxmox 5.1 (QEMU/KVM)   there were no console 
> freezes
> (Proxmox updates fixed this issue (ie virtual  Hardware Fix not an
> OpenBSD Software Fix)
> https://marc.info/?l=openbsd-misc=151467636114177=2
>
>
> So OpenBSD 6.2 Runs Fine on older QEMU and KVM but not on latest  KVM QEMU
>
> My 2 cents is that the issue is a change in Virtual Hardware that is
> incompatible with
> OpenBSD  as opposed to change in OpenBSD that has caused the issue,
>
>
> in my humble opinion it is more likely a old driver incompatibility
> with newer (Virtual) hardware.
>
>
>
> I hope this helps
> Tom Smyth



-- 
Kindest regards,
Tom Smyth

Mobile: +353 87 6193172
The information contained in this E-mail is intended only for the
confidential use of the named recipient. If the reader of this message
is not the intended recipient or the person responsible for
delivering it to the recipient, you are hereby notified that you have
received this communication in error and that any review,
dissemination or copying of this communication is strictly prohibited.
If you have received this in error, please notify the sender
immediately by telephone at the number above and erase the message
You are requested to carry out your own virus check before
opening any attachment.

Re: Performance issues as KVM guest?

[Infoomatic]

Hi Stefan,

Thanks a lot, that solved the problem! 
However, I still wonder why the difference in cputime consumption between a 
FreeBSD KVM and a OpenBSD KVM (both just a basic install) is so huge ... now I 
see 643min on OpenBSD vs 46min on FreeBSD.

Regards,
Robert

> Gesendet: Freitag, 12. Januar 2018 um 12:48 Uhr
> Von: "Stefan Fritsch" <s...@sfritsch.de>
> An: Infoomatic <infooma...@gmx.at>
> Cc: misc@openbsd.org
> Betreff: Re: Performance issues as KVM guest?
>
> Hi, I don't see this issue on my Debian system, but please try two things: * 
> disable kvm_intel.preemption_timer on the host (see 
> /sys/module/kvm_intel/parameters/preemption_timer ) This seems to be buggy in 
> linux 4.10 and newer * enable hpet in the vm config: Make sure there is no in 
> your libvirt xml (or don't pass -ho-hpet to qemu). Unfortunately, newer 
> libvirt versions seem to disable hpet by default. Different issue: If you 
> remove the USB controllers, the CPU load on the host will reduce by a few 
> percent (~ 3%). Add and remove all other usb controller sections. Just 
> removing the usb controller sections without adding the 'none' makes libvirt 
> add them back (this is stupid). Cheers, Stefan On Fri, 12 Jan 2018, 
> Infoomatic wrote: > Same problem here. While we did have significant 
> differences in cpu > usage between FreeBSD and OpenBSD (basic OS without 
> configuration: > FreeBSD ~ 33min CPU time, OpenBSD ~ 474min CPU time - both 
> started at > the same time), with the latest kernel patches for Ubuntu 17.04 
> (our > test environments all run Ubuntu 17.04 for KVM VMs), OpenBSD now 
> becomes > practically unusable: as soon as I su or login on the console with 
> su, > cpu usage is at 100% - the system freezes. :-/ guess we need some > 
> dedicated BSD machines to host some test-VMs ;-) > > Regards, > Robert > > > 
> > Gesendet: Donnerstag, 11. Januar 2018 um 20:32 Uhr > > Von: "Kirill 
> Miazine" > > An: misc@openbsd.org > > Betreff: Re: Performance issues as KVM 
> guest? > > > > * Kent Watsen [2018-01-11 17:38]: > > [...] > > > > > Since my 
> hosting provider https://www.bytemark.co.uk/cloud-hosting/ > > > > > patched 
> for Meltdown last weekend I'm seeing significant performance > > > > > issues 
> with an OpenBSD virtual instance there. It seems okay after a > > > > > fresh 
> reboot but then progressively returns to being very slow: for > > > > > 
> example "sleep 1" may take four seconds, then five, six, seven, then > > > > 
> > rather more. Curiously it does tend to be an integral multiplier. > > > > > 
> > > > > > I wondered, is anybody else seeing significant performance problems 
> with > > > > > OpenBSD (or other BSDs) virtual instances since Meltdown 
> patching? Is > > > > > there anything to tweak at my end or am I reliant on 
> the provider? > > > > > > > > > > -- Mark > > > > > > > > > There are a ton 
> of threads talking about this issue, and it's not meltdown > > > > specific. 
> Please search the archives. > > > > > > > > -ml > > > > > > [...] > > > Also, 
> Mark, could you say some more about the issue.  For instance, how long > > > 
> after a reboot does it take until you start to notice the issue, and how > > 
> > quickly does it get worse? > > > > I'm another customer of Bytemark 
> experiencing the same issue. I'm taking > > care of one VM there and I'm 
> primarly noticing it in two situations: > > sleep() takes a long time (e.g. 
> sleep(1) might take up to 40 seconds) > > and the clock slows down. > > > > 
> Right now, 9 hours after reboot, the clock on VM is 3 hours behind real > > 
> clock. And sleep(1) takes 13 secs: > > > > km@buildfarm ~ $ time sleep 1 > > 
> 0m13.85s real 0m00.00s user 0m00.01s system > > > > This all started after 
> the host was patched and VM rebooted. > > > > Bytemark guys are looking at 
> the issue and doing their own debugging. > > Here're findings so far: > > > > 
> I spun a few OpenBSD VMs up and left them overnight - looks like the > > 
> clock isn't drifting but there's still the 'time sleep 1' issue. > > My 
> testing results seemed to concur with User_4574's, virtio was slowing > > 
> down only a few minutes after a fresh install whereas compatibility > > would 
> stick at 1s, jump to 2s, etc. > > > > > > Thanks, > > > Kent > > > > > > > -- 
> > > -- Kirill Miazine > > > > > >

Re: Performance issues as KVM guest?

[Tom Smyth]

Hello Todd,

This issue (Virtual hardware issue happens on latest proxmox5.x  but
not on Proxmox 4.4 ) with 6.2 (and 6.1 for that matter)
It is discussed here
https://marc.info/?l=openbsd-misc=151472854021947=2

but in recent versions of Proxmox 5.1 (QEMU/KVM)   there were no console freezes
(Proxmox updates fixed this issue (ie virtual  Hardware Fix not an
OpenBSD Software Fix)
https://marc.info/?l=openbsd-misc=151467636114177=2


So OpenBSD 6.2 Runs Fine on older QEMU and KVM but not on latest  KVM QEMU

My 2 cents is that the issue is a change in Virtual Hardware that is
incompatible with
OpenBSD  as opposed to change in OpenBSD that has caused the issue,


in my humble opinion it is more likely a old driver incompatibility
with newer (Virtual) hardware.



I hope this helps
Tom Smyth

Re: Performance issues as KVM guest?

[Stefan Fritsch]

Hi,

I don't see this issue on my Debian system, but please try two things:

* disable kvm_intel.preemption_timer on the host 
(see /sys/module/kvm_intel/parameters/preemption_timer )
This seems to be buggy in linux 4.10 and newer

* enable hpet in the vm config:
Make sure there is no   in your libvirt 
xml (or don't pass -ho-hpet to qemu). Unfortunately, newer libvirt 
versions seem to disable hpet by default.


Different issue: If you remove the USB controllers, the CPU load on 
the host will reduce by a few percent (~ 3%). Add



and remove all other usb controller sections. Just removing the usb 
controller sections without adding the 'none' makes libvirt add them back 
(this is stupid).

Cheers,
Stefan

On Fri, 12 Jan 2018, Infoomatic wrote:

> Same problem here. While we did have significant differences in cpu 
> usage between FreeBSD and OpenBSD (basic OS without configuration: 
> FreeBSD ~ 33min CPU time, OpenBSD ~ 474min CPU time - both started at 
> the same time), with the latest kernel patches for Ubuntu 17.04 (our 
> test environments all run Ubuntu 17.04 for KVM VMs), OpenBSD now becomes 
> practically unusable: as soon as I su or login on the console with su, 
> cpu usage is at 100% - the system freezes. :-/ guess we need some 
> dedicated BSD machines to host some test-VMs ;-)
> 
> Regards,
> Robert
> 
> 
> > Gesendet: Donnerstag, 11. Januar 2018 um 20:32 Uhr
> > Von: "Kirill Miazine" <k...@krot.org>
> > An: misc@openbsd.org
> > Betreff: Re: Performance issues as KVM guest?
> >
> > * Kent Watsen [2018-01-11 17:38]:
> > [...]
> > > > > Since my hosting provider https://www.bytemark.co.uk/cloud-hosting/
> > > > > patched for Meltdown last weekend I'm seeing significant performance
> > > > > issues with an OpenBSD virtual instance there. It seems okay after a
> > > > > fresh reboot but then progressively returns to being very slow: for
> > > > > example "sleep 1" may take four seconds, then five, six, seven, then
> > > > > rather more. Curiously it does tend to be an integral multiplier.
> > > > > 
> > > > > I wondered, is anybody else seeing significant performance problems 
> > > > > with
> > > > > OpenBSD (or other BSDs) virtual instances since Meltdown patching? Is
> > > > > there anything to tweak at my end or am I reliant on the provider?
> > > > > 
> > > > > -- Mark
> > > > > 
> > > > There are a ton of threads talking about this issue, and it's not 
> > > > meltdown
> > > > specific. Please search the archives.
> > > > 
> > > > -ml
> > > > 
> > [...]
> > > Also, Mark, could you say some more about the issue.  For instance, how 
> > > long
> > > after a reboot does it take until you start to notice the issue, and how
> > > quickly does it get worse?
> > 
> > I'm another customer of Bytemark experiencing the same issue. I'm taking
> > care of one VM there and I'm primarly noticing it in two situations:
> > sleep() takes a long time (e.g. sleep(1) might take up to 40 seconds)
> > and the clock slows down.
> > 
> > Right now, 9 hours after reboot, the clock on VM is 3 hours behind real
> > clock. And sleep(1) takes 13 secs:
> > 
> > km@buildfarm ~ $ time sleep 1
> > 0m13.85s real 0m00.00s user 0m00.01s system
> > 
> > This all started after the host was patched and VM rebooted.
> > 
> > Bytemark guys are looking at the issue and doing their own debugging.
> > Here're findings so far:
> > 
> > I spun a few OpenBSD VMs up and left them overnight - looks like the
> > clock isn't drifting but there's still the 'time sleep 1' issue.
> > My testing results seemed to concur with User_4574's, virtio was slowing
> > down only a few minutes after a fresh install whereas compatibility
> > would stick at 1s, jump to 2s, etc. 
> >
> > > 
> > > Thanks,
> > > Kent
> > > 
> > 
> > -- 
> > -- Kirill Miazine <k...@krot.org>
> > 
> >
> 
> 

Re: Performance issues as KVM guest?

[Infoomatic]

Same problem here.
While we did have significant differences in cpu usage between FreeBSD and 
OpenBSD (basic OS without configuration: FreeBSD ~ 33min CPU time, OpenBSD ~ 
474min CPU time - both started at the same time), with the latest kernel 
patches for Ubuntu 17.04 (our test environments all run Ubuntu 17.04 for KVM 
VMs), OpenBSD now becomes practically unusable: as soon as I su or login on the 
console with su, cpu usage is at 100% - the system freezes. :-/ guess we need 
some dedicated BSD machines to host some test-VMs ;-)

Regards,
Robert


> Gesendet: Donnerstag, 11. Januar 2018 um 20:32 Uhr
> Von: "Kirill Miazine" <k...@krot.org>
> An: misc@openbsd.org
> Betreff: Re: Performance issues as KVM guest?
>
> * Kent Watsen [2018-01-11 17:38]:
> [...]
> > > > Since my hosting provider https://www.bytemark.co.uk/cloud-hosting/
> > > > patched for Meltdown last weekend I'm seeing significant performance
> > > > issues with an OpenBSD virtual instance there. It seems okay after a
> > > > fresh reboot but then progressively returns to being very slow: for
> > > > example "sleep 1" may take four seconds, then five, six, seven, then
> > > > rather more. Curiously it does tend to be an integral multiplier.
> > > > 
> > > > I wondered, is anybody else seeing significant performance problems with
> > > > OpenBSD (or other BSDs) virtual instances since Meltdown patching? Is
> > > > there anything to tweak at my end or am I reliant on the provider?
> > > > 
> > > > -- Mark
> > > > 
> > > There are a ton of threads talking about this issue, and it's not meltdown
> > > specific. Please search the archives.
> > > 
> > > -ml
> > > 
> [...]
> > Also, Mark, could you say some more about the issue.  For instance, how long
> > after a reboot does it take until you start to notice the issue, and how
> > quickly does it get worse?
> 
> I'm another customer of Bytemark experiencing the same issue. I'm taking
> care of one VM there and I'm primarly noticing it in two situations:
> sleep() takes a long time (e.g. sleep(1) might take up to 40 seconds)
> and the clock slows down.
> 
> Right now, 9 hours after reboot, the clock on VM is 3 hours behind real
> clock. And sleep(1) takes 13 secs:
> 
> km@buildfarm ~ $ time sleep 1
> 0m13.85s real 0m00.00s user 0m00.01s system
> 
> This all started after the host was patched and VM rebooted.
> 
> Bytemark guys are looking at the issue and doing their own debugging.
> Here're findings so far:
> 
> I spun a few OpenBSD VMs up and left them overnight - looks like the
> clock isn't drifting but there's still the 'time sleep 1' issue.
> My testing results seemed to concur with User_4574's, virtio was slowing
> down only a few minutes after a fresh install whereas compatibility
> would stick at 1s, jump to 2s, etc.   
>  
> > 
> > Thanks,
> > Kent
> > 
> 
> -- 
> -- Kirill Miazine <k...@krot.org>
> 
>

Re: Performance issues as KVM guest?

[Kirill Miazine]

* Kent Watsen [2018-01-11 17:38]:
[...]
> > > Since my hosting provider https://www.bytemark.co.uk/cloud-hosting/
> > > patched for Meltdown last weekend I'm seeing significant performance
> > > issues with an OpenBSD virtual instance there. It seems okay after a
> > > fresh reboot but then progressively returns to being very slow: for
> > > example "sleep 1" may take four seconds, then five, six, seven, then
> > > rather more. Curiously it does tend to be an integral multiplier.
> > > 
> > > I wondered, is anybody else seeing significant performance problems with
> > > OpenBSD (or other BSDs) virtual instances since Meltdown patching? Is
> > > there anything to tweak at my end or am I reliant on the provider?
> > > 
> > > -- Mark
> > > 
> > There are a ton of threads talking about this issue, and it's not meltdown
> > specific. Please search the archives.
> > 
> > -ml
> > 
[...]
> Also, Mark, could you say some more about the issue.  For instance, how long
> after a reboot does it take until you start to notice the issue, and how
> quickly does it get worse?

I'm another customer of Bytemark experiencing the same issue. I'm taking
care of one VM there and I'm primarly noticing it in two situations:
sleep() takes a long time (e.g. sleep(1) might take up to 40 seconds)
and the clock slows down.

Right now, 9 hours after reboot, the clock on VM is 3 hours behind real
clock. And sleep(1) takes 13 secs:

km@buildfarm ~ $ time sleep 1
0m13.85s real 0m00.00s user 0m00.01s system

This all started after the host was patched and VM rebooted.

Bytemark guys are looking at the issue and doing their own debugging.
Here're findings so far:

I spun a few OpenBSD VMs up and left them overnight - looks like the
clock isn't drifting but there's still the 'time sleep 1' issue.
My testing results seemed to concur with User_4574's, virtio was slowing
down only a few minutes after a fresh install whereas compatibility
would stick at 1s, jump to 2s, etc. 
   
> 
> Thanks,
> Kent
> 

-- 
-- Kirill Miazine 

Re: Performance issues as KVM guest?

[Todd C. Miller]

This sounds like the same issue as was described here:
https://marc.info/?l=openbsd-bugs=151430928212450=2

 - todd

Re: Performance issues as KVM guest?

[Mike Larkin]

On Thu, Jan 11, 2018 at 05:38:18PM +, Kent Watsen wrote:
> On 1/10/18 1:53 PM, Mike Larkin wrote:
> > On Wed, Jan 10, 2018 at 03:51:19PM +, Mark Carroll wrote:
> > > Since my hosting provider https://www.bytemark.co.uk/cloud-hosting/
> > > patched for Meltdown last weekend I'm seeing significant performance
> > > issues with an OpenBSD virtual instance there. It seems okay after a
> > > fresh reboot but then progressively returns to being very slow: for
> > > example "sleep 1" may take four seconds, then five, six, seven, then
> > > rather more. Curiously it does tend to be an integral multiplier.
> > > 
> > > I wondered, is anybody else seeing significant performance problems with
> > > OpenBSD (or other BSDs) virtual instances since Meltdown patching? Is
> > > there anything to tweak at my end or am I reliant on the provider?
> > > 
> > > -- Mark
> > > 
> > There are a ton of threads talking about this issue, and it's not meltdown
> > specific. Please search the archives.
> > 
> > -ml
> > 
> 
> Really? I just searched the last two years of list email for subject lines
> having substrings "virt", "kvm", "perf", and "slow", and didn't see anything
> on this specific issue.   Can you provide a link, or the name of the thread,
> or some keywords?
> 
> Also, Mark, could you say some more about the issue.  For instance, how long
> after a reboot does it take until you start to notice the issue, and how
> quickly does it get worse?
> 
> Thanks,
> Kent
> 

IIRC several of the threads referred to proxmox.

Re: Performance issues as KVM guest?

[Kent Watsen]

On 1/10/18 1:53 PM, Mike Larkin wrote:

On Wed, Jan 10, 2018 at 03:51:19PM +, Mark Carroll wrote:

Since my hosting provider https://www.bytemark.co.uk/cloud-hosting/
patched for Meltdown last weekend I'm seeing significant performance
issues with an OpenBSD virtual instance there. It seems okay after a
fresh reboot but then progressively returns to being very slow: for
example "sleep 1" may take four seconds, then five, six, seven, then
rather more. Curiously it does tend to be an integral multiplier.

I wondered, is anybody else seeing significant performance problems with
OpenBSD (or other BSDs) virtual instances since Meltdown patching? Is
there anything to tweak at my end or am I reliant on the provider?

-- Mark


There are a ton of threads talking about this issue, and it's not meltdown
specific. Please search the archives.

-ml



Really? I just searched the last two years of list email for subject 
lines having substrings "virt", "kvm", "perf", and "slow", and didn't 
see anything on this specific issue.   Can you provide a link, or the 
name of the thread, or some keywords?


Also, Mark, could you say some more about the issue.  For instance, how 
long after a reboot does it take until you start to notice the issue, 
and how quickly does it get worse?


Thanks,
Kent

Re: Performance issues as KVM guest?

[Mark Carroll]

On 10 Jan 2018, Mike Larkin wrote:

> On Wed, Jan 10, 2018 at 03:51:19PM +, Mark Carroll wrote:
(snip)
>> I wondered, is anybody else seeing significant performance problems with
>> OpenBSD (or other BSDs) virtual instances since Meltdown patching? Is
>> there anything to tweak at my end or am I reliant on the provider?
>
> There are a ton of threads talking about this issue, and it's not meltdown
> specific. Please search the archives.

Ah, perhaps I was wrong to think they're something else -- I'm not their
only customer who found significant issues starting immediately after
last weekend's patching when things had worked fine before. I'll look
back at those threads more carefully then, perhaps they made some other
relevant change at the same time.

-- Mark

Re: Performance issues as KVM guest?

[Mike Larkin]

On Wed, Jan 10, 2018 at 03:51:19PM +, Mark Carroll wrote:
> Since my hosting provider https://www.bytemark.co.uk/cloud-hosting/
> patched for Meltdown last weekend I'm seeing significant performance
> issues with an OpenBSD virtual instance there. It seems okay after a
> fresh reboot but then progressively returns to being very slow: for
> example "sleep 1" may take four seconds, then five, six, seven, then
> rather more. Curiously it does tend to be an integral multiplier.
> 
> I wondered, is anybody else seeing significant performance problems with
> OpenBSD (or other BSDs) virtual instances since Meltdown patching? Is
> there anything to tweak at my end or am I reliant on the provider?
> 
> -- Mark
> 

There are a ton of threads talking about this issue, and it's not meltdown
specific. Please search the archives.

-ml

> 
> OpenBSD 6.1 (GENERIC) #26: Wed Oct  4 18:41:35 CEST 2017
> 
> rob...@syspatch-61-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> real mem = 1055870976 (1006MB)
> avail mem = 1019322368 (972MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf1c10 (10 entries)
> bios0: vendor Bochs version "Bochs" date 01/01/2011
> bios0: Bochs Bochs
> acpi0 at bios0: rev 0
> acpi0: sleep states S3 S4 S5
> acpi0: tables DSDT FACP SSDT APIC HPET
> acpi0: wakeup devices
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: QEMU Virtual CPU version 2.1.3, 2200.42 MHz
> cpu0: 
> FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,POPCNT,HV,NXE,LONG,LAHF
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
> 64b/line 16-way L2 cache
> cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 1000MHz
> ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
> acpihpet0 at acpi0: 1 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu0 at acpi0: C1(@1 halt!)
> "ACPI0006" at acpi0 not configured
> "PNP0303" at acpi0 not configured
> "PNP0F13" at acpi0 not configured
> "PNP0700" at acpi0 not configured
> "PNP0400" at acpi0 not configured
> "PNP0501" at acpi0 not configured
> "ACPI0007" at acpi0 not configured
> pvbus0 at mainbus0: KVM
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
> pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
> pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
> wired to compatibility, channel 1 wired to compatibility
> pciide0: channel 0 disabled (no drives)
> atapiscsi0 at pciide0 channel 1 drive 0
> scsibus1 at atapiscsi0: 2 targets
> cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom 
> removable
> cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
> uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11
> piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int 9
> iic0 at piixpm0
> vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00
> vio0 at virtio0: address fe:ff:00:00:4f:1a
> virtio0: msix shared
> virtio1 at pci0 dev 4 function 0 "Qumranet Virtio Memory" rev 0x00
> viomb0 at virtio1
> virtio1: apic 0 int 11
> virtio2 at pci0 dev 5 function 0 "Qumranet Virtio Storage" rev 0x00
> vioblk0 at virtio2
> scsibus2 at vioblk0: 2 targets
> sd0 at scsibus2 targ 0 lun 0:  SCSI3 0/direct fixed
> sd0: 25600MB, 512 bytes/sector, 52428800 sectors
> virtio2: msix shared
> "Intel 6300ESB WDT" rev 0x00 at pci0 dev 6 function 0 not configured
> isa0 at pcib0
> isadma0 at isa0
> fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
> fd0 at fdc0 drive 1: density unknown
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pms0 at pckbc0 (aux slot)
> wsmouse0 at pms0 mux 0
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> lpt0 at isa0 port 0x378/4 irq 7
> usb0 at uhci0: USB revision 1.0
> uhub0 at usb0 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
> addr 1
> uhidev0 at uhub0 port 1 configuration 1 interface 0 "QEMU QEMU USB Tablet" 
> rev 1.00/0.00 addr 2
> uhidev0: iclass 3/0
> ums0 at uhidev0: 3 buttons, Z dir
> wsmouse1 at ums0 mux 0
> vscsi0 at root
> scsibus3 at vscsi0: 256 targets
> softraid0 at root
> scsibus4 at softraid0: 256 targets
> root on sd0a (312946608d4051a2.a) swap on sd0b dump on sd0b
> 

Re: Performance issues

[Ville Valkonen]

Hi,

acpiec still freezes (afaik. no acpi related commits lately, excluding
the hibernate ones). At times there seems to be a flick with the
second ethernet device. I'll try to examine that in a greater detail
when I have time.

For following snapshots, I've crafted a small script that downloads
all the needed files. After that: boot bsd.rd, perform base upgrade,
boot, sysmerge and package update - done.

Sincerely,
Ville

On 27 March 2012 05:37, Jay Hart jh...@kevla.org wrote:
 Ville,

 How do you update from one snapshot to the next? B I'm assume its not as
easy
 as copying the bsd file to your drive and booting that?

 I was trying to determine the procedure for this...

 Jay

 Hi,

 I've updated to the latest snapshot (dated 25.03.) via Swedish
 EU-mirror. Here's updated data in the case of need:
 http://weezel.fsck.fi/dump/

 ---
 Ville

 On 26 March 2012 10:28, Ville Valkonen weezeld...@gmail.com wrote:
 If you need more info please let me know since I have the similar
 machine with acpiec errors. Here's discussion (and data) that I've had
 before: http://marc.info/?l=openbsd-miscm=132835596005571w=2 . CPU
 related unknown model messages are obsolete since @jsg provided a
 patch and it's applied to upstream nowadays. I will update the data to
 correspond the present situation when I get home from the work.

 Sincerely,
 Ville

 On 26 March 2012 03:14, Jay Hart jh...@kevla.org wrote:
 On Sun, Mar 25, 2012, Jay Hart wrote:
 On Sun, Mar 25, 2012, Jay Hart wrote:
 1. Unless I disable acpi (see dmesg), box freezes at 'acpiec0 at
 acpi0'

 What about just disabling acpiec?


 You're a GENIUS, that was it! B ;')

 How do I make that stick reboot to reboot? B Assume I need to compile
 custom
 kernel?

 That's not a long term solution, I was curious to narrow down the
 problem. B The acpiec driver is kinda important, so running without it
 is not a happy ending. B Can you post the new dmesg? B Also, have a
copy
 of acpidump available (that's too big to mail to the list right now).


 Ted,

 Will post a new dmesg later this evening. B How do I get a acpidump?

 Jay

Re: Performance issues

[Ville Valkonen]

If you need more info please let me know since I have the similar
machine with acpiec errors. Here's discussion (and data) that I've had
before: http://marc.info/?l=openbsd-miscm=132835596005571w=2 . CPU
related unknown model messages are obsolete since @jsg provided a
patch and it's applied to upstream nowadays. I will update the data to
correspond the present situation when I get home from the work.

Sincerely,
Ville

On 26 March 2012 03:14, Jay Hart jh...@kevla.org wrote:
 On Sun, Mar 25, 2012, Jay Hart wrote:
 On Sun, Mar 25, 2012, Jay Hart wrote:
 1. Unless I disable acpi (see dmesg), box freezes at 'acpiec0 at acpi0'

 What about just disabling acpiec?


 You're a GENIUS, that was it! B ;')

 How do I make that stick reboot to reboot? B Assume I need to compile
custom
 kernel?

 That's not a long term solution, I was curious to narrow down the
 problem. B The acpiec driver is kinda important, so running without it
 is not a happy ending. B Can you post the new dmesg? B Also, have a copy
 of acpidump available (that's too big to mail to the list right now).


 Ted,

 Will post a new dmesg later this evening. B How do I get a acpidump?

 Jay

Re: Performance issues

[Stuart Henderson]

On 2012-03-26, Jay Hart jh...@kevla.org wrote:
 On Sun, Mar 25, 2012, Jay Hart wrote:
 On Sun, Mar 25, 2012, Jay Hart wrote:
 1. Unless I disable acpi (see dmesg), box freezes at 'acpiec0 at acpi0'

 What about just disabling acpiec?


 You're a GENIUS, that was it!  ;')

 How do I make that stick reboot to reboot?  Assume I need to compile custom
 kernel?

 That's not a long term solution, I was curious to narrow down the
 problem.  The acpiec driver is kinda important, so running without it
 is not a happy ending.  Can you post the new dmesg?  Also, have a copy
 of acpidump available (that's too big to mail to the list right now).


 Ted,

 Will post a new dmesg later this evening.  How do I get a acpidump?

 Jay



sudo acpidump -o jetway-nc9kdl   jetway-nc9kdl.txt
dmesg  jetway-nc9kdl.dmesg
tar czf jetway-nc9kdl-acpidump.tgz jetway-nc9kdl.*

Re: Performance issues

[Jay Hart]

 On Sun, Mar 25, 2012, Jay Hart wrote:
 On Sun, Mar 25, 2012, Jay Hart wrote:
 1. Unless I disable acpi (see dmesg), box freezes at 'acpiec0 at acpi0'

 What about just disabling acpiec?


 You're a GENIUS, that was it!  ;')

 How do I make that stick reboot to reboot?  Assume I need to compile custom
 kernel?

 That's not a long term solution, I was curious to narrow down the
 problem.  The acpiec driver is kinda important, so running without it
 is not a happy ending.  Can you post the new dmesg?  Also, have a copy
 of acpidump available (that's too big to mail to the list right now).

Ted,

acpidump located at

www.kevla.org/jwnc9kdl.tar.gz

I will post the dmesg this evening.

Jay

Re: Performance issues

[Jay Hart]

 On Sun, Mar 25, 2012, Jay Hart wrote:
 On Sun, Mar 25, 2012, Jay Hart wrote:
 1. Unless I disable acpi (see dmesg), box freezes at 'acpiec0 at acpi0'

 What about just disabling acpiec?


 You're a GENIUS, that was it!  ;')

 How do I make that stick reboot to reboot?  Assume I need to compile custom
 kernel?

 That's not a long term solution, I was curious to narrow down the
 problem.  The acpiec driver is kinda important, so running without it
 is not a happy ending.  Can you post the new dmesg?  Also, have a copy
 of acpidump available (that's too big to mail to the list right now).

Ted,

Here is the dmesg:

OpenBSD 5.1-current (GENERIC.MP) #208: Thu Mar 22 11:30:37 MDT 2012
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz (GenuineIntel 686-class) 2.13 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,SSE3,MWAIT,DS-CPL,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF
real mem  = 3476844544 (3315MB)
avail mem = 3409215488 (3251MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/20/10, SMBIOS rev. 2.7 @ 0xe9660 (51
entries)
bios0: vendor American Megatrends Inc. version 4.6.4 date 12/01/2011
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG HPET SSDT
acpi0: wakeup devices P0P8(S4) PS2K(S1) PS2M(S1) USB0(S4) USB1(S4) USB2(S4)
USB3(S4) USB7(S4) PXSX(S4) RP01(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4)
PXSX(S4) RP02(S4) PWRB(S1)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 133MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz (GenuineIntel 686-class) 2.13 GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,SSE3,MWAIT,DS-CPL,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz (GenuineIntel 686-class) 2.13 GHz
cpu2:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,SSE3,MWAIT,DS-CPL,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz (GenuineIntel 686-class) 2.13 GHz
cpu3:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,SSE3,MWAIT,DS-CPL,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 5 (P0P8)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus 3 (RP03)
acpiprt4 at acpi0: bus 4 (RP04)
acpiprt5 at acpi0: bus 2 (RP02)
acpiec at acpi0 not configured
acpicpu0 at acpi0: C1
acpicpu1 at acpi0: C1
acpicpu2 at acpi0: C1
acpicpu3 at acpi0: C1
acpitz0 at acpi0: critical temperature is 127 degC
acpipwrres0 at acpi0: FN00
acpitz1 at acpi0: critical temperature is 127 degC
acpitz2 at acpi0: critical temperature is 100 degC
acpibat0 at acpi0: BAT0 model CRB Battery 0 serial Battery 0 type Fake oem
-Virtual Battery 0-
acpibat1 at acpi0: BAT1 not present
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
acpivideo0 at acpi0: GFX0
bios0: ROM list: 0xc/0xf200!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 vendor Intel, unknown product 0x0bf3 rev 0x03
vga1 at pci0 dev 2 function 0 vendor Intel, unknown product 0x0be2 rev 0x09
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp at vga1 not configured
ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 4 int 16
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 4 int 17
pci2 at ppb1 bus 2
re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E-VL
(0x2c80), apic 4 int 17, address 00:30:18:a5:a2:55
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 5
ppb2 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: apic 4 int 18
pci3 at ppb2 bus 3
re1 at pci3 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E-VL
(0x2c80), apic 4 int 18, address 00:30:18:a5:a2:56
rgephy1 at re1 phy 7: RTL8169S/8110S PHY, rev. 5
ppb3 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: apic 4 int 19
pci4 at ppb3 bus 4
uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 4 int 23
uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 4 int 19
uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 4 int 18
uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 4 int 16
ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 4 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root 

Re: Performance issues

[Ville Valkonen]

Hi,

I've updated to the latest snapshot (dated 25.03.) via Swedish
EU-mirror. Here's updated data in the case of need:
http://weezel.fsck.fi/dump/

---
Ville

On 26 March 2012 10:28, Ville Valkonen weezeld...@gmail.com wrote:
 If you need more info please let me know since I have the similar
 machine with acpiec errors. Here's discussion (and data) that I've had
 before: http://marc.info/?l=openbsd-miscm=132835596005571w=2 . CPU
 related unknown model messages are obsolete since @jsg provided a
 patch and it's applied to upstream nowadays. I will update the data to
 correspond the present situation when I get home from the work.

 Sincerely,
 Ville

 On 26 March 2012 03:14, Jay Hart jh...@kevla.org wrote:
 On Sun, Mar 25, 2012, Jay Hart wrote:
 On Sun, Mar 25, 2012, Jay Hart wrote:
 1. Unless I disable acpi (see dmesg), box freezes at 'acpiec0 at
acpi0'

 What about just disabling acpiec?


 You're a GENIUS, that was it! B ;')

 How do I make that stick reboot to reboot? B Assume I need to compile
custom
 kernel?

 That's not a long term solution, I was curious to narrow down the
 problem. B The acpiec driver is kinda important, so running without it
 is not a happy ending. B Can you post the new dmesg? B Also, have a copy
 of acpidump available (that's too big to mail to the list right now).


 Ted,

 Will post a new dmesg later this evening. B How do I get a acpidump?

 Jay

Re: Performance issues

[Jay Hart]

Are you still having to disable acpiec?

Jay

 Hi,

 I've updated to the latest snapshot (dated 25.03.) via Swedish
 EU-mirror. Here's updated data in the case of need:
 http://weezel.fsck.fi/dump/

 ---
 Ville

 On 26 March 2012 10:28, Ville Valkonen weezeld...@gmail.com wrote:
 If you need more info please let me know since I have the similar
 machine with acpiec errors. Here's discussion (and data) that I've had
 before: http://marc.info/?l=openbsd-miscm=132835596005571w=2 . CPU
 related unknown model messages are obsolete since @jsg provided a
 patch and it's applied to upstream nowadays. I will update the data to
 correspond the present situation when I get home from the work.

 Sincerely,
 Ville

 On 26 March 2012 03:14, Jay Hart jh...@kevla.org wrote:
 On Sun, Mar 25, 2012, Jay Hart wrote:
 On Sun, Mar 25, 2012, Jay Hart wrote:
 1. Unless I disable acpi (see dmesg), box freezes at 'acpiec0 at
 acpi0'

 What about just disabling acpiec?


 You're a GENIUS, that was it! B ;')

 How do I make that stick reboot to reboot? B Assume I need to compile
 custom
 kernel?

 That's not a long term solution, I was curious to narrow down the
 problem. B The acpiec driver is kinda important, so running without it
 is not a happy ending. B Can you post the new dmesg? B Also, have a copy
 of acpidump available (that's too big to mail to the list right now).


 Ted,

 Will post a new dmesg later this evening. B How do I get a acpidump?

 Jay

Re: Performance issues

[Ted Unangst]

On Sun, Mar 25, 2012, Jay Hart wrote:
 1. Unless I disable acpi (see dmesg), box freezes at 'acpiec0 at acpi0'

What about just disabling acpiec?

Re: Performance issues

[Jay Hart]

 On Sun, Mar 25, 2012, Jay Hart wrote:
 1. Unless I disable acpi (see dmesg), box freezes at 'acpiec0 at acpi0'

 What about just disabling acpiec?



Snappy question section 5.9...  got it.

Jay

Re: Performance issues

[Jay Hart]

 On Sun, Mar 25, 2012, Jay Hart wrote:
 1. Unless I disable acpi (see dmesg), box freezes at 'acpiec0 at acpi0'

 What about just disabling acpiec?


Ted,

I'll try that.  Didn't know what it.

Jay

Re: Performance issues

[Jay Hart]

 On Sun, Mar 25, 2012, Jay Hart wrote:
 1. Unless I disable acpi (see dmesg), box freezes at 'acpiec0 at acpi0'

 What about just disabling acpiec?



Ted,

You're a GENIUS, that was it!  ;')

How do I make that stick reboot to reboot?  Assume I need to compile custom
kernel?

Jay

Re: Performance issues

[Carson Chittom]

Jay Hart jh...@kevla.org writes:

 On Sun, Mar 25, 2012, Jay Hart wrote:
 1. Unless I disable acpi (see dmesg), box freezes at 'acpiec0 at acpi0'

 What about just disabling acpiec?



 Ted,

 You're a GENIUS, that was it!  ;')

 How do I make that stick reboot to reboot?  Assume I need to compile custom
 kernel?

http://www.openbsd.org/faq/faq5.html#config

Re: Performance issues

[Ted Unangst]

On Sun, Mar 25, 2012, Jay Hart wrote:
 On Sun, Mar 25, 2012, Jay Hart wrote:
 1. Unless I disable acpi (see dmesg), box freezes at 'acpiec0 at acpi0'

 What about just disabling acpiec?


 You're a GENIUS, that was it!  ;')
 
 How do I make that stick reboot to reboot?  Assume I need to compile custom
 kernel?

That's not a long term solution, I was curious to narrow down the
problem.  The acpiec driver is kinda important, so running without it
is not a happy ending.  Can you post the new dmesg?  Also, have a copy
of acpidump available (that's too big to mail to the list right now).

Re: Performance issues

[Jay Hart]

 On Sun, Mar 25, 2012, Jay Hart wrote:
 On Sun, Mar 25, 2012, Jay Hart wrote:
 1. Unless I disable acpi (see dmesg), box freezes at 'acpiec0 at acpi0'

 What about just disabling acpiec?


 You're a GENIUS, that was it!  ;')

 How do I make that stick reboot to reboot?  Assume I need to compile custom
 kernel?

 That's not a long term solution, I was curious to narrow down the
 problem.  The acpiec driver is kinda important, so running without it
 is not a happy ending.  Can you post the new dmesg?  Also, have a copy
 of acpidump available (that's too big to mail to the list right now).


Ted,

Will post a new dmesg later this evening.  How do I get a acpidump?

Jay

Re: Performance issues with the DNS patch?

[Damien Miller]

On Sat, 26 Jul 2008, J Duke wrote:

 I realize that the whole fix to this DNS cache poisoning is to have
 random ports and random query ids, and that generating good, strong,
 random numbers costs cpu cycles and time. Has anyone else noticed the
 performance hit? Anything that I can do? Particularly I am open to any
 suggestions on commands that would help identify if that is really the
 problem, systat, vmstat, etc.

The additional overhead in the fixed bind is due to the need to manange
lots of open sockets. Since bind now randomises source ports, it must
open, bind and subsequently manage a UDP socket for each query whereas
before it only needed a single socket for its single query port.

Future releases of bind will reduce this overhead a little, but a good
portion of it is intrinsic.

That being said, you probably shouldn't be getting failed queries. Make
sure that:

1) You aren't running out of file descriptors in bind (check logs and
   ulimits against fstat -p [named-pid])

2) Your queries are not being firewalled. There are lots of firewalls
   that implement restrictions on high-numbered UDP ports. If you have
   such a firewall then you will cause queries to fail and be retried,
   which will cause additional load on your name server. -current tries
   hard to avoid well-known ports, but we can't predict every firewall
   configuration.

-d

Re: Performance issues with the DNS patch?

[Ted Unangst]

On 7/26/08, J Duke [EMAIL PROTECTED] wrote:
 I wonder is anyone is seeing performance issues with the patched DNS in the
  late snapshots?

http://marc.info/?l=bind-usersm=121726908015389w=2

Re: Performance issues with the DNS patch?

[Stuart Henderson]

On 2008-07-26, J Duke [EMAIL PROTECTED] wrote:
 I moved back to an earlier version of OpenBSD on the DNS server, and
 the Ironport traffic went up to normal, and the DNS lookup failures stopped.
 Cpu utilization went back down to around 9%. But I'm vulnerable.

Sending spam seems a good way to force certain DNS lookups to be
done by the receiver, so depending on exactly what DNS lookups your
spam filtering systems are doing, you might _really_ not want to
be pointing them at an easily poisoned resolver. 

 I realize that the whole fix to this DNS cache poisoning is to have random
 ports and random query ids, and that generating good, strong, random numbers
 costs cpu cycles and time.  Has anyone else noticed the performance hit?

It's not just generating random numbers that burns cycles, you also
take a hit from finding unused ports to send queries from, etc.

You might want to try unbound (in packages/ports for -current). 
It's pretty sane and easy to get along with. For a busy system
it has a big advantage over bind: if you configure IP aliases
on the machine and list them manually in separate outgoing-
interface lines, it will rotate between them, reducing the
contention on port numbers.

With unbound, don't take the shortcut of listing 0.0.0.0 /
::0 in Interface: lines, list incoming interfaces individually,
this avoids problems with replies going out with wrong source
addresses.

Note that this port randomisation does not _fix_ cache
poisoning, it just makes it more difficult.

Re: Performance issues with the DNS patch?

[Daniel Melameth]

On Sat, Jul 26, 2008 at 4:12 PM, J Duke [EMAIL PROTECTED] wrote:
 I wonder is anyone is seeing performance issues with the patched DNS in the
 late snapshots?
 I installed the July 22 snapshot on our DNS servers, which handle a pretty
 heavy load of lookups, mostly for anti-spam action.

 It was running at 45% or higher cpu utilization after the July 22 snapshot
 was
 installed.
 We run a couple of Ironport boxes, that handle about 200k emails per hour.
 They use the OpenBSD DNS servers to look up the sending IPs as a first
 defense
 against spammers, and drop about 98% of the inbound mail.
 With the snapshot installed the traffic went down to 70k per hour and
 people started complaining of DNS lookup failures for random sites.

While I haven't compared the two, this is a known issue with the ISC
patch as well--though I understand the beta version of BIND includes
optimized code that will reduce the impact in performance to
non-significant levels.

Re: Performance issues with the DNS patch?

[Florian Fuessl]

Hi,

is there a particular reason, why you have to use bind as resolver? If not,
I would try out running a DNS-recursor (PowerDNS-recursor, djbdns, ...)
which may offer more performance and maybe less pain in the future ;)

-Florian 

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of J Duke
 Sent: Sunday, July 27, 2008 12:13 AM
 To: misc@openbsd.org
 Subject: Performance issues with the DNS patch?
 
 I wonder is anyone is seeing performance issues with the patched DNS in
 the
 late snapshots?
 I installed the July 22 snapshot on our DNS servers, which handle a
 pretty
 heavy load of lookups, mostly for anti-spam action.
 
 It was running at 45% or higher cpu utilization after the July 22
 snapshot
 was
 installed.
 We run a couple of Ironport boxes, that handle about 200k emails per
 hour.
 They use the OpenBSD DNS servers to look up the sending IPs as a first
 defense
 against spammers, and drop about 98% of the inbound mail.
 With the snapshot installed the traffic went down to 70k per hour and
 people started complaining of DNS lookup failures for random sites.
 
 I moved back to an earlier version of OpenBSD on the DNS server, and
 the Ironport traffic went up to normal, and the DNS lookup failures
 stopped.
 Cpu utilization went back down to around 9%. But I'm vulnerable.
 
 I realize that the whole fix to this DNS cache poisoning is to have
 random
 ports and random query ids, and that generating good, strong, random
 numbers
 costs cpu cycles and time.  Has anyone else noticed the performance
 hit?
 Anything that I can do?  Particularly I am open to any suggestions on
 commands
 that would help identify if that is really the problem, systat, vmstat,
 etc.
 
 The server was beefy enough, and had been doing the job for months
 before
 the upgrade:
 
 OpenBSD 4.2-current (GENERIC) #593: Mon Dec 10 13:23:15 MST 2007
 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
 cpu0: Intel(R) Xeon(TM) CPU 3.20GHz (GenuineIntel 686-class) 3.21 GHz
 cpu0:
 FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36
 ,CF
 LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-
 ID,CX16,xTPR
 real mem  = 1073053696 (1023MB)
 avail mem = 1029713920 (982MB)
 mainbus0 at root
 bios0 at mainbus0: AT/286+ BIOS, date 10/20/04, BIOS32 rev. 0 @
 0xffe90,
 SMBIOS
 rev. 2.3 @ 0xfa910 (75 entries)
 bios0: vendor Dell Computer Corporation version A00 date 10/20/2004
 bios0: Dell Computer Corporation PowerEdge SC1425
 [...]
 em0 at pci2 dev 4 function 0 Intel PRO/1000MT (82541GI) rev 0x05: irq
 11,
 i
 address xx:xx:xx:xx:xx:xx
 
 Thanks for a great OS! And yes, I usually run snapshots, have for
 years,
 love it, and we buy
 plenty of CDs of each version..

Re: Performance Issues of Intel Quad Port NIC

[Geoff Steckel]

Jonathan Steel [EMAIL PROTECTED] wrote:

Hi Everyone

We recently purchased an Intel PRO/1000 GT Quad Port network card and
decided to run some stress tests to make sure it could maintain gigabit
connections on all four ports at the same time. I ran the test with five
computers and iperf-1.7.0 (newest version of iperf has speed issues with
OpenBSD). The computer with the NIC ran the iperf server in upd mode and
the four other machines ran as iperf upd clients.

The first test was using the GENERIC kernel

2 ports could sustain 900Mbit/s connections with about 30% packet drop rate
3 ports could sustain 900Mbit/s connections with about 80% packet drop rate
4 ports could sustain 900Mbit/s connections with about 95-99% packet drop
rate


The second test was using the GENERIC.MP kernel

2 ports could sustain 900Mbit/s connections with no dropped packets
3 ports could sustain 900Mbit/s connections with about 10% packet drop rate
4 ports could sustain 900Mbit/s connections with about 30-50% packet drop
rate



It would be really helpful if you gave us the before and after output of:
  netstat -ss -p ip
  netstat -ss -p tcp
  netstat -in
  netstat -m
  sysctl net
and ran
  iostat 1
for a bit during your tests.

  netstat -ss tells things about queue drops
  netstat -in tells packet counts
  netstat -m tells things about mbuf usage
  sysctl net tells things about tcp and ip settings and some duplicate
data about queues, etc.
  iostat 1 tells about CPU usage

For instance, I suspect that the IP input queue limit is too low,
as someone else mentioned. Using the PIC for interrupt vectoring
is indeed slow. But we can't tell without at least some of the numbers
and status above.

   geoff steckel

Re: Performance Issues of Intel Quad Port NIC

[Henning Brauer]

* Daniel Ouellet [EMAIL PROTECTED] [2008-01-15 21:19]:
 Jonathan Steel wrote:
 Is there any explanation for the speed difference? I have tried tweeking
 some sysctl values to no avail. Is there something else I can test for on
 the card? I'd be happy to run these tests again for any changes that are
 made.

 Use 4.2 and Henning did provide details a few times here, but use the 
 GENERIC only, not the MP kernel and try this:

 kern.maxclusters=128000
 net.inet.ip.ifq.maxlen=2500
 net.inet.ip.forwarding=1
 net.inet.carp.preempt=1
 net.inet.icmp.errppslimit=1000

err. that is what I use in one specific scenario. not a press these 
buttons for relief recipe.

-- 
Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg  Amsterdam

Re: Performance Issues of Intel Quad Port NIC

[Chris Cappuccio]

GENERIC.MP uses APIC instead of PIC which Microsoft, among others, claims
can handle a much higher interrupt load.  I was fussing around to make
APIC work on single processor kernels in my spare time, but I haven't gotten
anywhere yet.

What size packets were you using at 900Mbps? 1500 bytes?  These test would
be more interesting with 64 byte packets.

You could go into the kernel source and get rid of some of the features
that Linux and FreeBSD don't apply (like microtime() on every interrupt) to
see if you can up the packet per second capability.  But you should certainly
start with OpenBSD on APIC like Linux and FreeBSD do.  GENERIC.MP enables
APIC but you aren't using any of the other CPUs for any actual kernel work.

Jonathan Steel [EMAIL PROTECTED] wrote:
 Hi Everyone

 We recently purchased an Intel PRO/1000 GT Quad Port network card and
 decided to run some stress tests to make sure it could maintain gigabit
 connections on all four ports at the same time. I ran the test with five
 computers and iperf-1.7.0 (newest version of iperf has speed issues with
 OpenBSD). The computer with the NIC ran the iperf server in upd mode and
 the four other machines ran as iperf upd clients.

 The first test was using the GENERIC kernel

 2 ports could sustain 900Mbit/s connections with about 30% packet drop rate
 3 ports could sustain 900Mbit/s connections with about 80% packet drop rate
 4 ports could sustain 900Mbit/s connections with about 95-99% packet drop
 rate


 The second test was using the GENERIC.MP kernel

 2 ports could sustain 900Mbit/s connections with no dropped packets
 3 ports could sustain 900Mbit/s connections with about 10% packet drop rate
 4 ports could sustain 900Mbit/s connections with about 30-50% packet drop
 rate

 The only disturbing thing about these tests was that I also did the same
 test on Gentoo, and I could sustain 4 900Mbit/s connections with only a 3%
 drop rate. I found consisten results with the PRO/1000 MT Dual Port card
 as well, which has the same controller, the Intel 82546GB. I then tried
 the dual port card on FreeBSD FreeBSD 6.1 with the stock install which
 does not appear to use multiprocessors and it could maintain 2 ports at
 900Mbit/s without losing packets. Unfortunately FreeBSD 6.1 does not
 appear to support the 4 port card.

 I did some tests on an OpenBSD 3.8 machine and found the same problem.

 Is there any explanation for the speed difference? I have tried tweeking
 some sysctl values to no avail. Is there something else I can test for on
 the card? I'd be happy to run these tests again for any changes that are
 made.

 Here is the demsg of the test machine:

 OpenBSD 4.2-current (GENERIC) #9: Thu Oct 18 16:44:39 UTC 2007
 [EMAIL PROTECTED]:/sysHEAD/src/sys/arch/i386/compile/GENERIC
 cpu0: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (GenuineIntel 686-class)
 2.40 GHz
 cpu0:
 FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
 H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,
 xTPR
 real mem  = 3756482560 (3582MB)
 avail mem = 3648778240 (3479MB)
 mainbus0 at root
 bios0 at mainbus0: AT/286+ BIOS, date 08/25/07, BIOS32 rev. 0 @ 0xfd470,
 SMBIOS rev. 2.51 @ 0xdfeea000 (31 entries)
 bios0: vendor Phoenix Technologies LTD version 6.00 date 08/25/2007
 bios0: Supermicro PDSMi
 pcibios0 at bios0: rev 2.1 @ 0xfd470/0xb90
 pcibios0: PCI BIOS has 20 Interrupt Routing table entries
 pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82801GB LPC rev 0x00)
 pcibios0: PCI bus #15 is the last bus
 bios0: ROM list: 0xc/0xb000 0xcb000/0x1000 0xcc000/0x1000
 acpi at mainbus0 not configured
 ipmi at mainbus0 not configured
 cpu0 at mainbus0
 cpu0: Enhanced SpeedStep disabled by BIOS
 pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
 pchb0 at pci0 dev 0 function 0 Intel E7230 MCH rev 0xc0
 ppb0 at pci0 dev 1 function 0 Intel E7230 PCIE rev 0xc0
 pci1 at ppb0 bus 1
 ppb1 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x01
 pci2 at ppb1 bus 9
 ppb2 at pci2 dev 0 function 0 Intel PCIE-PCIE rev 0x09
 pci3 at ppb2 bus 10
 ppb3 at pci3 dev 1 function 0 Pericom PI7C21P100 PCIX-PCIX rev 0x01
 pci4 at ppb3 bus 11
 em0 at pci4 dev 4 function 0 Intel PRO/1000MT QP (82546GB) rev 0x03: irq
 11, address 00:1b:21:0e:c2:ec
 em1 at pci4 dev 4 function 1 Intel PRO/1000MT QP (82546GB) rev 0x03: irq
 11, address 00:1b:21:0e:c2:ed
 em2 at pci4 dev 6 function 0 Intel PRO/1000MT QP (82546GB) rev 0x03: irq
 5, address 00:1b:21:0e:c2:ee
 em3 at pci4 dev 6 function 1 Intel PRO/1000MT QP (82546GB) rev 0x03: irq
 11, address 00:1b:21:0e:c2:ef
 Intel IOxAPIC rev 0x09 at pci2 dev 0 function 1 not configured
 ppb4 at pci0 dev 28 function 4 Intel 82801G PCIE rev 0x01
 pci5 at ppb4 bus 13
 em4 at pci5 dev 0 function 0 Intel PRO/1000MT (82573E) rev 0x03: irq 11,
 address 00:30:48:8a:2e:7c
 ppb5 at pci0 dev 28 function 5 Intel 82801G PCIE rev 0x01
 pci6 at ppb5 bus 14
 em5 at pci6 dev 0 function 0 Intel PRO/1000MT (82573L) rev 0x00: irq 11,
 

Re: Performance Issues of Intel Quad Port NIC

[Daniel Ouellet]

Jonathan Steel wrote:

Is there any explanation for the speed difference? I have tried tweeking
some sysctl values to no avail. Is there something else I can test for on
the card? I'd be happy to run these tests again for any changes that are
made.


Use 4.2 and Henning did provide details a few times here, but use the 
GENERIC only, not the MP kernel and try this:


kern.maxclusters=128000
net.inet.ip.ifq.maxlen=2500
net.inet.ip.forwarding=1
net.inet.carp.preempt=1
net.inet.icmp.errppslimit=1000

Obviously the carp one wouldn't be needed if you do not have a CARP 
setup here, witch I think you do not. So, don;'t use that one.


Best,

Daniel