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
impact.

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. :-)

    -- Garrett

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.
>
> -allen
>
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191