To jsou některé zajímavé výsledky. Je vždy příjemné vidět, že MegaETH je na vrcholu :) Abychom data zasadili do určitého kontextu, celková latence požadavku RPC se skládá ze tří komponent: (1) latence rychlosti šíření světla z/na pozorovatele do/ze serveru, (2) doba, kterou server potřebuje k získání a postprocesnímu zpracování požadovaných dat, (3) doba, kterou pozorovatel potřebuje ke stažení odpovědi. Jak jste zmínil, testované metody RPC jsou na lehčí straně, a to jak z hlediska výpočetní náročnosti, tak z hlediska velikosti dat. To znamená, že experimenty byly převážně testovány (1), tj. latence šíření mezi pozorovateli a RPC servery. Nechápejte mě špatně – RPC MegaETH jsou také docela silné na (2) a (3) a bylo by zajímavé vidět experimenty, které je zatěžují! Jak tedy vyladíme latenci šíření? Ve skutečnosti zde není příliš mnoho knoflíků. Za prvé, můžeme nasadit servery RPC ve více geografických oblastech a automaticky směrovat požadavky na nejbližší server. Je to jako řetězce rychlého občerstvení, které otevírají obchody všude – poblíž je vždy pobočka! Přesněji řečeno, geograficky distribuované servery snižují fyzickou vzdálenost mezi uživateli a servery. Za druhé, můžeme optimalizovat topologii sítě. I když se jedná o stejnou dvojici odesílatele a příjemce, latence šíření se liší v závislosti na skutečné projeté síťové cestě. Například mezi východním pobřežím USA a Asií se latence může lišit 2x v závislosti na tom, zda datové pakety procházejí Tichomořím nebo Evropou. Někdy dokonce existuje více síťových cest sledujících stejnou geografickou trasu; Některé jsou více přetížené než jiné, což vyvolává vyšší latenci. Je to jako mít na výběr z více dálnic z bodu A do bodu B. Výhody latence, které jste pozorovali, s největší pravděpodobností pocházely z naší optimalizace trasy.