[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux1394-devel
Subject:    endpoint initial testing results.
From:       Daniel Pittman <daniel () rimspace ! net>
Date:       2003-10-23 10:13:07
[Download RAW message or body]

I had a chance to do some initial testing on the 'endpoint' code today,
with some interesting results.

The 'endpoint' was a fairly slow Cyrix M2 300, with a sparse file image
on a slow RAID-5 device under it, with kernel 2.6.0-test8

The master was a P4 1.7 system, and running 2.6.0-test7.

Creating a 320GB image and formatting it as ext3 worked reasonably well.
The performance seemed reasonably close to the raw performance of the
array, which is nice.

There were an enormous number of warnings from the 1394 kernel code
about waking the DMA context without the code being ready, though, which
I put down to the poor performance of the client machine.

The formatting completed successfully, mounting and putting data onto
the filesystem worked well, although the CPU load from the 'endpoint'
code was higher than I would have expected -- 25 to 50 percent of time,
fairly constantly. The server ran at ~1% higher system load for this.


I hit some real problems reading from the 'endpoint', though. Basically,
after reading for a while one end or the other would hang, and would not
resume talking until after a bus reset.

When the timeout happened, if I waited long enough, I got some errors on
the server side -- none on the client, though.

The first set, which showed up irregularly, were:

ieee1394: unsolicited response packet received - no tlabel match

I suspect this is the 'endpoint' code replying to a transaction on the
server after it has been aborted; is this correct?


I also got aborted read(10) requests to the client side, which were
not trying anything particularly exciting as far as I can tell. They
were issuing reads of 8, 248 and 88 sectors, with no options turned on.

The locations were all reasonable as well, and the pattern of requests
was consistent with the kernel reading correctly from my instrumentation
on the client side.


A bus reset would allow somewhere between four and ten reads to succeed,
then the system would hang in the same way the next time.


I don't have full debugging on the server side, and no more time to test
tonight.  If there is anything particularly valuable in tracking down
the cause of this bus hang, pointers would be great. :)

    Daniel

-- 
The only infallible rule we know is, that the man who is
always talking about being a gentlemen never is one.
        -- R. S. Surtees, _Ask Momma_


-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
mailing list linux1394-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-devel
[prev in list] [next in list] [prev in thread] [next in thread]