Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext'd related?)
- From: "Folkert Rienstra" <see_reply-to@xxxxxxxx>
- Date: Wed, 20 Jun 2007 01:00:00 +0200
"Michael Baeuerle" <michael.baeuerle@xxxxxxx> wrote in message news:ou9uj4-501.ln1@xxxxxxxxxxxxxxxxxxx
Folkert Rienstra wrote:
Michael Baeuerle wrote:
Folkert Rienstra wrote:
Michael Baeuerle wrote:
[...]
You don't get the correct time even if you use the half track-transferrate.
'half track-transferrate'?
Seagate has specified 10MByte/s "track-transferrate" (when
accessing multiple sectors on the same track with 1:1 interleave).
Because formatting works on the whole disk, the 4LP cannot reach this
value because of seeking and head-switching. The 7.5MByte/s average
value you have used for the Atlas2 is realistic for the 4LP too.
Right, so how about that half track transfer rate of yours now.
Because with the 7.5MByte/s the result of your calculation does not
match reality
What reality.
You are talking about Seagates where as subject is a Quantum drive here.
- so I have increased the overhead margin
There is no such 'overhead margin' in my calculation.
My calculation is derived from actual in the wild figures.
and tried again with 50% instead of 75% ...
That's just plain silly, that 75% has nothing to with overhead at all.
There is no percentage in my calculation, just the actual and very real
sequential R/W throughput figure derived from the begin and end
throughput speeds as measured by benchmarks which works out to an
average of ~7.5 MB/s with the max/med/min values that I supplied.
Have you not been paying attention?
but even then the calculated time is too short.
Using 7.5MByte/s leads to the ~10 minutes, using the "half
track-transferrate" (5MByte/s) leads to ~15 minutes.
So I ask again: 'half track-transferrate'?
10MByte/s are specified,
Actually, 80-12x Mbits/second are specified, you then pulled that 10MB/s out of your hat.
7.5MByte/s are a realistic guess.
As by magic. I have no idea where that 7.5 figure comes from.
I have added 5Mbyte/s as a "worst case" value
If only you did, you tied that to the interface rate specifically.
- only to check if I can reach the real format time with your formula now.
Silly and totally meaningless. The only figures to use are the actual ones,
not some sucked from your thumb calculation.
Calculating with lower values makes no sense because 5MByte/s you
can get on the external interface.
What has that got to do with it.
Checking above and below the guessed value.
Upper limit is the theoretical maximum,
Which is?
lower limit is the interface transferrate.
Which for the Quantum is 20MB/s.
You can get 10MB/s on the bus too.
Are you boxing yourself into a corner again?
No.
Yes.
What is relevant for the formatting time is the sustained avarage
transferrate.
Right, so nothing whatsoever to do with interface rates at all
(provided the drive is connected to a proper HBA for that drive)
You can never get 10MByte/s sustained avarage on the
interface if the disk cannot do it internal.
Exactly, and the same goes for your 5MB/s.
Btw, the Quantum can do 9.5MB/s sustained in outer bands, so it's more
than capable to fill a 10MB/s bus.
The 7.5 MB/s used in the calculation is merely the average of 9.5 MB/s
at the beginning of the drive and 5.5 MB/s at the end of the drive.
Because the relevant value is not specified by Seagate, I have guessed
it to be 7.5MByte/s.
Which appears to be spot on but has nothing to do with 75% of whatever.
But because this is a guess, it makes sense to check with a lower value too.
No, that makes no sense at all.
There is no point in guessing, there is no value in it.
The values I used were real world actual ones.
The value I have choosen (5MByte/s) is 2.5MByte/s below the guessed
value (the same as the nominal 10MByte/s are above the guessed value).
And totally meaningless. You can pick whatever you want.
In other words: Your calculation cannot explain (for this disk) why the
formatting take 4 times longer in reality.
Well, nothing can, as you demonstrated yourself in comparing Barracuda
4 with 4LP. It's just hit and miss. And not very well documented, if at all.
One IBM manual suggested "An average of 60 minutes should be allowed
to complete a "Format Unit" command".
They didn't even bother to detail it for the 2 available capacities within
that particular model. For some other models it wasn't specified at all.
That's the point.
Exactly, so why the wild theorizing with plucked from your arse numbers.
The ones I used were actual real world ones and should at least provide an
actual minimum time.
[...]
You surely find one that really have 20 minutes, but even slower as the
4LP you will find too. IMHO there can be no single "format time" formula
for all disks.
Of course there can - if they all do it the same way.
How many different kinds of (standard) formatting can there be ex-
cept for newer and older drives, with and without on-disk sector IDs.
What procedure needs 2 or more revolutions to complete for each and
every track. The only thing that I can think of LLF taking much more
time is that it involves verification at all times, once using writecheck
and if ordered, once again using a seperate verification run.
Beats me what the added value of a seperate verification run is then.
There may be issues with the PRML encoding [1]. Because with PRML the
bit density is normally so high that single bits in the raw data does
not have valid values any more, the decoder must use "maximum
likelyhood" pattern matching mathematics to decrease the error rate to
acceptable levels ... the firmware maybe want to recalibrate amplifiers,
digital filters or other software units in the decoder DSP.
A track completely filled with defined init patterns is ideal for such tasks.
Uhuh. And of course this is only an issue with Low Level Formatting
and not with your normal run of the mill writing of user data
Yeah, that makes such a lot of sense.
.
But finally nobody (except the manufacturer) knows because it is not
documented.
Micha
[1] The Barracuda 4 use RLL, the 4LP use PRML
- References:
- Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext'd related?)
- From: da9000
- Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext'd related?)
- From: Michael Baeuerle
- Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext'd related?)
- From: Folkert Rienstra
- Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext'd related?)
- From: Michael Baeuerle
- Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext'd related?)
- From: Folkert Rienstra
- Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext'd related?)
- From: Michael Baeuerle
- Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext'd related?)
- From: Folkert Rienstra
- Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext'd related?)
- From: Michael Baeuerle
- Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext'd related?)
- Prev by Date: Re: SCSI Ultra2, Ultra160 confusion
- Next by Date: Re: SAS and SATA (arrays) on one controller (LSISAS1068)?
- Previous by thread: Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext'd related?)
- Next by thread: Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext'd related?)
- Index(es):
Relevant Pages
|