T.R | Title | User | Personal Name | Date | Lines |
---|
3455.1 | Xetec got slammed on USENET | LODGE::LEN | David M. Len | Wed Feb 07 1990 17:27 | 7 |
| As I remember there was an intense slam on USENET about how the review
reccommended the Xetec. The posting flamed Amiga World and the author
for shoddy testing. The USENET message said that the Xetec would
corrupt data if MAXBUF was at the normal setting. They claimed that
when set to a low enough value to prevent corruption, that its speed
was not as great at the article reported. Didn't Amiga World print a
slight correction to that review, a month or so later?
|
3455.2 | Three Daves in a row | STAR::ROBINSON | | Wed Feb 07 1990 19:51 | 5 |
| Amiga World did print a retraction a month or two later. It just goes to
show that you should always cross check your recommendations just
as Dave is doing here. Actually I suspect the Xetec is OK, just not
number 1 as the original Amiga World stated.
Another Dave ;-)
|
3455.3 | I Love Xetec! | USRCV1::MONTREUILM | Customer Services Rochester N.Y | Wed Feb 07 1990 22:24 | 48 |
|
I've been using the Xetec FastTrack on my A500 for about 7 weeks
now with nothing but good things to say about ease of install and
setup. What and where is this evil MAXBUF setting ? I'm looking
at the manual and I see a setting for buffers but no such thing
as MAXBUF. I guess I would be cazy engough to try setting it to
the normal or even the max if someone could tell me where it is.
I use a Seagate ST296N 84MB drive (cheap and big not too slow at
28ms). I choose this product over the others available for the
500 due to the small package that clamps on the expansion port.
That package holds the SCSI adapter and an optional daughter module
with space for four SIMM memory modules (I use two 1 MB chips).
You can install 4MB chips for an extra 8MB. The external box can
hold a 3� or 5 inch drive. Most of the space in the external box
is taken up by the power supply board.
Ease of setup and use can be demonstrated by actually booting off
the unit 3 hours after walking in the door and finding the package.
This included installing the disk itself (you can get one preassembled
and tested), doing a low level format, making partitions, and cranking
in the software (ARP 1.3). Not having much experience in SCSI stuff
on PC's I was quite pleased. They supply a floppy to boot off that
uses graphical interface to configure the drive. I never touched
the mountlist in devs: .
I'm fairly sure this box is not a speed demon, but I didn't by it
for that. The same logic as a car, you don't need to go a 150mph
to be comfortable. I never did much testing with the interleave
setting (I left it at 1). Anybody who knows how to determine this
without repeated testing (I think this requies a low level format)
please let me know. I did run diskspeed 2.0 on a 10mb partion that
gave the following results;
Intensity: MED
7 Files/s Create
15 Files/s Open/Close
48 Files/s Scan
15 Files/s Delete
153 Seek/Read
I don't think these are at all good but I'm not so sure I would
notice a differance as a user if they were better. Buffers were
set to 10 I think when I ran this. Ask more questions if I left
something out.
Marty
|
3455.4 | Beware of blind devotion | LODGE::LEN | David M. Len | Thu Feb 08 1990 09:18 | 28 |
|
I love my Hardframe too, but if there are any known problems with it I
want to know about it.
I am sorry for the confusion (I work on to many different systems) the
parameter was related to "Maximum Transfer" (i.e. the biggest block of
data that the drive/controller could ship in 1 request/operation). If
this parameter is not explicitly set in devs:mountlist the OS will use
its standard default. The USENET posting's main flame was that the
controller software did not detect/report the problem, but just
corrupted the data. Thinking about it if the default value caused data
corruption Xetec would probably be out of business. The USENET poster
must have increased the parameter in a effort to improve performance and
wound up with a trashed file system (with the tone of the posting I was
sure he was speaking from personal experience).
I did not mean to imply the the Xetec controller was trash, I was
reporting information I read about 6 months ago (Xetec may have
corrected the problem). But the fact remains that the performance
numbers for the Xetec controller as stated in Amiga World are wrong.
For large block transfers the controller quickly returned trashed data,
therefore making it look fast to the test software. Someone using the
Amiga World article to buy a drive controller should be aware of this
information.
If you want to get the original posting, it should be in the notes file
fed from comp.sys.amiga. A title search on Xetec should get it.
|
3455.5 | what I remember | SAUTER::SAUTER | John Sauter | Thu Feb 08 1990 10:13 | 27 |
| I think the problem was that drivers are supposed to accept any length
buffer, and issue multiple requests to the hardware if necessary to
accomplish the whole transfer. The Xtech controller can't do long
transfers reliably, so the driver should have divided a long buffer
into several short ones.
The driver wasn't doing this, but nobody noticed because the old file
system never used buffers longer than 512 bytes. When the Fast File
System came along, the Xtec broke because FFS will occasionally use
a very long buffer, for example to read in a large program.
Recognizing this class of problems, Commodore introduced a new
parameter into the mount list which limits the size of buffer that
the Fast File System will use, thus avoiding the bug. The default,
of course, is that the buffer size is unlimited.
AmigaWorld ran their benchmarks with the buffer size set to the
default, and got some very good numbers for the Xetec. Unfortunately,
part of the goodness was due to the Xetec not transferring all the
data, and the benchmarkers didn't notice that. When they set the mount
list parameter low enough to permit the Xetec to work correctly, its
performance fell into line with the other controllers.
AmigaWorld was flamed for doing a poor benchmark, and apologized in a
later number of their magazine. Before making any decisions based on
their first review, you should read the follow-up.
John Sauter
|
3455.6 | I've always wondered... | EUCLID::OWEN | Homer Simpson for Governor | Thu Feb 08 1990 12:36 | 8 |
| Just curious...
How do you pronounce this product name?
Is it 'zee-tek'? or something else...
Steve
|
3455.7 | | HPSCAD::DMCARR | Asleep at the mouse | Thu Feb 08 1990 13:09 | 16 |
| Re: .6
> How do you pronounce this product name?
> Is it 'zee-tek'? or something else...
Yes, zee-tek is correct (I called for literature a while back & that's
how the person answering the phone pronounced it).
An additional question to any of you Xetec owners: does this drive
feature auto-park? Reason I ask is there's a Xebec program (typographical
error or totally different hard drive manufacturer?) on Fish disk
224 which makes it possible to use a Xebec drive with FFS and has a
program to auto-park the heads.
-Dom
|
3455.8 | | ULTRA::KINDEL | Bill Kindel @ BXB1 | Thu Feb 08 1990 14:08 | 12 |
| Re .7:
> An additional question to any of you Xetec owners: does this drive
> feature auto-park?
The Xetec Fast Track is the controller itself, to which the question
isn't applicable. Xetec packages the Fast Track alone and with various
hard disks.
My A590 controller/drive came with a PARK program, but I don't know if
I need to use it. It would be helpful if someone had a list of drives
that tells which ones auto-park and which ones don't.
|
3455.9 | Most drives do autopark these days | TLE::RMEYERS | Randy Meyers | Thu Feb 08 1990 18:26 | 8 |
| Re: Parking the drive
I have the technical documentation for the Seagate and Quantum drives.
I seem to remember that all the Seagate SCSI drives autopark on power
loss (I sure that the ST-157N, the model I use to own did). The
Quantum SCSI drives also autopark.
So, you can ignore those park programs.
|
3455.10 | Don't need a mountlist to change MaxTransfer | TLE::RMEYERS | Randy Meyers | Thu Feb 08 1990 18:50 | 34 |
| About MaxTransfer:
It's true that the system default is for a MaxTransfer of infinity
(actually, one 68000's address space worth, or 24 addressing bits).
But, that doesn't mean that the user has be know about the MaxTransfer
for it to be changed from the default.
I just bought a new A2091 disk controller (It's great!), and I noticed
that it uses a non-default MaxTransfer, but since the controller automounts
itself, the only way I could tell was by writing programs to probe the
AmigaDOS internal data structures.
If you use the standard AmigaDOS mount command to mount the drive,
you have to have MaxTransfer in the mountlist entry to change the
MaxTransfer from the default.
But, if you use some special vendor supplied mount command replacement,
then the replacement command probably is going to do the right thing.
If the drive is mounted because it's driver is in the Expansion
drawer and you give a BindDrivers command, it probably is going to
do the right thing.
If the disk controller automatically mounts the drive, it probably
is going to do the right thing.
So Xetec can be doing the right thing even if there is no MaxTransfer
in an AmigaDOS mountlist entry for the drive.
Amiga World might have screwed up because they noticed something
like: "Hey, the drive works even if I don't use XetecMount. I can
use the usual AmigaDOS mount command."
So, how does a Xetec mount the drive?
|
3455.11 | In search of... | DUGGAN::MCCARTHY | Mike McCarthy MRO4-2/C17 297-4531 | Thu Feb 08 1990 20:27 | 7 |
| Randy
Where did you get the 2091? The Memory Location didn't have any,
and didn't know when they would. They had them priced at $335
($750 with a Quantum 40 Meg drive).
Mike
|
3455.12 | Uses Binddrivers | FREEBE::MONTREUIL | Marty in Rochester N.Y. | Fri Feb 09 1990 23:11 | 28 |
|
Re. 10
The Xetec invokes the bindriver command to make use of a "harddisk"
file in the expansion drawer off a normal partition (boot:) when
using V1.3 kickstart. I used newzap to look at this driver and the header
shows that it is V1.4 with a date of 16 Aug 89, which is after the
Amiga World issue came out with its faulty testing. So another
possibility is that there was a problem and it was fixed or maybe
it was updated for other reasons. One more file exists in that
expansion drawer called v1.4cio.
If AmigaWorld did use a mountlist entry to configure the drive
they should have reported it. Also it seems to unfair to tweak
something like that since most users wouldn't do so and they are
no longer comparing disk controllers as they come out of the box.
When considering a hard disk controller on the A500 the total
package needs to be looked at since adding memory and additional
products is more difficult. I think the Xetec does a good job in
that catagory. If I owned an A2000 then speed, and compatabilty
with other boards would be stronger factors.
I should also mention Xetec makes a SCSI Tape unit for backups.
Thanks,
Marty
|
3455.13 | so what does it really do? | WJG::GUINEAU | | Sat Feb 10 1990 07:32 | 6 |
| Marty, have you run DiskPerf on it yet?
What kind of numbers (for you particular hard disk) do you get?
JOhn
|
3455.14 | Results are in.... | USRCV1::MONTREUILM | Customer Services Rochester N.Y | Sun Feb 11 1990 20:05 | 24 |
| Using DiskSpeed 2.0 with interleave set to 1.
Test Intensity: Med
7 Files/s Create
15 Files/s Open/Close
48 Files/s Scan
15 Files/s Delete
153 Seek/Read
Buffer Size 512 4096 32768 262144
=====================================================
Bytes/s Create 25056 42887 47772 50907
Bytes/s Create 26323 49344 53187 55924
Bytes/s Create 26662 49907 53229 55924
I'm thinking of giving Xetec a call to see if they can recommend
the best interleave setting for this ST296N. The manual expects
you to try various settings and run a disk speed program. Since this
involves a low level format each time I'd like to avoid this trial
and error method. If they have an answer I'll post the results
here.
|
3455.15 | Try and interleave of 2 or 3 | TLE::RMEYERS | Randy Meyers | Tue Feb 13 1990 16:21 | 11 |
| Re: .14
I predict the best interleave will be 2 or 3. Try both, and pick the
fastest.
An interleave of 1 is usually not good for an Amiga (at least a 68000
based Amiga). The numbers you report are fairly typical for a drive
with the wrong interleave. Changing the interleave will probably
increase the disk performance by a factor of three or four for the 4096
buffer size case, and will probably increase the very large buffer size
even more.
|
3455.16 | System Eyes has (had?) A2091s | TLE::RMEYERS | Randy Meyers | Tue Feb 13 1990 16:27 | 9 |
| Re: .11
I got the 2091 at System Eyes in New Hampshire, phone (603) 889-1234.
The price was in the $360-$380 range (I don't remember the exact
price).
Three weeks ago, I bought the only one they had in stock. I don't know
if they've gotten any more in. They are in short supply because Commodore
is stuffing them into Amiga 2000s to turn them into Amiga 2000HDs.
|
3455.17 | Interleave question | ENOVAX::BARRETT | The optical mouse that roared | Tue Feb 13 1990 16:50 | 5 |
| I'm not sure I can use different interleave values because I'm using a
hardcard through off my bridgeboard, but:
If you change the interleave, am I correct in assuming that you must
reformat the drive?
|
3455.18 | AmigaDOS format after interleave change | TLE::RMEYERS | Randy Meyers | Tue Feb 13 1990 18:57 | 6 |
| Re: .17
> If you change the interleave, am I correct in assuming that you must
> reformat the drive?
Yes. Changing the interleave scrambles all of the blocks on the disk.
|