21 Aug 19, Eugene Grosbein writes to Slawa Olhovchenkov:
EG>>>>>>> Hо для этого тебе потребуется хотя бы гигабитное соединение между EG>>>>>>> машинами, чтобы получить около 100MBytes/s на чтении или записи. SO>>>>>> 50MBytes/s EG>>>>> Почему так мало? SO>>>> размер буфера на RTT (RTT мерять с учетом необходимости передвать SO>>>> данные). задержки в сетевом стеке тоже учитывать. EG>>>>> Алекс Тутубалин имел почти line rate как раз на подобной задаче с EG>>>>> виндой и FreeBSD/ZFS. SO>>>> не на гигабите EG>>> Hа 10G. Hо на гигабите тем же самым хостам вдесятеро проще EG>>> поддерживать передачу на line rate, откуда падение вдвое-то в EG>>> условиях LAN? SO>> тут два варианта -- или ты читаешь то, что я пишу, или используешь SO>> свои фантазии.
EG> Hе понял тебя. Hа 10G меньше rt,
да
EG> но на 1G меньше rate,
похуй
EG> а при использовании большого MTU в несколько раз сглаживаются EG> требования к rtt.
с хуяли? где в формуле `speed = BUF_SIZE / RTT` ты нашел MTU?
и нет, тут BUF_SIZE -- это не TCP recv_space. это iSCSI MaxRecvDataSegmentLength, он согласовывается при логине как минимальное из таргета и инициатора и иногда бывает совсем небольшим. какжется у соляркиного родного таргета предел аж 64КБ. а у ESXi 256KB что ли.
более того, больший MTU увеличивает RTT, поскольку
а network_delay_resp = sum(switch_forward_delay){для каждого свича по пути} + sum(packet_serialization_time){для каждого линка} а packet_serialization_time = MTU / line_speed
в некоторых случаях packet_serialization_time может быть меньше, если прерывание тебе будут генерировать не по приему последнего байта пакета а чуть раньше. не уверен что так быват для сетевух. ну и для cuth throwgh свичей это время для приема Ethernet header, а не всего пакета. вот там jumbo frame может дать выйгрышь.
... Истинная цена живого человеческого общения -- счета от пpовайдеpа --- GoldED+/BSD 1.1.5-b20110223-b20110223 * Origin: (2:5030/500)
