Re: [RESULTS] Port 0x80 I/O speed
- From: "linux-os (*** Johnson)" <linux-os@xxxxxxxxxxxx>
- Date: Wed, 12 Dec 2007 15:18:30 -0500
On Wed, 12 Dec 2007, Rene Herman wrote:
Hi everyone.
That was a succesful request, thanks to all who responded. This message also
just now went out with all the respondents in CC but I believe that copy
isn't making the list, so here's one without...
In total you provided 60 reports which are listed below in increasing order
of time spent for an outb to port 0x0. Let's face it, these things are
competitions, and Chris has won!
Time varies between 0.54 microseconds and 2.50 microseconds, with most
around 1.3/1.4 microseconds. Numbers 58, 59 and 60 (the ones at > 2 us) I
dont completely trust since similar machines are among the fastest as well.
Note also that ISA isn't applicable to those 3...
Most machines need no delays anywhere, and those that do would probably be
served with a udelay(1) as well but I believe this sampling is showing that
a udelay(2) would be the conservative choice.
Thanks again to all those that responded. There's probably a few cut & paste
and/or math errors in the below. The jury can not be held accountable for
any missed prestige!
Congrats to Chris... ;-)
Cheers,
Rene
But there are some things that get set up long before
udelay() is calibrated! The interrupt controllers,
the timer, etc. You can't just substitute or you
will end up with machines that won't boot!
grep /usr/src/linux-`uname -r`/arch/i386/kernel/*.c
for lots of outb_p()'s!
That's why the manufacturing port, 0x80, really
needs to be used for I/O timing! If it kills that
one machine, then that one machine is broken and
needs to be fixed. It's probably an undetected
error in a FPGA that once reported will get fixed.
In fact, it might just be one motherboard and
if that motherboard was replaced, the problem
goes away. We have been there before. We can't
"fix" stuff that's not broken without running
the risk of breaking a lot more stuff.
[Snipped...]
Cheers,
*** Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@xxxxxxxxxxxx - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [RESULTS] Port 0x80 I/O speed
- From: David Newall
- Re: [RESULTS] Port 0x80 I/O speed
- From: Rene Herman
- Re: [RESULTS] Port 0x80 I/O speed
- References:
- [RESULTS] Port 0x80 I/O speed
- From: Rene Herman
- [RESULTS] Port 0x80 I/O speed
- Prev by Date: Re: [PATCH RT] Revert Softdisable for simple irqs.
- Next by Date: Re: [PATCH] IB/ehca: Serialize HCA-related hCalls if necessary
- Previous by thread: Re: [RESULTS] Port 0x80 I/O speed
- Next by thread: Re: [RESULTS] Port 0x80 I/O speed
- Index(es):