5 ms·

For a fuller picture: • Timestamps are necessary: UDP loss is bursty, when any component anywhere along the path (including the endpoints) is momentarily too b

by gojomo 12y ago

For a fuller picture: • Timestamps are necessary: UDP loss is bursty, when any component anywhere along the path (including the endpoints) is momentarily too burdened (buffers, CPU, wires) to forward every packet. • Try packets larger than the 'path MTU' between the two endpoints: any packet larger than that is fragmented somewhere en route, and then loss of any one fragment causes the full UDP packet to be lost. • Try alongside other traffic on the endpoints, and note that TCP streams can't find their achievable rates (or split the available bandwidth amongst themselves) without hitting the packet-dropping pressure that also affects UDP. So perhaps try with 1, 2, or more TCP streams trying to max wire-speed, between the same machines at the same time. Note also you can create arbitrarily-high loss rates by simply choosing to send more than the path and endpoints can handle. (Let one side send X thousand in a tight loop; on the other side only check for 1 per second for X thousand seconds. Many will be lost, depending on how much you've exceeded the available bandwidth/buffering between the send and receive.)

xamolxix 12y ago
> • try alongside other traffic on the endpoints, and note that TCP streams can't find their achievable rates (or split the available bandwidth amongst themselves) without hitting the packet-dropping pressure that also affects UDP. So perhaps try with 1, 2, or more TCP streams doing a max-speed copy at the same time. I agree. Having (or not) other traffic on the network will impact UDP throughput dramatically. As one who does VoIP QoS will soon find out.
julie1 12y ago
Avoid timestamps: computer are not perfect, their clocks tends to drifts in non predictable ways (even with NTP). I suspect seen quite real bugs due to clock drifting (and linux non monotonic timer (which impacted python) for a while (but problem is solved)) resulting in packet drops because networks stack don't like to see packets arriving in the future when I was using pyzmq. http://lists.zeromq.org/pipermail/zeromq-dev/2013-October/022996.html http://lists.zeromq.org/pipermail/zeromq-dev/2013-October/02... My intuition is we are close to relativistic problems. (Can't prove it, I have to code a kikoo lol form for tomorrow).

by gojomo 12y ago

xamolxix 12y ago

> • try alongside other traffic on the endpoints, and note that TCP streams can't find their achievable rates (or split the available bandwidth amongst themselves) without hitting the packet-dropping pressure that also affects UDP. So perhaps try with 1, 2, or more TCP streams doing a max-speed copy at the same time. I agree. Having (or not) other traffic on the network will impact UDP throughput dramatically. As one who does VoIP QoS will soon find out.

julie1 12y ago

Avoid timestamps: computer are not perfect, their clocks tends to drifts in non predictable ways (even with NTP). I suspect seen quite real bugs due to clock drifting (and linux non monotonic timer (which impacted python) for a while (but problem is solved)) resulting in packet drops because networks stack don't like to see packets arriving in the future when I was using pyzmq. http://lists.zeromq.org/pipermail/zeromq-dev/2013-October/022996.html http://lists.zeromq.org/pipermail/zeromq-dev/2013-October/02... My intuition is we are close to relativistic problems. (Can't prove it, I have to code a kikoo lol form for tomorrow).