Re: [RESULTS] Port 0x80 I/O speed

2007-12-12 Thread David Newall

linux-os (Dick Johnson) wrote:

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!
  


The initial value could be set conservatively high.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RESULTS] Port 0x80 I/O speed

2007-12-12 Thread Rene Herman

On 12-12-07 21:18, linux-os (Dick Johnson) wrote:


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!


We understand the problem. But it's not all that bad.

Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RESULTS] Port 0x80 I/O speed

2007-12-12 Thread linux-os (Dick Johnson)

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,
Dick 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 
[EMAIL PROTECTED] - 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RESULTS] Port 0x80 I/O speed

2007-12-12 Thread Vegard Nossum
On Dec 12, 2007 8:14 PM, Rene Herman <[EMAIL PROTECTED]> wrote:
> 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.

Hi.

Just want to say that I get up to 2.7 on my Acer Aspire 5720Z laptop.

cycles: out 3955, in 3679
cycles: out 3972, in 3683
cycles: out 3963, in 3692
cycles: out 3961, in 3663
cycles: out 3977, in 3679
cycles: out 3990, in 3675

The test program was run with the following frequency setup:

# cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to [EMAIL PROTECTED], please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 0 1
  hardware limits: 800 MHz - 1.47 GHz
  available frequency steps: 1.47 GHz, 1.07 GHz, 800 MHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 800 MHz and 1.47 GHz.
  The governor "performance" may decide which speed to use
  within this range.
  current CPU frequency is 1.47 GHz (asserted by call to hardware).

# cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Pentium(R) Dual  CPU  T2310  @ 1.46GHz
stepping: 13
cpu MHz : 1467.000
cache size  : 1024 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm
constant_tsc arch_perfmon pebs bts pni monitor ds_cpl est tm2 ssse3
cx16 xtpr lahf_lm
bogomips: 2930.06
clflush size: 64


This seems to be higher than the #60 on your list. What makes my
machine (and a few of the others') special?


Vegard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[RESULTS] Port 0x80 I/O speed

2007-12-12 Thread Rene Herman

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

1. 0.54 Chris Holvenstot: out 1301, in 1252
AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ (2412 MHz)

2. 0.56 Török Edwin: out 1107, in 1067
AMD Athlon(tm) 64 Processor 3200+, Asus A9N-E (2000 MHz)

3. 0.58 Mike Lampard: out 1342, in 249
AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ (2300 mhZ)

4. 0.69 Jeremy O'Brien: out 411, in 519
Pentium III M 1400Mhz (600Mhz)

5. 0.76 Ville Syrjälä: out 1830, in 1166
Intel(R) Core(TM)2 CPU 6600 (2400MHz)

6. 0.78 Maxim Levitsky: out 1650, in 1065
Core 2 Duo (ICH8/Intel DG965RY motherboard) (2128 MHz)

7. 0.83 Paolo Ornati: out 1498, in 964
Core2 Duo 1.8 GHz (1800 Mhz)

8. 0.88 Ondrej Zary: out 2824, in 1899
Pentium 4 3.2GHz, i925X (3200 MHz)

9. 0.90 Dave Young: out 2522, in 1788
Intel(R) Pentium(R) D CPU 2.80GHz (2800 MHz)

10. 0.90Randy Dunlap: out 2702, in 1903
Intel(R) Pentium(R) D CPU 3.00GHz (3000 MHz)

11.1.08 Maxim Levitsky: out 1730, in 1138
Core 2 Duo (ICH8/Intel DG965RY motherboard) (1596 MHz)

12.1.14 Peter Zijlstra: out 1743, in 1737
AMD Athlon(tm) MP 1800+ (1533 MHz)

13.1.16 Peter Zijlstra: out 116, in 47
Pentium 133 (100 MHz)

14.1.17 Ondrej Zary: out 263, in 93
Cyrix MII PR300 (225MHz), i430TX

15.1.18 [EMAIL PROTECTED]: out 1295, in 1162
1100 MHz Athlon, nForce2 chipset, nForce2 ISA bridge

16.1.20 Ville Syrjälä: out 1925, in 1266
Intel(R) Core(TM)2 CPU 6600 (1596 MHz)

17.1.21 Peter Zijlstra: out 811, in 354
Pentium III (Coppermine) (672 MHz)

18.1.22 Juergen Beisert: out 1215, in 1094
Intel(R) Celeron(TM) CPU (1000MHz)

19.1.23 Ondrej Zary: out 163, in 163
Pentium MMX 166MHz @133MHz, VIA VPX (133 Mhz)

20.1.27 Dave Haywood: out 1183, in 706
Pentium III (Coppermine) 930 MHz

21.1.28 Ondrej Zary: out 2178, in 1651
Celeron 1.7GHz (P4-based), i845 (1700 MHz)

22.1.29 Olivér Pintér: out 4062, in 2502
Intel(R) Pentium(R) 4 CPU 3.00GHz (3150 Mhz)

23.1.30 James Lamanna: out 3902, in 2372
Intel(R) Pentium(R) 4 CPU 3.00GHz

24.1.31 Ville Syrjälä: out 914, in 406
Pentium III (Coppermine) 700 Mhz

25.1.32 [EMAIL PROTECTED]: out 794, in 348
600 MHz PIII (Katmai), 440BX chipset, 82371AB/EB/MB PIIX4:

26.1.33 Edwin de Caluwé: out 667, in 305
Celeron (Coppermine) 500 MHz

27.1.34 Ville Syrjälä: out 1142, in 475
Pentium III (Coppermine) 850 MHz

28.1.35 Ville Syrjälä: out 607, in 272
Pentium II (Deschutes) 450 MHz

29.1.36 Pádraig Brady: out 4069, in 2507
Intel(R) Pentium(R) 4 CPU 3.00GHz:

30.1.37 Juergen Beisert: out 684, in 280
Pentium III (Katmai) 500 MHz

31.1.37 Nigel Cunningham: out 2472, in 2505
AMD 1.8GHz Turion ATI RS480 - Mitac 8350 mobo (1800 MHz)

32.1.38 Rene Herman: out 553, in 251
PII 400 (Intel 440BX) (400 MHz)

33.1.40 Guennadi Liakhovetski: out 1263, in 1221
AMD Duron 900MHz

34.1.41 John Stoffel: out 774, in 332
PIII, Dual 550Mhz Xeon

35.1.42 Török Edwin: out 2368, in 1783
Intel Core Duo T2300 (Dell Inspiron 6400, ICH7) (1667 MHz)

36.1.43 Luciano Rocha: out 2711, in 1856
Intel(R) Pentium(R) 4 CPU 1.90GHz

37.1.43 Ondrej Zary: out 620, in 305
Celeron 433MHz, i440BX

38.1.44 [EMAIL 

[RESULTS] Port 0x80 I/O speed

2007-12-12 Thread Rene Herman

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

1. 0.54 Chris Holvenstot: out 1301, in 1252
AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ (2412 MHz)

2. 0.56 Török Edwin: out 1107, in 1067
AMD Athlon(tm) 64 Processor 3200+, Asus A9N-E (2000 MHz)

3. 0.58 Mike Lampard: out 1342, in 249
AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ (2300 mhZ)

4. 0.69 Jeremy O'Brien: out 411, in 519
Pentium III M 1400Mhz (600Mhz)

5. 0.76 Ville Syrjälä: out 1830, in 1166
Intel(R) Core(TM)2 CPU 6600 (2400MHz)

6. 0.78 Maxim Levitsky: out 1650, in 1065
Core 2 Duo (ICH8/Intel DG965RY motherboard) (2128 MHz)

7. 0.83 Paolo Ornati: out 1498, in 964
Core2 Duo 1.8 GHz (1800 Mhz)

8. 0.88 Ondrej Zary: out 2824, in 1899
Pentium 4 3.2GHz, i925X (3200 MHz)

9. 0.90 Dave Young: out 2522, in 1788
Intel(R) Pentium(R) D CPU 2.80GHz (2800 MHz)

10. 0.90Randy Dunlap: out 2702, in 1903
Intel(R) Pentium(R) D CPU 3.00GHz (3000 MHz)

11.1.08 Maxim Levitsky: out 1730, in 1138
Core 2 Duo (ICH8/Intel DG965RY motherboard) (1596 MHz)

12.1.14 Peter Zijlstra: out 1743, in 1737
AMD Athlon(tm) MP 1800+ (1533 MHz)

13.1.16 Peter Zijlstra: out 116, in 47
Pentium 133 (100 MHz)

14.1.17 Ondrej Zary: out 263, in 93
Cyrix MII PR300 (225MHz), i430TX

15.1.18 [EMAIL PROTECTED]: out 1295, in 1162
1100 MHz Athlon, nForce2 chipset, nForce2 ISA bridge

16.1.20 Ville Syrjälä: out 1925, in 1266
Intel(R) Core(TM)2 CPU 6600 (1596 MHz)

17.1.21 Peter Zijlstra: out 811, in 354
Pentium III (Coppermine) (672 MHz)

18.1.22 Juergen Beisert: out 1215, in 1094
Intel(R) Celeron(TM) CPU (1000MHz)

19.1.23 Ondrej Zary: out 163, in 163
Pentium MMX 166MHz @133MHz, VIA VPX (133 Mhz)

20.1.27 Dave Haywood: out 1183, in 706
Pentium III (Coppermine) 930 MHz

21.1.28 Ondrej Zary: out 2178, in 1651
Celeron 1.7GHz (P4-based), i845 (1700 MHz)

22.1.29 Olivér Pintér: out 4062, in 2502
Intel(R) Pentium(R) 4 CPU 3.00GHz (3150 Mhz)

23.1.30 James Lamanna: out 3902, in 2372
Intel(R) Pentium(R) 4 CPU 3.00GHz

24.1.31 Ville Syrjälä: out 914, in 406
Pentium III (Coppermine) 700 Mhz

25.1.32 [EMAIL PROTECTED]: out 794, in 348
600 MHz PIII (Katmai), 440BX chipset, 82371AB/EB/MB PIIX4:

26.1.33 Edwin de Caluwé: out 667, in 305
Celeron (Coppermine) 500 MHz

27.1.34 Ville Syrjälä: out 1142, in 475
Pentium III (Coppermine) 850 MHz

28.1.35 Ville Syrjälä: out 607, in 272
Pentium II (Deschutes) 450 MHz

29.1.36 Pádraig Brady: out 4069, in 2507
Intel(R) Pentium(R) 4 CPU 3.00GHz:

30.1.37 Juergen Beisert: out 684, in 280
Pentium III (Katmai) 500 MHz

31.1.37 Nigel Cunningham: out 2472, in 2505
AMD 1.8GHz Turion ATI RS480 - Mitac 8350 mobo (1800 MHz)

32.1.38 Rene Herman: out 553, in 251
PII 400 (Intel 440BX) (400 MHz)

33.1.40 Guennadi Liakhovetski: out 1263, in 1221
AMD Duron 900MHz

34.1.41 John Stoffel: out 774, in 332
PIII, Dual 550Mhz Xeon

35.1.42 Török Edwin: out 2368, in 1783
Intel Core Duo T2300 (Dell Inspiron 6400, ICH7) (1667 MHz)

36.1.43 Luciano Rocha: out 2711, in 1856
Intel(R) Pentium(R) 4 CPU 1.90GHz

37.1.43 Ondrej Zary: out 620, in 305
Celeron 433MHz, i440BX

38.1.44 [EMAIL 

Re: [RESULTS] Port 0x80 I/O speed

2007-12-12 Thread linux-os (Dick Johnson)

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,
Dick 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 
[EMAIL PROTECTED] - 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RESULTS] Port 0x80 I/O speed

2007-12-12 Thread Vegard Nossum
On Dec 12, 2007 8:14 PM, Rene Herman [EMAIL PROTECTED] wrote:
 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.

Hi.

Just want to say that I get up to 2.7 on my Acer Aspire 5720Z laptop.

cycles: out 3955, in 3679
cycles: out 3972, in 3683
cycles: out 3963, in 3692
cycles: out 3961, in 3663
cycles: out 3977, in 3679
cycles: out 3990, in 3675

The test program was run with the following frequency setup:

# cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to [EMAIL PROTECTED], please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 0 1
  hardware limits: 800 MHz - 1.47 GHz
  available frequency steps: 1.47 GHz, 1.07 GHz, 800 MHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 800 MHz and 1.47 GHz.
  The governor performance may decide which speed to use
  within this range.
  current CPU frequency is 1.47 GHz (asserted by call to hardware).

# cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Pentium(R) Dual  CPU  T2310  @ 1.46GHz
stepping: 13
cpu MHz : 1467.000
cache size  : 1024 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm
constant_tsc arch_perfmon pebs bts pni monitor ds_cpl est tm2 ssse3
cx16 xtpr lahf_lm
bogomips: 2930.06
clflush size: 64


This seems to be higher than the #60 on your list. What makes my
machine (and a few of the others') special?


Vegard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RESULTS] Port 0x80 I/O speed

2007-12-12 Thread Rene Herman

On 12-12-07 21:18, linux-os (Dick Johnson) wrote:


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!


We understand the problem. But it's not all that bad.

Rene.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RESULTS] Port 0x80 I/O speed

2007-12-12 Thread David Newall

linux-os (Dick Johnson) wrote:

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!
  


The initial value could be set conservatively high.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/