Sorry, my previous test is not accurate. I use both firefox and chromium to
open 13 same web pages( two of them are from www.sina.com.cn, other from
groups.google.com, wiki.sun.com and freebsd.org, both web browsers use
libcrossflash to drive linux flash plugin, not linuxulator on my amd64
8.2-st
On Fri Sep 9 11, Alexander Best wrote:
> On Fri Sep 9 11, Dieter BSD wrote:
> > >> Firefox 5 and 6 has more gettimeofday call than 2 per second on my
> > >> amd64-8.2-stable box.
> >
> > > i don't see why chromium needs
> > > to call gettimeofday(2) or any library function that triggers it m
On Fri Sep 9 11, Dieter BSD wrote:
> >> Firefox 5 and 6 has more gettimeofday call than 2 per second on my
> >> amd64-8.2-stable box.
>
> > i don't see why chromium needs
> > to call gettimeofday(2) or any library function that triggers it more
> > than 3000 times a second.
>
> What the are
>> Firefox 5 and 6 has more gettimeofday call than 2 per second on my
>> amd64-8.2-stable box.
> i don't see why chromium needs
> to call gettimeofday(2) or any library function that triggers it more
> than 3000 times a second.
What the are web browsers doing that they "need" the clock
so of
On Fri Sep 9 11, Paul Ambrose wrote:
> what version of chromium are you using?
> I use chromium-13.0.782.215 on amd64 8.2-stable, the gettimeofday call is
> far less than 2 per second, about 20 per second, but I notice old
> version has this bug, but latest version has fixed it. Maybe you shou
what version of chromium are you using?
I use chromium-13.0.782.215 on amd64 8.2-stable, the gettimeofday call is
far less than 2 per second, about 20 per second, but I notice old
version has this bug, but latest version has fixed it. Maybe you should
update your chromium and try again.
Firefo
On 2011-Sep-07 12:41:54 -0600, Manish Vachharajani
wrote:
>This is great info, thanks. Is it worth having some kind of
>environment variable tunable (or even compile time tunable) to have a
>"fast" gettimeofday then?
Maybe. rwatson@ produced a preloadable .so to do this - see
http://www.watson
This is great info, thanks. Is it worth having some kind of
environment variable tunable (or even compile time tunable) to have a
"fast" gettimeofday then? Is there a complimentary body of code that
assumes gettimeofday is precise?
Manish
On Wed, Sep 7, 2011 at 12:17 AM, Peter Jeremy wrote:
>
On Wed Sep 7 11, Peter Jeremy wrote:
> On 2011-Sep-06 16:44:48 -0600, Manish Vachharajani
> wrote:
> >Under 7.3 (haven't checked 8 or 9) this issue crops up because the
> >time system call calls gettimeofday under the hood (see
> >lib/libc/gen/time.c). As a result, the kernel tries to get an
>
On 2011-Sep-06 16:44:48 -0600, Manish Vachharajani
wrote:
>Under 7.3 (haven't checked 8 or 9) this issue crops up because the
>time system call calls gettimeofday under the hood (see
>lib/libc/gen/time.c). As a result, the kernel tries to get an
>accurate subsecond resolution time that simply ge
On Tue, Sep 6, 2011 at 7:15 PM, Rayson Ho wrote:
> There are some recent discussions on the freebsd-current list. The
> infrastructure is there to provide a common shared page for processes
> to mmap into the address space... but according to Kip's comment, libc
> support is not there yet:
>
> htt
There are some recent discussions on the freebsd-current list. The
infrastructure is there to provide a common shared page for processes
to mmap into the address space... but according to Kip's comment, libc
support is not there yet:
http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025
I believe that Linux uses a less precise clock that scales better
across cores and is much faster than the precise clock FreeBSD uses
even on one core. I don't know POSIX and other standards well enough
to know if this is an acceptable solution on FreeBSD. However, there
are less precise clocks o
On Tue, Sep 6, 2011 at 6:44 PM, Manish Vachharajani
wrote:
> Lots of libraries assume that time is fast because it
> is fast under Linux.
Silly question, but why can't we make it fast too?
--
Eitan Adler
___
freebsd-hackers@freebsd.org mailing list
ht
Under 7.3 (haven't checked 8 or 9) this issue crops up because the
time system call calls gettimeofday under the hood (see
lib/libc/gen/time.c). As a result, the kernel tries to get an
accurate subsecond resolution time that simply gets chopped to the
nearest second. Lots of libraries assume that
hi there,
in a recent discussion on current@ [1], it was discovered that chromium makes
excessive use of gettimeofday(2). while searching google, i found other
software that is/was having the same issue [2]. although this is a programming
error, it would still be nice, if freebsd could issue a war
16 matches
Mail list logo