#Microbotics Hardframe
49 messages in this thread
Hello:
I've been looking into HD controllers for A2000's, and am just about ready to
buy one, having decided on the Microbotics Hardframe as the one that best suits
my needs. Unfortunately (?), I recently heard that the hardframe has many DMA
contention problems that end up slowing the access enormously. Along the same
vein, I also heard that more fast memory will eliminate this problem. I'd
appreciate any revelations — before I go and splurge for the Hardframe.
Everything else I've heard about the HF makes it out to be an excellent
controller.
Regards,
-Kenneth
I've been running my HardFrame a couple of months now and I LOVE it, it's easy
to set up, VERY fast (even with my SLUG-DRIVE). I have yet to see a read/write
error, and it AutoBoots, NOW. I also heard a lot about the DMA contention
problem (mostly 'cause I know a lot of guys who run CLTD productsand CLTD loves
to talk that up) – I have not noticed any problem, but to be honest I don't do
a lot of stuff in overscan mode – (I believe this is when the problem rears
it's head – if I'm wrong I'm sure somebody here will correct me). You can
'automount' all partitions or just set 'em up in your mountlist and use the
mount command. You should be aware that HardFrame does NOT support the Adaptec
cards, so you will need to be sure and have a SCSI device. Good Luck…
Rick:
Much appreciated. The 2090A was the only controller for which I consistently
heard rumours of DMA conflict, and that was only in overscan. I didn't have
any first hand information until a few days ago, it seems having fast mem more
or less eliminates this problem.
How much memory does a partition consume when mounted? I have a friend who
until recently had a 1 MB A500 hooked up to a ST-506 120 MB Maxtor via a
Palomax interface, and apparently the software for the 'max requires something
like 80 K per partition (not sure of the maximum size per part). I'm stuck
with 1 MB but should be upgrading to 3 MB within the month — nevertheless, I'd
like to know.
Regards,
-Kenneth
Kenneth,
It will vary with the manufacturer, but in any case, partitions eat memory.
There is only one reason I have ever found to partition a disk, and that is to
allow a more speedy restore from backups. other than that, you should go with
as few partitions as you can.
-larry
BTW, how much memory does each partition eat?
Michael St. Laurent
Michael,
Well, it depends on the manufacturer's software, but FFS partitions, as Dean
has pointed out, use a lot from having the FileSystem loaded for each partition
(dumb). In any case, the minimum would be the disk buffers used for each
partition.
-larry
Larry,
Yeah, there's a good reason that partitions eat memory, especially FFS
ones. CBM, in it's infinite wisdom, wrote Mount so that when you request a
partition using FFS, it loads a copy of FFS….. FOR EVERY PARTITION. The
filesystem is by definition reentrant. There is no reason that each partition
couldn't use the same physical code (12K of it). It's only that mount is too
stupid to use a copy if it already exists. <grrrrr>
-Dean
Arrrgh! You're right Dean.. I just checked. Oh well, perhaps it's time to
rewrite mount?
-larry
Larry,
I've made the request to CBM, although I can probably guess the eventual
results. 1.4 will have the problem fixed, but it's debatable if we'll see a fix
from CBM before then.
-Dean
Is there any reason for Mount to act in this manner? Is the ARP mount any
different? If there is no reason for this maybe the ARP mount can be written
to not do it. Just a thought. <grin>
Michael St. Laurent
Michael,
I'd love for ARP to do mount right. Altogether now… "How bout it
Charlie???"
-Dean
Dean:
From what you say, I take it that it's a problem with MOUNT not using the same
code, and not something else? In this case, does the ARP version of Mount work
differently?
Regards,
-Kenneth
Kenneth,
The problem is really that CBM is playing it's old game. "Ready, shoot,
aim". CBM developed the standard needed to allow autoboot to a FFS device,
which basicly consists of a list containing pointers to all loaded filesystems.
Then they went and released 1.3 and a Mount that ignored the information
available.
I've run ARP Mount and gotten the same results, so Charlie and crew just
duplicated the 1.3 functions.
-Dean
Larry:
Is there a limit on the size of each partition?
Regards,
-Kenneth
Kenneth,
Yes, a partitoon cannot be larger than 2 Gigabytes.
-larry
Well Ken, I wondered the very same thing after seeing some references to
HardFrame using about 150K per partition. I called Microbotics and they were
extremely helpful, ran some tests and called me back within two hours (I was
impressed – my only previous experence was with CLtd – try and get Tech support
from THEM sometime ) Anyway on my 1meg A2000, set up with 2 partions, and 20
buffers per partition, I boot with roughly 760K free (not much else
running-conman, WShell and DMouse). Microbotics told me about 75K per partion
with minimal buffers and that seem to be in the ballpark. I am now running 3Meg
(on a borrowed memory board) and run about 60 buffers on each partition just
for the fun of it (I'll have to give that board back very soon I suspect…) –
it's very fast. Have not seen a single read/write error since I installed the
hardframe. (could NOT say that about my old CLtd setup).
Kenneth,
DMA contention should only be a problem when you are running very DMA
intensive applications. I don't think anyone's actually done a serious study
of the affects of specific applications on DMA controller speeds.
I imagine that FAST RAM would solve the problem, since the DMA chips only use
CHIP RAM, while I assume the HARDFRAME can access any RAM.
I have the GVP Impact controller which I bought for two reasons. First, the
HardFrame was in short supply (read unobtainable) at that point; and second,
the hardware installation was a no-brainer since I bought the 80Q hard card.
Getting the HardFrame up and running definitely takes more hardware tinkering,
but once you've installed either one correctly, they both work like a charm. I
don't know anyone who's unhappy with either of the controllers. And I
certainly haven't heard of anyone who has real problems with DMA contention
under 'typical'
John
John:
Thanks, I don't anticipate any DMA intensive applications within the near
future, so I won't be too concerned about it 😉
I was giving serious consideration to the GVP 80Q HC as well, but several
things got in the way — I was originally going to mailorder it from the States
(I live in Toronto, Canada), but the total cost scared me into looking for a
more local solution. The GVP dealer here wats rather astronomical prices for
both the drive and the controller. I managed to find a deal on the Hardframe
and a separate SCSI drive, so…
Thanks for your help,
Regards,
-Kenneth
John,
You can DMA anywhere in the Amiga's addressing range. That's why you
can DMA into the A2620's 32 bit RAM…because it's in the addressing range.
Don
Aren't there some 32-bit memory boards that you can't DMA to? I thought I saw
someone here mention that a while back.
Michael St. Laurent
Michael,
Yup…those boards that don't auto-configure aren't in the Amiga's
addressing space…so you can't DMA into them.
Don
Please forgive my hardware ignorance, but if it is not in the addressing space
then how does the amiga access that memory?
Michael St. Laurent
Michael,
Because it's "attached" to the CPU.
Don
Don,
Dean Brown made a comment that he didn't think the GVP 32-bit
daughterboard was autoconfigure. Do you know anything? (I've been to busy at
work to call them and ask…)
John
John,
No, I don't know one way or the other.
Don
John:
I don't ever want to get into the position of contradicting something that
Dean said <grin>, but I asked a GVP tech SPECIFICALLY if a SCSI controller
could DMA into the GVP 32-bit memory, and he said yes. I asked this question
several different ways, each time searching the tech's face for signs that he
understood exactly what I was asking, and he appeared to. So, until someone has
one in his/her grubby little hands, I'm going to assume you can.
Ariel
Ariel,
Geeez, I don't come on THAT strong, do I? :*)
Actually I'm going to withdraw any comment I made about GVP's '030 board
and it's associated memory. It's highly likely that I mis-remembered something
I heard, and attributed "features" of one manufacturer to another. So, with
that said, I'm backing out of this thread altogether!
-Dean
Ariel,
Well, as it turns out, there is an element of truth in both statements.
You can indeedDMA directly into GVP's 32 bit memory, but they recommend
against it. The reason for this is that the '030 has both an instruction and a
data cache, (as opposed to the '020, which has only an instruction cache) and
the problem arises from data changing in memory while the processor has that
same data in its own cache. When the CPU has control of the data, it always
knows when its cache is invalid, but external devices are a different matter.
There are two ways around this. The first is to turn off the data cache (I
don't know if you can turn it off separately from the instruction cache or
not). The drawback to this method is that there is a considerable performance
hit.
The second method is to use the Mask parameter in the mountlist to exclude
the 32 bit memory from DMA. This turns out (according to GVP) to be the best
solution, since the processor is VERY fast, and programmed IO to 32 bit memory
is as fast or faster than DMA to it (bearing in mind the limitations of the
hard disk hardware).
Take it for what it's worth. I would have to play with one for a while to see
for myself.
-larry
Thanks for the research, Larry.
It turns out that our GVP cards arrived Friday, and I'll be seeing them for the
first time tomorrow. Since we have both C.Ltd (ick) cards handy and HardFrame
cards on order (not to mention my 2090 here at home), I should be able to bang
out a few diskperfs within a week or so.
I was hoping that I could get rid of that Mask parameter, but now I have my
doubts. The one good thing that could come out of this is if CBM creates a new
memory attribute (MEMF_DMA) for AllocMem(). While this doesn't help with the
current software, it WOULD allow application programs to take into account DMA
hardware.
Ariel
I have been using GVP and Microbotic's HardFrame for a while and realised that
the HardFrame slows down the machine more than the GVP… the difference isn't
that big but noticable.
Pat.
Pat,
Which GVP product are you referring to? The HardFrame is capable of raw
transfers of 5MB/second, although the DMA chip we use is is clocked at 12.5Mhz.
The Amiga can only handle about 597KB/second. I rather doubt that the HardFrame
is slowing down the system. It is more likely that the hard disk you're using
is slowing it down, and you only notice it with the GVP board.
Rick Stevens/MicroBotics
Rick,
You've stated that the Amiga is limited to 597KB/sec several times. I'm
curious, could you explain how that number was arrived at?
-Dean
Dean,
The hardware of the Amiga bus limits throughput itself, and AmigaDOS limits it
further. As to the actual methodology and measurement techniques used, I'll
have to ask our engineers about that. I don't know offhand how it is arrived
at, but it is accurate to the best of our knowledge.
Rick Stevens/MicroBotics
Rick,
Ok, I'd still like to hear how that number is arrived at…..
Now, the reason I asked is because, by my calculations, using a
reasonably good DMA device, the Amiga can actually transfer data at a rate of
3.58MByte/sec. (7.16Mhz clock, each memory access takes 4 clocks, for a memory
cycle rate of 1.79Mhz. Since the bus is 16bits wide, this calculates out to
3.58MBytes/sec) And for an actual measurement using diskperfa, I have a RAM
board that looks to the system as a disk device. It uses programmed I/O with a
standard 68000 processor. With diskperf and 32KByte buffers, I get a read rate
of 1.3Mbyte/sec. And that almost exactly matches what I should get considering
my sector move loop should move a longword in 22 clocks.
Stating that the Amiga can only transfer data at 597KBytes/sec is IMHO a
bit misleading. By no means is the limitation designed into the hardware of the
Amiga, although it is limited to 3.58MByte/sec.
Stepping off of soapbox!
-Dean
PS. If this message makes you want to grab your asbestos undies, I apoligize!
It's not meant as a flame, it's just that misinformation repeated, takes on the
aura of truth!
Dean, to support your results, when using the 2620 board, disperfs do go up.
e.g. I just did diskperfed RAM: And I got:
Buffer: 32k Read: 2,184,533 Write: 728,177
Khalid
Dean, I'll check into it.
Rick Stevens/MicroBotics
Rick,
2090, CDC Wren IV, diskperfa.
File create/delete: create 16 files/sec, delete 52 files/sec
Directory scan: 102 entries/sec
Seek/read test: 125 seek/reads per second
r/w speed: buf 512 bytes, rd 87381 byte/sec, wr 29454 byte/sec
r/w speed: buf 4096 bytes, rd 291271 byte/sec, wr 187245 byte/sec
r/w speed: buf 8192 bytes, rd 436906 byte/sec, wr 262144 byte/sec
r/w speed: buf 32768 bytes, rd 873813 byte/sec, wr 374491 byte/sec
Need I say more?
-larry
I'll check with our engineers.
Rick
Kenneth,
Hmmm, I've never heard of any DMA contention problems specific to the
HardFrame, tho the potential for such contention (under certain conditions)
exists with any DMA harddisk interface. I've had a HardFrame (and a Quantum
80S) since January–it's blazing fast and has given me zero problems. BTW, I
use a 680×440 interlaced Workbench and have noticed no slowdown whatsoever due
to overscan. Also, displaying hi-res, 4-bitplane images from within DPaint (or
by any other method, for that matter) causes no noticeable contention.
The HardFrame is indeed an excellent interface. Highly recommended.
-Dave
The HardFrame is the fastest hard disk interface for the Amiga. It has a raw
transfer rate of 5MB/sec. which is faster than almost any hard disk you can
name. It gets on the bus in 280 nS and off in 200 nS.
Rick Stevens/MicroBotics
I installed a Hardframe with a Quantum 80s this weekend. It is working good
except with autoboot used most of the games software I have tried so far will
not work. I would think that this is due to the software not knowing where to
find files such as "fonts" since there are two : one from the harddisk boot
and one from the game boot.
Is there any way to make the Amiga look at df0: first and boot from there if a
disk exist in df0: and if df0: is vacant to then boot from the harddisk?
Mike Firsching
Mike,
When you prepped your HD with RDprep, what did you set the HD's bootpri
value to? Mine is set to zero, which allows the system to boot from DH0: if
there is a bootable disk in that drive. If you set the HD's bootpri higher,
then the system will always boot from the HD regardless of what's in DH0:.
-Dave
You may have it, David. I set my priority at 5 for the first partition. I
wil experiment tonight and change it. What is the boot priority for dh0: and
how
can that be changed?
I'll tell you how it goes.
Mike Firsching
I have changed the boot priority of my first partition from 5 to 1 and
bingo!……the game software that was scrambled is now A.O.K..
Thanks David
Mike Firsching
P.S. Rick Stevens: I called your company about this and talked to person
named Mike and he told me it was a software problem and contact those companies
and see if they would upgrade their programs. Should I call him back to let
him know what the problem turned out to be?
Mike,
You're welcome. 8^) Glad you got things sorted out. BTW, when I said
"DH0:" in my last message I actually meant "D_F_0:". Oooops! Also, I don't
think there's any way to change DF0:'s bootpri…but you can play with the
bootpris of all other bootable devices, so it shouldn't cause any difficulties.
-Dave
'Sok, Mike. I'll do it. I remembered how to do it as soon as I saw Whap! put my
reply to you up. Sheesh! Is my face red!
Rick Stevens/MicroBotics
Mike,
I think that there is a way of doing it, but I can't recall what it is. I'll
check into it and get back to you as soon as I can.
Rick Stevens/MicroBotics
Rick,
No need to preach to the converted. I'm a satisfied customer. Make that
_very_ satisfied. 8^)
-Dave
Ah, glad to hear from one! I'm glad you like it. We slaved long and hard to do
it. Tell your friends! 😎
Rick Stevens/MicroBotics