Re: 1394 Performance

On 5 Feb, Mark Knecht wrote:
>> - But: gscanbus still claims the gap count is 63! Puzzling.
>
> Very. Question - did gscanbus still claim 63 even while the tests were going
> on?

I did not look into it while hdparm ran. I got this strange
reading (a) after the Windows PC was attached and the series of
bus resets were over and before I started hdparm, and again (b)
when I quit gscanbus to be sure and started it freshly after I
ran hdparm once or twice and (c) before I disconnected the
Windows PC. To be sure I let gscanbus look into all three nodes;
they all showed the same gap count (as they should) of 63 (which
we did not expect).

> hdparm -Tt = fast
> gscanbus says 63
> hdparm -Tt = still fast?

Indeed.

> If so this is very puzzling, and possibly a bug in what gscanbus is telling
> us.

Does anybody know of an easy way to fetch the gap count, besides
using gscanbus?

>> - After Windows is disconnected again, hdparms shows the same bad
>> read performance as in the first 3 runs.
>
> This leads me to wonder about gscanbus. I can believe that when you
> disconnect the Windows box you get a bus reset, and that bus reset pushes
> the gap count back to 63. I think gap count is required to be reset to 63
> after two bus resets to account for the possibility that two large 1394
> buses get connected together and the gap count of either is too small to
> allow the bus to operate correctly.

BTW, as I already mentioned in that post, when Windows joins the
bus there is actually a series of bus resets because Linux and
Windows fight over who is to become IRM. (Linux claimd DOS 98SE
is not 1394a compliant and reseted a few times.) However my
expectation is that Windows reduces the gap count after it
finally became IRM and bus master. (Well, all I know is that the
hard disk is not IRM capable and that Linux was not acting as IRM
after Windows was present, so I conclude that Windows was indeed
IRM and, along the line, also bus master.)

Seeing the old 63 gap count with Windows on, I even triggered
another bus reset with gscanbus's bus reset function, but after
that there was also gap count = 63 according to gscanbus.

Well, I don't possess the 1394 spec to check the authoritative
text, but here is what Don Anderson wrote in his book about
reduced gap counts and bus resets:

"Note that the first bus reset following the gap_count field
being updated (via a PHY configuration packet) has no effect on
the gap_count value. When a second bus reset occurs the gap_count
field is initialized to a value of 3Fh (63d)."

Is he true about that? Let's me wonder why it is not already set
back to 63 already by the first bus reset after the PHY packet
was broadcast.

-- 
Stefan Richter
-=====-=-=-- --=- --==-
http://arcgraph.de/sr/
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
mailing list Linux1394-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-user