Details:
This is on a MacBook running OS 10.4.11 and using the original Qualcomm
Eudora v 6.2.4. My email account is a Stanford popserver account, and I
send through a Stanford account called smtp-roam which they've
established for sending from outside connections, and which apparently
involves some kind of proxying.
I've been processing my email periodically for several days from a small
hotel in Paris, connected to the Internet through the hotel's Wi-Fi LAN,
one or both of which seem to have the name "orange", which in turn seems
to be some kind of commercial Internet connectivity service in Europe.
I actually get connected here using the iPass Connect software, to which
Stanford has a subscription, and which allows one to connect to any of a
huge list of Internet access points around the world -- including an
entry for this particular hotel. My mail, which comes from my email
account on a popserver at Stanford, arrives near instantaneously once
I'm properly connected and then check mail.
But when I send a replies or new messages, I seem to get connected to
and the message seems to get processed by the Stanford sending software,
up to the point where the "DATA" response shows up in the Eudora Task
Progress window -- after which there's a long delay (sizable fractions
of a minute, sometimes longer) before anything happens in the progress
bar in that window -- and this is accompanied in most cases by the far
eventually starting and whirring for a while.
This seems to happen consistently, in sessions on several days. How
might I understand what's going on?
> How might I understand what's going on?
Fire up Acitivity monitor and set it to show processes ordered by CPU
usage, then watch the window while sending mail.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
> Why does the response become very slow (but still eventually work) and
> the fan in my MacBook eventually start whirring madly, when I _send_
> email messages through through the Stanford University mail email system
> while connected via an outside (off-campus) Internet connection, but not
> when I _receive_ (that is, download) my email? (and this doesn't happen
> when I'm directly connected on campus).
Whell, without knowing anything about Stanford's setup etc., a quick
guess:
Your message needs to be sent to another person, therefore the fan
generates enough wind to transport the message to the recipient.
For receiving a message, too much wind would prevent its landing in your
machine.
;-)
Christian
--
Christian F. Buser, Hohle Gasse 6, CH-5507 Mellingen (Switzerland)
Hilfe fuer Strassenkinder in Ghana: http://www.chance-for-children.org
> Why does the response become very slow (but still eventually work) and
> the fan in my MacBook eventually start whirring madly, when I _send_
> email messages through through the Stanford University mail email system
> while connected via an outside (off-campus) Internet connection, but not
> when I _receive_ (that is, download) my email? (and this doesn't happen
> when I'm directly connected on campus).
This is probably a useless analogy. If you were working with radio, a
transmitter would generate much more signal power than your receiver.
Even with computers you probably rfequire more power to send than to
receive.
Also far out, the transmission line impedance at your various locations
can differ greatly. A standard telephone impedance is 600 ohms. But
actual values can vary all over the place. A low impedance will require
more power to generate a particular voltage on the line.
I would think that your networks guru at Stanford would know all about
such things. How much are you willing to do to track this down. If you
are using a phone line, are you willing to carry a signal source and a
multimeter or two?
Bill
--
Most people go to college to get their missing high school education.
> Why does the response become very slow (but still eventually work) and
> the fan in my MacBook eventually start whirring madly, when I _send_
> email messages through through the Stanford University mail email system
> while connected via an outside (off-campus) Internet connection, but not
> when I _receive_ (that is, download) my email? (and this doesn't happen
> when I'm directly connected on campus).
I'll add to the guesses as to what is happening.
For receiving mail, you're probably authenticating with simple
username/password authentication and receiving the email in the clear
from the POP server.
For sending mail to the Stanford SMTP server, you're using an SSL
connection and encryption, which is much more CPU-intensive and
time-consuming sending packets back and forth and the server & Eudora
doing some handshaking to verify that packets haven't been lost. Since
the CPU has to work much harder to send than to receive, more heat is
generated and the fan has to kick on.
FWIW, that's not unusual. I notice the same thing when I'm
sending/receiving mail from outside my ISP. Receiving the POP mail is
quick, easy, and transparent--I don't have to do anything unusual. To
send mail, I have to establish an SSL connection and it's much slower
than if I use an unencrypted connection from home.
My MacBook seems to get pretty hot and the fan runs a lot if I'm using
it for an extended time on a regular desktop. I purchased a Thermopak
(brand name) pad that sits under it to cool it. The Thermopak uses a
phase-shift filling to absorb much of the heat. I've been really
pleased with the performance; it does an effective job of keeping the
MacBook cooler and avoiding a lot of the fan activity. It was a little
spendy, but I think worth it.
--
Kathy
> > Why does the response become very slow (but still eventually work) and
> > the fan in my MacBook eventually start whirring madly, when I _send_
> > email messages through through the Stanford University mail email system
> > while connected via an outside (off-campus) Internet connection,
> I'll add to the guesses as to what is happening.
> For sending mail to the Stanford SMTP server, you're using an SSL
> connection and encryption, which is much more CPU-intensive and
> time-consuming sending packets back and forth and the server & Eudora
> doing some handshaking to verify that packets haven't been lost. Since
> the CPU has to work much harder to send than to receive, more heat is
> generated and the fan has to kick on.
Thanks much. I had supposed something like this must be happening,
imposed by the smtp-roam software on the Stanford server, not by any
deliberate choices on my part.
I'm just quite surprised at the scale of the resulting transmission
slow-down and especially the fan speedup. The replies I'm sending are
mostly just brief pure text single paragraph responses. Delays due to
repeated handshaking I can understand; but the encryption must be a bear
to cause that much CPU heating. God forbid I should try sending an
image or data file!
> I'm just quite surprised at the scale of the resulting transmission
> slow-down and especially the fan speedup. The replies I'm sending are
> mostly just brief pure text single paragraph responses. Delays due to
> repeated handshaking I can understand; but the encryption must be a
> bear to cause that much CPU heating. God forbid I should try sending
> an image or data file!
I don't really believe that the encryption is responsible for all that
CPU usage, unless your computer is some relic from the eighties.
I like the response by kmorgan better than my own, The fundamental
reason for the heat is the charge and discharge of stray capacitance in
the electronics. There is no easy way to prevent dissipation of the
energy stored in that capacitance. AS you know from working on lasers,
efficient capacitor charging can be a problem.
I would not worry about overheating the computer. It should be designed
to handle peak computing loads where binary ones become zeroes and vice
versa at a rapid rate. While the same problems will exist at the
communication interface, the switching rate there is going to be at
least an order of magnitude lower than the clock rate of the computer.
Even in the case where a highly capacitive twisted pair telephone is
being driven, it will be the modem that bears that burden, not the
computer.
> For sending mail to the Stanford SMTP server, you're using an SSL
> connection and encryption, which is much more CPU-intensive and
> time-consuming sending packets back and forth and the server & Eudora
> doing some handshaking to verify that packets haven't been lost. Since
> the CPU has to work much harder to send than to receive, more heat is
> generated and the fan has to kick on.
The very same SSL and encryption is used for all secure (https) web connections
and data transfer, so does the fan go on whenever you browse a web site using https?
At Gmail, for example, you can easily switch between http and https,
and see whether there is an observable difference,
with nothing else varying.
--
> The very same SSL and encryption is used for all secure (https) web
> connections and data transfer, so does the fan go on whenever you browse a
> web site using https?
I've never really paid attention. Secure web connections do seem to be
a bit slower than plain http, but there are too many variables to really
be sure about that.
> At Gmail, for example, you can easily switch between http and https,
> and see whether there is an observable difference,
> with nothing else varying.
Anyone with a Gmail account who cares to check it out? (I don't have
one and don't plan to get one, so...)
--
Kathy
Make that two useless analogies. None of the above has ANY
connection to TCP/IP on ethernet.
--
Wes Groleau
Standards?a parable
http://Ideas.Lang-Learn.us/WWW?itemid=145
I could ask my son to do so, but that would tell you absolutely nothing
about how _your_ hardware and software are behaving.
--
Wes Groleau
We don?t teach long division; it stifles their creativity ?
http://Ideas.Lang-Learn.us/WWW?itemid=62