I use a 3G internet connection and have been struggling for months with a time-out issue when polling various smtp servers. I use three - two in my country (RSA) and one in the US. My service provider has not been able to help resolve the issue, which I suspect is related to Pegasus, and therefore out of their support experience (these newbies!!).
Although my internet connection is acceptably fast, when sending mail, Pegasus frequently locks up. This is, strangely enough, not consistently the case. Some days, it happens all the time, others it is more prevalent in the afternoons, when network congestion is typically higher.
The only way to resolve it, is to shut down Pegasus and restart it. Sometimes, when I try to force it to send, I get an error message stating that "another smtp session is already in progress". David H suggests the following:
"In this case, a good first thing to try might be to
switch to using non-blocking sockets (by adding "-z 1024" to the
Pegasus Mail commandline); non-blocking sockets are a less
demanding form of connection and some non- standard drivers in
the past have worked with them where they haven't worked with the
more standard non-blocking sockets."
Has anyone come across this? And more importantly, where exactly do I add this command line? Any help would be greatly appreciated.
You would add the "-z 1024" to the end of the command line in your Pegasus shortcut.
As to what effect it may have, I have no idea, sorry. [:S]
Yes, but where do I find this command line? Do I right click on the Pegasus icon on my desktop, and add it to the target line? After .exe? Windows does not allow me to do that.
Aah, I think I've got it. I omitted a space before -z 1024.
Tested sending now, and the outgoing mail was gone before I could look up! Hold thumbs that it works when the system gets slow in the afternoon ...
Cheers
OK, so that works, but strangely enough, inserting the command string nearly hangs up Pegasus. Tabbing between windows in PM is excruciatingly slow now. I tested it - removed the -z 1024 string, and it was fine, then re-inserted the string, restarted, and I was back to a crawl. What could cause this?
The only thing that should slow down is the TCP/IP operations. Are you sure you did the commandline properly?
1. Right click on the WinPMail shortcut and select "Properties".
2. Select the "Shortcut" tab.
3. Edit the "Target line" to add the commandline option.
A blocking sockets commandline option will generally look like the following:
c:\pmail\winpm-32.exe -z 1024
or
"c:\Program Files\pmail\winpm-32.exe" -z 1024
depending on whether long filenames are used requiring the quotes.
This also may be a packet fragmentation problem. The POP3/SMTP transmissions may fail if the MTU packet size is so large that a packet is fragmented. In many cases the receiving system router blocks the receiving servers "packets fragmented" response to the sending system using "MTU Discovery". These oversize packets are not accepted and so are resent. This results in a timeout, generally at the end of the message transmission but it can be anywhere in the process. You need to reduce the MTU size. Windows defaults to a 1500 MTU and many routers and DSL connections need 1492. You might simply want to turn off the MTU Discovery operation.
You might want to get a copy of SG TCP Optimizer that I find quite handy. http://www.speedguide.net/downloads.php This little utility will allow you to test your MTU for maximum size without fragmentation against specific servers. If will also make it easy to adjust the MTU.
And finally, does this computer, by chance, happen to have an NVidia NForce 4 chipset on the motherboard? If so, many other have had this exact problem, and it turned out to be an optimization setting for the built in NIC which caused the problems with packet fragmentation. Disabling the advanced optimization capability called "checksum offload" made all the problems of sending SMTP mail via WinPMail disappear.
Thomas wrote:
And finally, does this computer, by chance, happen to have an NVidia
NForce 4 chipset on the motherboard? If so, many other have had this
exact problem, and it turned out to be an optimization setting for the
built in NIC which caused the problems with packet fragmentation.
Disabling the advanced optimization capability called "checksum
offload" made all the problems of sending SMTP mail via WinPMail
disappear.
Spot-on - it is the Nvidia chipset, yes! Where do I disable the checksum offload?
Spot-on - it is the Nvidia chipset, yes! Where do I disable the checksum offload?
Not sure I've never seen one but I change the properties of my hardware in the device manager. Right click on my computer, select properties, hardware, device manager and find your network card. Usually the "advanced" tab has these options.
Your previous draft for topic is pending
If you continue, your previous draft will be discarded.