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. Regards, Martin martinvisse...@gmail.com On Sat, Feb 21, 2009 at 10:44 AM, Chris <chris.zhang....@gmail.com> 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 <k...@attitia.com> 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 >> connections) >> >> ------------------------------------------------------------------------ >> Kind Regards >> >> Kyle >> >> >> >> James Polley wrote: >> >>> you can use openssl s_client in place of telnet to connect - >>> >>> http://www.jaharmi.com/2007/09/26/using_openssl_securely_connect_your_imap_account >>> 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. >>>> >>>> >>>> >>>> pe...@chubb.wattle.id.au 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 > -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
