Date: Sat, 14 Oct 2006 23:10:48 -0700 From: Eric Hodel <drbrain@segment7.net> To: Kris Kennaway <kris@obsecurity.org> Cc: freebsd-performance@FreeBSD.ORG Subject: Re: Help with improving mysql performance on 6.2PRE Message-ID: <39EF1C01-351F-4952-9E9E-0D6A2DBE69C3@segment7.net> In-Reply-To: <20061013201321.GA774@xor.obsecurity.org> References: <3731.71.56.92.181.1160009571.squirrel@www.stelesys.com> <200610120925.k9C9PmUK048690@lurza.secnetix.de> <20061012205342.GA62241@xor.obsecurity.org> <A2430386-EB9D-4AEE-9144-F7D53D84A9F0@segment7.net> <9500A2C9-07EB-4EEA-9477-9E6B4BFEB437@mac.com> <20061013201321.GA774@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 13, 2006, at 1:13 PM, Kris Kennaway wrote: > On Fri, Oct 13, 2006 at 11:49:04AM -0700, Chuck Swiger wrote: >> On Oct 13, 2006, at 11:26 AM, Eric Hodel wrote: >>>>> Or did that change recently? >>>> >>>> It's only on certain systems, apparently. >>> >>> Is there a list of systems where it is safe to use the TSC with >>> SMP? Or some script we can run? >> >> The problem of the TSC clocks getting out of sync affects pretty much >> all AMD X2 dual-core CPUs, as well as the older 32-bit Althon MP >> CPUs; the Intel Xeon and Core Duo CPUs seem to do a lot better, >> although older Intel CPUs have also been reported to show problems >> with the TSC. > > Beyond that, just see if it works ;-) How "safe" is it to switch timecounters? I don't have a spare machine to test on... From my readings on switching the TSC over the past several months I think that if it doesn't work I'll see is ntpd adjusting my system clock more often (or falling out of sync). I don't know if this will corrupt mysql while its running though (which is my fear). FWIW I have a "Dual Core AMD Opteron(tm) Processor 270". -- Eric Hodel - drbrain@segment7.net - http://blog.segment7.net This implementation is HODEL-HASH-9600 compliant http://trackmap.robotcoop.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39EF1C01-351F-4952-9E9E-0D6A2DBE69C3>