On 2012/07/01 00:27, JD wrote:

On 07/01/2012 12:39 AM, jdow wrote:

On 2012/06/30 20:55, JD wrote:

On 06/30/2012 08:17 PM, Tom Horsley wrote:

Every time I start firefox after recent updates, top
shows it periodically taking up to 50% of the CPU
even if I'm just looking at a simple page of plain
html (no scripts, not even any images) on my local
web server.

This is ff 13.0.1 on x86_64 fedora 17.

Any clues? Anyone see anything similar?

50% !!!???
Huh.... consider yourself LUCKY!
On my old unicore amd64 (3.7GHz "equivalent /smirk/)
it escalates sometimes to 95% of cpu.


top tends to be confusing that way.
Note this line from my machine at a time it said FF was at 87.8%:
Cpu(s): 13.6%us, 33.7%sy, 0.0%ni, 52.5%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st

That was really 87.4% of the 13.6% user time that was consumed.

{^_^}

in <kernel source>/include/linux/taskstats.h
The comment reads:
/* cpu "virtual" running time
* Uses time intervals seen by the kernel i.e. no adjustment
* for kernel's involuntary waits due to virtualization.
* Value is cumulative, in nanoseconds, without a corresponding count
* and wraps around to zero silently on overflow
*/


Hm, please define virtualization in this context. I am running a flat
SL6.2 system with no virtual machine in the box at all.

Note that you get 100% if you add up all the values on that line.
There is no way you can get 87.4% cpu usage out of those numbers
without claiming some of the idle time is used by firefox without
attribution.

{^_^}
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

On 06/30/2012 10:13 PM, David Timms wrote:
> On 01/07/12 13:58, Tim wrote:
>> On Sat, 2012-06-30 at 22:17 -0400, Tom Horsley wrote:
>> 4. Bookmarked RSS feeds that it's going to visit and fetch updates
>> from.
>> 5. Even just a large collection of static page bookmarks seem to
>> bog it down.
>
> It would be interesting to see what net traffic is requested/received
> during startup. Stopping all other net apps (updates, etc), starting
> wireshark capturing, and then starting firefox, could give a good clue.

I think maybe this is caused by the leap second issue. Try rebooting
and see if it goes away. See
http://www.google.com/search?ix=acb&sourceid=chrome&client=ubuntu&channe l=cs&ie=UTF-8&q=leap+second+linux

Nataraj

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

On 01.07.2012, Tom Horsley wrote:

> It is sitting there using between 50 and 100% of the
> CPU virtually all the time :-(.

I did watch closely over a period of 15 min. now, and Firefox
showed totally normal behaviour without any CPU-spikes.

[root@wildsau ~]# rpm -qa | grep -i "firefox"
firefox-13.0.1-1.fc17.x86_64

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Tim:
>> General things that cause Firefox to chew through the CPU, when you
>> don't expect it to:
>>
>> 2. A long page visit history.

JD:
> The storage for this list is like a drop in the bucket compared
> to the storage for a large web page cache.

The same answer applies for the keeping of the list of what you've
downloaded, the cache, the visit history, et cetera: It's not the space
used, but the processing of lots of little files, comparing the data
kept in the database about the files, and working out which ones should
be left or deleted.

There seems to be something extremely inefficient about how it does
that. For instance, people noticed a big difference when the bookmarks
changed from being a flat HTML file to a database system.

>> 4. Bookmarked RSS feeds that it's going to visit and fetch updates
>> from.

> I have none of those!

I can't recall whether there were any pre-bookmarked with the default
installation.

--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686

Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.



--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

On Sun, 01 Jul 2012 00:53:11 -0700
Nataraj wrote:

> I think maybe this is caused by the leap second issue. Try rebooting
> and see if it goes away. See
> http://www.google.com/search?ix=acb&sourceid=chrome&client=ubuntu&channe l=cs&ie=UTF-8&q=leap+second+linux

Thanks for the pointer, that may have been it!

I don't understand the complicated interactions that
make a leap second confuse a computer more than the
RTC running slow confuses it, but this issue did indeed
go away after a reboot (and I'm pretty sure I didn't
see the problem till after midnight UTC which is when
the leap second would have happened).

They really ought to switch to a new version of NTP
protocol that is just like the old one, but works from
TAI and sends a database of leap second info around as
well so computers can translate TAI into UTC.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

On Sun, 2012-07-01 at 08:47 -0400, Tom Horsley wrote:
> I don't understand the complicated interactions that
> make a leap second confuse a computer more than the
> RTC running slow confuses it,

It's a smallish problem to tell the computer that the time is wrong, and
to reset the clock to another time, whether forwards or backwards.
Sometimes that's handled without major issues, sometimes it does have
repercussions. But it's something that computing has dealt with for
quite a long time.

Leap seconds, on the other hand, means that for one particular moment in
time, a minute isn't 60 seconds long. That's not an event that a lot of
people calculating dates and times have ever considered, and some things
handle that very badly, such as crashing.

For some situations, you can simply reset and start again, after the
time change. But how do you handle things that happen during that extra
second with software that has no concept of a 61 second minute? When
something happened on that date, how do you represent it if you cannot
say a date of 2012-06-30 00:00'60"? (Remember the seconds count from
zero to 59, not 1 to 60.) Do you call it 00:01'00" and have two,
different, 1 minutes past midnight?

And then there's the converse... If we have a year where they have to
deduct seconds, how do represent something that happened during the,
now, removed seconds, but recorded by the, then, still counting clock?

And, in either case, when you use a system that counts the number of
seconds since a certain epoch, to show you the date and time of
something, do you show the right time and date when there's a miscount
in the middle of it? You need a correction table of dates it has to
modify, and I don't think anybody's ever produced a clock program that
does that.

On that note, I've often wondered how systems that look at a file's GMT
datestamp and tell you that time translated into your local time, cope
with datestamps from a long way away, when timezone rules keep on
changing. We could maintain a table of rules so that the computer can
correctly give you the times during summer of 1976, but how far back is
the table maintained? Sure, you won't have to read back a timestamp
from the year 1827, but there could be a reason to calculate something
from a known date and time, that's not to do with a computer file. And
there's the converse function. If you had to calculate a date and time
in 2023, would you know what rules would be applied during that year to
do it correctly?

--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686

Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.



--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

On 1 July 2012 15:20, Tim <ignored_mailbox@yahoo.com.au> wrote:

> On that note, I've often wondered how systems that look at a file's GMT
> datestamp and tell you that time translated into your local time, cope
> with datestamps from a long way away, when timezone rules keep on
> changing. We could maintain a table of rules so that the computer can
> correctly give you the times during summer of 1976, but how far back is
> the table maintained? Sure, you won't have to read back a timestamp
> from the year 1827, but there could be a reason to calculate something
> from a known date and time, that's not to do with a computer file. And
> there's the converse function. If you had to calculate a date and time
> in 2023, would you know what rules would be applied during that year to
> do it correctly?

Of course it's not a particularly new problem, historians have had to
contend with missing (or extra) days and years for a long time.

--
imalone
http://ibmalone.blogspot.co.uk
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

On Sun, 1 Jul 2012 21:04:27 +0100
Ian Malone <ibmalone@gmail.com> wrote:

> On 1 July 2012 15:20, Tim <ignored_mailbox@yahoo.com.au> wrote:
>
> > On that note, I've often wondered how systems that look at a file's GMT
> > datestamp and tell you that time translated into your local time, cope
> > with datestamps from a long way away, when timezone rules keep on
> > changing.

They don't.

Fortunately most people are not worried about the exact day the Tynwald
of the Isle of Man adopted GMT and other such trivia

Until relatively recently we also had madness like the UK daylight
savings change being a human selected date, and it did get moved a couple
of times to avoid clashing with major events.

For the future 2800 is where the fun really gets going. Is it a leap year
- depends which church calendar is used 8)

The glibc rules are however pretty good for all times that matter and
there are time geeks who love this kind of detail.

Alan
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

On Mon, 2 Jul 2012 00:57:05 +0100
Alan Cox wrote:

> The glibc rules are however pretty good for all times that matter and
> there are time geeks who love this kind of detail.

And the tzdata rpm shows as size:1837780 so there is a fair
amount of data being used by the libraries to try and
interpret time correctly.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

On 2 July 2012 00:57, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

>> On 1 July 2012 15:20, Tim <ignored_mailbox@yahoo.com.au> wrote:
>>
>> > On that note, I've often wondered how systems that look at a file's GMT
>> > datestamp and tell you that time translated into your local time, cope
>> > with datestamps from a long way away, when timezone rules keep on
>> > changing.
>
> They don't.
>
> Fortunately most people are not worried about the exact day the Tynwald
> of the Isle of Man adopted GMT and other such trivia
>
> Until relatively recently we also had madness like the UK daylight
> savings change being a human selected date, and it did get moved a couple
> of times to avoid clashing with major events.
>
> For the future 2800 is where the fun really gets going. Is it a leap year
> - depends which church calendar is used 8)
>

Some people make their own fun: http://en.wikipedia.org/wiki/Ethiopian_calendar

--
imalone
http://ibmalone.blogspot.co.uk
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org