#SCSI II & Networks
13 messages in this thread
Just an update. I finally landed that big frame grabbing job and have been
really putting the old 5850 through the paces in the last two weeks. I had to
build up a dedicated setup for running the diaquest for this operation. I got
a new 486-33 MB EISA-VLB with 1MB of SRAM 16 Meg Dram. 1.34GB SCSI II with a
DPT EISA controller. Paul, I never dreamed that EISA was so much faster than
ISA-VLB. Here's some questions I thought you could help me with. The
controller really needs the cache module. I tried Smartdrv but as expected
when running 3DS it interferes with the rendering modes. So far it seems OK
with Action Animator. How much cache would you recommend for dealing with 3/4
MB TGA's saving to disk? My old IDE-ISA system used 4 Meg cache on the ctrl
and the save operation never held up the tape operations. The new SCSI II
without cache holds up the tape preroll by 6 seconds per frame. ie. 20seconds
per frame before and 26 seconds now without cache. Do I need the 4 meg or will
the DPT half meg daughter card be enough? I split my ISA bus Dram so I only
have 16meg on each machine now. With ram prices what they are I decided to
put the money into a 1 meg cache. I hope this was a wise move for the long
run. RAM is slowly coming back down in price now but it will be another month
or so before I buy. When I finish this big frame grabbing job I'll price out
a DX66 to beef up the rendering. Right now prices on the 66 are falling fast.
Networking: I use WFW with a thinnet hookup. I tried to do a dual rendering
on two machines at once and that worked ok with the 66 doing 3 frames for every
2 on the EISA 33 machine. When done I launched WFW and tried to transfer the
TGA's to the EISA machine for output to tape. Can't run 3DS or action animator
in WFW you know. The problem was that about every 10th or 13th frame aborted
the disk to VTR due to corrupted file. I finally did a tape backup and
restored to the other machine. It actually was faster than the network. Is it
common to get corrupted files on the network? I never seem to have a problem
with the smaller files in databases and spreadsheets.
Lastly, I attempted to design my workstation arround these two CPU systems
using one monitor, one keyboard, two mice. I got a keyboard/monitor switch box
from T-COM. It is not satisfactory. It switches the monitor with ghosting on
the display. I've got some ideas to correct this which I'll try next week.
The keyboard switches but occasionally causes the other machine to reboot
during the switching process. I've resorted to a two keyboard station but this
can get real confusing with one monitor. Any ideas?
Pardon the jump-in, Don, but I've got an idea about your switching problem. I
had the same sort of what I figure is a mechanical switch bleed problem with a
single-keyboard/dual CPU setup too. Try getting a three or four output switch
and seperate the two outputs by an empty one. This seems to keep the keyboard
signals discreet and minimizes this sort of problem, at least it did for me.
Should fix your monitor problem too, as I my setup worked pretty good.
Hope this is somewhat helpful,
-Alan Iglesias
Hey, Thanks for the ideas. I am using a two position switch. I didn't think
the isolation would be a problem but I learn things every day. The dealer
seems to think the switch is defective because it should work, he says. I'll
let him handle it for now. I've got to many projects going to experiment on a
$25.00 switch. I'm putting your suggestion in my backup ideas box for now.
Alan: the switch problem is solved. Paul Linde's suggestion worked. ie.
supplying power from one CPU and only switching the signal data. The video
ghosts is still puzzling. It's not getting signal bleed from the other cpu, I
checked this out. It appears to be either the extra length cable or the switch
itself. I should have an answer today when I get time to do some more
detective work.
Hi Don,
Glad things are working out. Actually, I *have* seen ghosting with a long
monitor cord extension, so that just might be it…
-Alan
I just verified it. It's not the switch box. –Just the double length cable.
Don:
You need to have as much cache on the controller as the largest file you are
saving to minimize any speed hits. You should be able to get by with a
one meg, but two would work every time.
Greg Pyros
Thanks for the reply. I just spoke to DPT and they recommended 4 meg for
smoothe maximum speed using DOS. Their cache uses only half (2M) for reads and
half (2M) for writes. Going over 4 meg is a waste of memory with dos,per DPT.
Don,
Congrats on the work and new equipment. EISA is definately nice, it's the only
thing we run, and we bus-master everything! There isn't anything that comes
close to it.
I'm not entirely sure why your controller is holding up your tape operations.
Even without a cache, at it's bare minimum configuration, it should save frames
of that size without any delay at all. Especially if the EISA is fully
configured, it should fly without a cache. Can you tell me a little more about
your setup? Are you rendering to memory and then doing a simultaneous disk
save/frame dump to tape? Give me a little bit more info and I'll see if I can't
help more.
The network problems are odd too. The file corruption shouldn't happen at all,
especially not as sporadically as every 10th or 13th frame. We run an extremely
large Netware 3.11 LAN but we Alpha/Beta'd WFW. We really dogged the program
and it held up well. I would probably start by totally checking the
configuration of the controller. Did you go into the EISA CFG setup and set the
bus speed for the card? I know you're knowledgable about the equipment already,
it just seems that with the slow data dump, and the sporadic file corruption,
that the controller isn't operating correctly. Also what does your bootup
looklike with regards to the DPT?
As to the monitor/keyboard switch … we actually use one monitor/keyboard for
every six rendering machines. We made our own boxes and they've worked well.
Simple multi-contact switch setup. However, one thing that we needed to do was
to make sure that the keyboard always got its power from one unit. Initially
when the units switched, the power flux caused the keyboard to lockup and the
machines to go south. Also depending upon the monitor, you may need to either
turn it off/on during the switch or use an empty channel in the middle of the
switch to make sure that there isn't any signal bleed
[>> Continued in next msg]
[>> Continued from previous msg]
from one unit to the next.
I'll think about this while I'm nailing plywood to my windows. 🙂 Hurricane
Emily will be here shortly.
If you have a moment, give me a little more info about the config files, what
cards are in the EISA machine and what order you're dumping to disk and tape,
and I'm sure we can figure this out fairly quickly.
Congrats again on the work and the new equipment!
Paul
>> Are you rendering to memory and then doing a simultaneous disk save/frame
dump to tape? Give me a little bit more info and I'll see if I can't help more.
I rendered to the hard drive then use disk to VTR to record the frames to tape.
Time with ISA bus with 4 meg cache ctrl. is 3 frames per minute. Current time
with EISA bus no cache is 2 FPM. There is about a 7-9 second read time per
frame that I have now eliminated by using smartdrive. I just ordered the half
meg module for the DPT which I'll try before spending for the 4 meg memory
module. This is an important issue because over the course of the project it
could save a couple of days of time on the machine. That's translated into a
couple of days the VTR is sitting on pause, right?
Good points about bus speed. I just used the ECU program and selected defaults
for everything. EISA is new to me so I'm learning one step at a time and I've
got customers waiting in the middle of all this, so I have to be careful not to
bite off more than I can chew. For now the network is a minor problem but I
thought I'd mention it. The DPT is the only EISA card in the system.
Interesting about your switch and the power flux problem. I'll have to open
the box and trace the wiring to see if that is possible. Now, the cpu's
speaker beeps and keyboards lock up as you stated. I'm going to check this out
today. It's a good lead. Thanks.
>> Also what does your bootup looklike with regards to the DPT?
I get the copyright statement that according to the manual indicates OK!
Then I get a list of drives with some nomenclature listed, I,m not sure how to
interpret yet. Then into config.sys stuff.
Don't hit your thumb with the hammer!<g>
Don (kicking those hurricanes up north) Landis
—> Lastly, I attempted to design my workstation arround these two CPU
systems using one monitor, one
keyboard, two mice. I got a keyboard/monitor switch box from T-COM. It is not
satisfactory. It switches the monitor with ghosting on the display. I've got
some ideas to correct this which I'll try next week. The keyboard switches but
occasionally causes the other machine to reboot during the switching process.
I've resorted to a two keyboard station but this can get real confusing with
one monitor. Any ideas?
I recently ordered a switchbox from HYMCO that will do what you're talking
about. It's a 4-way (ABCD) and has a connector for monitor AND keyboard. It
runs just fine, and I use it along with a standard 9-pin 4-way box to do the
mouse.
And the box lists for about $40.
Thanks for the info. I got the Keyboard switch to work thanks to a suggestion
from Paul Linde and the ghosts on the monitor has been narrowed down to
insufficient shielding on the extra monitor cable extension from the box to the
CPU. If I shield each R-G-B line the ghost disappears. Unfortunately,
generic monitor extension cables are only shielded overall.