Network Latency Bandwidth Calculator

Maglagay ng link rate, round-trip time at laki ng paglipat upang makita ang totoong ceiling ng isang solong TCP flow — kasama ang pangalan ng bottleneck, oras ng paglipat at bawat substitution.

Daanan

Ang pinakamabagal na hop sa path — madalas ay ang rated speed ng inyong plan.
Ping time sa kabilang dulo — gamitin ang pinakamalaking halaga na inyong inaasahan kapag may load.

Paglipat

Ang payload na ililipat — isang file, backup, o dataset.

Mga parameter ng TCP

Bytes na maaaring i-buffer ng receiver. 65,535 ang unscaled maximum; walang laman = walang limitasyon sa window.
Payload bytes bawat packet — pinupuno ng 1,460 ang isang karaniwang Ethernet frame. Walang laman = balewalain ang overhead at loss.
Average na posibilidad ng packet loss. Walang laman o 0 = walang limitasyon sa loss.

Throughput at oras ng paglipat

Inaasahang TCP throughput

—

Ilagay ang link rate, round-trip time at laki ng data.

Mga formula at substitution

throughput = min(bilis × eff, window ÷ RTT, MSS ÷ RTT ÷ √p) · BDP = bilis × RTT

    Ang bawat halagang inyong ilalagay ay kinakalkula sa browser na ito — walang ipinapadala saanman.

    FAQ

    Bakit mas mabagal ang aking paglipat kaysa sa link rate na binabayaran ko?

    Ang isang solong TCP flow ay humaharap sa tatlong independiyenteng ceiling, at ang pinakamababa ang nananaig. Binabawasan ng protocol overhead ang mismong link nang humigit-kumulang 5% — ang isang karaniwang Ethernet frame ay nagdadala ng 1,460 payload bytes out of 1,538 sa wire. Nililimitahan ng receive window ang throughput sa window ÷ RTT, kaya ang klasikong 65,535-byte na window ay naglilimita sa isang 50 ms na path sa humigit-kumulang 10.5 Mbit/s gaano man kabilis ang link. At nililimitahan ito ng loss sa (MSS ÷ RTT) ÷ √loss. Pinapangalanan ng resulta sa itaas kung aling ceiling ang naglilimita sa inyong mga numero.

    Ano ang bandwidth-delay product, at bakit nito itinatakda ang laki ng window?

    Ang BDP — link rate × round-trip time — ay ang dami ng data na kasalukuyang ipinapadala sa anumang sandali. Ang TCP ay maaaring magkaroon ng hindi hihigit sa isang unacknowledged window na outstanding, kaya ang window na mas maliit sa BDP ay nag-iiwan sa pipe na bahagyang walang laman: sa 100 Mbit/s na may 50 ms RTT, ang pipe ay naglalaman ng 625 kB, at ang 65,535-byte na window ay halos isang ikasampu lang ang napupuno nito. Iyan ang dahilan kung bakit ang mabilis at mahahabang path ay nangangailangan ng TCP window scaling (RFC 7323), na nagpapataas sa negotiable maximum mula 65,535 bytes patungong halos 1 GB.

    Paano nililimitahan ng packet loss ang TCP throughput?

    Itinuturing ng TCP ang loss bilang congestion at hinahati nito sa dalawa ang sending rate nito sa bawat kaganapan ng loss, kaya kahit ang maliliit na rate ng loss ay mahalaga sa mabilis na mga path. Tinatantya ng Mathis model ang ceiling bilang (MSS ÷ RTT) ÷ √p — sa 0.01% loss sa isang 50 ms na path na may 1,460-byte MSS, iyon ay humigit-kumulang 23 Mbit/s, anuman ang bilis ng link. Ipinapalagay ng modelo na ang mga kaganapan ng loss ay pantay na nakakalat at independiyente; sa ibaba ng humigit-kumulang 1% ay tumpak nitong nasusubaybayan ang realidad, at para sa sunod-sunod na loss (bursty loss) ito ay masyadong optimistiko.

    Ang mga megabyte ba rito ay kapareho ng sa aking file manager?

    Hindi eksakto. Ang pahinang ito ay gumagamit ng mga decimal unit, ang kumbensyon sa networking: 1 kbit = 1,000 bits at 1 MB = 1,000,000 bytes. Karamihan sa mga file manager ay nagbibilang gamit ang mga unit na nakabatay sa 1024, na madalas ay maling nalalagyan ng label na MB — ang isang "100 MB" na file doon ay karaniwang 100 MiB ≈ 104.86 decimal MB, kaya nangangailangan ito ng humigit-kumulang 5% na mas mahabang oras upang mailipat kaysa sa ipinapahiwatig ng decimal na numero. Ilagay ang 104.86 MB dito upang tumugma ito nang eksakto.

    Isinulat at sinuri ng editorial team ng BroBroGo.Huling na-update:

    Pag-unawa sa TCP Throughput Ceilings

    Ang totoong bilis ng paglipat ng data sa isang solong TCP flow ay hindi lamang itinatakda ng bilis ng iyong koneksyon. Ito ay pinamamahalaan ng tatlong independiyenteng limitasyon: ang kapasidad ng link, ang receive window, at ang pagkawala ng packet. Ang pinakamababa sa tatlong ceiling na ito ang siyang nagiging aktwal na bottleneck na naglilimita sa iyong koneksyon.

    Kapag ginamit ang Network Latency Bandwidth Calculator, makikita ang "Inaasahang TCP throughput" kasama ang sub-label na nagpapakita kung aling partikular na limitasyon ang aktibo. Ang dynamic sub-label na ito ay maaaring magpakita ng "limitado ng kapasidad ng link", "limitado ng ang receive window", o "limitado ng pagkawala ng packet". Sa pamamagitan ng pagtukoy sa pinakamababang ceiling, malalaman mo kung aling bahagi ng network path ang dapat isaayos upang mapabilis ang paglipat ng data.

    Ang Bandwidth-Delay Product (BDP) at Laki ng Window

    Ang Bandwidth-Delay Product o BDP ay naglalarawan sa dami ng data na maaaring maging "in flight" o kasalukuyang ipinapadala sa network path sa isang partikular na sandali. Kinakalkula ito gamit ang formula na:

    BDP = bilis × RTT = ‹rate› × ‹rtt› = ‹bdp› = ‹bytes›

    Upang mapuno ang kapasidad ng link, ang window ng pagtanggap ng receiver ay dapat sapat ang laki upang mapanatili ang tuloy-tuloy na pagdaloy ng data habang naghihintay ng acknowledgment (ACK) mula sa kabilang dulo. Kung ang window ng pagtanggap ay mas mababa sa BDP, ang transmitter ay mapipilitang huminto at maghintay, na nagiging sanhi ng pagkabawas ng throughput.

    Kinakalkula ng tool ang "Window upang mapuno ang path" gamit ang formula na:

    Window upang mapuno ang path = BDP ÷ 8 = ‹bdp› → ‹window›

    Kung ang kasalukuyang window ng pagtanggap ay masyadong mababa, ipapakita ng system ang dynamic note na: "Ang pagpapataas ng receive window sa ‹window› ay magbibigay-daan sa paglipat na ito na umabot sa hanggang ‹value›."

    TCP Window Scaling (RFC 7323)

    Sa ilalim ng orihinal na detalye ng TCP, ang maximum na laki ng window ng pagtanggap ay limitado lamang sa 65,535 bytes. Sa mga modernong high-speed network na may mataas na latency (tinatawag na Long-Fat Networks o LFN), ang limitasyong ito ay hindi sapat upang mapuno ang BDP.

    Upang malutas ito, ipinakilala ang TCP window scaling sa ilalim ng RFC 7323. Depende sa mga inilagay na halaga sa calculator, maaaring lumitaw ang mga sumusunod na abiso:

    • "Ang pagpuno sa path na ito ay nangangailangan ng ‹window› na window — lampas sa 65,535-byte unscaled maximum, kaya dapat i-negotiate ng magkabilang dulo ang TCP window scaling (RFC 7323)."
    • "Ang pagpuno sa path na ito ay nangangailangan ng ‹window› — lampas sa pinakamalaking window na maaaring i-negotiate ng TCP (1,073,725,440 bytes). Ang isang solong flow sa path na ito ay hindi kailanman lalampas sa ‹value›."

    Ang absolute maximum na window size na maaaring i-negotiate ng TCP gamit ang RFC 7323 ay 1,073,725,440 bytes. Ang pagtatangkang maglagay ng window na lampas dito ay magdudulot ng error.

    Ang Epekto ng Packet Loss sa Throughput

    Itinuturing ng TCP ang pagkawala ng packet (packet loss) bilang senyales ng congestion o pagsisikip sa network. Kapag may nawalang packet, binabawasan ng TCP ang bilis ng pagpapadala nito upang bigyang-daan ang network na makabawi.

    Ginagamit ng calculator ang Mathis model upang kalkulahin ang limitasyon ng throughput batay sa packet loss. Ang formula para dito ay:

    Limit ng pagkawala (Mathis) = MSS ÷ RTT ÷ √p = ‹mss› ÷ ‹rtt› ÷ √‹p› = ‹value›

    Ang Mathis model ay umaasa sa palagay na ang packet loss ay pantay na nakakalat at independiyente. Ang modelong ito ay nananatiling maaasahan lamang para sa mga loss rate na mas mababa sa 1%. Kung ang inilagay na pagkawala ng packet ay lumampas sa limitasyong ito, ipapakita ng tool ang babalang: "Ang loss na lampas sa 1% ay labas sa maaasahang range ng Mathis model — ituring ang loss ceiling bilang optimistiko."

    Overhead sa Network Protocol

    Ang bawat packet na ipinapadala sa network ay naglalaman ng karagdagang data bukod sa mismong payload. Ang karagdagang data na ito ay tinatawag na protocol overhead. Sa calculator na ito, ang overhead ay ibinabatay sa pamantayang Ethernet na nagdaragdag ng 78 bytes bawat packet (40 bytes para sa TCP/IP headers at 38 bytes para sa physical wire overhead).

    Ang efficiency ng protocol ay kinakalkula sa pamamagitan ng:

    Efficiency ng protocol = MSS ÷ (MSS + 78 B) = ‹mss› ÷ ‹frame› = ‹eff› (40 B packet headers + 38 B sa wire)

    Dahil sa overhead na ito, ang aktwal na limitasyon ng link (Link ceiling pagkatapos ng overhead) ay palaging mas mababa kaysa sa raw link rate:

    Limit ng link = bilis × efficiency = ‹rate› × ‹eff› = ‹value›

    Mga Panuntunan sa Pagkalkula at Limitasyon ng Modelo

    Ang calculator ay gumagamit ng mga tiyak na panuntunan at may mga limitasyong dapat isaalang-alang sa pagsusuri ng mga resulta:

    • Decimal-Based Units: Ang lahat ng unit sa tool ay decimal-based (halimbawa, 1 kbit = 1,000 bits, 1 MB = 1,000,000 bytes). Ang mga file manager sa mga operating system ay karaniwang gumagamit ng binary-based units (1024-based, kung saan ang 100 MB na file ay katumbas ng 100 MiB o humigit-kumulang 104.86 decimal MB).
    • Steady-State Assumption: Ipinapalagay ng modelo na ang koneksyon ay nasa steady-state at gumagamit ng isang solong TCP flow. Hindi kasama sa kalkulasyon ang mga epekto ng TCP slow start, congestion-control tuning, mabagal na receiver, at TLS handshakes. Dahil dito, ang mga totoong paglipat ay magsisimula nang mas mabagal at maaaring hindi maabot ang kalkuladong ceiling.
    • Mga Limitasyon sa Input: Ang mga input para sa bilis ng link, round-trip time, laki ng data, at window ng pagtanggap ay dapat mas mataas sa zero. Ang MSS ay dapat isang buong numero sa pagitan ng 1 at 65,495 bytes, at ang packet loss ay dapat nasa pagitan ng 0 at 100 porsyento.

    Proteksyon sa Privacy ng Data

    Ang calculator na ito ay binuo na may priyoridad sa lokal na pagpoproseso. Ang bawat halagang inyong ilalagay ay kinakalkula sa browser na ito — walang ipinapadala saanman. Ang lahat ng kalkulasyon ay lokal na pinapatakbo sa iyong device, kaya walang panganib na maipadala ang iyong sensitibong impormasyon ng network sa mga panlabas na server.

    Mga Madalas Itanong (FAQ)

    Ano ang bandwidth-delay product, at bakit nito itinatakda ang laki ng window? Ang BDP — link rate × round-trip time — ay ang dami ng data na kasalukuyang ipinapadala sa anumang sandali. Ang TCP ay maaaring magkaroon ng hindi hihigit sa isang unacknowledged window na outstanding, kaya ang window na mas maliit sa BDP ay nag-iiwan sa pipe na bahagyang walang laman: sa 100 Mbit/s na may 50 ms RTT, ang pipe ay naglalaman ng 625 kB, at ang 65,535-byte na window ay halos isang ikasampu lang ang napupuno nito. Iyan ang dahilan kung bakit ang mabilis at mahahabang path ay nangangailangan ng TCP window scaling (RFC 7323), na nagpapataas sa negotiable maximum mula 65,535 bytes patungong halos 1 GB.

    Bakit mas mabagal ang aking paglipat kaysa sa link rate na binabayaran ko? Ang isang solong TCP flow ay humaharap sa tatlong independiyenteng ceiling, at ang pinakamababa ang nananaig. Binabawasan ng protocol overhead ang mismong link nang humigit-kumulang 5% — ang isang karaniwang Ethernet frame ay nagdadala ng 1,460 payload bytes out of 1,538 sa wire. Nililimitahan ng receive window ang throughput sa window ÷ RTT, kaya ang klasikong 65,535-byte na window ay naglilimita sa isang 50 ms na path sa humigit-kumulang 10.5 Mbit/s gaano man kabilis ang link. At nililimitahan ito ng loss sa (MSS ÷ RTT) ÷ √loss. Pinapangalanan ng resulta sa itaas kung aling ceiling ang naglilimita sa inyong mga numero.

    Paano nililimitahan ng packet loss ang TCP throughput? Itinuturing ng TCP ang loss bilang congestion at hinahati nito sa dalawa ang sending rate nito sa bawat kaganapan ng loss, kaya kahit ang maliliit na rate ng loss ay mahalaga sa mabilis na mga path. Tinatantya ng Mathis model ang ceiling bilang (MSS ÷ RTT) ÷ √p — sa 0.01% loss sa isang 50 ms na path na may 1,460-byte MSS, iyon ay humigit-kumulang 23 Mbit/s, anuman ang bilis ng link. Ipinapalagay ng modelo na ang mga kaganapan ng loss ay pantay na nakakalat at independiyente; sa ibaba ng humigit-kumulang 1% ay tumpak nitong nasusubaybayan ang realidad, at para sa sunod-sunod na loss (bursty loss) ito ay masyadong optimistiko.

    Ang mga megabyte ba rito ay kapareho ng sa aking file manager? Hindi eksakto. Ang pahinang ito ay gumagamit ng mga decimal unit, ang kumbensyon sa networking: 1 kbit = 1,000 bits at 1 MB = 1,000,000 bytes. Karamihan sa mga file manager ay nagbibilang gamit ang mga unit na nakabatay sa 1024, na madalas ay maling nalalagyan ng label na MB — ang isang "100 MB" na file doon ay karaniwang 100 MiB ≈ 104.86 decimal MB, kaya nangangailangan ito ng humigit-kumulang 5% na mas mahabang oras upang mailipat kaysa sa ipinapahiwatig ng decimal na numero. Ilagay ang 104.86 MB dito upang tumugma ito nang eksakto.

    Data Rate ConverterMag-convert sa pagitan ng Mbps, MB/s, Gbps, Kbps, at iba pang mga unit ng data transfer rate.Data Storage ConverterMag-convert sa pagitan ng bytes, KB, MB, GB, TB at ng kanilang mga binary unit (KiB, MiB, GiB) agad-agad.IPv4 Subnet CalculatorMaglagay ng IP at CIDR o subnet mask upang makuha ang network, magagamit na range, broadcast address, at bilang ng host.Ano ang Aking IPTingnan ang public IP address na ginagamit ng koneksyong ito, kasama ang mga detalye ng network, rehiyon, at edge node na nakikita mula rito.