#Gateway PC Prob w/Studio
18 messages in this thread
I have what I thought was a unique problem, and I've been afraid to come out of
the closet with it, BUT NOW I KNOW I'M NOT ALONE!
The problem is with 3D Studio and any make of Gateway (confirmed on all 486
DX2-66's through P-100's). Regardless of which video card is in use, regardless
of how much RAM you have (this problem has been verified with between 16 and 32
Meg of RAM), what version of DOS (demonstrated with 5.0 thru 6.22), and whether
a PCI or VLB is present. It seems to be a CPU/FPU thing in conjunction with the
Micronics boards that Gateway uses. The use of any memory management beyond
Phar Lap contributes to the severity of the problem, as does the number and
type of drivers loaded in config.sys and autoexec.bat. (CD ROM drivers seem to
be especially onerous). The big revelations – I haven't heard of it happening
to any other brand name PCs., and the problem can be LESSENED (though not
minimized or eliminated) somewhat by continuously pressing the PF11 key, so
that the keyboard buffer fills up. In fact, a rendering frame that might take
an hour without special handling, drops to 5 to 10 minutes. I learned recently
that a company in San Francisco using Gateways in a production animation
environment were having the same problem, and had also discovered the partial
solution of depressing the PF11 key.
So, what IS the problem? In scenes where either/both face and vertex counts
exceed 100,000, OR ipas routines such as Skin, Flame, Bones, etc are in use,
rendering can slow to a crawl, swap files will be created even when sufficient
RAM is present to process, etc. The telltale sign is that the fuel gauge stops
moving while transforming objects, while procedural objects are being created,
or while normals are being prepared. How do I know this is happening, and that
the rendering times are out in left field, you ask? On a recent project, I had
to lease 5 Pentium 90s, 1 Pentium 75, and a Pentium 60. These clones all
outperformed my Gateway P-90 in rendering by factors of 2 to 4, depending on
whether not I effectively taped down the PF11 key. If the tape worked loose,
and somehow the key was not depressed, the next frame rendering time could
increase by a factor of 30. At first I thought the files were causing my
machines (Pentium and DX2-66) to lock up, since they had only 32 Meg of RAM
versus the 48 on the leased machines. Not so – after a few reboots, I
inadvertently let my Pentium continue rendering, even though the gas gauge did
not move for nearly an hour and a half, and there was no disk activity. The
gauge suddently began moving again after the hour and a half, and the frame
finished rendering within the next few minutes. A 94 minute render, versus 3
1/2 minutes on the clone Pentium 50. Sad stuff!
Today, when I tried to recreate the problem to make sure I got the various
messages right, I got a fatal one (for the render) that I hadn't seen before –
"EXP Mesh Op Failure – no object ready" while the last round of normal
preparation was occuring. The message occurred five minutes into the render of
the first frame. This particular file has thirteen skin objects, two flame .ixp
boxes, and consists of around 20,000 vertices and 36,000 faces.
Anyone have a similar experience, and some type of long term solution? I'm very
happy with Gateway quality and service, but my next PC will be a clone if I
can't fix this problem with my current machines. I may even arrange an
across-the-board trade and keep my RAM. If their are no solutions, are there
any takers for a new Pentium 90??
Obviously, the move to NT, and a different memory management strategy for 3D
Studio may make all this a non-issue with release 5.
Thanks in advance. I'm posting copy of this on the Gateway forum, with some
additional background for the "uninitiated" there.
Bob Weil
Hi Robert,
<< gateway problems..>>
Any forum members with Gateways wish to add any additional comments?
>>Any forum members with Gateways wish to add any additional comments?
Sure; I can honestly say it's never happened to me, and that's w/some of my
scenes that include skinned objects dumping 300,000 to 500,000 polys to the
renderer, or in scene where I exceded 300,000 faces in addition to having
skinned objects (as an example, the grass by itself on my first complete dragon
picture was 320,000 odd polys, not counting the dragon, and it took under ten
minutes at 600*800). As a guess based on what others have posted here, maybe
somewhere in the autoexec.bat/config.sys lies the POWER.EXE that others have
said slowed them down. Perhaps he could try it w/the 'Jonas minimum recomended
boot' (you know, the 'files/buffer/path/mouse' autoexec.bat and config.sys) and
seeing if that speeds things up and work from there. If he's swapping, that's
another story (my P90 has 64 megs).
John Stetzer
JWS
Thanks John..
Anyone else using Gateways'?
>>Any forum members with Gateways wish to add any additional comments?
I've got 3 Gateways (60,100,100) with 64M RAM and never seen this problem.
However, I would like to alert everyone to another serious Gateway problem I
uncovered just this week.
The last two systems I bought had file corruption problems. Unfortunately,
it's very hard to discover. I used one system for 2 months before I realized
the problem was with my hardware and not software.
Here's the only test I know – copy a large file from one directory to another
(preferably from one hard disk to another). Do a binary compare (fc /b
testfile.ani d:testfile.ani) and if you encounter no errors, then thank your
lucky stars. I used animation files around 50M and would get over 6 bytes that
flipped a bit. I originally discovered the problem when copying files from the
PAR drive to my c: drive. The files would be slightly corrupted, and I would
blame it on the PAR software (sorry Gus and Greg). When the new version came
out and I still got the corruption, I started looking deeper.
Gateway sent me a replacement (like pulling teeth) motherboard, 64M RAM, and
cables. The replacement parts worked. When I received my latest computer, I
kept getting a strange error message in Windows when I ran a particular
program. I loaded the software onto another computer and it worked just fine.
I got to comparing the .exe's between computers, and they were different. As
my temperature began to rise, I performed my copy test and sure enough –
failure. Determined not to talk to tech support again, I thought out the
problem, replaced the hard disk cable with a shiny new one, and the problem was
fixed.
This problem is worse than a virus, because every type of file is at risk. I
have over 2 months of work that may have one bit flipped here and there. My
PAR animation had glitches in one or two frames. My windows program would give
me an insufficient memory error. What about all my 3ds project files??? I
hate computers….
Again, this has happened on the last two systems I purchased from Gateway. I'm
not sure if the problem is the cable quality, or the cable installation, but
replacing the cable seems to have fixed the problem. Run the copy test on
several files to several locations, preferably to different disks.
byron
engineering arts
thanks for the post Byron.
Gateway Service??? I'd call that a misnomer for sure. In the shop here we've
got 20+ G2k P5-60's. 90 percent of the time, they run beautifully. One of them
is a pain in the boot. File transfers seem to be a consistently bad problem, as
we run Acad and 4+ gigs of drawings over a Novell 3.11. Occasionally though, a
file just gets buttered really bad and I've got no explanation. (Talk about
upset users!) So there is definetely a problem out there with some G2k's. To
add some fuel, an HP Tech that G2K sent out to fix my worst performer, (this
after I replace a MB, RAM, 2 HD's, one Video, and a power supply) thinks they
had a bad batch of mother boards come through. My beef is in that Gateway
refused to send a whole new box. I'll try the file comparison trick though.
That hadn't occurred to me. Good luck to all Gateway victims and keep fighting!
-noel at MEIMSA
Thanks for the feedback Noel..
Byron:
>> The files would be slightly corrupted, and I would blame it on the PAR
>> software (sorry Gus and Greg).
All is forgiven, now that you found out what it really is! <bg>
Greg Pyros
Byron,
This may make some people out there completely freak out, but… I know of
several instances where Gateway has shipped computers with VIRUSES already on
them! When I got my first Gateway five years ago, it came with the Jerusalem-B
virus on the hard drive; Tom Hudson also got a Gateway some years ago, and it
was virused. This is horrific beyond imagination: when the PC you get comes
directly from the factory with a virus already on it.
Sure hope they've fixed this problem the last few years, but be warned: check
any new computer you get, just in case. It *can* happen.
— Jon
Jon,
Thanks for the warning. Since I couldn't be sure of the integrity of any data
on my HD, I formatted and reinstalled everything. I've spent months trying to
get all my hardware and software working together, and it FINALLY IS WORKING!
Now could someone please tell me what I'm supposed to do with it?
byron
John –
I've done the "minimum boot" routine, which included stripping out the DOS
memory manager, drivers for the CD Rom, etc, with only about a 10-20 percent
improvement in performance.
Of course, this is sufficient improvement to justify a 3D Studio-only boot,
which I use when I don't need Windows or other DOS programs.
Bob Weil
>>I've done the "minimum boot" routine
If that doesn't fix the problem, don't know what else it could be, unless maybe
it's some setting in the CMOS (I_think_I remember someone saying they'd changed
something in their CMOS that had speeded things up (it might have been
shadowing enabled/disabled); I'm probably just misremembering things, though
(it may not have even happened and I may just grasping at straws), so don't
quote me); sorry I couldn't be of more help. Just as a FWIW, assuming 3ds
doesn't swap, I get the same render times whether or not I use my Windows boot
or a minimum boot.
John Stetzer
JWS
Jonas –
<<gateway problems>>
Just thought that I'd add that I posted a similar message on the Gateway forum
to my message of 3/8 on this forum – as yet no response.
Would have thought someone on their technical side would have looked into it.
Oh well – that's customer service for you.
Bob
Bob,
>> …message on the Gateway forum to my message of 3/8 on this forum – as yet
no response.
I'm not surprised you haven't heard from Gateway. I checked out their forum
last week for the first time – man, talk about a lot of hostile people. I've
never seen so many life threatening messages. The latest PC Magazine has an
article about all the unhappy Gateway customers. I'm sure you'll eventually
get a response.
I never realized just how civilized this forum is. Must be the karma from all
the 3ds Gurus.
byron
I have no problems with speed on my machine however,
I also have a gateway P5-90 that I have had a problem with since day 1. The
thing hangs intermittently whenever I try to render a tiff sequence. And I
recently tried to install OS2warp and the crash proof program crashed. I then
checked my simm chips to find that I had chips that were not all the same.
As of this writing Gateway is sending me some matched memory chips to replace
those in my machine and Intel is sending a new pentium CPU.
If this corrects the problem I will be sure to let everone know.
Glenn –
What do you mean specifically when you say "not matched?" My first sixteen and
second sixteen meg are two different types of chips (though the same speed and
manufacturer). The newer SIMM accomplishes the same memory with less physical
chips. In fact, the Micronics motherboard in my 486 and P-90 (? – I'll need to
confirm this) will only support two 16 meg SIMM chips of one variety, and two
of the other, installed in a specific order.
Thanks,
Bob Weil
Bob,
Did you ever uncover a solution to this problem? My 3D artist has a Gateway
P-90 that exhibits this problem. He has found that pressing ANY key (not just
PF11) to fill the keyboard buffer will un-stall 3DS.
Thanks for your informative message. The fact that the stall can be affected by
memory management and/or use is especially interesting. I'll have to run some
more tests on his machine to examine this factor. What XMS memory managers have
you tried?
Having read through the entire thread here, it seems that a number of people
have machines that do not experience the problem. My artist's machine is less
than a month old — I wonder if the working machines are older?
–Ron