The server should be fast enough.
I did run a traceroute alongside and that did not show packet loss, but I
do now see some TCP data loss events and retransmits of segments in
'netstat -s', and "TCP Previous segment lost" with varying time gaps in
wireshark. So I guess it is indeed a networking problem.
As I see it both with wired and wireless on the client, the problem must
be either in the server or the switch near the server (replacing the
cable from the server did not help).
I suspect the integrated e1000e NIC. Guess I'll add an extra NIC in the
server soon to see if that helps.
Thanks a lot for your help!
P.S. I see one strange thing in wireshark: NFS (or the networking stack)
seems to switch between small and large package (?) sizes occasionally in
the same stream. Is that normal?
Source Destination Protocol Info
[...]
<server> <client> RPC Continuation
<server> <client> RPC Continuation
<client> <server> TCP kink > nfs [ACK] ...
<server> <client> RPC Continuation
<server> <client> RPC Continuation
<client> <server> TCP kink > nfs [ACK] ...
<server> <client> TCP [TCP segment of reassembled PDU]
<server> <client> TCP [TCP segment of reassembled PDU]
<client> <server> TCP kink > nfs [ACK] ...
<server> <client> TCP [TCP segment of reassembled PDU]
<server> <client> TCP [TCP segment of reassembled PDU]
<client> <server> TCP kink > nfs [ACK] ...
[...]
<server> <client> TCP [TCP segment of reassembled PDU]
<server> <client> RPC Continuation (total: 65535 bytes)
<client> <server> TCP kink > nfs [ACK] ...
<server> <client> RPC Continuation
<server> <client> RPC Continuation
<client> <server> TCP kink > nfs [ACK] ...
[...]
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html