This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: How to debug synchronisation in the usbs.c in a new usb-driver for the ARM at91sam7s...


I did a double check, and the only difference is the usbs code. Fresh recompiles for both and the same results. 

This shouldn't be just an effect of the usb 'millisecond frame' since it is a high speed device. The data rates are around 10 MB/s
with packet sizes of 512 bytes. So we are getting about 20 packets/msec frame, with the semaphore/complete flag being posted once
every 128 packets (64KB or about 6 milliseconds).

Our system is very sensitive to instruction cache performance, so this could be just a side effect of that too (ie. the code changes
position a bit and is now spanning a page boundary and has to be flushed).

After writing the above I repeated the test with instruction cache disabled. There is very little performance drop (a few percent in
favour of the semaphore code) now, but the system throughput drops 80 percent. 

Derek
 

-----Original Message-----
From: Bart Veer [mailto:bartv@ecoscentric.com] 
Sent: Monday, February 20, 2006 1:09 PM
To: derek.bouius@sympatico.ca
Cc: ecos-discuss@sourceware.org
Subject: Re: [ECOS] How to debug synchronisation in the usbs.c in a new usb-driver for the ARM at91sam7s...

>>>>> "Derek" == Derek Bouius <derek.bouius@sympatico.ca> writes:

    Derek> I tested the below patch and it works.
    Derek> The throughput performance change compared to using a
    Derek> semaphore (in our system) is
    Derek> usbs_devtab_cwrite : 17% drop
    Derek> usbs_devtab_cread : 53% drop
    Derek> which is quite significant!

Very significant - but I am rather sceptical. Granted, semaphores will
be more efficient. However for USB communication throughput is
constrained by the host and by USB's millisecond frames. A massive
performance difference like the above would imply that a lot of
transfers are now being pushed into the next frame. That is possible
if the eCos target's performance is borderline when it comes to
feeding data to the host, but it would be a bit of a coincidence. Are
you sure that there are no other differences, e.g. debug vs.
production builds?

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]