public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Derek Bouius" <derek.bouius@sympatico.ca>
To: "'Bart Veer'" <bartv@ecoscentric.com>
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...
Date: Mon, 20 Feb 2006 19:21:00 -0000	[thread overview]
Message-ID: <20060220192107.MBJN10262.tomts22-srv.bellnexxia.net@derekwin> (raw)
In-Reply-To: <20060220180922.76A54DC8722@snape.ecoscentric.com>

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

  reply	other threads:[~2006-02-20 19:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-16 16:15 Derek Bouius
2006-02-16 16:26 ` Andrew Lunn
2006-02-16 16:31   ` Gary Thomas
2006-02-16 22:57     ` Bart Veer
2006-02-20  9:38       ` Nick Garnett
2006-02-20 11:49         ` Bart Veer
2006-02-20 14:30           ` Nick Garnett
2006-02-20 16:02             ` Bart Veer
2006-02-16 16:43   ` oliver munz @ s p e a g
2006-02-16 16:54   ` Derek Bouius
2006-02-20 13:42     ` Bart Veer
2006-02-20 17:35       ` Derek Bouius
2006-02-20 18:09         ` Bart Veer
2006-02-20 19:21           ` Derek Bouius [this message]
2006-02-16 16:45 ` oliver munz @ s p e a g
2006-02-16 20:07   ` Derek Bouius
2006-02-16 20:20     ` oliver munz @ s p e a g
     [not found] <000e01c63669$092c4500$6500a8c0@Burnt>
2006-02-21  9:55 ` Nick Garnett
2006-02-21 18:57   ` Robert Bryce
2006-02-21 20:35     ` Bart Veer
  -- strict thread matches above, loose matches on Subject: below --
2006-02-16  2:56 oliver munz @ s p e a g
2006-02-16  8:28 ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060220192107.MBJN10262.tomts22-srv.bellnexxia.net@derekwin \
    --to=derek.bouius@sympatico.ca \
    --cc=bartv@ecoscentric.com \
    --cc=ecos-discuss@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).