high load system do not take all CPU time

[Robert Bonomi]

<kes-kes at 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.