SLUG Mailing List Archives
Re: [SLUG] Need a lesson in routing [WAS: memory]
- To: Kyle <kl@xxxxxxxxxxx>
- Subject: Re: [SLUG] Need a lesson in routing [WAS: memory]
- From: Martin Visser <martinvisser99@xxxxxxxxx>
- Date: Sat, 21 Feb 2009 14:22:07 +1100
- Cc: SLUG <slug@xxxxxxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=wEiLsS+O4B3/OYTL8s7xYIweULT/xVCBHgA0gRCw21w=; b=n3CQxLws7IQ7Mg1wu0uG5lArgraQXFe2ER6WIjRy0DzI7GAmlDt/+61p+l4Xa3yLQE Hc34Xq3gqqYvz2MGGf2g0F3s7qIrOrhZlJ5nhWTeDvAOX/iOzds0HbLOX+FgK3DAjmyE 8xQIPpjLBDs2RIMy3FksGfoE8FKwPj/x5Ytio=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=K59UMVwrL3JM9J6YtazglSe1Ez0leQs8fQlWuQqL1WutmhrOtm2DVFbI50DpAwD2Gt lnXTDflDgDd4nE40NrZk2+vWpWcjavkEfUWGT0P/vENT3/k8RpXQhKskmG9KOzdDynyY gc+kWI0yOwxmcEme92DxrtMGAdhDfWezCOaLg=
Kyle, a few things.
Firstly you talk about "15Kbps". In my mind this reads as 15 thousand bits
per second. This is slower than dialup speeds. (A little "b" is always bits
*not* bytes, which is "B" in communication speek). Even if you meant 15 000
bytes per second (which equate to 150 000 is slow). So I am not sure what
you really mean here.
Secondly as you seem to have different experience with different
applications there is some value in splitting up your testing. The first
thing I would do is make sure you are good getting good throughput (goodput)
up and down. Your ISP probably has a webserver that will network-wise be
close to you (not on the big-bad internet). You want to do a download from
there. For instance Internode has a number of files on their mirror (which
will be unmetered) specifically for this purpose -
http://mirror.internode.on.net/pub/test/10meg.test. Your ISP may have
something similar ( I know iiNet does) or even other largeish files like
windows security updates that available there for easy update. To test
upload speed, your ISP might have provided you with limited personal web
space. You get one of those large files and then try uploading it. Firefox
reports goodput, but you could also use something like wget. If something
seems wrong, you can do a packet capture with wireshark you can get an idea
of things like retransmissions, fragmenting and the like.
Finally, even with good throughput you may have other application issues.
For instance if you app needs to do a DNS look or go elsewhere to verify
some credentials before the transfer you can have problems. For instance
sshd in its default configuration often causes issues for users because it
wants to do a reverse DNS lookup on the address of the connecting client. If
your primary DNS can't give that answer (because it is a private
unregistered address) then it can take some time to traverse multiple DNS
servers before eventually giving up. Similar if your traffic is protected by
SSL/TLS and the certificate presented has CRL (certificate revocation list)
specified and for some reason it can't access the CRL server it could take
15 seconds or more to time out. To determine if such issues exist you can
examine logs for the applications, (which often report that such timeouts,
or use wireshark again to infer from the request/response sequence as to
whether your app is getting the right answers in a timely manner or not.
I'm not saying you have either of this issues, but it is important to try
and separate out the layers - the lower ones (physical through transport)
would be covered by the first tests, and then more detailed log/protocol
examination would let you see any application layer issues.
On Sat, Feb 21, 2009 at 10:44 AM, Chris <chris.zhang.syd@xxxxxxxxx> wrote:
> Sorry I meant authentication and account information backend. If they are
> stored in a remote ldap server and the traffic is slow to that server, in my
> experience it can cause clients to get bad responses. Also can you take off
> SSL and see if it is faster?
> Perhaps check syslog for errors on the IMAP server. And supply your private
> key to wireshark to see the plain traffic.
> On 21/02/2009, at 9:59 AM, Kyle <kl@xxxxxxxxxxx> wrote:
> Not sure I understand you there James.
>> I telnet-ed in to test Peter's theories below. But for good measure, I
>> just tried with openssl as a command too and that responds immediately.
>> I just don't get it. One host behind the server/router is a MAC on OSX
>> with 4GB, another WinXP with 2GB. The WinXP host is by far the worst. But
>> irrespective the MAC is not exactly blindingly quick either. (Both wired
>> Kind Regards
>> James Polley wrote:
>>> you can use openssl s_client in place of telnet to connect -
>>> has a guide.
>>>> But for good measure Telnetted (and
>>>> Wiresharked) over both my SSL IMAP port and 25. Both responses come back
>>>> PDQ. And Wireshark shows traffic moving from one host to the other and
>>>> return. I'm pretty confident of my iptables setup as I have refined that
>>>> over a period of years.
>>>> peter@xxxxxxxxxxxxxxxxxx wrote:
>>>>> So, connexions to the (imap? smtp?) mail server time out. Can you run
>>>>> wireshark on the server, and see what's happening? Does the server
>>>>> have a correct route to the clients?
>>>>> If it's smtp, then try telnet from a client to the server (telnet
>>>>> 192.168.1.1 25) on the inside of the firewall, while watching top on
>>>>> the firewall. What does the load look like? Does the telnet session
>>>>> time out? During which part of the connexion?
>> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
>> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html