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