PCI bandbreedte (simpel) testen

[dion_b]

Zoals de oudgedienden hier weten ben ik al ruim anderhalf jaar bezig met een monumentale So5/7 chipset benchmark project. De eerste fase (het verzamelen van zo representatief mogelijke borden) is ondertussen klaar (met een paar erg irritante uitzonderingen, maar zie maar eens een ALi Aladdin 7 of een VLSI Lynx mobo te vinden). De tweede, een synthetische memory benchmark van de borden in optimale en slechtste BIOS settings, is ook zo goed als klaar. Daarover post ik binnenkort zodra ik de resultaten verwerkt heb een uitgebreid verslag. Maar ik ben al vooruit aan het kijken naar fase 3, namelijk de PCI bandbreedte testen.

Voor de goede orde, de eerdere twee topics die ik hierover opende:
Chipset benchmark methodiek
[rml][ So5/7 chipset benchmark]Eerste resultaten[/rml]

Nu is er sinds die twee topics vooral een ding veranderd en dat is de hoeveelheid borden die gebenched moet worden. Die is gestegen tot zo'n 40 Niet alleen zijn er een stuk of 30 verschillende chipsets in die periode, maar ondertussen is duidelijk dat de verschillen tussen hoe merken de timings en BIOS instellingen configgen bijna evenveel verschil uitmaken als de verschillen tussen chipsets, dus ondertussen streef ik naar 2 borden voor elk veel voorkomende chipset.

Dat betekent dat tijd de belangrijkste criterion is voor tests, anders ben ik met pensioen voordat ik klaar ben


De synthetische geheugentest heeft in ieder geval uitgewezen dat er ZEER grote verschillen zitten tussen de chipsets (meer dan een factor drie tussen de snelste en de traagste ) en dat bovendien geen rechte lijn te trekken is tussen leeftijd van een chipset en snelheid (i430VX en SiS 5571 uit 1997 kunnen zich clock-for-clock zeer gunstig meten met Via MVP4 en SiS 5591 van anderhalf jaar later). Ik verwacht dat nog veel sterker te zien bij PCI bandbreedte.


Het probleem:
Op een FSB van 66MHz hoort de PCI bus op 33MHz te draaien met een maximale theoretische throughput van 133MB/s. Hoe bepaal ik hoe hoog de werkelijke maximale gemiddelde throughput is?


Tot nu toe voorgestelde oplossingen:
- een gigabit NIC erin hangen en netwerk performance meten, al dan niet mbv een SQL-database erachter
- een HDD array met minstens 133MB/s throughput benchen


Ik vrees dat geen van beiden een optie zijn. Allereerst heb ik de hardware niet. Twee Gigabit NICs zou nog te overzien zijn, maar de nodige HDDs voor 133MB/s+controller is te duur.
Daarnaast is er met name voor de NICs een ander probleem: tijd. Ik heb niet de tijd om een volledig OS te installeren op de PCs in kwestie. Dat betekent dat ik met een bootdisk moet werken om te benchen. Zelfs Knoppix booten is geen sinecure (CD boot is afwezig bij 2/3 van mijn plankjes), maar krijg ik wel voor elkaar door Knoppix (MET volle hardware detectie) op een HDD te zetten.


Dus:
Hoe met de default Knoppix progjes of een MS DOS tool die PCI bandbreedte te meten

Softwarematig het makkelijkst lijkt me idd een RAID array hdparm'en, maar ik heb dus geen dergelijke bandbreedtes. Wat heb ik wel qua PCI apparaten:

- VGA kaarten (alles van S3 805 tem 32MB S3-Savage2000 en 16MB Voodoo3-3000)
- IDE controllers (ATA66 en 100), maar geen HDD's sneller dan 30MB/s, bovendien geen HW RAID (dus ongeschikt voor bootdisk/knoppix oplossing)
- SCSI controllers- U2W (80MB/s) als snelste controller, maar geen RAID, ook een RAID kaart, maar die trekt max 20MB/s op twee kanalen
- NIC: allerlei 10/100, van CPU extensieve 3Com, Intel en Digital chips tot CPU intensieve RTL8139 en SiS900. Geen Gigabit.
- andere gebruikelijke zut, niets wat veel bandbreedte verstookt


Het enige wat ik op basis hiervan kan bedenken is iet met de VGA kaart te doen. De Savage2000 is een AGP chip, dus werkt in PCI uitvoering sowieso met de PCI als bottleneck. Omdat het een PCI kaart is doet de chipset northbridge er niets anders mee dan PCI arbitraten, oftewel het kan goed als maat dienen van PCI performance. Maaaaar... ik zit vast aan een enkele CPU voor al die planken en dat is een P100. Is er op een P100 onder DOS of Knoppix zinnig te benchen op een manier dat PCI performance zou tonen


Totaal andere insteek:
PCI bandbreedte is behalve voor iemand met een monsterSCSI array an sich niet zo interessant. Maar het is wel makkelijk te meten. Wat eigenlijk relevant is, is de PCI latency. Als ik die kan meten kan ik die bandbreedte rustig laten voor wat het is. Maar de meeste metingen van PCI latency die ik zie doen dat dmv... bandbreedte. Iemand een idee hoe de latency te meten los van de totale bandbreedte

[BalusC]

Ik ken zelf helaas geen PCI bandbreedte/PCI latenty benchmarkprogramma's. Maar het loont wellicht de moeite om in http://www.benchmarkhq.ru/english.html te rondkijken Er zitten vast ook wat DOS-based videokaartbenchmarkprogseltjes tussen.

[Verwijderd]

Er is wel een hardware oplossing (duur): http://www.hardcoreware.net/reviews/review-143-3.htm wellicht dat er ook een alternatief is in de vorm van de bekende POST 80h diagnostic kaartjes maar dan met een wat uitgebreidere uitlezing?

[ Voor 16% gewijzigd door Verwijderd op 15-07-2004 16:53 ]

[MewBie]

ik weet niet of je nog wat aan mijn Benchmarks heb van een hele tijd geleden
http://home.hccnet.nl/fam.bastiaan/Images/PC/
deze zijn gedaan op CL3 met alle andere timing combinaties en op 112MHz (ALi Aladdin 5+ chip)
voor verdere specs moet je maar ff kijken bij mn ftp server specs, al is er ondertussen flink wat veranderd in de tijd tussen de benchmarks en nu

misschien wat leuk vergelijkings materiaal, mijn benches zijn gedaan na een normale boot en dan de nodige meuk uitzetten, heb er zelfs 1 gedaan met prime op de achtergrond

[ Voor 19% gewijzigd door MewBie op 15-07-2004 18:06 ]

[dion_b]

Verwijderd schreef op 15 juli 2004 @ 16:51:
Er is wel een hardware oplossing (duur): http://www.hardcoreware.net/reviews/review-143-3.htm wellicht dat er ook een alternatief is in de vorm van de bekende POST 80h diagnostic kaartjes maar dan met een wat uitgebreidere uitlezing?

Erg leuk apparaatje, maar hij meet helaas de usage en de clocksnelheid, niet de (beschikbare) bandbreedte. Als zodanig zou hij erg handig zijn icm een zware RAID array om te benchen, maar neemt de noodzaak voor een 100% load niet weg.

BalusC schreef op 15 juli 2004 @ 16:33:
Ik ken zelf helaas geen PCI bandbreedte/PCI latenty benchmarkprogramma's. Maar het loont wellicht de moeite om in http://www.benchmarkhq.ru/english.html te rondkijken Er zitten vast ook wat DOS-based videokaartbenchmarkprogseltjes tussen.

* dion_b bookmarkt

Kon er ook geen PCI dingen vinden, maar er zitten minstens twee grappige DOS tools om los te laten op mijn verzamelingen obscure videokaarten (jawel, als ik klaar ben met de mobochipsets heb ik een even grote lading VGA chipsets om te doen - groot verschil is echter dat ik daar wel gewoon een OS install met default VGA driver kan ghosten, waardoor ingewikkeldere tests simpel genoeg te doen zijn)

MewBie schreef op 15 juli 2004 @ 18:00:
ik weet niet of je nog wat aan mijn Benchmarks heb van een hele tijd geleden
http://home.hccnet.nl/fam.bastiaan/Images/PC/
deze zijn gedaan op CL3 met alle andere timing combinaties en op 112MHz (ALi Aladdin 5+ chip)
voor verdere specs moet je maar ff kijken bij mn ftp server specs, al is er ondertussen flink wat veranderd in de tijd tussen de benchmarks en nu

misschien wat leuk vergelijkings materiaal, mijn benches zijn gedaan na een normale boot en dan de nodige meuk uitzetten, heb er zelfs 1 gedaan met prime op de achtergrond

Ben bang dat ik er niet zoveel mee kan, dat zijn namelijk specifieke RAM benchmarks. Veel relevanter is ook dat ik om alle resultaten vergelijkbaar te houden alles met exact dezelfde CPU en RAM (althans, 3 verschillende maar vaste RAM configs) doe. Aangezien jouw benches niet met een P54C-100 en 2x32MB EDO SIMM, 1x 64MB EDO DIMM of 2x 32MB SDRAM DIMM gedaan zijn, is het appels en peren vergelijken.

[ Voor 29% gewijzigd door dion_b op 15-07-2004 18:16 ]

[deadinspace]

dion_b schreef op 15 juli 2004 @ 14:53:
Tot nu toe voorgestelde oplossingen:
- een gigabit NIC erin hangen en netwerk performance meten, al dan niet mbv een SQL-database erachter
- een HDD array met minstens 133MB/s throughput benchen

Ik vrees dat geen van beiden een optie zijn. Allereerst heb ik de hardware niet. Twee Gigabit NICs zou nog te overzien zijn, maar de nodige HDDs voor 133MB/s+controller is te duur.

Als je die route wil nemen zou ik gaan voor NICs, en dan geen SQL db oid erachter hangen, maar gewoon zinloze nulletjes overpompen mbv bandbreedte-testers. Op die manier heb je ook geen dure HDs nodig.

Hoe met de default Knoppix progjes of een MS DOS tool die PCI bandbreedte te meten

Nouja... Default Knoppix progjes. Als je Knoppix op HD installt om te gebruiken voor die benchmarks, dan kun je op die HD natuurlijk ook een paar programma's erbij zetten. Dat is relatief weinig moeite lijkt me

Het enige wat ik op basis hiervan kan bedenken is iet met de VGA kaart te doen. De Savage2000 is een AGP chip, dus werkt in PCI uitvoering sowieso met de PCI als bottleneck. Omdat het een PCI kaart is doet de chipset northbridge er niets anders mee dan PCI arbitraten, oftewel het kan goed als maat dienen van PCI performance.

Dat is nog wel een leuke optie ja... Je zou bijvoorbeeld een klein DOS programmaatje kunnen maken die naar 320x200x8 VGA mode springt, en een bepaald aantal keer het hele videogeheugen overschrijft (evt telkens met een andere kleur), en dan de duur hiervan timen. Dit is vrij simpel en relatief efficient te doen in assembly.

Het enige gevaar is... Wat als de chipset (of de videokaart misschien) een 'intelligent' buffering truukje toepast? Als die zien dat je telkens over hetzelfde stuk videogeheugen heenschrijft, dan kunnen ze tot dan toe gequeuede writes in principe negeren.

Maaaaar... ik zit vast aan een enkele CPU voor al die planken en dat is een P100. Is er op een P100 onder DOS of Knoppix zinnig te benchen op een manier dat PCI performance zou tonen

Tsja, da's spannend. 133 MB/sec vs 100 MHz. Dat is 1.3 byte per clockcycle. Als we één instructie per cycle aannemen, dan moet iedere instructie 2 bytes verslepen, en af en toe mogen er een paar instructies wat rustiger aan doen (en dat is nodig voor loops e.d.). Dat is nog niet triviaal. Kun je niet aan een Pentium op 200 MHz komen ofzo? Of werkt die niet op alle moederborden?

[PD2JK]

Als je het met NIC's gaat doen, haal je met één NIC toch nooit de 133MB/sec?

1Gb = 125MB/sec.

Als je nou twee Gb NIC's neemt en deze gaat 'trunken' P2P met een ander flink systeem die ook 2 Gb NIC's heeft? Theoretisch 250MB/sec.

En dan maar nutteloze enen en nullen overpompen.

_{Ik denk even mee, of gaat dit echt niet werken}

[ Voor 8% gewijzigd door PD2JK op 20-07-2004 18:03 ]

[DaWaN]

Hmm jammer, ik heb pas nog een paar werkende Socket 7 borden als verveling verrot staan rammen Maar wel koewl dat je die oude borden gaat bechen

[dion_b]

Prutz0r schreef op 20 juli 2004 @ 18:01:
Als je het met NIC's gaat doen, haal je met één NIC toch nooit de 133MB/sec?

1Gb = 125MB/sec.

Als je nou twee Gb NIC's neemt en deze gaat 'trunken' P2P met een ander flink systeem die ook 2 Gb NIC's heeft? Theoretisch 250MB/sec.

En dan maar nutteloze enen en nullen overpompen.

_{Ik denk even mee, of gaat dit echt niet werken}

Dit gaat om 2 redenen wel werken:

- geen PCI chipset komt in de buurt van de maximale bandbreedte - 90MB/s is al veel
- PCI is helemaal niet 133MB/s namelijk

1KHz=1000Hz, maar 1KB=1024B...

PCI=32b breed en draait op 33MHz, dat is 1056000000b/s
Maar deel dat door 8, en dan door 1024^2 en je krijgt: 125.88MB/s

Kortom, Gb is perfect, maar je houdt het probleem van de CPU als bottleneck

[FreeRider]

Interessant topic. Het lijkt me zeer interessant om een vergelijk te zien van de efficientie van meerdere (ook moderne) chipsets.

Ik heb een beetje gezocht op internet, maar veel PCI kaarten krijgen niet de hele bandbreedte vol.

hier een interessant stukje :

A standard PCI bus runs at 33 MHz and transfers 32 bits of data on the
rising edge of each clock pulse. This gives a maximum theoretical
burst transfer rate of approximately 125MiB/sec. However, there is
overhead on each command which will lower the overall data rate,
depending on the ratio of commands to data transferred. In the
general case, the performance of the PCI bus cannot be determined
except by direct measurement. However, I suspect you are primarily
concerned with the performance of a single device in the absence of
other PCI devices, or in the presence of devices making a minimum of
PCI bus transfers. In real-world tests on a single active PCI device,
you can expect a maximum of approximately 110MiB/s. See for example
StorageReview.com's review of the Adaptec 2400A RAID controller at
http://www.storagereview....00107/200107037410_2.html.
Scroll down to the Disk/Read Transfer Rate line under the table
labeled RAID 0 with 4 Drives.

[knip]

The amount of bandwidth consumed by different devices would depend on
the device in question. 10Mbit ethernet cards will transfer
approximately 1.25MiB/sec. 100Mbit cards will transfer about 12.5
MiB/sec. Gigabit cards about 125MiB/sec (though at this speed, few
cards can achieve over about 800Mbit, even in a 64-bit PCI slot).

Video cards can utilize nearly all the AGP bandwidth provided, but the
specific utilization would depend on the size and number of textures
being transferred, and the number of polygons in each frame being
displayed. A high-end card such as the Radeon 9700 still will not use
much bandwidth if it is displaying a simple spinning cube, for
example.

Sound cards do not transfer much data at all. CD quality sound at
44.1khz with 32-bit samples requires a fraction of a megabyte per
second. Sound cards though are making 44,100 PCI bus transfers every
second, and so are extremely sensitive to PCI bus latency, rather than
bandwidth.

Ik denk, na het een en ander gelezen te hebben, dat de makkelijkste en (relatief) goedkoopste manier toch een RAID array met 2 tot 4 7200 RPM disks is. De controllerkaart moet uiteraard de beste (meest efficiente) zijn die er te koop is, en hij moet dan ook nog eens goed herkend worden door de BIOS-sen van al je moederboards. Daarmee zou je dan een DOS-based benchmarkje kunnen draaien waaruit je de piekwaarden pakt.

Volgens mij is een systeem met Gigabit NIC's niet de beste methode. Enerzijds moet je "bron" PC de data op volle snelheid ophoesten (zou wel kunnen met een snelle PC met een RAMdisk waaruit de data wordt gelezen), en daarnaast is het nog de vraag of een gigabit NIC wel de volle efficientie haalt. Ook moet de kaart DOS of Linux drivers hebben.

edit:
Eigenlijk zou je deze kaart moeten hebben. Zal wel niet goedkoop zijn...

[ Voor 3% gewijzigd door FreeRider op 20-07-2004 23:57 ]

[PD2JK]

FreeRider schreef op 20 juli 2004 @ 23:41:
knip

Klopt, één NIC zal nooit de 125MB/sec halen, misschien is daarom dat trunking idee wel wat. Heb je nou echt zoveel CPU kracht nodig om 125MB/sec te halen met trunken? (De maximale bandbreedte van een PCI-bus).

---

Hardware RAID controllers hoeven dus niet op de kracht van de CPU te teren.

Kan je niet zo'n controller lenen van iemand met een stel schijfen?

[dion_b]

Kleine update:

Ik begin te wanhopen dat ik een werkende Linux basis krijg die met alle (of zelfs de meerderheid) van mijn mobo's gaat werken- met behulp van m'n vriendin heb ik nu een licht gemodificeerde Knoppix op een HDD gezet (+-50% van de mobo's kan niet van CD boorten), maar dus nog met alle hardwaredetectie erin. Resultaten zijn bedroevend, ik heb al een waslijst chipsets waar ik niet eens tot de (beoogde) runlevel 2 kom:

- ALi Aladdin IV
- SiS 5582
- OPTi Viper
- Utron UT801x
- UMC 890C

Sterker nog, tot nu toe lukt het alleen met:

- i430 reeks
- Via MVP3

Allicht dat het met de andere Via chipsets ook gaat werken, maar als ik 2/3 van de mobo's niet aan de praat krijg valt het af

Ook twijfel ik aan het nut van hdparm om te benchen; er zijn twee bench opties, -t die een data read bench doet en -T die een cache read doet. -t blijkt diskafhankelijk (identieke scores (6.7MB/s voor een Seagate ST32120) op i430FX (PIO4 max), Via MVP3 (ATA-33, wat de HDD niet ondersteunt, maar dus ook UDMA, wat hij wel kan) en i440BX (ook ATA-33, maar dan met P3-500 erbij)). Gek genoeg maakt Linux runlevel uit - dit is in runlevel 2, in Knoppix 3.4 KDE (in Xterm) krijg ik 7.9MB/s...). -T, de cache transfer bench, is daarentegen volledig CPU afhankelijk; 79.1MB/s met een P100 ongeacht chipset, 214MB/s op de P3-500.

Kortom, voor de PCI bench ga ik een dos progje gebruiken (moet nog kiezen welke). Nu nog die array regelen...

[Femme]

FreeRider schreef op 20 juli 2004 @ 23:41:
Interessant topic. Het lijkt me zeer interessant om een vergelijk te zien van de efficientie van meerdere (ook moderne) chipsets.

Ik heb een beetje gezocht op internet, maar veel PCI kaarten krijgen niet de hele bandbreedte vol.

Ik heb ook wel eens opmerkelijke verschillen gezien in bandbreedtebenutting van verschillende PCI-kaarten. Ik kan me een Adaptec 29320 herinneren die 126MB/s deed op een nForce2-plank terwijl andere SCSI-controllers daar minimaal 10MB/s onder zaten.

Ik denk, na het een en ander gelezen te hebben, dat de makkelijkste en (relatief) goedkoopste manier toch een RAID array met 2 tot 4 7200 RPM disks is. De controllerkaart moet uiteraard de beste (meest efficiente) zijn die er te koop is, en hij moet dan ook nog eens goed herkend worden door de BIOS-sen van al je moederboards. Daarmee zou je dan een DOS-based benchmarkje kunnen draaien waaruit je de piekwaarden pakt.

Latency kun je er niet mee testen, maar voor bandbreedte tests is het inderdaad wel een goede test.

Met AnalyzeDisk uit IPEAK SPT kun je eenvoudig de buffer transfer rate van een harde schijf testen. Dat kan ook een manier zijn om de efficiency van de bus te bepalen.

Als je ook de performance van de onboard ATA controllers wilt benchen is het wellicht interessant om één van de RankDisk traces van Tweakers.net te pakken. Dat geeft een beter beeld van de real world performance van de controller. Je hebt er wel Windows voor nodig. Als je dan ook nog de performance gaat meten met een losse PCI controller dan kun je ook een mooie vergelijking maken van de invloed van de PCI implementatie op de disk I/O performance.

[ Voor 6% gewijzigd door Femme op 21-07-2004 02:22 ]

[FreeRider]

Femme schreef op 21 juli 2004 @ 02:21:Ik heb ook wel eens opmerkelijke verschillen gezien in bandbreedtebenutting van verschillende PCI-kaarten. Ik kan me een Adaptec 29320 herinneren die 126MB/s deed op een nForce2-plank terwijl andere SCSI-controllers daar minimaal 10MB/s onder zaten.

Ja, niet elke kaart perst alles eruit. Met een enkele disk eraan is m'n ATTO UL3D kaartje ook ongeveer 10 MB/sec sneller dan een Adaptec 29160. Dus voor zo'n test moet je zeker weten dat je de meest efficiente/snelle kaart hebt, zodat dat niet de bottleneck is bij het testen. Ideaal is een kaart die niet leunt op de CPU (zoiets als een LSI MegaRAID ?).

Als benchmark zou je dan dit programmaatje van C'T kunnen gebruiken. Draait onder DOS en zij gebruiken het ook voor de benches in hun blad (=vergelijkingsmateriaal )

Maar, hoe test je de PCI latency ? Je zou wel de invloed ervan op de benchmark kunnen testen, maar of dat representatief is ? Er zijn genoeg DOS progseltjes waarmee je de PCI registers kan editen (als het niet in de BIOS kan) ....

[Verwijderd]

Heise Online heeft destijds een RocketDrive (www.cenatek.com) afgenomen als test-tool.
Het is namelijk een PCI-based solid-state disk die gebruik maakt van SDRAM.
heb er zelf ook nog eentje liggen, maar daar doe ik niks mee aangezien het een test-exemplaar was (soort prototype) en deze fouten bevatte waardoor de data corrupt werd.
De PCI-bus van mijn toenmalige K7S5A bordje had een werkelijke limiet van 90MB/s

Helaas geen PCI-X versie vooralsnog.