TEST4NET բլոգ — ցանցերի և անվտանգության թեստավորում

Ultra Ethernet 1.1 ընդդեմ RoCEv2. ի՞նչ է փոխվում AI ֆաբրիկի տրանսպորտում և ինչպես դա փորձարկել

Written by Alexander Zemskov | 17 հոկ, 2026 թ., 06:00:00

Գլխավորը

2026 թվականի հոկտեմբերի 12-ին Ultra Ethernet Consortium-ը հրապարակեց 1.1 սպեցիֆիկացիան: 1.0 տարբերակից (2025 թվականի հունիսի 11) 16 ամիս անց ստանդարտը դուրս եկավ scale-out-ի սահմաններից, ընդգրկեց դարակի ներսի կապերը և congestion control-ը դարձրեց ծրագրավորվող: RoCEv2-ով աշխատող ֆաբրիկների համար սա փոխարինում չէ, այլ երկրորդ տրանսպորտ առաջինի կողքին: Ֆաբրիկը պետք կլինի փորձարկել երկու տրանսպորտի համար էլ:

Ի՞նչ է ավելացրել 1.1 տարբերակը

  • Unified Local պրոֆիլ scale-up-ի համար: Տրանսպորտ արագացուցիչների միջև կարճ կապերի համար. կոմուտատորների մեկ մակարդակ կամ ընդհանրապես ոչ մեկը: Նախատեսված է lossless ֆաբրիկի համար PFC-ով կամ credit-based flow control-ով (CBFC): Հարցումը կրում է հակառակ ուղղության հաստատումը, ուստի առանձին ACK-երի կարիքը պակասում է:
  • Unified Forwarding Header (UFH): IP վերնագրի փոխարինում. հասցեավորումը տեղափոխվում է 12-բայթանոց MAC վերնագրի մեջ, խնայողությունը՝ մինչև 20 բայթ մեկ փաթեթի հաշվով: Համեմատության համար. UET 1.0-ի բազային փաթեթը կրում է 104 բայթ վերնագրեր:
  • Idle reduction: Միջփաթեթային ինտերվալը կրճատվել է միջինը 84 բայթից մինչև հաստատուն 80: Էֆեկտը նկատելի է scale-up-ին բնորոշ կարճ հաղորդագրությունների վրա:
  • CSIG: 4 կամ 8 բայթանոց թեգ, որը թարմացնում է ուղու վրա գտնվող յուրաքանչյուր կոմուտատոր. հերթի վատագույն ուշացումը կամ նվազագույն ազատ թողունակությունը: Ստացողը թեգը վերադարձնում է ACK-ի մեջ, և ուղարկողը տեսնում է իրական խցանման կետը, այլ ոչ թե ECN-ի մեկ բիթ:
  • PCM: Congestion control-ի և բալանսավորման ալգորիթմները NIC-ի վրա բեռնվում են որպես ծրագրեր: Բազային NSCC-ը և RCCC-ը պահպանվում են և կարող են օգտագործել CSIG-ը: Ալգորիթմը կարելի է փոխել քարտի ողջ ծառայության ընթացքում՝ առանց սիլիցիումի փոփոխության:
  • In-Network Collectives: Ռեդուկցիան կատարվում է կոմուտատորի վրա. վերջնակետը ուղարկում է 1 ԳԲ 2 ԳԲ-ի փոխարեն՝ 1 ԳԲ արդյունքով allreduce-ի համար:

Ինչպես է սա հարաբերվում RoCEv2-ի հետ

Ընդհանուրը. երկու տրանսպորտներն էլ RDMA են Ethernet-ի վրա, երկուսն էլ հենվում են ECN-ի և PFC-ով lossless ֆաբրիկի վրա: Unified Local-ը ուղղակիորեն նախատեսված է PFC/CBFC-ի համար, այնպես որ PFC-ը մնում է ֆաբրիկում:

Ի՞նչ է փոխվում. - Կորուստներ: RoCEv2-ը օգտագործում է go-back-N. մեկ կորստից հետո վերաուղարկվում է հոսքի ամբողջ պոչը: UET-ը օգտագործում է selective ACK. վերաուղարկվում են միայն կորած փաթեթները: - Բալանսավորում: RoCEv2-ը հոսքը պահում է մեկ ուղու վրա ECMP հեշի միջոցով: UET-ը փաթեթները բաշխում է բոլոր ուղիներով, իսկ ընդունող NIC-ը վերականգնում է հերթականությունը: - Congestion control: RoCEv2-ում աշխատում է DCQCN-ը. կոմուտատորը դնում է ECN նշում, ստացողը ուղարկում է CNP, ուղարկողը նվազեցնում է արագությունը: Ռեակցիան իրականացված է NIC-ի firmware-ում, սիգնալը մեկ բիթ է: UET-ում՝ NSCC ուշացման, կտրված փաթեթների և ECN-ի հիման վրա, RCCC՝ ստացողի կրեդիտների հիման վրա, 1.1 տարբերակից՝ CSIG և ցանկացած ալգորիթմ PCM-ի միջոցով: Փաթեթը դեն նետելու փոխարեն՝ packet trimming. կոմուտատորը փաթեթը կտրում է մինչև 64 բայթ տիպիկ 4 ԿԲ-ի փոխարեն և փոխանցում է առաջնահերթ հերթով:

Սրանցից ոչ մեկը RoCEv2-ը չի վերացնում: Keysight-ը և Nokia-ն 2025 թվականի հոկտեմբերի 1-ին AresONE 800GE-ի և 7220 IXR-H5 / 7250 IXR-10e կոմուտատորների վրա ցույց տվեցին, որ UET 1.0-ը և RoCEv2-ը DCQCN-ով աշխատում են մեկ ֆաբրիկում միաժամանակ:

Ի՞նչ է սա նշանակում ֆաբրիկի թեստավորման համար

«RFC 2544 + DCQCN լռելյայն կարգավորումներով» թեստը այլևս չի ծածկում ռիսկը: Գեներատորը և մեթոդիկան պետք է կարողանան. - էմուլացնել RoCEv2/DCQCN-ը և UET-ը զուգահեռ միևնույն 400/800GE կապուղիների վրա. սա հենց միգրացիայի սցենարն է. - ստուգել CC ալգորիթմների հավաքածուն. NSCC, RCCC, դրանց համադրությունը և NIC վենդորի custom PCM ծրագրերը. - ստուգել CSIG-ը կոմուտատորների վրա. թեգը թարմացվո՞ւմ է յուրաքանչյուր հոփի վրա, վատագույն արժեքը հասնո՞ւմ է ուղարկողին. - չափել AI բեռնվածության համար կրիտիկական մետրիկները. կոլեկտիվների ավարտի ժամանակը, ուշացման պոչը, կտրված փաթեթների և վերաուղարկումների բաժինը, PFC դադարների հաճախականությունը, victim flow-երը incast-ի ժամանակ. - scale-up-ի համար՝ դեկոդավորել UFH կադրերը առանց IP-ի և կրճատված միջփաթեթային ինտերվալը: Ոչ բոլոր անալիզատորներն են դա աջակցում:

Միգրացիայի ուղի RoCEv2-ից

  1. Ֆիքսել բազային գիծը RoCEv2/DCQCN-ի վրա. incast, PFC դադարներ, կոլեկտիվների ժամանակ:
  2. Ստուգել կոմուտատորների packet trimming-ի և CSIG-ի աջակցությունը: Trimming-ը կա ներկայիս պլատֆորմների մի մասի վրա, CBFC-ը և LLR-ը պահանջում են նոր սիլիցիում:
  3. Ներդնել UET-ը պիլոտային սեգմենտում խառը ռեժիմով՝ առանց PFC-ի կարգավորումները փոխելու, և կրկնել նույն թեստերը:
  4. Scale-up-ի համար սպասել Unified Local-ի աջակցությանը NIC-երում. 1.1-ի բոլոր ֆունկցիաներին անհրաժեշտ է ապարատային աջակցություն, մի մասը կգա firmware-ով:
  5. Վենդորից պահանջել աջակցվող պրոֆիլների ցանկ. UEC-ին համապատասխանությունը ինքնահավաստագրում է չեկլիստով, անկախ սերտիֆիկացում չկա:

Ի՞նչ է սա նշանակում բիզնեսի համար

RoCEv2-ը մնում է AI կլաստերների հիմնական տրանսպորտը առնվազն գնումների հաջորդ ցիկլի ընթացքում: Բայց նոր NIC-երն ու կոմուտատորները արժե ընտրել UET 1.1-ը հաշվի առնելով. packet trimming, CSIG, PCM: Հակառակ դեպքում երկու տարի անց ֆաբրիկը պետք կլինի փոխել ամբողջությամբ, այլ ոչ թե թարմացնել firmware-ով: Գլխավոր ռիսկը «UEC ready» մակնշմանը վստահելն է. միասնական սերտիֆիկատ չկա: Միակ պաշտպանությունը սեփական փորձարկումներն են ստենդի վրա մինչև հաշիվը վճարելը:

Ի՞նչ անել

Եթե UET-ի միգրացիան կամ ֆաբրիկի ստուգումը ձեր պլաններում է, կապվեք TEST4NET-ի հետ. կքննարկենք սցենարը և կառաջարկենք փորձարկումների ծրագիր:

Աղբյուրներ