Ethereal-users: Re: [Ethereal-users] Very slow ping response time from Internet while sending ma
Phillip Wilson wrote:
Hi Guys
Not sure if I'm asking the right people, or even the right question, but I'm
willing to try anything right now.
This problem started a couple of days ago and it's taken me until this morning
to get a handle on it. We have a 2Mbps ADSL connection shared between 25 users
for web browsing and e-mail. We have our own SMTP mailer inhouse that forwards
all outgoing mail to our ISP. A couple of days ago people started to complain
that web browsing was okay one moment, but unusably slow the next. Pinging one
of our ISPs nameservers during a slow period showed average response times of
2500ms where we normally have 30ms. The connection is still alternating between
fast and slow periods.
This morning I noticed that the connection slows down while our SMTP mailer is
sending mail to our ISP
Hopefully you don't have 25 users trying to use all of the limited
upstream bandwidth of your ADSL connection to send mail. :-)
If you expect to have a lot of users sending mail - or doing any other
form of uploading - so that the upstream bandwidth is being heavily used
for a significant amount of time, perhaps the "A" in "ADSL" is the
problem, and you should look into getting SDSL. ("ADSL" was originally,
I think, designed for video to the home, with the upstream channel
acting as a control channel; it's still somewhat oriented towards
typical home Internet use, with a lot more downloading than uploading
being done.)
I downloaded and installed the Windows version to my laptop and captured all
data while an email message was being sent to our ISP. Filtering to show only
packets from my mail server to my ISPs mail server showed that things start
normally with the usual SMTP hand shaking stuff, then things appear to go a bit
awry. Almost every packet says "TCP Window Full" in the Info column. These
lines are in red text on a black background which makes me thing they're not
good.
It means that your ISP's mail server's TCP implementation has told your
mail server that it has room for N bytes of data on the connection
between them, and N is small enough that your mail server can send that
much data in a single packet - which it does, so as to get as much data
sent as possible per packet (so that the fixed per-packet overhead is as
small a percentage as possible of the data being sent).
I'm a bit surprised that the window is that small, but perhaps they're
trying to keep any single customer's mail server from chewing up all the
bandwidth or buffer space.
However, I doubt that's your problem; in fact, if they had a *smaller*
window, that might *improve* your response while mail is being sent,
even though it'd take longer for the mail to be sent.
The problem here is *probably* latency. While a TCP segment full of
mail data is being sent, no other packet can be sent on the link; the
larger the TCP segment is, the longer that packet is, and the longer
that other transmissions will have to wait. That might significantly
delay, for example, pings (as the ping won't be sent until the TCP
segment has been sent).
2500ms is 2.5s, and if your uplink is 800Kb/s, that's 100KB/s, so that's
250KB; if it's 400Kb/s, that's 125KB. That's a bit bigger than, for
example, a typical Ethernet packet, and hence bigger than the TCP
segments I'd expect your mail server would be sending, so I'd be a bit
surprised to see the link completely tied up for that long.
I'd suggest you try capturing all outgoing traffic on the link while
mail is being sent and you're pinging the name server, and see whether
the data being sent to the server is "clogging" the uplink and
preventing the pings from getting out in a timely fashion. (If so, I'm
not sure why that's happening - the TCP on the mail server probably
isn't going to be queueing up multiple segments to be sent, so that a
ping or whatever has to get in line behind several segments, because
it's not going to be sending segments into a closed window, but maybe
I'm missing something here.)
