Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 25 reacties
Submitter: Squee

De Standard Performance Evaluation Corporation, ofwel SPEC, heeft een fout ontdekt in zijn SPECjbb 2013-benchmarksoftware. De fout kan een te hoge SPECjbb-score opleveren. De scores van de benchmarksuite zijn om die reden door SPEC ongeldig verklaard.

De SPECjbb 2013-benchmarksoftware is in gebruik voor het testen van servers. Daarvoor worden de prestaties van Java-code gemeten. De software is sinds januari vorig jaar op de markt, maar ontwikkelaar SPEC meldt echter dat het een storende fout in de benchmarksoftware heeft gevonden. De bug in het zogenaamde partial purchase request-testonderdeel kan een te hoge score opleveren, waardoor het maken van eerlijke vergelijkingen niet mogelijk is.

SPEC heeft na ontdekking van de bug besloten om SPECjbb 2013 niet langer te verkopen. Ook het uploaden van benchmarkscores is niet langer mogelijk en bestaande scores zijn aangemerkt als  onbetrouwbaar. SPEC zegt aan een bugfix te werken. Licentiehouders van de SPECjbb 2013-suite zullen te zijner tijd een gratis update krijgen.

Lees meer over

Moderatie-faq Wijzig weergave

Reacties (25)

SPEC is tamelijk bekend, maar ook dat - bijv. processorboeren - creatief omgaan om een hoge (deel)score te halen. Wat dat betreft was het altijd geinig om te zien dat AMD altijd een voor hem voordelige SPEC score tevoorschijn toverde (en pseudo aantoonde Intel de loef af te steken), waar Intel dat andersom net zo hard deed (of misschien ook nog doet, al zal AMD fors aan relevantie voor Intel ingeboet hebben, omdat ze op het actuele productportfolio van Intel's Xeons geen antwoord hebben).

M.a.w. benchmarking naar kengetallen is een leuke manier of toch enigszins dingen te kunnen vergelijken, maar hecht er niet al te veel waarde aan voor real life situaties. Real life situaties zijn vaak niet eenduidig te benchmarken, zelfs al gebruik je een SAP benchmark voor een server die je voor SAP wilt gebruiken. Domweg omdat SAP (en ieder ander groot software pakket) ook veel factoren afhangen van het gebruik (bijv. groot volume transacties op klein aantal artikelen, vs. veel artikelen, klein volume transacties). Benchmarks zijn slechts indicatoren. Die nuttig kunnen zijn.

De vraag is in hoeverre genoemde afwijking in een SPEC test echt merkbaar was in de praktijk. SPEC verkoopt zelf tests. Zij zullen niet snel een nuancering aanbrengen in het nut van tests, als dat je inkomstenbron is (kwakzalver zegt hierboven hetzelfde).

[Reactie gewijzigd door kdekker op 10 december 2014 14:15]

Wat jij aanhaalt over SPEC en processorboeren zal voornamelijk over de SPECcpu2006 (of oudere SPECcpu2000) benchmark gaan. Deze is wel redelijk gedateerd en heeft wel wat haken en ogen, en daarom zijn ze al een tijdje bezig aan een opvolger te werken.

SPECjbb daarentegen is een business level benchmark; het simuleert een complete Java gebaseerde client/server en bijbehorende middleware omgeving die de IT infrastructuur van een supermarktketen implementeerd; er worden producten afgerekend bij kassa's, er wordt voorraad bijgehouden en automatisch orders geplaatst naar de magazijnen om de winkels aan te vullen, er is online verkoop van goederen, en bepaalde data mining algorithmen om het koopgedrag van klanten te analyseren. Denk aan het voorraad beheer systeem van AH gecombineerd met de infrastructuur die ze hebben om het gedrag met de AH bonuskaart te analyseren. Dit soort business level benchmarks worden meestal gebruikt om de performance van grote enterprise server systemen te vergelijken. Denk aan IBM Power, Oracle SPARC, HP Superdome systemen bijvoorbeeld.

De bug die nu ontdekt is komt er op neer dat er onder bepaalde omstandigheden incomplete transacties gemaakt worden, maar deze wel als een complete transactie geteld worden. Hierdoor valt de score dus hoger uit dan hij had moeten zijn. Wat er gebeurd is dat als er een aankoop transactie plaatsvind van een kassa, en deze doet de voorraad van een bepaald winkel product onder de 10% zakken, waarna er een aanvul request wordt gestuurd voor dit product naar de magazijnen/toeleveraar. Nu is het zo dat er in de tijd die het kost om deze transactie te verwerken en het product weer aan te vullen het mogelijk bleek om zoveel kassa transacties te hebben dat de voorraad van het product op raakt. De Kassa transacties die dit product probeerden af te rekenen faalden daardoor niet, maar lieten deze doorgaan waarbij dat product genegeerd werd, en ze werden alsnog als 'volledige' transactie meegeteld in de score. In feite werden er dus niet op voorraad zijnde producten als afgerekend beschouwd bij de Kassa, in plaats van dat er een ontevreden klant werd gesimuleerd die staat te klagen dat zijn favoriete product <X> niet beschikbaar is :Y)
Ik heb zelf wel enige ervaring met business level benchmarks. Hoewel die benchmarks dichter in de buurt komen van de realiteit (en dus ook wel wat zinnigs zeggen) blijft het een geautomatiseerd proces. Echte gebruikers werken met meer patronen.

Dat nu door een bug - hulde dat je zo nauwkeurig uitgezocht hebt wat het is - geflatteerde getallen uit de benchmark komen rollen is toch maar van beperkt belang. Effectief maakt het niet zo heel veel uit. Ik vermoed dat klanten de scaling cijfers die ze afleiden van de resultaten van een benchmark toch vaak met een factor vermenigvuldigen om de worst-case-real-life situatie aan te kunnen + toekomstige groei op te kunnen vangen. Op basis van een combinatie van gevoel en ervaring vermoed ik dat die vermenigingsvuldigingsfactor zomaar factor 2 of meer kan zijn.
Ik werk zelf in de performance tak voor SPARC, dus we hebben veel met dit soort benchmarks te maken (vandaar ook dat ik dit nieuwsbericht gesubmit had, dit nieuws kwam groot bij ons binnen ;) ).

Ik ben het met je eens dat deze benchmarks nog steeds zijn wat ze zijn; benchmarks. Ze zullen nooit de specifieke use-case van een klant beslaan, alhoewel je wel bepaalde classificaties hebt van soorten workloads, dus helemaal niets zeggend zijn ze nou ook weer niet.

Wat ik ook al hiervoor zei; het is vooral een belangrijk (en als het goed is objectief) meetinstrument om de relatieve performance verschillen tussen verschillende systemen te kunnen meten, niet voor absolute verwachte performance. Om verschillende generaties te vergelijken (hoeveel meer capaciteit verwacht ik door te upgraden naar systeem X?), maar ook om de performance van systemen van verschillende aanbieders voor dit soort workloads in kaart te brengen. Dit is gewoon de enige manier om een idee te krijgen hoe een grote IBM Power of een SPARC server zich ten opzichte van elkaar zullen gedragen; ze zijn qua architectuur zo verschillend dat je het niet zomaar op de specs af kunt gaan om te bepalen welke het beste is voor jouw type workload.

Juist vanwege dat laatste punt is deze gevonden bug dus zo belangrijk. Als jij met systeem X wel die bug raakt en met systeem Y niet (of in mindere mate), dan zal systeem X een veel betere performance score halen dan systeem Y, terwijl het misschien in de werkelijkheid helemaal niet zo'n hoge score zou kunnen behalen als de bug niet zou bestaan. De hele doelstelling van een objectieve vergelijking kunnen maken tussen systeem X en Y op basis van dit soort type workload is dus compleet van tafel. Geen wonder dus dat SPEC de benchmark heeft teruggetrokken -- dat is de enige juist actie, zeker als je jezelf als benchmark instituut geloofwaardig wilt houden.

Overigens staat gewoon op de SPEC site uitgelegd wat de bug precies inhield, maar ik dacht dat het wel wat toegevoegde waarde had om het hier iets duidelijker uit te leggen :)
Je hebt gelijk dat je iets moet hebben om heel verschillende processoren en architecturen te kunnen vergelijken.

Ik vermoed dat ik op tweakers als frequente gebruiker van SPARC, PowerPC en Itanium hardware al een minderheid ben. Dan is het wel leuk om iets uit de SPARC hoek te horen :-). Uit je reactie is dan leuk om te merken dat er toch nog meer gebruikers zijn die meer dan Linux/Windows/Intel gebruiken...

In de praktijk gebruik ik zelf slechts de entry level machines, en daar speelt de (slechte) prijs/prestatie verhouding van genoemde processoren/architecturen zo danig parten, dat Linux met Xeon het vaak wint. De prestaties van die processor zijn gewoon erg goed voor de prijs die ervoor gevraagd wordt. Maar ja, Solaris op SPARC en AIX op PowerPC en HPUX met Itanium zitten vast aan specifieke hardware (en onze klanten gebruiken het). Misschien is HPUX op Itanium eerdaags HPUX op Xeon. Ik zal maar niet meer woorden wijden aan deze redelijk off-topic reactie _/-\o_ .
Standard Performance Evaluation Corporation (SPEC) was founded in October, 1988, by Apollo,
Hewlett-Packard,MIPS Computer Systems and SUN Microsystems in cooperation with E. E.
Times. SPEC is a nonprofit consortium of 22 major computer vendors whose common goals are
“to provide the industry with a realistic yardstick to measure the performance of advanced
computer systems” and to educate consumers about the performance of vendors’ products. SPEC
creates, maintains, distributes, and endorses a standardized set of application-oriented programs
to be used as benchmarks.
http://research.microsoft...markhandbook/chapter9.pdf
https://www.spec.org/benchmarks.html

Even wat achtergrond info erbij.
Dit is meer gericht op servers en server platformen en geeft je de mogelijkheid om hardware vooraf te 'sizen'.

Al blijft het meer een indicatie en kan (software-) leveranciers informatie soms beter/anders zijn dan je kan plannen.
Voorbeeld SAP: http://global.sap.com/campaigns/benchmark/index.epx
Maar als alle gemaakte benchmarks last hebben van dezelfde bug, dan maakt het toch voor de onderlinge vergelijking niks uit ?
De bug is juist dat er iets kan veranderen, niet dat het altijd, en in dezelfde hoeveelheid gebeurd. Dus ja, dat maakt juist voor onderlinge vergelijking uit.

[Reactie gewijzigd door LankHoar op 10 december 2014 13:48]

Als het alleen in sommige gevallen een te hoge score geeft wel.
Wel als vrijwel gelijke systemen ongelijke scores krijgen wegens het anders toepassen van een onderdeel. Zo iets als te veel bonuspunten uitreiken voor het hebben van een dubbele bekerhouder in de auto, kan een vergelijkbare of zelfs op alle andere vlakken betere auto dezelfde overall-score krijgen voor het hebben van twee losse bekerhouders, niet echt eerlijk toch?
Volgens het artikel kan de fout kan een te hoge SPECjbb-score opleveren. Dat suggereert dat het dus niet bij elke benchmark voorkomt. Onderlinge vergelijking is dus ook niet meer betrouwbaar
Dapper dat ze hier mee naar buiten durven te treden. Dat geeft mij weer de indruk dat het bedrijf toch een `toffe peer' is. Ik heb alleen geen vertrouwen meer in een nieuwe editie van de software.
Dus mensen maken een foutje, moet kunnen, melden dit netjes dat het mogelijk tot onjuiste resultaten heeft geleid en hierdoor niet langer valide zijn en dan vind jij dat ze niet meer te vertrouwen zijn? Man wat word je wereldje dan klein.. 8)7
Deze logica gaat natuurlijk niet voor alles op. Zum beispiel: er is een reden dat enkel bepaalde statistische software pakketten worden gebruikt, zoals SAS en SPSS, in de analyse van medische onderzoeken: de pakketten zijn `gevalideerd' en onderzoekers zijn niet verantwoordelijke voor de fouten die eventueel in het pakket zitten (en dus niet verantwoordelijk voor logisch correcte conclusies, op basis van foutieve informatie). Daarentegen sluit de validatie (hopelijk) alle fouten in het pakket uit. Dat is in ieder geval het belangrijkste argument in het voordeel van het systeem.

Het punt is dat zo'n benchmark een best wel grote impact kan hebben op een (mogelijk) kostbare beslissing. Blijkbaar is de interne Quality Control niet afdoende.

Verder: er is een verschil tussen het product niet meer afnemen van zo'n bedrijf en ze `veroordelen' voor het maken van een foutje. Het laatste probeer ik niet te doen (maar impliceer je wel dat ik doe), het eerste lijkt me niet meer dan logisch (ik ga ook niet terug naar een restaurant waar het eten niet lekker smaakte, dan liever een nieuw restaurant proberen). Ik bedoelde in mijn eerste post dat ik het bedrijf dus wel tof vind, maar ik heb geen vertrouwen meer in hun product.
Zou toch eigenlijk moeten zijn:
Ik bedoelde in mijn eerste post dat ik het bedrijf dus wel tof vind, maar ik heb geen vertrouwen meer in de uitslagen van hun product tot nu toe.
Dat hebben ze zelf ook niet en hebben daarom de tot nu toe behaalde resultaten ongeldig verklaard.

Het gebruik van, zoals jij zegt gevalideerd, pakket als SPSS kan ook makkelijk leiden tot foutieve resultaten als je je meetpunten niet goed definieert en/of het juiste gewicht geeft.
Right, maar om vertrouwen te hebben in de nieuwe producten moet ik wel aannemen dat er iets verandert in de eigen evaluatiestructuur van hun product.

Dat laatste punt is een beetje onzinnig, omdat je het dan hebt over verkeerd gebruik van het programma.
Onzinnig? Dat is precies wat in de SPECjbb test gebeurt is aldus de makers zelfs. Er wordt in sommige gevallen te veel punten toegekend, oftewel verkeerd gewicht aan het betreffende meetpunt.
Edit: SPECjbb goed schrijven.

[Reactie gewijzigd door GewoonWatSpulle op 10 december 2014 15:16]

Als het goed begrijp gaat het hier om het programma dat verkeerde gewichten toekent. Als ik je SPSS voorbeeld goed begrijp bedoel je dat de gebruiker verkeerde gewichten toekent aan meetpunten. Dit lijkt me belangrijk verschil.
Ik denk niet dat je het goed begrijpt, is er een verschil tussen een SPSS gebruiker fout en SPECjbb ontwikkelaar fout? Ze 'bouwen' toch alle twee een testscenario waarin ze een verkeerde waarde aan een meting geven?
Voor het correct gebruik van SPSS voor het soort doeleinde dat ik bedoelde is er weer een fall-back systeem dat `peer-review' heet: dit is standaard in de academische wereld (alhoewel dit in de praktijk niet feilloos werkt). Misschien is de rek van de analogie er een beetje uit en zijn we nu appels met peren aan het vergelijken ;)

1 onbetrouwbaar programma, met 999 betrouwbare gebruikers en 1 onbetrouwbare gebruiker levert 1000 mogelijk foutieve resultaten op (waarvan er 1 zeker lijkt).
1 betrouwbaar programma, met 999 betrouwbare gebruikers en 1 onbetrouwbare gebruiker levert hopelijk slechts 1 foutief resultaat op.

Of er een conceptueel verschil is tussen de twee type fouten durf ik nu geen uitspraak over te doen. Wat denk ik belangrijker is: de plek van de fout in de keten van de gebruikers. Hoe eerder, hoe langer/breder/groter de kettingreactie. Een fout op het niveau van de ontwikkelaars is in mijn optiek dan ook minder toelaatbaar.
Je vindt dat je hun product niet meer moet gebruiken omdat ze er een fout in hebben gemaakt, maar je kan het ook bij je zelf zoeken. Je hebt er immers vroeger voor gekozen een pakket te gebruiken dat niet afdoende is gecontroleerd door een onafhankelijke partij, terwijl je het blijkbaar toch voor iets belangrijks gebruikt.

Ga je dit dan met je volgende pakket weer doen? En als je niets van een bug hoort, is dat pakket dan wel valide?
Ik denk dat het moeilijk leven is als je leeft onder de aanname dat geen enkel pakket valide is tot anderszins bewezen (zelfs zonder in allerlei filosofisch gezeur over bewijsbaarheid te vervallen). Echter heeft dit pakket bewezen niet valide te zijn (in ieder geval 1 realisatie). Dat is voor mij toch anders.
Noem eens één software pakket waar géén bugs in zitten.... _/-\o_

Een (slecht) restaurant waar je 1x per maand komt en een paar tientjes uitgeeft, is niet vergelijkbaar met een software pakket waar je dagelijks mee werkt. Beetje appels en peren vergelijken. Of ruil jij ook je auto in wanneer deze te vaak een kapot lampje heeft?

Fouten worden gemaakt, niets bijzonders, zolang die ook maar worden hersteld. En dat is waar ze nu mee bezig zijn.
Je kan het ook omdraaien: je weet in de nieuwe versie in ieder geval zeker dat deze bug er uit is, iets dat je niet weet als je andere concurrerende pakketten zou gaan gebruiken ;)
Het is wel extreem dapper van zo'n bedrijf dat ze dit toegeven.
Dit kost toch best veel geld dat ze dit doen!. Zeker dat ze t.z.t nieuwe licenties uitdelen aan de huidige licentie hebbers en ze kunnen nu geen nieuwe licenties verkopen en de 2014 versie wordt ook niet gekocht :)!

Mijn verwachting is dat ze hier wel goed aan doen zodat ze in 2014 weer betrouwbaarder worden.
Ik vraag me alleen wel af of ze niet kunnen weten wie die bug heeft misbruikt of voordeel van gehad heeft.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True