Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*More\s+measurements\s*$/: 20 ]

Total 20 documents matching your query.

1. More measurements (score: 1)
Author:
Date: Tue, 30 Jan 2001 01:04:10 +1100
l
/archives/netdev/2001-01/msg00329.html (9,425 bytes)

2. Re: More measurements (score: 1)
Author: Wedgwood <cw@xxxxxxxx>
Date: Tue, 30 Jan 2001 12:48:40 +0100
s
/archives/netdev/2001-01/msg00348.html (9,574 bytes)

3. Re: More measurements (score: 1)
Author: ler" <davem@xxxxxxxxxx>
Date: Wed, 31 Jan 2001 00:47:10 +1100
b
/archives/netdev/2001-01/msg00352.html (11,697 bytes)

4. Re: More measurements (score: 1)
Author: ni@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 30 Jan 2001 22:14:24 +0300 (MSK)
t
/archives/netdev/2001-01/msg00356.html (8,087 bytes)

5. Re: More measurements (score: 1)
Author: xx
Date: Tue, 30 Jan 2001 22:55:15 +0300 (MSK)
y
/archives/netdev/2001-01/msg00358.html (8,500 bytes)

6. Re: More measurements (score: 1)
Author: xx
Date: 30 Jan 2001 21:52:14 +0100
c
/archives/netdev/2001-01/msg00360.html (8,563 bytes)

7. Re: More measurements (score: 1)
Author: on <andrewm@xxxxxxxxxx>
Date: Wed, 31 Jan 2001 11:30:48 +1100
n
/archives/netdev/2001-01/msg00366.html (8,549 bytes)

8. Re: More measurements (score: 1)
Author: on <andrewm@xxxxxxxxxx>
Date: Wed, 31 Jan 2001 11:37:28 +1100
!
/archives/netdev/2001-01/msg00367.html (8,884 bytes)

9. Re: More measurements (score: 1)
Author: Wedgwood <cw@xxxxxxxx>
Date: Tue, 30 Jan 2001 16:42:39 -0800 (PST)
o
/archives/netdev/2001-01/msg00369.html (8,580 bytes)

10. Re: More measurements (score: 1)
Author: " <jleu@xxxxxxxxxxxxxx>
Date: Wed, 31 Jan 2001 11:23:17 +0800
u
/archives/netdev/2001-01/msg00381.html (9,801 bytes)

11. More measurements (score: 1)
Author: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Tue, 30 Jan 2001 01:04:10 +1100
Let's compare 3coms and eepro100s. And the effects of MMIO versus PIO, and other stuff. 3c905C 3c905C 3c905C 3c905C 3c905C eepro100 eepro100 eepro100 CPU affine ints rx pps tx pps MMIO I/O ops ints 2
/archives/netdev/2001-01/msg00718.html (9,425 bytes)

12. Re: More measurements (score: 1)
Author: Andi Kleen <ak@xxxxxx>
Date: Tue, 30 Jan 2001 12:48:40 +0100
The Intel driver (e100.c) uploads special firmware and does it for RX and TX. eepro100 doesn't. Perhaps you could measure that driver too? It unfortunately doesn't support zc. iirc Ingo at some point
/archives/netdev/2001-01/msg00737.html (9,624 bytes)

13. Re: More measurements (score: 1)
Author: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Wed, 31 Jan 2001 00:47:10 +1100
Sure. Anyone have a URL for intel's driver? mm... My cycle soaker is not aggressive enough in its generation of memory traffic. I think I need to tune it so when all CPUs are 'soaking', memory traffi
/archives/netdev/2001-01/msg00741.html (11,775 bytes)

14. Re: More measurements (score: 1)
Author: kuznet@xxxxxxxxxxxxx
Date: Tue, 30 Jan 2001 22:14:24 +0300 (MSK)
Hello! This was due to pushes made by 4K writes used by old sendfile(). Pretty silly feature, but it seems to be required. 25% of packets are better than full collapse in some cases. Sigh... In any c
/archives/netdev/2001-01/msg00745.html (8,112 bytes)

15. Re: More measurements (score: 1)
Author: kuznet@xxxxxxxxxxxxx
Date: Tue, 30 Jan 2001 22:55:15 +0300 (MSK)
Hello! Interesting. 0.9% is ridiculously small, but 2.5% is some big number. 8)8) Actually, I am not sure that mmio improves something in your case. Even these 0.9% can be random or systematic error.
/archives/netdev/2001-01/msg00747.html (8,525 bytes)

16. Re: More measurements (score: 1)
Author: Jes Sorensen <jes@xxxxxxxxxxxxx>
Date: 30 Jan 2001 21:52:14 +0100
Ingo or Don Becker (sorry don't remember if it was Ingo or Don) did some tests showing that the write speed to IO ports was about 10 times the slower and read about 5 times slower. There is also the
/archives/netdev/2001-01/msg00749.html (8,588 bytes)

17. Re: More measurements (score: 1)
Author: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Wed, 31 Jan 2001 11:30:48 +1100
Ah. Thanks. It's good to have an explanation :) In my testing, in all cases, at all times, with all NICs, the link is 100% saturated. I don't need another dimension to deal with!
/archives/netdev/2001-01/msg00755.html (8,603 bytes)

18. Re: More measurements (score: 1)
Author: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Wed, 31 Jan 2001 11:37:28 +1100
Interesting. Question: when the CPU reads from a PCI location, are the CPU <-> PCI bridge buses blocked for the duration of the read, or does the PCI bridge reconnect? I'm guessing that the major ben
/archives/netdev/2001-01/msg00756.html (8,931 bytes)

19. Re: More measurements (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Tue, 30 Jan 2001 16:42:39 -0800 (PST)
My vague recollection is: 1) Any old style IO flushes fifos in both directions in the path on the PCI bus to the device before the transaction is even started. 2) As mentioned, writes cannot be poste
/archives/netdev/2001-01/msg00758.html (8,677 bytes)

20. Re: More measurements (score: 1)
Author: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Date: Wed, 31 Jan 2001 11:23:17 +0800
Hi, That's about RX mitigation, where a special hardware assistance is required. For TX interrupts, the current driver arbitrarily asks for a TX interrupt every forth packet (to do garbage collection
/archives/netdev/2001-01/msg00770.html (9,944 bytes)


This search system is powered by Namazu