Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
On Oct 13, 2009, at 12:35 AM, Luigi Rizzo wrote: On Mon, Oct 12, 2009 at 09:48:42PM +0200, Thomas Backman wrote: I'm copying this over from the freebsd-performance list, as I'm looking for a few more opinions - not on the problems *I* am having, but rather to check whether the problem is universal or not, and if not, find a possible common factor. In other words: I want to hear about your experiences, *good or bad*! Here's the original thread (not from the beginning, though): http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html Long story short, my version: when the disk is stressed hard enough, console IO becomes COMPLETELY unbearable. 10+ seconds to switch between windows in screen(1), running (or even typing) simple commands, etc. This happens both via SSH and the serial console. hi, this issue (not specific to FreeBSD, and not new -- it has been like this forever) is discussed in some detail here http://www.bsdcan.org/2009/schedule/events/122.en.html The following code (a bit outdated) can help http://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048704.html cheers luigi Hmm, how stable would you say the code is? (And/or has there been any progress since March?) I'd prefer something that I feel confident in using in production, and the warning in the README clearly says "stay away!". Regards, Thomas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
Luigi Rizzo wrote: On Mon, Oct 12, 2009 at 09:48:42PM +0200, Thomas Backman wrote: I'm copying this over from the freebsd-performance list, as I'm looking for a few more opinions - not on the problems *I* am having, but rather to check whether the problem is universal or not, and if not, find a possible common factor. In other words: I want to hear about your experiences, *good or bad*! Here's the original thread (not from the beginning, though): http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html Long story short, my version: when the disk is stressed hard enough, console IO becomes COMPLETELY unbearable. 10+ seconds to switch between windows in screen(1), running (or even typing) simple commands, etc. This happens both via SSH and the serial console. hi, this issue (not specific to FreeBSD, and not new -- it has been like this forever) is discussed in some detail here http://www.bsdcan.org/2009/schedule/events/122.en.html The following code (a bit outdated) can help http://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048704.html Are you certain? The reported symptoms sound very unusual. Can you reproduce the problem with the provided instructions yourself? Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
On Tue, Oct 13, 2009 at 11:13:31AM +0100, Kris Kennaway wrote: > Luigi Rizzo wrote: > >On Mon, Oct 12, 2009 at 09:48:42PM +0200, Thomas Backman wrote: > >>I'm copying this over from the freebsd-performance list, as I'm > >>looking for a few more opinions - not on the problems *I* am having, > >>but rather to check whether the problem is universal or not, and if > >>not, find a possible common factor. > >>In other words: I want to hear about your experiences, *good or bad*! > >> > >>Here's the original thread (not from the beginning, though): > >>http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html > >> > >>Long story short, my version: when the disk is stressed hard enough, > >>console IO becomes COMPLETELY unbearable. 10+ seconds to switch > >>between windows in screen(1), running (or even typing) simple > >>commands, etc. This happens both via SSH and the serial console. > > > >hi, > >this issue (not specific to FreeBSD, and not new -- it has been > >like this forever) is discussed in some detail here > > > > http://www.bsdcan.org/2009/schedule/events/122.en.html > > > >The following code (a bit outdated) can help > > > >http://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048704.html > > Are you certain? The reported symptoms sound very unusual. Can you > reproduce the problem with the provided instructions yourself? sure -- with ATA/SATA disks, the test in the original post is enough to trigger cwpart of the problem time file /etc/*# this one is fast cat /dev/zero > /same_disk_as_etc/somedir/somefile & sleep enough_to_flush_disk_cache # 10-30 sec time file /etc/*# this one takes forever Now, getting sluggish behaviour on the console might need something more such as dependencies between the program being run and disk activity (logging, etc.) but the 'capture effect' on the disk is completely reproducible. Perhaps SCSI and various RAID incarnations may have a better behaviour or need a larger number of greedy clients to trigger the problem. cheers luigi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
Thomas Backman wrote: I'm copying this over from the freebsd-performance list, as I'm looking for a few more opinions - not on the problems *I* am having, but rather to check whether the problem is universal or not, and if not, find a possible common factor. In other words: I want to hear about your experiences, *good or bad*! Here's the original thread (not from the beginning, though): http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html Long story short, my version: when the disk is stressed hard enough, console IO becomes COMPLETELY unbearable. 10+ seconds to switch between windows in screen(1), running (or even typing) simple commands, etc. This happens both via SSH and the serial console. Hmm, this looks familiar - I've noticed it before on the physical (VGA) console and I notice it all the time under VMWare. It sort of looks like disk IO really blocks network IO in this case - I use the VMs over ssh. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ivan Voras wrote: > Thomas Backman wrote: >> I'm copying this over from the freebsd-performance list, as I'm >> looking for a few more opinions - not on the problems *I* am having, >> but rather to check whether the problem is universal or not, and if >> not, find a possible common factor. >> In other words: I want to hear about your experiences, *good or bad*! >> >> Here's the original thread (not from the beginning, though): >> http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html >> >> >> Long story short, my version: when the disk is stressed hard enough, >> console IO becomes COMPLETELY unbearable. 10+ seconds to switch >> between windows in screen(1), running (or even typing) simple >> commands, etc. This happens both via SSH and the serial console. > > Hmm, this looks familiar - I've noticed it before on the physical (VGA) > console and I notice it all the time under VMWare. It sort of looks like > disk IO really blocks network IO in this case - I use the VMs over ssh. I've seen some similar behaviour here with my zfs/istgt backend. I "resolved" the issue by reducing the arc_max so that each disk-io cycle would be "short enough" not to cause the istgt to generate timeouts towards my two vmware hosts. The io-backend for the box is a megaraid 8308 (mfi) card with 8 disks on it. This box is running RELENG_7 now (I tried running it with RELENG_8 but it had a nasty tendency of simply locking up, dragging down both my ESXi hosts with it). //Svein - -- - +---+--- /"\ |Svein Skogen | sv...@d80.iso100.no \ / |Solberg Østli 9| PGP Key: 0xE5E76831 X|2020 Skedsmokorset | sv...@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | sv...@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listm...@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +---+--- |msn messenger: | Mobile Phone: +47 907 03 575 |sv...@jernhuset.no | RIPE handle:SS16503-RIPE - +---+--- If you really are in a hurry, mail me at svein-mob...@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - Picture Gallery: https://gallery.stillbilde.net/v/svein/ - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrUdB4ACgkQODUnwSLUlKQjtwCcDWA7BqDdwQ6w8zo0shNJDpJW shkAoKK1hN5QVrmg59J4lGV3V45ooiPj =nUay -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
On Tue, 13 Oct 2009, Ivan Voras wrote: Thomas Backman wrote: I'm copying this over from the freebsd-performance list, as I'm looking for a few more opinions - not on the problems *I* am having, but rather to check whether the problem is universal or not, and if not, find a possible common factor. In other words: I want to hear about your experiences, *good or bad*! Here's the original thread (not from the beginning, though): http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html Long story short, my version: when the disk is stressed hard enough, console IO becomes COMPLETELY unbearable. 10+ seconds to switch between windows in screen(1), running (or even typing) simple commands, etc. This happens both via SSH and the serial console. Hmm, this looks familiar - I've noticed it before on the physical (VGA) console and I notice it all the time under VMWare. It sort of looks like disk IO really blocks network IO in this case - I use the VMs over ssh. Real hardware and virtual hardware have vastly different performance properties, so I'd be careful not to assume that the issue described by the original reporter and the issue you're experiencing are the same. In our kernel, low level network protocols will essentially always take precedence over disk I/O activity. So on face value "disk IO really blocks network IO" is highly unlikely. There are two much more likely possibilities: (1) poor VM implementation causes the virtual CPU to be suspended behind synchronous host OS I/O or (2) the network stack is running fine but the interactive user application is getting I/O or locks scheduled behind a bulk process. A useful diagnostic here is to compare the behavior of three kinds of network latency tests: (1) ping from the host OS to the guest OS (2) netperf TCP_RR from the host OS to the guest OS (3) ssh interactive latency If (1) is highly variable during I/O, it's almost certainly a property of the VM technology you're using, and there's nought to be done about it in the guest OS. If (2) but not (1) is highly variable, it may well be a scheduling issue, although under high memory pressure you couldn't rule out paging out of netserver pages/etc causing latency. If (3) but not (1) or (2) is highly variable, it's most likely an I/O scheduling issue, perhaps caused by priority inversion on lockmgr locks on a vnode, disk I/O scheduling leading to starvation, etc. Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Spinlock called when not threaded
Hello, while compiling seamonkey 2.0 rc1 (source tbz from seamonkey website) on freebsd 8.0 rc1 I'm getting this error: Fatal error 'Spinlock called when not threaded.' at line 78 in file /usr/src/lib/libthr/thread/thr_spinlock.c (errno = 2) Abort trap (core dumped) gmake[5]: *** [/tmp/seamonkey/comm-central/mozilla/dist/lib/libsoftokn3.chk] Error 134 gmake[5]: Leaving directory `/tmp/seamonkey/comm-central/mozilla/security/nss/cmd/shlibsign' gmake[4]: *** [libs] Error 2 gmake[4]: Leaving directory `/tmp/seamonkey/comm-central/mozilla/security/manager' gmake[3]: *** [libs_tier_toolkit] Error 2 gmake[3]: Leaving directory `/tmp/seamonkey/comm-central/mozilla' gmake[2]: *** [tier_toolkit] Error 2 gmake[2]: Leaving directory `/tmp/seamonkey/comm-central/mozilla' gmake[1]: *** [default] Error 2 gmake[1]: Leaving directory `/tmp/seamonkey/comm-central/mozilla' gmake: *** [default] Error 2 I'm using following configure arguments: --enable-application=suite --disable-ogg --disable-wave Any ideas how to fix this problem? Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
2009/10/13 Robert Watson : > > On Tue, 13 Oct 2009, Ivan Voras wrote: > >> Thomas Backman wrote: >>> >>> I'm copying this over from the freebsd-performance list, as I'm looking >>> for a few more opinions - not on the problems *I* am having, but rather to >>> check whether the problem is universal or not, and if not, find a possible >>> common factor. In other words: I want to hear about your experiences, *good >>> or bad*! >>> >>> Here's the original thread (not from the beginning, though): >>> http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html >>> >>> Long story short, my version: when the disk is stressed hard enough, >>> console IO becomes COMPLETELY unbearable. 10+ seconds to switch between >>> windows in screen(1), running (or even typing) simple commands, etc. This >>> happens both via SSH and the serial console. >> >> Hmm, this looks familiar - I've noticed it before on the physical (VGA) >> console and I notice it all the time under VMWare. It sort of looks like >> disk IO really blocks network IO in this case - I use the VMs over ssh. > > Real hardware and virtual hardware have vastly different performance > properties, so I'd be careful not to assume that the issue described by the > original reporter and the issue you're experiencing are the same. In our > kernel, low level network protocols will essentially always take precedence > over disk I/O activity. So on face value "disk IO really blocks network IO" > is highly unlikely. Yes, I agree for both reasons and that is why I wasn't complaining until encountering this thread. > There are two much more likely possibilities: (1) poor VM implementation > causes the virtual CPU to be suspended behind synchronous host OS I/O or (2) > the network stack is running fine but the interactive user application is > getting I/O or locks scheduled behind a bulk process. > > A useful diagnostic here is to compare the behavior of three kinds of > network latency tests: > > (1) ping from the host OS to the guest OS > (2) netperf TCP_RR from the host OS to the guest OS > (3) ssh interactive latency > > If (1) is highly variable during I/O, it's almost certainly a property of > the VM technology you're using, and there's nought to be done about it in > the guest OS. Here's an example of a ping session with 0.1s resolution during a few seconds-stall in ssh: 64 bytes from 161.53.72.188: icmp_seq=1576 ttl=64 time=0.383 ms 64 bytes from 161.53.72.188: icmp_seq=1577 ttl=64 time=0.405 ms 64 bytes from 161.53.72.188: icmp_seq=1578 ttl=64 time=0.360 ms 64 bytes from 161.53.72.188: icmp_seq=2304 ttl=64 time=4.194 ms 64 bytes from 161.53.72.188: icmp_seq=2305 ttl=64 time=0.454 ms 64 bytes from 161.53.72.188: icmp_seq=2306 ttl=64 time=0.376 ms note huge packet loss. It looks like it's VM fault or something like it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
On 13 Oct 2009, at 14:33, Ivan Voras wrote: If (1) is highly variable during I/O, it's almost certainly a property of the VM technology you're using, and there's nought to be done about it in the guest OS. Here's an example of a ping session with 0.1s resolution during a few seconds-stall in ssh: 64 bytes from 161.53.72.188: icmp_seq=1576 ttl=64 time=0.383 ms 64 bytes from 161.53.72.188: icmp_seq=1577 ttl=64 time=0.405 ms 64 bytes from 161.53.72.188: icmp_seq=1578 ttl=64 time=0.360 ms 64 bytes from 161.53.72.188: icmp_seq=2304 ttl=64 time=4.194 ms 64 bytes from 161.53.72.188: icmp_seq=2305 ttl=64 time=0.454 ms 64 bytes from 161.53.72.188: icmp_seq=2306 ttl=64 time=0.376 ms note huge packet loss. It looks like it's VM fault or something like it. It sounds like the VM is failing to execute the guest during certain types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go amiss to confirm that the VM really is suspending the guest at about the same time ICMP latency goes up. However, given the above I think I you can reasonable assume that the 4ms jump you're seeing there is due to global host OS/VM scheduling, and not FreeBSD scheduling. Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
Robert N. M. Watson wrote: On 13 Oct 2009, at 14:33, Ivan Voras wrote: If (1) is highly variable during I/O, it's almost certainly a property of the VM technology you're using, and there's nought to be done about it in the guest OS. Here's an example of a ping session with 0.1s resolution during a few seconds-stall in ssh: 64 bytes from 161.53.72.188: icmp_seq=1576 ttl=64 time=0.383 ms 64 bytes from 161.53.72.188: icmp_seq=1577 ttl=64 time=0.405 ms 64 bytes from 161.53.72.188: icmp_seq=1578 ttl=64 time=0.360 ms 64 bytes from 161.53.72.188: icmp_seq=2304 ttl=64 time=4.194 ms 64 bytes from 161.53.72.188: icmp_seq=2305 ttl=64 time=0.454 ms 64 bytes from 161.53.72.188: icmp_seq=2306 ttl=64 time=0.376 ms note huge packet loss. It looks like it's VM fault or something like it. It sounds like the VM is failing to execute the guest during certain types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go amiss to confirm that the VM really is suspending the guest at about the same time ICMP latency goes up. However, given the above I think I you can reasonable assume that the 4ms jump you're seeing there is due to global host OS/VM scheduling, and not FreeBSD scheduling. Btw. it's not a "4 ms jump" - there are 726 lost packets in between. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
Robert N. M. Watson wrote: On 13 Oct 2009, at 14:33, Ivan Voras wrote: If (1) is highly variable during I/O, it's almost certainly a property of the VM technology you're using, and there's nought to be done about it in the guest OS. Here's an example of a ping session with 0.1s resolution during a few seconds-stall in ssh: 64 bytes from 161.53.72.188: icmp_seq=1576 ttl=64 time=0.383 ms 64 bytes from 161.53.72.188: icmp_seq=1577 ttl=64 time=0.405 ms 64 bytes from 161.53.72.188: icmp_seq=1578 ttl=64 time=0.360 ms 64 bytes from 161.53.72.188: icmp_seq=2304 ttl=64 time=4.194 ms 64 bytes from 161.53.72.188: icmp_seq=2305 ttl=64 time=0.454 ms 64 bytes from 161.53.72.188: icmp_seq=2306 ttl=64 time=0.376 ms note huge packet loss. It looks like it's VM fault or something like it. It sounds like the VM is failing to execute the guest during certain types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go amiss to confirm that the VM really is suspending the guest It's VMWare ESXi underneath, which is *Officially Not Linux* though some ducks may disagree - anyway, I suspect tracing the host in this way is next to impossible without some kind of diamondium-level contract. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 6.2-RELEASE does not use second CPU on pentium D
On Wednesday 25 April 2007 4:47:48 am Alex Povolotsky wrote: > Hello! > > I have a Pentium D box, running 6.2-RELEASE. In dmesg, I see CPU#1 > launched, but I never see any process running on it, and mptable shows > > cluster-one# mptable -verbose > > === > > MPTable > > looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009e800 > searching CMOS 'top of mem' @ 0x0009e400 (633K) > searching default 'top of mem' @ 0x0009fc00 (639K) > searching BIOS @ 0x000f > > MP FPS found in BIOS @ physical addr: 0x000fe200 > > --- > > MP Floating Pointer Structure: > > location: BIOS > physical address: 0x000fe200 > signature:'_MP_' > length: 16 bytes > version: 1.4 > checksum: 0x9f > mode: Virtual Wire > > --- > > MP Config Table Header: > > physical address: 0x000fe210 > signature:'PCMP' > base table length:64 > version: 1.4 > checksum: 0x7f > OEM ID: '' > Product ID: '' > OEM table pointer:0x > OEM table size: 0 > entry count: 1 > local APIC address: 0xfee0 > extended table length:0 > extended table checksum: 0 > > --- > > MP Config Base Table Entries: > > -- > Processors: APIC ID Version State Family Model Step > Flags > 0 0x14BSP, usable 15 6 4 > 0xbfebfbff > > === > > while in dmesg > > Copyright (c) 1992-2007 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 6.2-RELEASE-p3 #2: Thu Apr 19 00:19:54 MSD 2007 > tark...@cluster-one.zinester.com:/usr/obj/usr/src/sys/P4D > WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant > WARNING: MPSAFE network stack disabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2808.41-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf64 Stepping = 4 > > Features=0xbfebfbff ,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0xe49d,> > AMD Features=0x2010 > AMD Features2=0x1 > real memory = 1046757376 (998 MB) > avail memory = 1015095296 (968 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > > [...] > SMP: AP CPU #1 Launched! > > The kernel is, of course, SMP. > > What can I do, where can I search for solution? > > Second core IS enabled in BIOS > cluster-one# sysctl hw | grep cpu > hw.ncpu: 2 > hw.acpi.cpu.cx_supported: C1/0 > hw.acpi.cpu.cx_lowest: C1 > hw.acpi.cpu.cx_usage: 100.00% > cluster-one# sysctl machdep | grep cpu > machdep.cpu_idle_hlt: 1 > machdep.hlt_cpus: 2 > machdep.hlt_logical_cpus: 0 > machdep.logical_cpus_mask: 2 > > so second CPU is halted, attempt to start it with sysctl does not help > Alex. What does 'sysctl machdep | grep hyper' show? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
On Tue, 13 Oct 2009, Ivan Voras wrote: Robert N. M. Watson wrote: On 13 Oct 2009, at 14:33, Ivan Voras wrote: If (1) is highly variable during I/O, it's almost certainly a property of the VM technology you're using, and there's nought to be done about it in the guest OS. Here's an example of a ping session with 0.1s resolution during a few seconds-stall in ssh: 64 bytes from 161.53.72.188: icmp_seq=1576 ttl=64 time=0.383 ms 64 bytes from 161.53.72.188: icmp_seq=1577 ttl=64 time=0.405 ms 64 bytes from 161.53.72.188: icmp_seq=1578 ttl=64 time=0.360 ms 64 bytes from 161.53.72.188: icmp_seq=2304 ttl=64 time=4.194 ms 64 bytes from 161.53.72.188: icmp_seq=2305 ttl=64 time=0.454 ms 64 bytes from 161.53.72.188: icmp_seq=2306 ttl=64 time=0.376 ms note huge packet loss. It looks like it's VM fault or something like it. It sounds like the VM is failing to execute the guest during certain types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go amiss to confirm that the VM really is suspending the guest It's VMWare ESXi underneath, which is *Officially Not Linux* though some ducks may disagree - anyway, I suspect tracing the host in this way is next to impossible without some kind of diamondium-level contract. What information do you need? I have a platinum VMWare contract. What version of ESXi? LER ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD Status Reports April - September, 2009
On Mon, Oct 12, 2009 at 8:55 PM, Eugene Grosbein wrote: > On Sun, Oct 11, 2009 at 05:54:29PM +, Daniel Gerzo wrote: > > FreeBSD/ZFS > > > >Contact: Pawel Dawidek > > > >We believe that the ZFS file system is now production-ready in FreeBSD > >8.0. Most (if not all) reported bugs were fixed and ZFS is no longer > >tagged as experimental. There is also ongoing work in Perforce to > bring > >the latest ZFS version (v19) to FreeBSD. > > That's great news. However, my experience says me not place dot-zero > relese under business-critical tasks and load. > > What about status of ZFS in 7.2? Does 7.2 contain the same ZFS code? > > 7.2-RELEASE includes ZFSv6. 7-STABLE (after the release of 7.2) includes ZFSv13. 8.0-RELEASE will include ZFSv13. IOW, 8.0 and 7.3 will have roughly the same ZFS code, although I believe the plan is to leave it marked as "experimental" in 7.x and only remove that warning in 8.x. -- Freddie Cash fjwc...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
2009/10/13 Larry Rosenman : note huge packet loss. It looks like it's VM fault or something like it. >>> >>> It sounds like the VM is failing to execute the guest during certain >>> types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go >>> amiss to confirm that the VM really is suspending the guest >> >> It's VMWare ESXi underneath, which is *Officially Not Linux* though some >> ducks may disagree - anyway, I suspect tracing the host in this way is next >> to impossible without some kind of diamondium-level contract. >> > What information do you need? I have a platinum VMWare contract. > > What version of ESXi? Hi, It is ESXi 3.5 - but if the problem is really in ESXi I presume anyone could reproduce it. My setup is nothing special - Xeon 5405, 8 GB RAM, SATA drives on ICH9. As for what data is needed, it depends on what you can get - from this discussion thread it looks like it would be enough to verify that disk IO doesn't leave VM processes waiting (i.e. that disk IO doesn't interfere with CPU-bound or idle virtual machines). Though now when I think of it - doesn't Linux ATA driver poll IO in some funky way, expecting to get lower latency that way? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
On Tue, 13 Oct 2009, Ivan Voras wrote: 2009/10/13 Larry Rosenman : note huge packet loss. It looks like it's VM fault or something like it. It sounds like the VM is failing to execute the guest during certain types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go amiss to confirm that the VM really is suspending the guest It's VMWare ESXi underneath, which is *Officially Not Linux* though some ducks may disagree - anyway, I suspect tracing the host in this way is next to impossible without some kind of diamondium-level contract. What information do you need? I have a platinum VMWare contract. What version of ESXi? Hi, It is ESXi 3.5 - but if the problem is really in ESXi I presume anyone could reproduce it. My setup is nothing special - Xeon 5405, 8 GB RAM, SATA drives on ICH9. As for what data is needed, it depends on what you can get - from this discussion thread it looks like it would be enough to verify that disk IO doesn't leave VM processes waiting (i.e. that disk IO doesn't interfere with CPU-bound or idle virtual machines). Though now when I think of it - doesn't Linux ATA driver poll IO in some funky way, expecting to get lower latency that way? Have you looked at the information available via the performance tab(s) in the client pointing at the ESXi server? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
re: 8.0 RC1 cd boot problem [btx/bios]
Played with this some more. Both the add in cards have their own bios. Their bios can't be disabled. Their raid is not configured so they act as dumb paddles. All bios are up to date. Referring to the below map... - If I swap the position of the cards it won't boot from cd. - If I swap the position of the cards and yank the drives off the 20269, its bios doesn't load and the system boots from cd. - Of course removing the 20269 boots from cd. Booting off the hard drive works fine in all combinations. So I'm pretty sure this is a BTX loader problem involving bios scans? BTX stops right after detecting the ich4 devices... bios cd is cd0 bios drive a: is disk0 bios drive c: is disk1 _ This config boots fine from cd and is now in use: mobo: dell bluford onboard pata: pri m: udma66 s: - sec m: cdr s: dvdrw pci nearest cpu: 1: drive 2: - 3: drive 4: - 5: - 6: - 7: - 8: - pci next nearest cpu: pri m: udma100 s: - sec m: - s: - Prior message-id: d2e731a10909301617l1bad5dcbi7e5681e17fde1a04 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
8.0 RC1 cd sysinstall install.cfg fd0 missing
I'm not seeing the menu option to load an install.cfg from the floppy anymore. The kernel does detect fdc0 and fd0. Regression? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
