[olug] ubuntu slowing down
DYNATRON tech
dynatron at gmail.com
Wed Oct 28 21:37:16 UTC 2009
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
More information about the OLUG
mailing list