Ile użytecznej przepustowości zabiera narzut protokołu w łączu domowego NAS?

Narzut protokołu zwykle usuwa kilka procent dobrze wypełnionego przewodowego łącza NAS przed uwzględnieniem SMB i zachowania aplikacji. Przy standardowym MTU 1500 bajtów TCP przez IPv4 może przenosić 1460 bajtów ładunku aplikacji w każdym pakiecie IP, podczas gdy ramkowanie Ethernet, preambuła i przerwa między ramkami pochłaniają dodatkowy czas przewodu.

Ta arytmetyka to tylko teoretyczny sufit efektywności dla dużych, czystych transferów. Małe pliki, częściowe pakiety, potwierdzenia, komunikaty SMB, szyfrowanie, opóźnienia, retransmisje, oczekiwania na pamięć masową i zachowanie klienta mogą znacznie obniżyć rzeczywiste goodput.

Jaka jest różnica między prędkością linii a goodput?

Prędkość linii opisuje, jak szybko interfejs sygnalizuje bity, podczas gdy goodput liczy tylko dostarczone dane aplikacji. Nagłówki, potwierdzenia, retransmisje i komunikaty kontrolne to rzeczywisty ruch, ale nie bajty dodane do ukończonego pliku użytkownika.

Port 1GbE nie może więc dostarczać 125 MB/s ładunku pliku w nieskończoność. Ta liczba przelicza miliard sygnalizowanych bitów na sekundę na bajty przed odjęciem jakiegokolwiek narzutu ramkowania lub protokołu.

Goodput powinno być mierzone na poziomie aplikacji po zakończeniu transferu. Liczniki interfejsu mierzą szerszy ruch i mogą obejmować ponowne próby lub dane, które aplikacja jeszcze nie zatwierdziła.

Ile usuwają nagłówki Ethernet, IP i TCP?

Dla standardowego TCP przez IPv4 bez opcji, nagłówki TCP i IP zmniejszają efektywność ładunku. Koszt 40 bajtów TCP/IP to około 2,7% MTU IP przed uwzględnieniem narzutu przewodu Ethernet.

Na poziomie przewodu Ethernet pełnowymiarowa ramka wykorzystuje również nagłówek o długości 14 bajtów, 4-bajtowe FCS, 8-bajtowy preambułę i delimiter startowy oraz 12-bajtową przerwę między ramkami. Ładunek TCP o rozmiarze 1460 bajtów może więc zajmować około 1538 bajtów-czasów na prostej, nieoznakowanej ścieżce Ethernet.

Ten stosunek to około 94,9% efektywności ładunku. Przybliżony sufit wynosi więc około 949 Mbps na 1GbE, 2,37 Gbps na 2,5GbE oraz 9,49 Gbps na 10GbE przed uwzględnieniem SMB, pamięci masowej, potwierdzeń i ograniczeń implementacyjnych.

Dlaczego rozmiar ładunku wpływa na procent utraconych danych?

Większość nagłówków ma stały rozmiar na pakiet, więc większe ładunki rozkładają stały narzut ramki. Pełny pakiet o rozmiarze 1500 bajtów jest znacznie bardziej efektywny niż pakiet zawierający tylko kilkaset bajtów.

Małe, synchroniczne żądania mogą więc spędzać większą część czasu na łączu na ramkowanie, żądania, odpowiedzi i potwierdzenia. Liczba plików i rundy aplikacji mają znaczenie nawet przy umiarkowanej liczbie bajtów ładunku.

Ramki jumbo poprawiają ten stosunek jeszcze bardziej, ale maksymalny matematyczny zysk jest mniejszy niż wiele wąskich gardeł w pamięci masowej. Wymagają też spójnego wsparcia MTU na każdym urządzeniu i warstwie wirtualnej na ścieżce.

Jaką dodatkową pracę dodaje SMB ponad TCP?

SMB dodaje nagłówki wiadomości, semantykę żądań i odpowiedzi, kredyty, stan uwierzytelniania, podpisywanie lub szyfrowanie oraz rundy operacji na plikach. małe pliki powtarzają konfigurację aplikacji i protokołu.

Dla dużego, potokowego odczytu lub zapisu narzut SMB można rozłożyć na znaczne ładunki i kilka oczekujących żądań. Dla małych plików i operacji na metadanych, wiadomości otwarcia, zapytania, uprawnień, zamknięcia i katalogu stanowią większą część czasu trwania operacji.

Podpisywanie i szyfrowanie również zużywają CPU i przepustowość pamięci, niekoniecznie dodając dużą liczbę bajtów na łączu. Narzut protokołu obejmuje więc koszt przetwarzania, a nie tylko rozmiar nagłówka.

Dlaczego rzeczywiste transfery mogą tracić więcej niż przewiduje arytmetyka nagłówków?

Arytmetyka nagłówków zakłada pełne ładunki, brak strat, odpowiednie okna i punkty końcowe, które przetwarzają pakiety wystarczająco szybko. opóźnienie i straty generują koszty wykraczające poza bajty nagłówka.

Utrata pakietów powoduje retransmisje i redukcje kontroli przeciążenia. Opóźnienie ogranicza szybkość, z jaką nadawca otrzymuje informacje zwrotne. Małe okna TCP, niedopełnione kolejki, przerwy w zapisie lub jeden zajęty rdzeń CPU mogą pozostawić łącze bezczynne, mimo że teoretyczna efektywność ramki jest wysoka.

Menedżer plików może również wykonywać buforowane kopiowanie pojedynczego strumienia, podczas gdy benchmark używa kilku pracowników lub buforów pamięci. Różnica między tymi narzędziami wynika z zachowania aplikacji, a nie tylko z nagłówków protokołu.

Jak domowy NAS powinien szacować praktyczną przepustowość?

ramki jumbo zmniejszają narzut tylko na zweryfikowanej ścieżce. Zacznij od standardowego sufitu efektywności przewodu MTU, a następnie odejmij zmierzone ograniczenia punktów końcowych i obciążenia zamiast stosować uniwersalny procent.

Użyj testu tylko sieciowego, aby ustalić przepustowość TCP, następnie wykonaj kopiowanie dużych plików NAS, obciążenie małymi plikami oraz rzeczywistą aplikację. Zarejestruj prędkość linii, bajty aplikacji, CPU, opóźnienia pamięci masowej, retransmisje, rozmiar pakietu oraz czy podpisywanie lub szyfrowanie jest włączone.

Planowanie z zapasem 10–15% poniżej prędkości łącza może być rozsądne dla harmonogramowania dużych transferów, ale nie jest to stała protokołu. Dobrze dostrojona sieć LAN może zbliżyć się do sufitu efektywności przewodu, podczas gdy małe pliki lub ograniczone punkty końcowe mogą tracić znacznie więcej.

Najczęściej zadawane pytania

Jaki jest teoretyczny sufit ładunku TCP na 1GbE?

Przy pełnych pakietach TCP/IPv4 o rozmiarze 1500 bajtów i prostym rozliczeniu Ethernet, to około 949 Mbps przed ograniczeniami SMB i punktów końcowych.

Czy SMB zawsze kosztuje 10 lub 15 procent?

Nie. Jego wpływ zależy od rozmiaru żądania, liczby plików, podpisywania, szyfrowania, współbieżności, CPU, pamięci masowej i implementacji klienta.

Czy ramki jumbo odzyskają cały narzut protokołu?

Nie. Zmniejszają częstotliwość ramkowania i przetwarzania na pakiet, ale nie usuwają operacji SMB, potwierdzeń, oczekiwań na pamięć masową ani zachowania aplikacji.

Dlaczego kopiowanie NAS 10GbE może pozostać poniżej 9,49 Gbps?

Macierz pamięci masowej, dysk klienta, CPU, ścieżka PCIe, ustawienia SMB, głębokość kolejki, utrata pakietów i narzędzie kopiujące mogą stać się ograniczeniem przed efektywnością przewodu.

Ostateczne wnioski

Nadwyżka protokołu zmniejsza prędkość linii do niższej przepustowości efektywnej przez stałe obciążenia Ethernet, IP, TCP i SMB. Pełne standardowe ramki mogą zachować około 95% prędkości przewodu jako ładunek TCP, ale rzeczywiste transfery NAS również ponoszą koszty operacji plikowych, bezpieczeństwa, informacji zwrotnych, strat, opóźnień i zatorów punktów końcowych. Najpierw oblicz sufit nagłówka, a następnie zmierz specyficzną dla obciążenia różnicę.