stds-1394: empirical character of SBP2 scatter/gather
Pat LaVarre
lavarre at iomega.com
Wed Jun 27 05:53:41 PDT 2001
* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <lavarre at iomega.com>
*
> "John Nels Fuller" <jfuller at computer.org>
> 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 isg.apple.com
> If you want to question
> Microsoft's implementation
> you should email 1394 at microsoft.com.
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 t10.org
More information about the T10
mailing list