<kes-...@yandex.ru> wrote; > > can I get interrupt limit or calculate it before that limit is > reached?
You can extrapolate from the current cpu time spent in interrupt handling and the current interrupt rate to a situation where roughly 100% of the cpu capacity is spent in interrupt handling. > > interrupt source is internal card: > # vmstat -i > interrupt total rate > irq14: ata0 349756 78 > irq16: ehci0 7427 1 > irq23: ehci1 12150 2 > cpu0:timer 18268704 4122 > irq256: re0 85001260 19178 > cpu1:timer 18262192 4120 > cpu2:timer 18217064 4110 > cpu3:timer 18210509 4108 > Total 158329062 35724 > > Have you any good I/O tuning links to read? Since the 'issue' is the _network_ card, you are being limited by the rate at which the RealTeK chipset, and the device driver software, can transfer data to/from the Ethernet. This -may- be the 'wire speed' limit, or the hardware simply may not be capable of performing _at_ 'wire speed', or (theoretically) it might be a performance limit in the driver software. In your case, the driver software can be eliminated as the limiting factor because there is lots of 'idle' cpu time. This means that either the 'wire' is saturated, or the hardware (at *either* end of the link) is not capable of operating at full "wire speed". Or one is getting bit by the 'bAndwidth delay product' on TCP connections. This describes a situation where the limit on 'un-ACKed' packets transmitted is reached -before- the ACK for the first packet is returned. If the application that use the nentwork are generating lots of 'small' packets, modifying the protocol to use a smaller number of larger packets can make for a -significant- performance increase. Network devices have limits on the number of 'packets per second' they can handle, as well as the bit-rate they can support. Note: If you are doing long-distance, high-latency, 'connections', one may be limited to well below wire speeds by the 'bandwidth delay product'. This issue can be ameliorated by increasing the TCP window size. _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
