Towards a User-Oriented Benchmark for Transport Protocols ...
30 pages
English

Towards a User-Oriented Benchmark for Transport Protocols ...

-

Le téléchargement nécessite un accès à la bibliothèque YouScribe
Tout savoir sur nos offres
30 pages
English
Le téléchargement nécessite un accès à la bibliothèque YouScribe
Tout savoir sur nos offres

Description

Laboratoire de l’Informatique du Parallélisme
École Normale Supérieure de Lyon
oUnité Mixte de Recherche CNRS-INRIA-ENS LYON-UCBL n 5668
Towards a User-Oriented Benchmark for
Transport Protocols Comparison in very High
Speed Networks
Romaric Guillier ,
July 2007Ludovic Hablot ,
Pascale Vicat-Blanc Primet
oResearch Report N 2007-35
École Normale Supérieure de Lyon
46 Allée d’Italie, 69364 Lyon Cedex 07, France
Téléphone : +33(0)4.72.72.80.37
Télécopieur : +33(0)4.72.72.80.80
Adresse électronique : lip@ens-lyon.fr Towards a User-Oriented Benchmark for Transport Protocols
Comparison in very High Speed Networks
Romaric Guillier , Ludovic Hablot , Pascale Vicat-Blanc Primet
July 2007
Abstract
Standard TCP faces some performance limitations in very high speed wide
area networks, mainly due to a long end-to-end feedback loop and a conser-
vative behaviour with respect to congestion. Many TCP variants have been
proposed to overcome these limitations. However, TCP is a complex protocol
with many user-configurable parameters and a range of different implementa-
tions. It is then important to define measurement methods so that the transport
services and protocols can evolve guided by scientific principles and compared
quantitatively. The goal of this report is to present some steps towards a user-
oriented benchmark, called ITB, for high speed transport protocols compari-
son. We first present and analyse some results reported in the literature. From
this study we identify classes of ...

Sujets

Informations

Publié par
Nombre de lectures 61
Langue English
Poids de l'ouvrage 3 Mo

Exrait

Laboratoiredel'InformatiqueduParallélismeÉcoleNormaleSupérieuredeLyonUnitéMixtedeRechercheCNRS-INRIA-ENSLYON-UCBLno5668TowardsaUser-OrientedBenchmarkforTransportProtocolsComparisoninveryHighSpeedNetworksRomaricGuillier,LudovicHablot,PascaleVicat-BlancPrimetJuly2007ResearchReportNo2007-35ÉcoleNormaleSupérieuredeLyon46Alléed'Italie,69364LyonCedex07,FranceTéléphone:+33(0)4.72.72.80.37Télécopieur:+33(0)4.72.72.80.80Adresseélectronique:lip@ens-lyon.fr
TowardsaUser-OrientedBenchmarkforTransportProtocolsComparisoninveryHighSpeedNetworksRomaricGuillier,LudovicHablot,PascaleVicat-BlancPrimetJuly2007AbstractStandardTCPfacessomeperformancelimitationsinveryhighspeedwideareanetworks,mainlyduetoalongend-to-endfeedbackloopandaconser-vativebehaviourwithrespecttocongestion.ManyTCPvariantshavebeenproposedtoovercometheselimitations.However,TCPisacomplexprotocolwithmanyuser-congurableparametersandarangeofdifferentimplementa-tions.Itisthenimportanttodenemeasurementmethodssothatthetransportservicesandprotocolscanevolveguidedbyscienticprinciplesandcomparedquantitatively.Thegoalofthisreportistopresentsomestepstowardsauser-orientedbenchmark,calledITB,forhighspeedtransportprotocolscompari-son.Werstpresentandanalysesomeresultsreportedintheliterature.Fromthisstudyweidentifyclassesofrepresentativeapplicationsandusefulmetrics.Wethenisolateinfrastructureparametersandtrafcfactorswhichinuecnetheprotocolbehaviour.Thisenableustodenescenariocapturingandsynthesis-ingcomprehensiveandusefulproperties.Wenallyillustratethisproposalbypreliminaryresultsobtainedonourexperimentalenvironment,Grid'5000,wehavebuiltandareusingforcontributinginthisbenchmarkdesign.Keywords:ProtocolBenchmark,TCP,Performanceevaluation,HighSpeedtransport,HighSpeednetworksRésumé
Laversion“standard”deTCPestconfrontéeàuncertainnombredelimita-tionsdeperformancedanslesréseauxàtréshautdébitquisontprincipale-mentcauséesparunebouclederétroactiondeboutenbouttroplongueetuncomportementtrèsprudentvis-à-visdelacongestion.UngrandnombredevariantesdeTCPontétéproposépourtenterdesurpasserceslimitations.Ce-pendantTCPestunprotocolecomplexecomportantbeaucoupdeparamêtresdénissablesparl'utilisateuretunéventaild'implémentationsdifférentes.Ilestalorsimportantdedénirdesméthodesdemesureanquelesservicesetlesprotocolesdetransportpuissentévoluerselondesprincipesscientiquesetêtrecomparésquantitativement.Lebutdecerapportestdeprésenterunedémarcheversladénitiond'unbancd'essaiorientéutilisateur,appeléITB,pourlacomparaisondeprotocolesdetransportsdanslesréseauxàhautdébit.Nouscommençonsparprésenteretanalyserquelquesrésultatsprésentdanslalittérature.Apartirdecetteétude,nousidentionsdesclassesreprésenta-tivesd'applicationsetdesmétriquesutiles.Nousisolonsensuitelesparamêtresinfrastructurelsetlesfacteursdetracquiontuneinuencesurlecomporte-mentdesprotocoles.Cecinouspermetdedénirdesscénariospermettantdecaptureretdesynthétiserdespropriétésutilesetcomplètes.Finalement,nousprésentonsdesexemplesderésultatsobtenusdansl'environmentexpérimentalGrid'5000illustrantnotredémarche.Mots-clés:Bancd'essaideprotocoles,TCP,évaluationdeperformances,transporthaut-débit,réseauxhaut-débit2
BenchmarkforTransportProtocols1Contents1Introduction22Relatedwork32.1Transportprotocolsforhighspeednetworks......................32.2Evaluationframeworks.................................42.2.1EvaluationsonRealExperimentalNetworks.................52.2.2EvaluationsonEmulatedNetworks......................52.2.3EvaluationswithNS2simulator........................73DenitionandgoalsofaTransportBenchmarksuite73.1Whatisabenchmark?..................................73.2ExampleoftheNPBanditsusage...........................73.3Guidelinesfortransportprotocolbenchmarking....................84ITB:InriaTransportBenchmarkproposal84.1Representativeapplicationsselection..........................84.2Metrics.........................................94.2.1Metricstypes..................................94.2.2Throughput...................................94.2.3Fairness.....................................104.2.4Efciency....................................104.3Systemparameters...................................104.3.1Topology....................................114.3.2Capacities....................................114.4Workloadparameters..................................114.5Benchmark.......................................124.5.1WMapplicationcharacteristics.........................124.5.2PPapplicationcharacteristics.........................124.5.3BUapplicationcharacteristics.........................134.5.4PAapplicationcharacteristics.........................134.6ITBclassesdenition..................................135Realexperiments155.1Topologyexample....................................155.2TUapplication.....................................165.3BUapplication.....................................165.4PAapplication......................................185.5ITBparameters.....................................185.5.1Problemsize:RTTparameter.........................185.5.2Workloadparameters..............................215.6Metricsconsiderationexample.............................236Conclusion237Acknowledgement24
2R.Guillier,L.Hablot,P.Primet1IntroductionToday,mostdatatransferapplicationsandabout90%oftheInternettrafcusetheTCPprotocol.TCPhasshownagreatscalabilityinnumberofusers,butnotinlinkcapacity.TheTCPperformancecanbeverylowandunstableindata-centerapplications,gridcomputingapplications,interactivecommunicationswithinhighspeedlongdistancenetworksinfrastructureslikebbertohome(FTTH)orlambdagridsenvironments.TheconservativebehaviourofTCPwithrespecttocongestioninIPnetworksisattheheartofthecurrentperformanceissuesfacedbythehigh-performancenetwork-ingcommunity.Severaltheoreticalandexperimentalanalysishaveshownthatthedynamicsofthetraditionalfeedbackbasedapproachistooslowinveryhighspeednetworksthatmaylosepackets.Consequentlynetworkresourceutilisationisnotoptimalandtheapplicationperformanceispoorandmaybedisappointing.Manyhigh-endcomputingapplicationswishtotransferlargevolumesofdataoverwideareanetworksandrequirehighdataratesinordertodoso.However,theseapplicationsarerarelyabletotakefulladvantageofthehigh-capacity(2.5Gbps,10Gbpsandupwards)networksinstalledtoday.DatafromInternet2showthat90%ofthebulkTCPows(denedastransfersofatleast10MBofdata)uselessthan5Mbps,andthat99%uselessthan20Mbpsoutofthepossible622Mbpsprovision.Therearemanyreasonsforsuchpoorperformance.Manyoftheproblemsaredirectlyrelatedtotheendsystem,totheprocessorandbusspeed,andtotheNICwithitsassociateddriver.TCPconguration(e.g.smallbufferspace)hasalsoasignicantimpact.Butwhentheseproblemsarexed,thecongestioncontrolalgorithmisoneofthekeycomponentwhichhastobemodiedtoalleviatetheperformanceprobleminhighspeedlongdistancenetworksenvironments.Congestioncontrolisthemostimportantandcomplexpartofatransportprotocolinpacketswitchsharednetwork.TCPprovidesafullydistributedcongestioncontrolprotocolwhichstatisticallyshareavailablebandwidthamongowsfairly.TCPwasdesignedrstandforemsottoberobustandwhencongestionisdetected,TCPsolvestheproblembutattheexpenseofperformance.Forexample,forastandardTCPconnectionwith1500-bytepacketsanda100msround-triptime,achievingasteady-statethroughputof10Gbpswouldrequireanaveragecongestionwindowof83,333segments,andapacketdroprateofatmostonecongestioneventevery5,000,000,000packets(orequivalently,atmostonecongestioneventevery12/3hours).Tosolvethisproblemseveralprotocolsenhancementshavebeenproposed[WHVBPa05,SL04,XHR04].Alltheseprotocolsarenotequivalentandnotsuitedforallenvironments.SomeoftheprotocolstargetinghighspeedInternet,attempttoimproveTCPresponsefunctionwhiletryingtoretainmaximumbackwardscompatibilitywithlegacyimplementations.Othersfocusondifferenttargetenvironments,forexamplededicatedopticalnetworks.TheyarelessconservativeandtheycanbeimplementedinuserspaceandoverUDP.Sinceacoupleofyears,theevaluationandcomparisonoftheseprotocolsreceiveanincreasingamountofinterest.However,TCPandotheralternativesarecomplexprotocolswithmanyuser-congurableparametersandarangeofdifferentimplementations.Severalaspectscanbestudiedandvarioustestingmethodsexist.Theresearchcommunity1recogniseitisimportanttodeploymeasure-mentmethodssothatthetransportservicesandprotocolscanevolveguidedbyscienticprinciples.Researchersanddevelopersneedagreed-uponmetrics-acommonlanguageforcommunicatingre-sults,sothatalternativeimplementationscanbecomparedquantitatively.Usersofthesevariantsneedperformanceparametersthatdescribeprotocolcapabilitiessothattheycandevelopandtunetheirapplications.Protocoldesignersneedexamplesofhowuserswillexercisetheirservicetoimprovethedesign.Thegoalofthisreportisthentocontributetothiseffortandpresentsomestepstowardsa1Seattleworkshop,February2007
BenchmarkforTransportProtocols3user-orientedbenchmarkdesignforhighspeedtransportprotocolscomparison.Therestofthereportisorganisedasfollows.RelatedworksandongoingeffortsarereviewedinSection2.Section3denesthenotionofbenchmarkandintroducesafewexamplesofsuchtools.Section4introducesthemetrics,parametersandmeasurementmethodsconstitutingourbench-markpropositionfortransportprotocols.Section5illustratesthisproposalwithpreliminaryresultsobtainedonourexperimentalenvironment,Grid'5000,wehavebuiltandareusingforcontributinginthisbenchmarkdesign.Finally,weconcludeinSection6andproposesomeperspectivesforprotocolandnetworkserviceenhancement.2RelatedworkHighSpeedtransportprotocoldesignandevaluationisahotresearchtopic[VBTK06].WerstoverviewandclassifyproposedalternativestoTCPandthensurveyseveraleffortstowardsasystem-aticevaluationoftheseproposals.2.1TransportprotocolsforhighspeednetworksTherecentalternativestoTCP,dedicatedtohighspeedInternet,aimatsolvingtheproblemofthepoorresponsefunctionofTCPinlargebandwidth-delayproductnetworksbymodifyingtheparameters,αfortheincreaseandβforthedecrease,oftheAdditiveIncreaseMultiplicativeDecrease(AIMD)algorithmthatisusedduringthecongestionavoidancephaseofTCP.ForexampleHighSpeedTCP[Flo03]andScalableTCP[Kel03]increasetheaggressivenessinhigh-performancecontextswhiletryingtostayfairtostandardTCPowsinlegacycontexts.Table2summarisestheAIMDvaluesthatareusedbydifferentTCPvariants.In[PFTK98],Padhyeetal.presentasimpleTCPmodeltoexpressthethroughputasafunctionoftheRTT,segmentsize,AIMDconstantsandlossprobability:qMSSq(1)RTT23p+RTO338pp(1+32p2)3SSMthatcanbereducedtorR=RTT2p(2)ifweassumethatthelossrateissmall(typicallythecaseintheopticalnetworksthatformsthebackboneofmostgrids/datacenters).ThesamekindofapproachhasbeenmadeforthenewTCPvariants[Xu07]andsimilarexpressionsexist.Table1providesanapproximatevalueofthecanddparametersconsideringthatalltheformulaareintheformcSSMR=RTTpd(3).H-TCPissupposed[SL04]tohavethesameresponsefunctionasHighSpeedTCP.CUBICisnotincludedintheTable1asitsresponsefunctiondoesn'ttintheformula.BychoiceoftheAIMDconstants,ithasthesameresponsefunctionasTCPRenoforasmallcongestionepoch/BDPvaluetoensureitsfairnesswithrespecttothisprotocol.TheseresponsefunctionsprovideaninsightoftherelativeperformanceofeachTCPvariantsforagivenBDPvalue,butthismodeldoesn'tcaptureanumberofcharacteristicsofrealnetworkslikereversetrafcormultiplexing.ManyoftheseTCP
4TCPvariantcdTCPReno1.220.5BIC15.50.5HighSpeedTCP0.120.835Scalable0.081.0R.Guillier,L.Hablot,P.PrimetTable1:TCPvariants'responsefunctionparametersTCPvariantαβTCPReno121BIC1orbin.search81CUBICcub(cwnd,history)51HighSpeedTCPinc(cwnd)decr(cwnd)HamiltonTCPf(lastloss)1RRTTTTmmainxScalableTCP0.01cwnd81Table2:TCPvariants'AIMDconstantsvariantsareavailableinallrecentLinuxkernel:HighSpeedTCP[Flo03],ScalableTCP[Kel03],Hamilton-TCP[SL04],BIC[XHR04],CUBIC[RX05]andtheycanbeusedbyeveryone.TCPVegas[BOP94]andFAST-TCP[DXWH07]useothercongestioninformationavailable(round-triptimevariations,ExplicitCongestionNotication,etc)toregulatethroughputatthesenderendandthusnelycontrolbufferllinginrouters,managingIPcongestinooptimally.XCPgoesfurtherfromtoday'sstandards,proposinganewcooperativecongestioncontrolschemefeaturingaprecisecongestionwindowindicationgoingfromrouterstoendhosts.UDT,aUDP-basedDataTransferprotocol[GG07]addresstheproblemoftransferringlargevol-umetricdatasetsoverhighbandwidth-delayproductopticalnetworks.LikesomeTCPvariantssuchas[XHR04],UDTemploysanewwindow-basedcongestioncontrolalgorithmtargetingatuncon-trolledsharednetworks.2.2EvaluationframeworksSinceacoupleofyearsseveralteamsaimatdevelopingmethodologiesandtoolsprovidingcompre-hensivestandards-compliancetestingofTCPimplementations.Inthissection,wepresentinitiativesfocusingonTCPvariantevaluation.Varioustestingmethodsexisttoevaluatetransportprotocolper-formance:realInternet,realexperimentalnetworks,emulatednetworks,simulation.Eachonehasitspitfalls.Amixofseveralmethodsishighlyrequiredtoproduceconvincingresults[All99].Toourknowledge,therealInternet,throughthePlanetlabtestbedforexample,hasnotbeenemployedtoevaluateextensivelythenewTCPvariants.Severalmethodologiesandresultshavebeenproposedby[LLS06,Flo06,HLRX06]toidentifycharacteristicsanddescribewhichaspectofevaluationsce-nariodeterminethesecharacteristicsandhowtheycanaffecttheresultsoftheexperiments.Thenextsectionscomparerelatedworksaccordingtothetypeofmethodtheyhaveadopted.
BenchmarkforTransportProtocols52.2.1EvaluationsonRealExperimentalNetworksFewrealexperimentshavebeenran[CAK+05,LLS06]toanalysethebehaviourofarangeofnewprotocolsinhighspeedInternetcontext.Otherrecentworkfocusonsharedhighspeednetworksdedicatedtohighperformancedistributedapplications[GHK+07,GSP07,GHK+06].Therealex-perimentmethodgivesarealinsightoftheprotocolbehaviourinveryhighspeedenvironment(e.g.10Gbps),explorestheinteractionswiththehardwareinfrastructureandgenerallyhelpstodebugtheglobalhardwareandsoftwarecommunicationchain.Wan-In-LabWan-In-Lab[GSLL07]isatestbedoftheCaliforniaInstituteoftechnology.Itisbuiltarounda2400kmopticbbercableandarraysofopticalswitchestoconstructnetworkswithvariablelengthandRTT.Itisaccessibletousersthroughawebinterface.Thisinterfaceallowsuserstouploadexperimentalkernels,instrumentedwiththeWeb100tools,andtorunasetofpredenedtests.Theresultsofthesetestsarethenprocessedandplacedonthewebinbothgraphicalandnumericalform.ProtocolsaretestedforRTTfairness,convergencespeedbothwithandwithoutexistinglargeows,interactionwithshortows,andfairnessbetweenowstraversingdiffreentnumbersofhops.Theyareconsideringarangeofexperimentscombiningatopologyandsomenetworkingcondi-tionstostudyinterestingcases2.Themaininterestofthistestbedisthepossibilitytoperformrealexperimentsusingreallinks(1to10Gbpsspeed)andopticalswitchesandtohaveaccesstoahugerangeofRTTs(from0to180mswith2msincrements)byconguringtheopticalswitches.Grid5000Grid'5000project[BCC+06],isanexperimentalgridplatformgathering2500proces-sorsoverninegeographicallydistributedsitesinFrance.Thenetworkinfrastructureisanintercon-nectionofLANs(i.e.gridsites)andan10Gbpsopticalvirtualprivatenetwork(VPN).AsimpliedtopologyisshowninFigure1.TheparticularityofthistestbedistoprovideresearcherswithafullyrecongurabilityfeaturetodynamicallydeployanyOSimageorTCPstackonanyendhostofthetestbedandwithafullydedicatedopticalnetwork.ThistestbedhasbeenusedforexperimentingdifferentTCPstacksandseveraltypesofworkloadcorrespondingtorealisticgridcomputinganddata-centerapplications[GHK+07,GSP07].Internet-liketrafccanalsobeinjectedinthistestbed.2.2.2EvaluationsonEmulatedNetworksDeploymentofrealnetworksiscostlyandexperimentscanbetimeconsuming.Moreover,suchtestbedshardlyproviderangeoflatenciestofullyexploreprotocolbehaviour.Forthesereasons,severalteamsadoptemulationmethodbyusingsoftwareorhardwarenetworkemulators.HamiltonUniversityframeworkWiththeirlatestexperimentsonTCP[LLS06],DoughLeithetal.presentanexperimentaltest-bed,basedaroundtheDummynet[Riz97]networkemulator.ThegoalistostudytheperformanceofvariousTCPvariantsandtoproposeofaseriesofbenchmarktestseasilyreproducible.ThetopologyusedisaclassicaldumbbellwithaDummynetrouterinthemiddletoemulatelatencyandtosetqueuesizeandbottleneckspeedAsetofscripts3,alongwiththeresultsofalargequantityofexperimentswithgraphsaremadeavailable.Theyareconsideringawiderangeofparametersincluding:queuesize,bottlenecksize,2http://wil.cs.caltech.edu/mwiki/index.php?title=Experiments3workingwithTCP-Linux[WC06],aNS-2patchtouseGNU/LinuxTCPcongestioncontrolalgorithmmodulestoperformexperiments
610 GbE Links  1 GbE LinksLilleOrsayNancyRennesR.Guillier,L.Hablot,P.PrimetnoyLGrenobleBordeauxToulouseSophiaFigure1:Grid'5000backboneRTT(16,22,42,82,162ms),asymmetricRTT,TCPvariantsandnumberofwebsessions.Theavailabletestsweredonewithtwoowsandamaxbottlenecksizeof250Mbps.NorthCarolinaStateUniversityframeworkFortheexperiments[HLRX06]andvalidationoftheirTCPvariants4,InjongRheeetal.useatestbedalsobasedonDummynet.TwoDummynetroutersareused,onetomanagetheAQMandthebandwidthlimitation,thesecondtoadddelay,formingadumbbelltopology.Thechoiceofthistopologyismotivatedbythefactthatevenamorecomplicatedtopologylikeaparkinglotfailstocapturetherealismofproductionnetworks.Thebottleneckisxedto400MbpsandtheRTTvaluesusedare16,64,162and324ms.Twokindsofbackgroundtrafcmaybeinjected:short-livedandlonglived.Theshort-livedtrafcisgeneratedwithacustomversionoftheSURGE[BC98]webtrafcgeneratorfollowing5differentkindoftrafcdistribution.Thelong-livedtrafcisgeneratedusingiperf.Theamountofbackgroundtrafcissettobeabout70Mbps(lessthan20%ofthebottleneckcapacity).Thebasicscenarioconsistsinmonitoringtheinteractionsoftwoowswhentheyareinteractingwithvariouslevelsofbackgroundtrafc.AIST-INRIAframeworkTheAISTandINRIAteamsusehardwareemulatorscombinedwithnet-workvirtualisationsoftwareeWANtoevaluateprotocolsunderdifferentlatencyandtopologycon-ditions[PTK+06].AIST-GtrcNET-10isahardwareemulatorthatallowslatencyemulationupto858mswithoutlosses,ratelimitationandprecisebandwidthmeasurementsat10Gbpswirespeed.GtrcNET-10p3isafullyprogrammablenetworktestbed,whichisa10Gbpssuccessorofawell-establishednetworktestbed,GtrcNET-1.4BICandCUBICTCP
BenchmarkforTransportProtocols72.2.3EvaluationswithNS2simulatorTMRGNS-2frameworkIntheIRTFdraft[NS207],WeiandFloydproposeaframeworkofbenchmarkingTCPvariantsbasedontheNS2networkemulator.Itdenestopologies,trafcchargesandmetricsthatcouldbeusedtoevaluatetheperformanceofTCPstacks.Currently,threetopologiesareconsidered:dumbbell(onebottleneck),parking-lot(multiplebot-tleneck)withcrosstrafcanda“simplenetwork”topologywithtransitandsbtudomains.Fourkindoftrafcmodelsareproposed:FTPtrafc(long-livedows),Webtrfac(short-livedows),videostreamingtrafc(CBRtrafcoverUDP)andvoicetrafc(CBRorON/OFFows).MetricsdenedintheTRMG'smetricsdraft[Flo07]areconsidered:throughput,queueingdelay,jitter,lossrate,responsetime,fairness,convergenceandrobustness.Eachkindofmetricsisadaptedtothetraf-cmodelitiscurrentlytryingtomeasure.Astheyaredescribingaframework,theydon'tprovideexplicitscenariithatmightbeinterestingtorun.PolitecnicodiBaristudiesMascoloin[MV06]isusingNS-2simulationstoobservetheimpactofreversetrafconthenewTCPcongestioncontrolalgorithms.Thetestbedisbasedonadumbbelltopologywithatmost6differentsources/destinations.Thebottlenecksizeis250Mbpsandisalsosharedbytwonetworkstransmittingwebtrafc.Heismainlyfocusingontheproleoftheworkloadsthatareappliedtothesystem(on/offreversetrafc,reversetrafc+webtrafc,reversetrafc+webtrafc+differentRTTs).HeisusingthefollowingRTTsvalues:40,80and160ms.Themetricsusedtoanalysetheresultsaremainlylinkutilisation,goodput,congestionwindowsizeandtimeoutsevents.Thisshortoverviewshowsthatsoftwaretestbeds(simulatorsoremulators)enablecomplextopolo-gies,largenumberofowsexperimentsbutthebottleneckcapacityislimitedto400Mbpsandthelatenciesto400ms.Hardware-basedtestbedsgiveresearchersaccessto10Gbpsandupto800mslatenciesbutpresentsomelimitationintopologiescomplexity.3DenitionandgoalsofaTransportBenchmarksuite3.1Whatisabenchmark?Abenchmarkisaprogramorasetofprograms,whichcalculatetherelativeperformanceofamachineoranarchitecture(hardware),oranotherprogram(software).Eachbenchmarkmayeitherfocusonquantity(executionspeed,amountofdatacomputed,etc.)oronquality(robustness,security,etc.).Benchmarkcanbeexecutedattwodifferentlevels:lowlevelormicrobenchmarks:Testingtheperformanceofoneparticularcomponentorfunc-.noitapplicationlevel:Aimingatrepresentingtypicalapplications/workloadsofaplatformthatneedsevaluation.AmongtheexistingHighPerformanceComputing(HPC)benchmarks,theNASParallelBenchmark(NPB)[FY02]iswellknown.Thissetofprogramsrepresentsthetypicalapplicationsclassesexecutedonclusters.3.2ExampleoftheNPBanditsusage(InBTH,PCCG,,thEeP,NFPTB,I[SF,YL0U2,]iMsGaacnodmSmPo)ntlhyatusgeidvebseancghomodarpk.anTelheofNthPeBdiisffaergernotupparoaflleeilgahtppplriocagtriaomnss
  • Accueil Accueil
  • Univers Univers
  • Ebooks Ebooks
  • Livres audio Livres audio
  • Presse Presse
  • BD BD
  • Documents Documents