stds-1394: empirical character of SBP2 scatter/gather

Pat LaVarre lavarre at
Wed Jun 27 05:53:41 PDT 2001

* From the T10 Reflector (t10 at, posted by:
* "Pat LaVarre" <lavarre at>
 > "John Nels Fuller" <jfuller at>

 > Win 98 and ME will be much more arbitrary
 > (in fact Win 98 was the reason that
 > unrestricted page tables were
 > added to the standard).

Ahhh.  Perfect, thank you, this kind of secret history is exactly the kind of 
thing I imagine I've missed by not being here this past few years.  Anybody 
got more?

 > I know from a past life
 > that Windows 2000 and XP
 > will generate the kind
 > of page table that you expect
 > (but with page size of 0),

Am I right to think you mean to say typically the page table looks like I 
expect, a simple-minded physical mapping of contiguous virtual memory ... but 
you mean to make no comment re how reliably their page tables look like this?

Sorry to say I'm working at this moment remotely without ready access to 
detailed data, but the system I've seen best instrumented is the debug build 
of Win2KSP2 (patched by guess in the raw binary to spit out more debug 
info).  I thought that was where I had seen much of this weirdness.

Do you mean to say you have reason to believe I'm dreaming?  (I think I'm not 
dreaming, but if you have data that says I am dreaming, well then, at least I 
know I'm looking at unusual stuff.)

 > (but with [an ORB page_size] of 0),

WHY zero?  If the o.s. can reliably produce a restricted page table, why not 
tell the device that's what's going on?

 > Which OS are you using?

Win98SE + some reputedly necessary patches, WinMe, Win2K, Win2KSP1, Win2KSP2, 
WinXP, MacOS9, MacOSX, Mac 1394 boot, Linux sometime soon, etc. etc. etc.

 > What you are asking about
 > is primarily a function of the OS.

Aye: primarily a function of its i/o stack taken together as a whole.  For 
example, on Windows I see bytes per cdb choked off down near 6K.  I know of 
devices that run 2X slower when abused like that.

 > The target device should not care
 > about how the page table is specified
 > other than the size of packets it must create
 > (addresses are just numbers
 > that are filled into the headers).

"Should not"?  Sure, agreed.

Meanwhile, back in the real world, this idea of assaulting the device with 
the diversity of how fragmented physical memory may be strikes me as the 
sharpest difference between 1394 and the other prosumer techniques for 
connecting mass storage.

I'm not nuts here, am I?  I mean, I rather doubt I'm the only person who has 
ever seen that host/device hardware shipped by a third-party in fact cares?

1) I hear third-hand that some author of the quasi-public sample Apple MacOS9 
1394 storage driver decided to double-buffer as needed to align all 
segment_base addresses to multiples of x10.  Is this false and vicious 
slander - or true?

2) I hear lots of 1394 mass storage is in fact a bridge from 1394 to 
something else?  Odds are good the Something Else cares.

Our history of pain here re silicon bought from third parties drives us in 
our own designs to arrange for pauses to occur only at x200 byte boundaries 
... but I can see that bridges designed without benefit of our advice neglect 
to implement this Good Practice.

I've even seen hardware rude enough to pass the 1394 data rate straight 
through to the other side, producing irregular data clocks there.

 > > mailto:sbp3 at

 > If you want to question
 > Microsoft's implementation
 > you should email 1394 at

Sorry, I'm not sure how to understand this.

I appreciate she who ships first wins.  I'm not looking to persuade Microsoft 
to change anything that shipped already - I'm thinking that would be an utter 
waste of my time and theirs.

I am looking to characterise the binary-code-only they did ship.  Theirs, 
Apple's, and so on.  I hear Mac OS X source is quasi-public, so that will 
help.  Meanwhile, I'm looking for shortcuts.

Surel I'm no 

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list