A napokban egy összetett alkalmazáskésleltetés-mérési projekt kapcsán felmerült a kérdés, hogy hol legyen az első mérési pont a rendszerben. Maga a rendszer egy több hostos elosztott alkalmazás, amiben mindenfelé létre lettek hozva mérési pontok. Nyilvánvaló, hogy az első mérési pont ott kell, hogy legyen, ahol bejutnak az adatok a rendszerbe, ezt történetesen egy Linux. A teljes elosztott alkalmazás késleltetési ideje sok milliszekundumos nagyságrendben mozog, nekem meg sem fordult a fejemben, hogy az említett első mérési pontot nem ezen a gateway Linux rendszeren kellene létrehozni, de egy kolléga felvetette, hogy van ám az előtt a Linux előtt egy switch is, és hogy gyakorlatilag az az első eszköz a teljes rendszerben, azon kellene egy monitor portot konfigurálni, hogy valóban a legkorábbi ponton kapjuk el a bejövő adatokat.
Ekkor kibújt belőlem a networkös, hiszen a switching, akár a gyorsabb cut-through de még a lassabb store-and-forward esetében is a milliszekundumos nagyságrend alatt, mikroszekundumos berkekben mozog. Arról nem is szólva, hogy az elosztott rendszer hostjai közötti NTP szinkronizációnak is vannak korlátai, sosem törtem ilyenen a fejem, de
állítólag LAN-on az NTP szinkronizáció precizitása jó, ha megüti a 20 mikroszekundumos tartományt. Ergo felesleges vesződni a monitor porttal, ha nem is tudjuk olyan precízen jegyzetelni az adatokat, amennyit az egyetlen switcheléssel korábbi sniffing jelentene.
Ennek apropóján utánanéztem, hogy tulajdonképpen mennyi az annyi: mekkora manapság a switchek késleltetése? Átpörgettem pár adatlapot különböző gyártóktól, és arra jutottam, hogy az enterprise termékek esetében a mezei 100Mb/s-es eszközöktől a 10Gb/s-es Ethernet eszközökig nagyjából néhány tíz mikroszekundumos késleltetéssel lehet számolni. Persze nehéz ezeket az adatokat összehasonlítani, hiszen nem ugyanazokkal a módszerekkel dolgoznak a különböző műhelyek a mérések során, van ahol a beérkező keret első bitjétől megy a stopper a kimenő keret első bitjéig, máshol (store-and-forward méréseknél) a beérkező keret utolsó bitjétől a kimenő első bitjéig. Gyakran nincs feltüntetve, hogy mekkora Ethernet keretméret mellett végezték a mérést, máshol egész adatsorok vannak egészen jumbo frame méretig. De úgy körülbelül a néhány tíz mikroszekundum jó közelítést ad, és ez nagyjából a kilencvenes évek közepe, az
ASIC áramkörök switchekben való megjelenése óta így van. Az alapok a cisco.com-on elolvashatók a "Cut-Through and Store-and-Forward Ethernet Switching for Low-Latency Environments" doksiban.
Persze vannak extrém igényeket kielégítő termékek is. Úgy tűnik, hogy mostanában a low latency switching piacot leginkább a tőzsdei rendszerek, illetve azoknak is egy speciális szegmense, a High-Frequency Trading rendszerek fűtik. Az egyik, erre a piacra szakosodott gyártó, az Arista például 600 nanoszekundumos késleltetésű cut-through switchekkel hergeli a vevőit már a tervezési dokumentumaiban is, így rackek között is már 2,4 mikroszekundomot képesek elérni.
No, ettől messze vannak azok az eszközök, amikhez én hozzáférek, de épp volt kéznél egy 3Com 5500-EI, gondoltam kipróbálom, hogy mekkora a késleltetése, nem éppen mai darab, de legalább enterprise cucc. Az adatlap pusztán annyit közöl, hogy "Store-and-forward switching; latency <10 μs". Lássuk. Elővettem a Systimax patchkábeleket, két egyforma laptopot, egyforma OS-szel (Ubuntu 12.04.1), és céleszköz híján ment a ping, először 1000 bájtos mérettel:
50 packets transmitted, 50 received, 0% packet loss, time 48998ms
rtt min/avg/max/mdev = 0.462/0.495/0.528/0.036 ms
Hm... 495μs átlagos RTT-re, annak a fele 247,5μs, igaz ebben benne van az is, hogy a switchtől független két OS-en át kell verekednie magát, valószínűleg maga a kapcsolás sokkal rövidebb ideig tart, mint amennyi idő alatt a két végen lévő TCP/IP stacken átjut az ICMP, de valahogy akkor is kevesebbre számítottam. Aztán kipróbáltam 32 bájtos mérettel is:
50 packets transmitted, 50 received, 0% packet loss, time 48998ms
rtt min/avg/max/mdev = 0.167/0.184/0.218/0.021 ms
Így már csak 184μs az átlagos RTT, azaz egy átlagos odaút már csak 92μs, úgy, hogy ebben a két Linux TCP/IP stackje is benne van, nem csak a kapcsolás. Ez valóban sokkal közelebb van az adatlap alapján megcélzott <10μs-hez, gyakorlatilag én ezt a a <10μs adatot már simán el is hiszem.
