Ось кілька цікавих результатів. Завжди приємно бачити, що MegaETH виходить на перше місце : ) Щоб уявити дані в певному контексті, наскрізна затримка запиту RPC складається з трьох компонентів: (1) затримка поширення швидкості світла від/до спостерігача до/з сервера, (2) час, необхідний серверу для захоплення та подальшої обробки запитуваних даних, (3) час, необхідний спостерігачу, щоб завантажити відповідь. Як ви вже згадували, методи RPC, які тестуються, є легшими, як з точки зору обчислювальної вартості, так і з точки зору розміру даних. Це означає, що в експериментах в основному перевірялося (1), т. Е. Затримка поширення між спостерігачами і RPC-серверами. Не зрозумійте мене неправильно - RPC MegaETH також досить сильні на (2) і (3), і було б цікаво побачити експерименти, які їх напружують! Отже, як точно налаштувати затримку поширення? Власне, ручок не так вже й багато. По-перше, ми можемо розгорнути RPC-сервери в кількох географічних регіонах і автоматично спрямувати запит на найближчий сервер. Це схоже на те, як мережі швидкого харчування відкривають магазини всюди – поруч завжди є відділення! Точніше, наявність георозподілених серверів зменшує фізичну відстань між користувачами та серверами. По-друге, ми можемо оптимізувати топологію мережі. Навіть якщо він знаходиться між однією парою відправника та одержувача, затримка поширення залежить від фактичного пройденого мережевого шляху. Наприклад, між Східним узбережжям США та Азією затримка може змінюватися в 2 рази в залежності від того, чи проходять пакети даних через Тихий океан або через Європу. Іноді існує навіть кілька мережевих шляхів, що йдуть одним і тим же географічним маршрутом; Деякі з них більш перевантажені, ніж інші, що спричиняє більшу затримку. Це все одно, що мати кілька автомагістралей на вибір з пункту А в пункт Б. Переваги затримки, які ви спостерігали, швидше за все, виникли завдяки нашій оптимізації маршруту.