VMware Communities
dotel
Contributor
Contributor

Very Slow Network support, In Dos Enviornment IPX Problem?

Background: We have been using Vmware workstation 4.5 and 5.0, extensivly in our envoironment. We run a propriatary and extreamly strange DOS envoirnment for our product shipping software. This sofrtware will only run under vmware or a true dos 6 workstation. Never have been able to get this to run under any other form of emulation or tweaking. We have abour 200 PC's running this applications, ~150 running Suse linux and ~50 or so running XP. We have purchased licenses for vmware workstation and have been VERY VERY happy. We have 15-20 Macs that would love to be able to access software, but we have had to wait. Untill now, I understand this is a beta and not an eval. but any info I can get or give will greatly help us in expanding our use of Vmware products.

VM Enviornment: Dos 6.0, running with 16mb of memory assigned to the vm session. Session uses a Novell 3.12 DOS 16bit NIS driver to access the legacy server. (also a VM, but thats not the problem). Network is 100% IPX/SPX No tcp/ip is bound to the virtual machines. VM image is a cookie cutter image that is pushed out over network to clients. We use same VM image for Windows and Linux workstations. VM image has not changed in almost 3 years. Starting with Vmworkstation 4.5.

Test hardware: Apple Dualcore 2.66, 2gb memory, 500gb Hdd, geforce 7300, OSX 10.4

Problem: On the virtualization system for the mac, the VM session will start and dectect the virtual network card. The system runs very fast up untill the point where we log onto the server. At this point the VM session will appear to freeze and the CPU utilization on the HOST will hit 100% This will remain at 100% for almost exactaly 2 minutes. At this point I will be given a logon screen in the VM. I will log into the network where is will process the startup sections, VERY slowly. Average speed on file transfer is 20 minutes for a 1.5mb file. The program will eventualy load, however will not operate because the database will time out.

Steps Taken: I have attempted to use updated network drivers. Adjusted the timing (and removed) dosidle, to verify a timing issuse on the network card. I enabled debug on the windows and linux workstations to verifiy if debug was causing delays. (Enabling debug on the windows/linux workstation DOES greatly slow down the logon process, 20-30 seconds with debug on, vs, less then 2 with it off, however that is not close to the 6+ minutes it takes for the process on the mac version).

Theory: I have a few working ideas but they are only ideas. IPX/SPX is a very very chatty protocal, If the Beta is logging and debugging IPX/SPX traffic, it must be handling a ton of data. 150+ machines chatting all hitting the virtual NIC must be alot of CPU overhead. Another idea, is that maybe IPX/SPX traffic is just a dying bread and perhaps the mac version is optimized for tcp/ip only.

Help: Has anyone else had any problems/luck with Dos and Nis? Speed issuses? Solutions? If VMWARE needs a copy of the virtual image I would be happy to provide it, however I doubt they could reproduce it without both the server and clients. I would love to get my hands on a copy of the beta with debug disabled, to verify if the problem does lay in the debug routines. I already have the funding set asside for the product, I just have to make it work first.

Thanks, A solution would make me, and my marketing/graphics department very very happy.

Reply
0 Kudos
14 Replies
TheLoneVM
VMware Employee
VMware Employee

IPX/SPX? Oooh, must be running an oldschool DOOM deathmatch marathon! Smiley Happy

Seriously, please enter an Online Support Request for this bug (and post the SR# in this thread). Thanks!

http://www.vmware.com/support/services/Beta.html

Reply
0 Kudos
admin
Immortal
Immortal

You might consider trying your DOS VM under the Workstation 6 beta. If it gives you acceptable performance, but the Fusion beta doesn't, that would be an interesting datapoint.



Here's the link for Wks6: http://www.vmware.com/products/beta/ws/



You mentioned that you took out the CPU idler. A DOS VM is going to need a CPU idler of some kind; maybe you could try alternatives to DOSIDLE.EXE. This thread lists several:



http://www.vmware.com/community/thread.jspa?threadID=19586



When you wrote "I have attempted to use updated network drivers," what exactly do you mean? A VM of that vintage will contain, by default, a virtual network adapter that looks like an AMD PCNET-32 card. Do you mean that you went out and fetched a newer NDIS driver for that card? I would expect the old one to work.



Another tactic would be to try Fusion's (or Workstation 6's) new support for a virtual Intel PRO/1000 MT card. I myself have only used these with more recent flavors of Windows, but I notice that Intel offers NDIS drivers for them. Copy the driver from Intel's Web site into your DOS VM before changing the virtual hardware.



To equip your VM with a virtual Intel PRO/1000, you must edit its .vmx file while it is fully powered off. Use a smart editor such as BBEdit or textwrangler (TextEdit can mess up .vmx files if you cut and paste in the wrong way). Insert a line like this:

<tt>ethernet0.virtualDev = "e1000"</tt>

The line order doesn't matter. Remove any other lines that begin with

ethernet0.virtualDev

.



You also wrote "maybe IPX/SPX traffic is just a dying breed and perhaps the mac version is optimized for tcp/ip only." That would seem out of character for our company. Our attitude basically is that we provide the VM with an Ethernet adapter; what you write into your Ethernet frames is your business, be it IP, IPX, or whatever.



Finally, as the previous poster suggested, filing a bug report would be greatly appreciated. However, I need to set your expectations about timeframe: because DOS is not a supported guest OS in this beta release of Fusion, your bug report will have to stand in line behind bug reports on supported features. I'm sorry about that.



Thanks for your patience, and thanks for trying Fusion.

Reply
0 Kudos
dotel
Contributor
Contributor

Yes I did get newer NDIS drivers, Tho not alot to choose from. I didn't think it would help either, but I can't scratch it off the list of possible problems until I tried it.

I'll try the Intel driver. Then submit a bug if need be. I will also play with other idle programs.

As for not a supported OS. LOL I'm so used to that with this project. Not a single thing sort of a 1.8 million dollar conversion/rewrite/rebuild is "supported". Everything is just plain WEIRD. Thank to VMWARE I at least no longer have to have a bank of 26 proprietary 286 machines running in the mail room. And we have been able to move the call center out of the stone age. No more 286 dumb terminals. I got a standing ovation when I introduced them to EMAIL. Smiley Happy

Reply
0 Kudos
dotel
Contributor
Contributor

Note: I did find a solution, I do no know why it matters so much, but now it's working.

Solution: I updated to the new beta of program, still had same problem, maybe 10-15% faster but still un-usable. However Setting the Virtual machine settings to "Dual CPU" allowed application to run 1000x's faster. Application is now usable. I'm now testing for stability. The Fusion beta is still significantly slower then our non-beta counterparts but is 100% usable from a business standpoint.

Question: I never thought to enable dual cpu support for the Vm machine, because DOS is not understand what dual cpu's are. I don't know why this makes such a huge difference. I ran our other virtual dos sessions, all based on either pc-dos 7 or msdos 6.22. They both behave the same way under fusion. HOWEVER, when I make the same changes under vmware 5.5 or 6. On the PC. There is no speed change at all. These are running the EXACT same virtual machines.

Suggestion: For all those running dos/win 3.1 etc or anything DOS based. Try enabling the Dual CPU support, even tho dos should not be able to support it. It makes a world of difference.

Reply
0 Kudos
HPReg
VMware Employee
VMware Employee

dotel,

Thanks for reporting this. I'm glad you have found a workaround for now, but I'm going to let our Fusion network guru take a look at this thread.

Reply
0 Kudos
admin
Immortal
Immortal

Thanks for reporting this slowdown!

We already know the root cause behind the slowdown, and are actively working on fixing it. Coming soon in the next beta in a theater near you!

We'll be sure to test and make sure IPX/SPX slowdown has disappeared when we fix this root cause.

Reply
0 Kudos
rcardona2k
Immortal
Immortal

I hope the fix is to drop all IPX/SPX packets right at the virtual interface Smiley Wink

Just kidding! -- we all love[/i] Novell protocols.

Reply
0 Kudos
Andreas_Masur
Expert
Expert

Just kidding! -- we all love[/i] Novell protocols.

Do we??? Smiley Happy Smiley Happy Smiley Happy

Reply
0 Kudos
dotel
Contributor
Contributor

All right, but if you do drop the support for IPX. I'm going to give the over-worked, grumpy and irritable graphics department YOUR address. Ever been attacked by a straight edge and exacto knif?

Reply
0 Kudos
HPReg
VMware Employee
VMware Employee

"but if you do drop the support for IPX"

Relax. We will not be dropping IPX for the simple reason that there is no explicit support for IPX. All we care about at the virtual hardware layer is Ethernet frames. As bhaveshdavda wrote above, we are just going to fix the performance issue.

Reply
0 Kudos
dotel
Contributor
Contributor

hehe I know, just joking around with ya guys.

Reply
0 Kudos
TheLoneVM
VMware Employee
VMware Employee

Dotel, please check your private messages. Thanks!

Reply
0 Kudos
Pat_Lee
Virtuoso
Virtuoso

Dotel,

We have networking improvements that should resolve this problem in beta 3. Please remove the workaround we previously provided and let us if beta 3 solves your particular networking problem.

Thanks,

Pat

Reply
0 Kudos
msohnius
Contributor
Contributor

Well done, folks! I loved this thread: someone reports, in some detail, a really weird problem, the right person is brought into the game, goes out and finds the smoking gun, and then fixes the problem in time for the next release. Brilliant!

In addition, even though nobody spilled the beans, I am sure that the bug fix will ultimately benefit everybody, not just IPX users. I would hazard a guess that it had to do with the reaction of the virtual ethernet interface to very heavy broadcast traffic. This is the norm in an IPX/SPX environment, but it can also happen for TCP/IP, so a bug fix will benefit everybody.

NB. The use of VMware to keep legacy environments up and running can only increase. I have the same problem with an app running on original (Novell) UnixWare (the problem being huge re-write/porting costs that up until now make me use ancient and moribund hardware). Ultimately, I forsee the world's Libraries of Record and government archives running virtualised computers by their hundreds, starting with Apple II's and Commodore Pets, just to read "historic" documents on 8" floppy disks!

Reply
0 Kudos