[olug] ubuntu slowing down

Matthew Will mwill at midlandsnetworksolution.com
Wed Oct 28 21:51:06 UTC 2009


I agree.  I have an old HP laptop that's an early P4.  I upgraded to 1gb
and even put in a 10k rpm hard drive.  For the most part it screams
pretty good.

I think facebook was mentioned earlier on this thread.  That's what I
primarily do on that laptop is fb and play mafia wars which is a
facebook game.

There are some posted tweaks for firefox to help speed up facebook and
some of it's apps.  I still find though the longer I am logged into
facebook it does crank hard on the cpu.  Ram is fine.  Periodically I
just close out firefox and go back in to refresh resources.  Sounds like
something you'd tell a windows user but it works for me.

Other apps running on the laptop do run well also.  So if its not
profile related or something else I'm sorry.  But ubuntu runs great on
my very early P4.

matthew will
 

 

-----Original Message-----
From: olug-bounces at olug.org [mailto:olug-bounces at olug.org] On Behalf Of
DYNATRON tech
Sent: Wednesday, October 28, 2009 4:37 PM
To: Rob.Townley at gmail.com; Omaha Linux User Group
Subject: Re: [olug] ubuntu slowing down

rob, i like your suggestion (create a new user profile).

ubuntu in full shoud not have problems on anything 1GHZ+512MB or better.
it
may have a lag here or there, but it's got chops for older boxes. i have
it
running a LAMP server with  P3-1GHZ+512MB and 5 NIC's. it runs fine.

however, i've seen questionable web-browsing tactics bring an ubuntu
system
to it's knees several times.
as far as stability, firefox (or maybe peoples habits?) seems to be the
weakest link in ubuntu.

most cases, creating a new user profile, and removing the old can make
it
scream on the web again (make sure you add your new profile to the
administrative group before deleting the old).

if a new profile doesn't work for you, the new ubuntu comes out this
week.
give it a shot. they seem to be consistently better with every release.
you
can also do some packet sniffing to see if you've become saturated
somewhere.




as far as the bloat comment, i think in general it's a
stretch....although
the kernel does suffer from some bloat...it's nothing compared to the NT
kernel/OS. that is what i call bloat.
patch upon patch upon patch upon....(you get the idea).
it's also a small part of planned obsolescence...you have to keep
throwing
money down for the latest gear. that's what keeps industry bloated.






On Mon, Oct 26, 2009 at 8:57 PM, Rob Townley <rob.townley at gmail.com>
wrote:

> On Mon, Oct 26, 2009 at 8:16 PM, G. Joseph Rosas <joe.rosas at gmail.com>
> wrote:
> > Has anyone tried Lubuntu yet?
> >
> > http://en.wikipedia.org/wiki/Lubuntu
> >
> >
> >>
> > _______________________________________________
> > OLUG mailing list
> > OLUG at olug.org
> > https://lists.olug.org/mailman/listinfo/olug
> >
>
> i would create a new user, reboot, and login with that user.  If it
> persists, fire up ethereal.  Do you have a proxy?
>
> In the IRC ##networking channel, there is a "slow browsing" discussion
> right now.  You may want to post a packet capture ##networking and see
> what they say.  In there case, a proxy or router may have been
> resetting the tcp windows scaling such that http requests  were being
> sent in chunks of 24 bytes -- that would be slow, way slow.    The
> article mentioned is  from 2004 but shows how to set your tcp window
> size.
>
> heftig> i'm trying to debug a case of "slow browsing" and it seems the
> http answer is transferred in many chunks of 24 bytes. what could
> cause this?
>        <Tramp> heftig: MTU? Window Scaling?
>        <heftig>        Tramp: pmtu 1200, window 6272
>        <Tramp> yeah, well. Window Scaling problems (as far as I
remember)
> arise from the opposite side misinterpreting the "scaling factor"
> (2^^n) as actual window size (n). So to check if that's the problem
> one would have to disable window-scaling on one's own side
>        <heftig>        hmm
>        <Tramp> or maybe pastebin the tcpdump of a "slow request"
(first
> dozen packets or so)
>        <heftig>        Tramp: one stream: http://omploader.org/vMm1xdg
>        <heftig>        seems deactivating the scaling removed the
problem
> >_>
>        <heftig>        could a transparent proxy with a buggy tcp
> implementation be
> the cause?
>        <Tramp> heftig: thought so. After the initial handshake your
host
> 10.110.83.247 reduced the window to 54
>        <Tramp> what OS is that box running?
>        <heftig>        linux
>        <Tramp> Kernel Version?
>        <heftig>        2.6.31
>        <Tramp> hmm.
>        <Tramp> well. I had the feeling that Window-Scaling was the
reason,
> but I'm not into it enough to debug it deeper without digging in to
> documentation myself.
>        <heftig>        Tramp: thanks, I learned something :)
>        <Tramp> I'm not even sure if the "win 54" actually means, what
> tcpdump shows or if I am misinterpreting it (in the same way the other
> host may)
>        <rjt>   heftig, is this Ubuntu
>        <Tramp> (i.e. it could be something like (some significant bits
of
> 54)^^7+(some less significant bits) - that's what I'd have to dig
> into)
>        <rjt>   heftig, Ubuntu 8.10 ? Just happen in the last month?
>        <heftig>        Tramp: wireshark says 54 means 6912
>        <Tramp> ah. See. So I'm misinterpreting it the same way the
remote
> host does.
>        <Tramp> so the remote host has the same broken implementation I
have
> :)
>        <heftig>        :)
>        <Tramp> (or rather my tcpdump)
>        <heftig>        well, tcpdump just shows the value and doesn't
seem
> to take
> scaling into account
>        <Tramp> apparently it's 2^^7*54
>        <Tramp> (2^^7)*54 - with the "7" being the scaling-factor
announced
> in the initial syn
>        <heftig>        ah, i see
>        <heftig>        http://omploader.org/vMm1xdg
>        <heftig>        err
>        <heftig>        Window scale: 7 (multiply by 128)
>        <heftig>        stupid clipboard ><
>        <Tramp> yes - and the other host (announcing "wscale 0") says
he
> doesn't use scaling. Now I don't know if that means "hey, don't do
> Scaling, I'm to dumb to understand it"
>        <heftig>        ah, no
>        <heftig>        what is says is: i understand scaling. my scale
is 1
>        <heftig>        (2^0)*X
>        <Tramp> ah. ok then. So apparently the other side's
implementation
> is
> broken then.
>        <heftig>        yeah, seems it's a transparent proxy
>        ===     Tramp <n=mt at adsl-188-155-95-72.adslplus.ch> "mt"
>        ===     Tramp: member of ##networking
>        ===     Tramp: attached to irc.freenode.net
"http://freenode.net/"
>        ===     Tramp is identified to services
>        ===     Tramp is signed on as account Tramp
>        ---     End of WHOIS information for Tramp.
>        ===     heftig <i=jan at silver.heftig.linuxsecured.net> "Jan
> Steffens"
>        ===     heftig: member of ##networking
>        ===     heftig: attached to irc.freenode.net
"http://freenode.net/"
>        ===     heftig is identified to services
>        ===     heftig is signed on as account heftig
>        ---     End of WHOIS information for heftig.
>        <Tramp> looks like. If I contatct this host directly, it
announces
> "wscale 3"
>        <heftig>        well, thanks for your help :)
>        <Tramp> yw
>        <heftig>        Tramp: just found this article: seems a broken
> router
> rewriting the scale field to 0 could be the cause as well.
> http://lwn.net/Articles/92727/
>        <Tramp> what's the OS of the proxying machine?
>        <heftig>        wish i knew
>        <heftig>        apparently it runs squid
>        <Tramp> nmap -O (unless this could give you trouble)
>        <heftig>        it's not me being proxied. anyway, i would need
to
> know the ip
>        <heftig>        ...which i suppose a simple http service
returning
> the
> client ip would do
>        <Tramp> should do. Additionally if not all your connections are
> affected, it would rule out the proxy as the culprit, I'd say
> _______________________________________________
> OLUG mailing list
> OLUG at olug.org
> https://lists.olug.org/mailman/listinfo/olug
>



-- 
dynatron digital services
box 191 - 68037
www.dynatron.org
dynatron at gmail.com
_______________________________________________
OLUG mailing list
OLUG at olug.org
https://lists.olug.org/mailman/listinfo/olug



More information about the OLUG mailing list