Rata de erori e uriasa (5%) la RX. TCP va merge cu viteza mica, chiar daca UDP o sa iti raporteze sute de mega (fiind neconfirmat). Din cite stiu iperf face test UDP default deci fara relevanta ( senderul raporteaza cite frame-uri/pachete a pus online, receiverul cite primeste...). Poate ar fi bine de incercat si un iperf de la B la A (acolo cred ca vei obtine cei 5% loss) De asemenea, la wget poti captura si sa vezi cite retry-uri sunt pe TCP din cauza packet loss. Alex
On Sat, May 15, 2021 at 9:20 AM Adrian Sevcenco <adrian.sevce...@cern.ch> wrote: > On 5/15/21 1:59 AM, Petru Rațiu wrote: > > Daca compari mere cu pere, primul pas e sa incerci sa elimini mai bine > > diferentele. Din ce zici tu inteleg ca compari transferul facut cu iperf > cu > > ceva pe http. Http ce? Poate serverul ala are el ceva special, poate iei > http chior, e un fisier pus intr-un director > e singura masina cu probleme, de pe orice alta masina wgetul merge cu ~100 > MB/s > inclusiv masini conectate in acelasi switch cu A > > > dintr-o aplicatie care genereaza datele alea din ceva gatuit, etc. Daca > > zici ca sigur-sigur nu e nimic fancy acolo si ca wgetul pe localhost > merge > > bine, poate e cazul sa te uiti mai atent la firewallurile de pe drum, > poate > > are cineva idei crete despre traficul pe tcp/80 care nu se aplica la > iperf. > nope, nu am avut nici o idee :)) > in cazul de fata eu sunt si portarul si fundasul si atacantul .. > evident, si echipa adversa :)) > > > In orice caz, mai redu nitel diferentele dintre scenarii. Ce ti-a zis > pana > > acum testul cu iperf e ca nu e de la retea (si daca poti sa opresti > > serverul http sa pui iperf in locul lui pe acelasi port poti elimina si > > dubiile privind limitarile de banda de pe firewalluri), de-acu te uiti la > > nivelul de aplicatie (http adica). > in principiu B (serverul cu iperf si http) se exclude ca problema intru-cat > nici un alt client nu are probleme .. singurul cu probleme e A, si nu stiu > ce > sa verific la el ... > (B face mirror la centos/epel etc si nodurile isi fac update de la el) > > adica, de ex errorile pe interfata sunt similare cu a altora: > [root@rd ~]# ethtool -S enp4s0f0 | grep errors | grep -v ' 0' > rx_errors: 1760250 > rx_crc_errors: 1575883 > rx_csum_offload_errors: 447 > > de asemeni desi vad erori: > [root@rd ~]# ip -s -d link show enp4s0f0 > 2: enp4s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel > state UP mode DEFAULT group default qlen 1000 > link/ether 00:30:48:8b:96:7a brd ff:ff:ff:ff:ff:ff promiscuity 0 > addrgenmode none numtxqueues 1 numrxqueues 1 > gso_max_size 65536 gso_max_segs 65535 > RX: bytes packets errors dropped overrun mcast > 4666228626 30258015 1760623 24690 0 382096 > TX: bytes packets errors dropped carrier collsns > 7382979912 21335872 0 0 0 0 > > mai am noduri cu erori care nu au probleme cu downloadul cu zeci de MB/s > de la nodul B > probabil o chestie de inceput ar fi sa schimb cablul doar ca trebuie sa > ajunga cineva fizic acolo.. > asa ca intrebam cam ce (alte) modalitati de diagnostic am pentru asa ceva > ... > de ex: cum pot sa exclud (sau nu) probleme cu cablul? > > Multumesc frumos! > Adrian > > _______________________________________________ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
