Subject: Re: com rumblings...
To: Garrett D'Amore <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 06/15/2006 14:43:11
I have only limited hardware that I can test with. Which is one of the
reasons that I've put these changes in a branch [gdamore-uart] instead
of just committing. This way other people can also help with testing,
especially those who are most concerned about the potential performance
I don't have an easy way (that I know of) to instrument the execution
times of these things without perturbing the results themselves.
Frankly, if it takes 1 cycle more on some random piece of hardware, but
nobody notices, then I don't care. But if it takes 1 cycle more and
that causes a failure to operate somewhere, then I need to know about
it. This is one of the reasons that I want to get folks who are most
likely to be impacted b this to test it for themselves.
Plus, it buys me some CYA. :-)
Allen Briggs wrote:
> On Thu, Jun 15, 2006 at 01:17:06PM -0700, Garrett D'Amore wrote:
>> Wouldn't those 4- or 6- (or more!) port cards generally have working
>> FIFOs on them?
> Working FIFOs or not, it takes a certain amount of time to process
> the interrupts and read the data. It's hard to guess the effect
> of any changes in an optimized system. In some cases, just adding
> unexecuted code in the right place can shuffle things around to
> perturb the instruction cache footprint. So you might end up with
> N+1 parts of your critical path that lie in the same location in
> your N-way instruction cache. Or something else.
> This is why it would be nice to be able to measure the change in
> a real setup or three. Actually, if you have a 4-port card, can
> you do some tests using one port as source and the other as sink?
> Maybe you could measure the execution time in cycles of the h/w
> interrupt routines before and after the change. Do you have access
> to a cycle counter?
> As Charles said, maybe the 4-6 modems on a 486 is not that interesting
> anymore, but it would be nice to get some measurement instead of
> a bunch of paper analysis or hand-waving.
> So I think Pavel's setup is worth testing, but not just for operation,
> but also for the amount of system time it takes to do some specific
> operations. Or, better, some measure like clock cycles/interrupt with
> old code and new.
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191