Dotaz: sendmsg: No buffer space available

[lertimir]

Měl jsem několikrát problém, že při normální práci (web, ssh, mail client) se mi odpojoval notebook od sítě. Paralelní puštěním pingu jsem dostal následující výpis

64 bytes from 192.168.1.1: icmp_seq=3100 ttl=64 time=6.16 ms
64 bytes from 192.168.1.1: icmp_seq=3101 ttl=64 time=4.77 ms
64 bytes from 192.168.1.1: icmp_seq=3102 ttl=64 time=1.44 ms
64 bytes from 192.168.1.1: icmp_seq=3103 ttl=64 time=2.05 ms
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
From 192.168.1.23: icmp_seq=3307 Destination Host Unreachable
From 192.168.1.23 icmp_seq=3307 Destination Host Unreachable
From 192.168.1.23 icmp_seq=3328 Destination Host Unreachable

už jsem si vygooglil, že řešení by mělo být zvýšením hodnoty /proc/sys/net/core/wmem_max. Původní hodnota je 212992, zvýšeno na 8388608. Takže není to akutní problém, ale: 1) chtěl bych pochopit, co se vlastně děje. 2) to že implicitní hodnota nedostačuje, může být proto, že problém je fakticky někde úplně jinde a já problém jen obcházím. Jestli je to maximum alokovaných bufferů tak je možné, že mi je něco alokuje a neuvolnuje a já dojedu na limit.

víte někdo, co to vlastně je a jak poznat, co je alokováno?

Odpovědi

[2X4B-523P]

ja se dogooglil k jinemu workaroundu a tam se jedna o chybu v ovladaci

https://community.scaleway.com/t/investigating-ping-sendmsg-no-buffer-space-available/313

[Sten]

Pokud tam neposíláte gigabajty za sekundu, tak nejspíš leakuje paměť ovladači síťovky.

[lertimir]

Spíš jsem ne rychlosti 500kb/s. No a jak to změřit? aktuální hodnoty co je obsazené a co je volné. A případně jak to hlásit. Mám:

lspci -vv -s 09:00.0
09:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter
        Subsystem: Hewlett-Packard Company Device 2231
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
       
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 19
        Region 0: I/O ports at 3000 [size=256]
        Region 2: Memory at c0400000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [70] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 <64us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us
                        ClockPM+ Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR+, OBFF Via message/WAKE#
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+, LTR+, OBFF Disabled
                LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
        Capabilities: [100 v2] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
        Capabilities: [140 v1] Device Serial Number 00-23-b7-fe-ff-4c-e0-00
        Capabilities: [150 v1] Latency Tolerance Reporting
                Max snoop latency: 3145728ns
                Max no snoop latency: 3145728ns
        Capabilities: [158 v1] L1 PM Substates
                L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
                          PortCommonModeRestoreTime=150us PortTPowerOnTime=150us
        Kernel driver in use: rtl8723be
        Kernel modules: rtl8723be

[Michal Kubeček]

Pro TCP spojení snažící se saturovat 10Gb/s ethernet by mělo smysl tu hodnotu zvyšovat, pro ping s intervalem 1 sekunda ani omylem, to tam musí být úplně jiný problém. Viz též sendmsg(2):

       ENOBUFS
              The output queue for a network interface was full.  This  gener-
              ally  indicates  that the interface has stopped sending, but may
              be caused by transient congestion.   (Normally,  this  does  not
              occur in Linux.  Packets are just silently dropped when a device
              queue overflows.)

víte někdo, co to vlastně je a jak poznat, co je alokováno?

Maximální velikost trasmit queue socketu (v bytech). Kolik paměti socket využívá, lze zjistit pomocí ss s přepínačem -m.

[lertimir]

Tak zvýšení velikosti obecně nepomůže. Navíc při v podstatě stejné práci se čas, kdy spojení dojede k havárii se velmi liší. někdy je to hodina, nekdy 12 hodin. příkaz ss -m dává hodnoty u některých spojení i cca 140000, ale je to dynamické (samozřejmě) a vteřinu poté je spojení prázdné. Pingy na AP jsou krátké, pod 10 ms (pingy do internetu i dlouhé, protože zapojení je počítač-AP-Ethernet-wifiKlient-poskytovatel) Někdy pomůže znovu nahodit siťový stack (service netvork stop; service network start), ale i toto má neobvyklé chování. STOP někdy trvá i cca 10=15 sekund než stack spadne. Naopak někdy start nenajede tedy networkManagerapplet hlásí nastavování rozhraní a tím skončí.

[2X4B-523P]

mozna by mohlo napovedet i par voleb prikazu ethtool, je tam i moznost spustit nejaky selftest, ale jestli to napovi chybu ovladace si nejsem jist...

pokud je spatne nastaveni, by mohlo jit zjistit pres sysctl, ale ono toho neni mnoho, co se meni od defaultu, napriklad ja z toho nemenil nikdy nic...

netstat je na cteni pred spanim...

[2X4B-523P]

tak jsem zkusil ten self test pres ethtool a v poradku, ale sejmulo mi to pripojeni