poor performante Multiptp , excelent singe ptp, why?

[antonioff]

Hi all,
I have 3 ptp connected, but poor perferomance tcp.
A-B (Mode Bridge/Station-bridge) 110Mb/down 70Mb/up - distance 10Km
B-C(Mode Bridge/station bridge) 170/down 100/up - distance 22km
C-D(Mode bridge/station bridge) 130/down 90/up - distance 7km

A-D 50/down and 20/up Why?

Test in tcp mode 20 session
All device is netmetal last 6.34.3 with nv2. Possible problem sinc tdma time in any ptp?

Idea?

[p3rad0x]

Hi,

Is this links routed or bridged ?

[InoX]

I have shift to nstreme instead of nv2. Better speeds than nv2 and also lower ping. Try it.

[0ldman]

What channels?
Shielding?

[docmarius]

The degradation happens because of the store and forward process on each element in the chain.

To pass 2 intermediate stations, your data packet will have to be received, queued, dequeued and sent 4 additional times (if your B and C nodes consist of 2 access points linked together by ethernet).
So, even if a flow could be theoretically high, it will take a longer time for acknowledge packages to be sent back the chain, and trigger the next data run on the transmission.
An unacknowledged UDP stream (like video) could actually reach the full speed, but not other connections relying on a handshake.

[ste]

@docmarius

The degradation happens because of the store and forward process on each element in the chain.

To pass 2 intermediate stations, your data packet will have to be received, queued, dequeued and sent 4 additional times (if your B and C nodes consist of 2 access points linked together by ethernet).
So, even if a flow could be theoretically high, it will take a longer time for acknowledge packages to be sent back the chain, and trigger the next data run on the transmission.

This is what the tcp sliding window mechanism is for.

[docmarius]

@ste

This is what the tcp sliding window mechanism is for.

You mean this is exactly the mechanism that causes data slow down:

@wikipedia

For the highest possible throughput, it is important that the transmitter is not forced to stop sending by the sliding window protocol earlier than one round-trip delay time (RTT). The limit on the amount of data that it can send before stopping to wait for an acknowledgment should be larger than the bandwidth-delay product of the communications link. If it is not, the protocol will limit the effective bandwidth of the link.

If we consider a transmission delay of 1 msec/hop (RTT 6msec) and a maximum window size of 64k for TCP, than the maximum theoretical bandwidth is 10 MBps (166 windows/sec * 64k). Now take in account that the RTT could be bigger because of CPU processing, queuing and retransmissions due to co-location and interference…

@antonioff: what is your A-D ping time?

[ste]

@docmarius

@ste

This is what the tcp sliding window mechanism is for.

You mean this is exactly the mechanism that causes data slow down:

@wikipedia

For the highest possible throughput, it is important that the transmitter is not forced to stop sending by the sliding window protocol earlier than one round-trip delay time (RTT). The limit on the amount of data that it can send before stopping to wait for an acknowledgment should be larger than the bandwidth-delay product of the communications link. If it is not, the protocol will limit the effective bandwidth of the link.

If we consider a transmission delay of 1 msec/hop (RTT 6msec) and a maximum window size of 64k for TCP, than the maximum theoretical bandwidth is 10 MBps (166 windows/sec * 64k). Now take in account that the RTT could be bigger because of CPU processing, queuing and retransmissions due to co-location and interference…

@antonioff: what is your A-D ping time?

Your assumption of 64k is wrong. All modern OS including ROS use higher window sizes (dynamic) to overcome the latency problem.

[docmarius]

You may be right.
Any other explanation for the bandwidth reduction in multi-hop setups?

[ste]

@docmarius

You may be right.
Any other explanation for the bandwidth reduction in multi-hop setups?

I guess: Packet aggregation in NV2 which disturbs the ack mechanism of tcp. The acks might come at fast changing rates and cause hickups. We see this problems a long time now (getting better with newer ROS releases). nstreme never had this problems. nstreme has more problems with interference (did not check this with newer ROS releases so it might be better now??).