sbp2 scatter/gather - "great loss" of speed
Pat LaVarre
lavarre at iomega.com
Wed Jul 4 06:23:13 PDT 2001
* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <lavarre at iomega.com>
*
> <ewa at apple.com> 07/04/01 01:00 AM
> t10 at t10.org
> Apple uses the "unrestricted page table"
> exclusively (except for the occasional
> ORB with no page table at all)
Ah, another chink of empirical character. Helpful, thank you.
> Several commercially available
> 1394-ATA bridges have bugs in this area,
> and we painfully double-buffer some I/O
> to them as a result,
> at a great loss in performance.
Holding to my focus on empirical reality ...
Can you confirm that by a "great loss" you mean something measurable?
You have a bridge to a drive, you change only the bridge by only fixing this
bug, and you see human-perceived speed increase notably? You change the
bridge back and you see speed decrease notably?
> ... some I/O ...
Or is "some" the key word here? Do you mean to say something less direct -
less scientific - something more open to conflicting interpretation?
Since most of the unrestricted page tables I see are in fact normalised to
physical page size, me, I would expect to see the potential of losing much
speed to double-buffering become actual only in the rare case where the page
table is in fact not normalised. (I hear the Windows version of QuickTime is
good at producing such cases.)
Aye, personally, I'm pleased to see people start demanding not only integrity
but also minimum sustained transfer rates from storage devices. The broader
the understanding of merit, the more measures on which I can hope to compete
well.
But I'd guess we'll see double-buffering for alignment as issue in the real
world only as a rare pause while streaming. People who move only
not-real-time data wouldn't much care.
How wrong-headed am I here?
> an unconstrained scatter/gathr list,
> [Apple] expose this in ... API,
> and allow drivers to specify ...
Empirically, then, once a given driver agrees to double-buffer, the device's
expensive specified ability to cope with strange page tables is then never
used?
Ouch. I hate to see a spec published but then little regarded. I hate to
see generic cost a lot more than device-specific. Kind of like an unequally
enforced law: people's vision of what the law is grows fuzzy - inescapably.
> Several commercially available 1394-ATA bridges
> have bugs in this area,
> and we painfully double-buffer
> some I/O to them as a result,
> at a great loss in performance.
> I will not identify them;
Understood your personal obligations preclude you from publically shaming
broken bridges and the broken devices built out of those bridges.
But can we somehow celebrate the bridges and devices known to work?
Especially the bridges known to work when segment byte size modulo 4 is 1, 2,
or 3? (Me, I'm aware of bridges that work for 2 but not for 1 and 3.)
> ask your silicon suppliers
> very clearly if they have this problem or not.
Is there any quasi-public document posted somewhere that draws attention to
this fruitful concentration of misunderstanding?
Sure, me, I'd like to think I would ask about why unrestricted page tables
are unrestricted from day one.
But I'm aware of - self-evidently junior - silicon designers who some time
ago - erroneously and arrogantly - concluded that the English of the spec
can't have possibly meant what it said. 1394 is a quad-based bus, therefore
quad-alignment is "of course" guaranteed. Flatly wrong, I know. But not
obviously wrong enough to some people prematurely given more responsibility
than we might now wish.
I'm also aware of people who bought silicon without thinking to ask this
question.
I'm also aware of people who think everything on a 16-bit ATA bus involves
pairs of bytes. Intensely influential people, like the author of Microsoft's
Win95B Esdi506.pdr Atapi. he worl
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10
mailing list