Wednesday, December 11, 2002, 2:17 PM, Joseph Mann (Ipswitch) wrote with a straight face:
> As you probably are aware I just wanted to mention > that IMail doesn't interact directly with hardware. You're kidding, right? Maybe in an MS Press book it doesn't interact with hardware. In real life, software breaks when it is fed the unanticipated--even through a driver and Hardware Abstraction Layer! A very simple example: Not too long ago, some Win32 apps began having their installation routines bomb. Why? Because of TOO MUCH disk free space being reported back by the driver on new large capacity disks (causing an overflow condition). That installer software "doesn't directly interact with the hardware" either, but a bigger harddisk than the programmers ever imagined possible broke it just the same. Coding for unanticipated conditions has always been a challenge. How many remember programs that were hard-wired to install and run only on the C: drive? Heck, how many remember the timing loops used to control execution speed in some 8088 DOS programs, and that those programs became instantly unusable when run on a 386? Look, I really like Imail's administrative simplicity and functional elegance. That's why--when wearing my consultant hat--I've recommended it to many clients. But with all due respect, the userbase experience here is clear: Imail has issues running on some popular server hardware. If not, how is it that dozens of other commercial mail daemons, and Win2K itself, work absolutely flawlessly with these allegedly "faulty buffering" NICs? My intuition tells me that Imail probably has an aging core codebase that is in need of a rewrite for today's realities. Loyal supporters like me hope you are hard it work on it. In the meantime, perhaps Ipswitch programmers could check if any of the user-tweakable Intel NIC driver settings would help Imail function more reliably. Several posters here have expended a lot of time and effort to help define and narrow the problem. Now get to work and FIX IT so I can continue recommending Imail solutions to outside clients! :) Regards, Dev -------------- Dev Anand, MCSE,CCNA,A+ Network Manager Biomorphic VLSI, Inc. Westlake Village, CA 91362 dev_at_biomorphic_dot_com pcpro_at_vcnet_dot_com -----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 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/
