On Fri, Nov 28, 2003 at 08:22:30PM -0500, Tom Lane wrote:
>
> One variable I didn't think to ask about is whether you are running
> NTP. In my experience an ntp daemon that has achieved lock will never
> step the clock back by even 1 usec (it's supposed to use much more
> subtle methods than that
I ran Tom's second script for two hours on an AMD Duron on Linux 2.4.18.
No problems.
Gavin
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> What kinda processor are you running?
>From dmesg:
Timecounter "i8254" frequency 1193182 Hz
CPU: Intel Celeron (631.29-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x686 Stepping = 6
Features=0x383f9ff
-Neil
--
On Fri, 28 Nov 2003, Neil Conway wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > On Fri, 28 Nov 2003, Neil Conway wrote:
> >> $ uname -a
> >> FreeBSD home.samurai.com 4.9-RELEASE [...]
> >
> > what is kern.timecounter.method set to?
>
> $ sysctl kern.timecounter.method
> kern.timecount
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Fri, 28 Nov 2003, Neil Conway wrote:
>> $ uname -a
>> FreeBSD home.samurai.com 4.9-RELEASE [...]
>
> what is kern.timecounter.method set to?
$ sysctl kern.timecounter.method
kern.timecounter.method: 0
FYI, I ran the test program for another 30
On Fri, 28 Nov 2003, Neil Conway wrote:
> $ uname -a
> FreeBSD home.samurai.com 4.9-RELEASE FreeBSD 4.9-RELEASE #0: Thu Nov 6 21:25:41 EST
> 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAMURAI i386
>
> This machine produces no output after running the test app for about
> 30 minutes.
what
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>> 15 minutes of error is acceptable?
> Apparently *shrug* That was just the first answer back though, so we'll
> see what happens ...
BTW, it seems from this thread that the BIND guys have seen even more
bogus behavior than this from gettimeofday()
On Fri, 28 Nov 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Just got my first response on this, and, in fact, this is 'acceptable
> > behaviour' to a certain extent ... there is a kernel tuneable called
> > kern.timecounter.method, that is either 1 or 0:
>
> 15 minute
On Fri, 28 Nov 2003, Marc G. Fournier wrote:
> On Fri, 28 Nov 2003, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > > I'm suspecting that the issue is amplified by load on the server itself
> >
> > That would fit right in with my idea that the failure occurs when the
> > p
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Just got my first response on this, and, in fact, this is 'acceptable
> behaviour' to a certain extent ... there is a kernel tuneable called
> kern.timecounter.method, that is either 1 or 0:
15 minutes of error is acceptable?
On Fri, 28 Nov 2003, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
>
> > $ time ./a.out 2>&1 | tee a.txt
> > out of order tv_sec: 1070066197 273140, prev 1070066195 721010
> > out of order tv_usec: 1070066197 273140, prev 1070066195 721010
> > out of order tv_sec: 1070067322 11
On Fri, 28 Nov 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > I'm suspecting that the issue is amplified by load on the server itself
>
> That would fit right in with my idea that the failure occurs when the
> process loses its timeslice partway through gettimeofday().
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> I'm suspecting that the issue is amplified by load on the server itself
That would fit right in with my idea that the failure occurs when the
process loses its timeslice partway through gettimeofday(). Heavier
load would presumably make it more lik
On Fri, 28 Nov 2003, Tom Lane wrote:
> Could it be a hardware problem on Marc's box? Or specific to some other
> aspect of that installation (Marc, is pgsql74.hub.org multi-CPU, for
> example?)
All the servers are SMP ... pgsql74 is on a Dual-Xeon ...
Marc G. Fournier Hub.Org Net
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> Ah, I have made a mistake. It's only a 2.2.18 kernal. Dual SMP P-III, perhaps
> that's the issue there.
Hm. I seem to recall there were still lots of SMP bugs in the 2.2.*
kernels.
> And on the FreeBSD system I've got this:
> $ time ./a.out 2>&1
On Fri, 28 Nov 2003, Darcy Buskermolen wrote:
> I've been running this code on a pair of FreeBSD (i386) boxen, for some time
> now, one of which is a 4.8-STABLE, the other is a 5.2-BETA.
>
> In 10 minutes of execution the 4.8 box has only shown the following:
>
> out of order tv_sec: 1070063393 11
On Fri, 28 Nov 2003, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > On Fri, 28 Nov 2003, Tom Lane wrote:
> >> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > On an Intel Linux 2.4.18 I get them quite often, 25 in 1'45", but they
> > are all just a microsecond.
> >>
> >> W
Tom Lane <[EMAIL PROTECTED]> writes:
> Whoa. Try the following test program.
I tried this on two uniprocessor x86 machines:
(1)
$ uname -a
Linux tokyo 2.6.0-test10 #3 Mon Nov 24 13:43:54 EST 2003 i686 GNU/Linux
This machine produces this output, after running the test app for
about 30 minutes:
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> On Fri, 28 Nov 2003, Tom Lane wrote:
>> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> On an Intel Linux 2.4.18 I get them quite often, 25 in 1'45", but they
> are all just a microsecond.
>>
>> What do you mean by "just a microsecond"?
> I mean i
Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> After 30+ minutes I'm now starting to see the same problems on my 5.2 testbed
> as well. I'm going to fire this test up on my FreeBSD 3.x and 2.x boxen and
> see if' it's there too. I can confirm that this not a SMP issue as that it's
> happeing on
On Fri, 28 Nov 2003, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > On an Intel Linux 2.4.18 I get them quite often, 25 in 1'45", but they
> > are all just a microsecond.
>
> What do you mean by "just a microsecond"?
I mean it's always a "out of order tv_usec..." line and t
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> On an Intel Linux 2.4.18 I get them quite often, 25 in 1'45", but they
> are all just a microsecond.
What do you mean by "just a microsecond"?
Attached is a tightened-up test program that will only complain if the
value of gettimeofday goes backwar
On November 28, 2003 04:19 pm, Tom Lane wrote:
> I said:
> > The failure is definitely quite repeatable on pgsql74.hub.org. I don't
> > see it on svr1.postgresql.org, though, which seems to be running almost
> > the same kernel.
>
> After looking more closely, I take that back: svr1 is failing too
On Fri, 28 Nov 2003, Tom Lane wrote:
> Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> > On November 28, 2003 12:33 pm, Tom Lane wrote:
> >> Whoa. Try the following test program. Then send it in to your friendly
> >> local BSD hackers
>
> > I've been running this code on a pair of FreeBSD
On November 28, 2003 12:33 pm, Tom Lane wrote:
> I said:
> > I'm wondering if there's an actual bug in gettimeofday() in this
> > platform, such that once in a while it returns a value that's off
> > a minute or so ...
>
> Whoa. Try the following test program. Then send it in to your friendly
> l
I said:
> The failure is definitely quite repeatable on pgsql74.hub.org. I don't
> see it on svr1.postgresql.org, though, which seems to be running almost
> the same kernel.
After looking more closely, I take that back: svr1 is failing too,
though not as often:
> uname -a
FreeBSD svr1.postgresql
Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> On November 28, 2003 12:33 pm, Tom Lane wrote:
>> Whoa. Try the following test program. Then send it in to your friendly
>> local BSD hackers
> I've been running this code on a pair of FreeBSD (i386) boxen, for some time
> now, one of which i
On November 28, 2003 12:33 pm, Tom Lane wrote:
> I said:
> > I'm wondering if there's an actual bug in gettimeofday() in this
> > platform, such that once in a while it returns a value that's off
> > a minute or so ...
>
> Whoa. Try the following test program. Then send it in to your friendly
> l
I said:
> I'm wondering if there's an actual bug in gettimeofday() in this
> platform, such that once in a while it returns a value that's off
> a minute or so ...
Whoa. Try the following test program. Then send it in to your friendly
local BSD hackers
> uname -a
FreeBSD pgsql74.hub.org 4.
29 matches
Mail list logo
