The network is awful - 500μs latency on non-small ping (on small ping latency is great: 33μs)

200μs of NEO/go without sha1 case is still questionable:

T(transmit request) = 10μs (deco rx throttle) + t(link-tx-request)
T(transmit answer)  = 10μs·4.5 (~ 4.5 KB answer for 4K ZData) + teco.rx-delay (= 3μs ?)

	||
	vv

T(link) ~= 60μs

T(teco-local,no-sha1,NEO/go) was ~= 100μs (see time-sep17-teco.txt)
T(deco-local,no-sha1,NEO/go) was ~=  20μs (see time-sep17-deco.txt)

	||
	vv

T(teco-deco,no-sha1,NEO/go) = 100μs/2 + 20μs/2 = 60μs ?

if so RTT(getobject) should be 60+60 = 120μs  but we have 200μs.

Something is wrong with the network: ping latency is 110μs but go-go
time is ~ 360μs which is not the same as 110 + 100 (go-go time on teco;
on deco it is 30 and it should be even less: 100/2 + 30/2).

Will investigate.

With some care it is possible for serveRecv to put itself to pause and
handoff execution to goroutine for which a packet arrived.

See comments in serveRecv about how it is done.

For BenchmarkTCPlosr cuts RTT 12.5μs -> 6.6μs .

BenchmarkSyncChanRTT-4           5000000               350 ns/op
BenchmarkBufChanRTT-4            5000000               352 ns/op
BenchmarkBufChanAXRXRTT-4        3000000               407 ns/op
BenchmarkNetPipeRTT-4            2000000               938 ns/op
BenchmarkNetPipeRTTsr-4          1000000              1594 ns/op	<-- here
BenchmarkTCPlo-4                  300000              4814 ns/op
BenchmarkTCPlosr-4                100000             12261 ns/op	<-- here
BenchmarkLinkNetPipeRTT-4         500000              3017 ns/op
BenchmarkLinkTCPRTT-4             100000             15650 ns/op

the δ beetwen TCPlo + serveRecv style RX and full link over TCPlo is ~ 3μs.

-> need to find out why TCPlosr = TCPlo + 8μs