Todd, Don't forget the sp3 for your w2k.. amongst other fixes they did resolve some issues with nics, etc.
~Rick ----- Original Message ----- From: "Todd Ryan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, December 13, 2002 7:31 AM - SATCOM Subject: Re: [IMail Forum] FIXED! Imail SLOW When Running On Fast W2K Hardware > I'm pretty excited about what Dev has found. Since I posted about this a > month or so ago, I've just let my mail run on the NT4 BDC since I was never > able to get it to perform efficiently on a PowerEdge 2550 running 2000. > > Out of curiosity, those of you who have had similar problems with the Intel > NICs and IMail, were these 2000 machines or NT4? I have tried 2 different > servers with NT4 and Intel NICs and have not had any problems. I then tried > two different 2000 servers with Intel NICs and both performed miserably. > > I also want to note that when I tried IpSwitch's fix (Use a 3com), I believe > I put the 3com in the 2000 machine and disabled the onboard Intel 100 and > Broadcomm 1000 in Windows ONLY. I did NOT disable it in the bios. And I > STILL had the same performance problems. I am hoping that disabling it in > the bios will make the difference. > > I'm about to try this again. Hopefully this time I'll be able to get IMail > onto a 2000 box and get rid of my last remaining NT BDC. But this time I'm > going about it a bit differently. I'm moving IMail to a temporary NT BDC > (did this today) and will then wipe the original NT IMail box, install the > 3Com NIC, disable onboard NICs in the BIOS, then build it as a fresh 2000 > box. Then migrate the mail back. > > I'll post on my results hopefully next week. > > Thanks again, Dev! > > --Todd. > > > ----- Original Message ----- > From: "Travis W. Rabe" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, December 11, 2002 2:33 PM > Subject: RE: [IMail Forum] FIXED! Imail SLOW When Running On Fast W2K > Hardware > > > > Actually I have tried using a Netgear and a 3COM gigabit NIC for the hell > of > > it and got the same problem as the Gigabit NIC shipped with Dell. I have > > three of the same types of Dell servers (one running SQL 2000, one running > > IIS and one running Imail.) The result is the same no matter what I do > for > > the iMail server. Gigabit=BAD, 100MB=GOOD. I have had <knock on wood> > none > > of the same problems with the throughput on other servers. > > > > I have to agree with Dev on this one. > > > > Travis > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Joseph Mann > > Sent: Wednesday, December 11, 2002 11:28 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [IMail Forum] FIXED! Imail SLOW When Running On Fast W2K > > Hardware > > > > As you probably are aware I just wanted to mention that IMail doesn't > > interact > > directly with hardware. The exception only occurs with IMonitor that will > > interact with the communication port if you have IMonitor setup to do so. > > > > In the past three years there have been two common components when used in > > conjunction, don't seem to play to well together. > > That would be Dell based servers in conjunction with the Intel Pro NIC, > > most likely on-board based. You mentioned that you performed numerous > > netstat sessions. In my experience with this issue I have see some > reports > > 96 pages in length due to something not closing a socket correctly, > > therefore > > basically running the box out of sockets. If it were IMail once I stopped > > all service it SHOULD have cleared everything up, but that was not the > case. > > > > I personally believe it has to do with Intel's buffering technique, which > I > > have included a > > snippet from their web site below. If the system bus becomes extremely > busy > > the card will > > then wait for the bus to become available before releasing data. > > > > /////// > > First, it maximizes data throughput, taking > > full advantage of all available network bandwidth. > > Second, it minimizes the need for the system's CPU > > to move network data, leaving it more time to work > > on other tasks. Other design features provide > > additional performance for the EtherExpress PRO/100 > > adapters. For example, the cards use a high speed > > transmit and receive FIFO cache of 16K static random > > access memory (SRAM). The FIFO accumulates network > > data when other peripherals are using the system's I/O > > bus, then releases the data as the bus becomes available. > > The result is a highly efficient flow of data from the > > adapter to the PC and back. > > /////// > > > > > > -- Joe M. > > > > Wednesday, December 11, 2002, 1:32:11 PM, you wrote: > > > > > > D> Hopefully the following may be of some help to others. > > > > D> I had a similar problem as Todd. Here is a part of his > > D> thread: > > > > D> http://www.mail-archive.com/[email protected]/msg59929.html > > > > D> In my case, an existing NT4 Imail installation was > > D> moved to a new, very fast (P4-2.4GHz/512MB) Dell > > D> PowerEdge running W2K, hardware RAID, Imail 7.13, and > > D> KWM 3.0. > > > > D> The result? We had inexplicably slow logins, flaky mail > > D> downloads, GLACIAL webmail, and random SMTP/POP > > D> hangs--and all with CPU utilization near ZERO. Oh yeah, > > D> and a lot of ticked-off users!! > > > > D> Anyway, after a week of debugging, hardware swapping, > > D> cloned testbeds, performance logging, and analyzing > > D> over 200 MB of packet captures, I now have it humming > > D> along quite nicely, thank you. > > > > D> The usual caveat here: The following fixes worked for > > D> me, your mileage may vary. :) > > > > > > D> 1. My dual-homed Dell server was equipped with an Intel > > D> Gigabit ethernet integrated into the motherboard, along > > D> with an Intel Pro100/S NIC. I noticed in a post that > > D> Todd extracted from Ipswitch TechSupp the stunning > > D> admission that Imail is incompetent at reliably > > D> communicating with two popular server adapters: > > > > D> http://www.mail-archive.com/[email protected]/msg59332.html > > > > D> Guess what? Tech support is right. My tests showed that > > D> Imail would randomly just stop communicating for > > D> varying periods of time over these two adapters. This > > D> particular "going into limbo" issue was resolved by > > D> replacing them with two 3C905C's. > > > > D> Note that to fully eliminate this issue, it was > > D> necessary to completely DISABLE the onboard Gigabit > > D> Ethernet adapter in the server's CMOS setup. The second > > D> Intel Pro adapter card was also physically removed from > > D> the box. > > > > D> ISSUE SUMMARY: No fast, server-quality NICs are allowed > > D> within sight of an Imail box. Ipswitch apparently wants > > D> us to continue running the latest 1998-era hardware. :) > > > > > > D> 2. Packet captures indicated that Imail did not like > > D> operating over a NIC with more than one IP address > > D> assigned to it. This may be somehow related to the > > D> Imail programming blunder of binding to all IP address. > > D> Inexplicably, the speed of the machine may also play a > > D> role, since an identical multiple IP setup cloned to a > > D> P2/266 had no such Alzheimer's issues. And yes, the > > D> Imail address WAS the primary IP. The fact is that > > D> removing the second IP on this P4 made a HUGE > > D> difference in Webmail stability and speed. It doesn't > > D> make sense, but as I said, YMMV. > > > > D> ISSUE SUMMARY: Only one IP address per NIC on a Pentium > > D> 4 box running Imail. > > > > > > D> 3. Once the above was sorted out (users--especially > > D> WebMail--noticed a HUGE difference in performance and > > D> reliability with the two fixes above), there was still > > D> a mysterious 1.5 - 6 second delay on some incoming SMTP > > D> and POP sessions. > > > > D> The cause? In this case, it was NetBIOS name lookups > > D> timing out. > > > > D> To verify the problem, look for this unanswered NBT > > D> query request string in your packet > > D> captures: "*<00...(15)>" > > > > D> Without getting too involved in the machinations of > > D> NetBIOS or of our internal network and firewall layout, > > D> basically Windows 2000 (or perhaps a 'getHostAddress()' > > D> call by Imail) was insisting on performing an > > D> unnecessary reverse lookup (computer name from IP > > D> address) on the incoming connection. It was sending a > > D> node status request directly to the perceived > > D> source--my NAT Public IP address (the equivalent of a > > D> "nbtstat -A <ip_address>"). > > > > D> The irony? After NetBIOS repeatedly times out and > > D> finally gives up trying to resolve the name, W2K then > > D> simply ignores the timeout and successfully proceeds > > D> with the SMTP/POP connection! Sheeesh! > > > > D> The solution? If the NetBIOS query can't be resolved > > D> with properly configured WINS/DNS, go into the HOSTS > > D> file (systemroot\winnt\system32\drivers\etc\) on your > > D> Imail box and give the IP address query that is timing > > D> out a name to satisfy the lookup. In my case (failing > > D> to resolve the NAT Public IP), this is what it looks > > D> like: > > > > > > D> 127.0.0.1 localhost #existing entry > > D> ... ... #more existing entries > > D> 207.178.203.99 anyname.mydomainname.com #BINGO! > > > > > > D> Note that the NetBIOS timeout issue was not present on > > D> an otherwise identically configured NT4 box. > > > > D> ISSUE SUMMARY: Look for unexplained response delays of > > D> multiples of 1.5 seconds. If you have them, sniff the > > D> wire (make sure to check ALL interfaces on multi-homed > > D> boxes!) for unresolved NetBIOS queries. If necessary, > > D> simply create a suitable Hosts file entry to make > > D> Windows happy! > > > > D> By the way, the Hosts file is checked every time name > > D> resolution is attempted. Changes in it take effect > > D> immediately and do NOT require a reboot! > > > > D> As I said, the box absolutely rocks now. I don't claim > > D> to know why some of these fixes worked, just that they > > D> did. Perhaps this will provide a helpful starting point > > D> to others facing similar inexplicable slowdowns. > > > > D> Cheers, > > > > D> Dev > > > > D> -------------- > > D> Dev Anand, MCSE,CCNA,A+ > > D> Network Manager > > D> Biomorphic VLSI, Inc. > > D> Westlake Village, CA 91362 > > D> dev_at_biomorphic_dot_com > > D> pcpro_at_vcnet_dot_com > > > > > > D> To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > > D> List Archive: > > http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > > D> Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ > > > > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > > List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ > > > > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > > List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ > > > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ > ___________________________________________________________________ > Virus Scanned and Filtered by http://www.FamHost.com E-Mail System. > > ___________________________________________________________________ Virus Scanned and Filtered by http://www.FamHost.com E-Mail System. To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
