About the delay signal

[SoonyangZhang]

The data packets are sent from server to client (A-->B). Why use the one way delay signal from client to server (B-->A, the reverse link) for control? That really confuse me a lot. The packets are accumulted on the link of A-->B. It seems to me the delay value from B-->A has nothing releated to reflect link congestion.

delay = (receivedtime.tv_sec-pdu->seconds)*1000.0+(receivedtime.tv_usec-pdu->millis)/1000.0;

[yzaki]

Hello Zhang, We don’t use the one way delay but rather the round trip time. We send the packet sent time with the original packet and the client would echo back this time back to the sender through the ACK. So when you receive the pdu packet it will contain the send time of that packet recorded at the server side and by subtracting this from the received time you get the round trip time. Hope this helps.

…

----- Dr. Yasir Zaki Assistant Professor of Computer Science NYU Abu Dhabi Computational Research Building (A2) Office Number 191 Office Tel (UAE): +971 2 628 4860 NYU Abu Dhabi, Saadiyat Campus P.O. Box 129188 Abu Dhabi, United Arab Emirates

On 3 Jul 2020, at 1:38 PM, Zhang Songyang ***@***.***> wrote: The data packets are sent from server to client (A-->B). Why use the one way delay signal from client to server (B-->A, the reverse link) for control? That really confuse me a lot. The packets are accumulted on the link of A-->B. It seems to me the delay value from B-->A has nothing releated to reflect link congestion. delay = (receivedtime.tv_sec-pdu->seconds)*1000.0+(receivedtime.tv_usec-pdu->millis)/1000.0; — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_yzaki_verus_issues_6&d=DwMCaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=l04SnaQVzqcT8bIQZnZVN5_lqiW2O2HHogtrrMBx2YI&m=cNwYr-ioyJp7zSH-vQWWYAxDMlwnLP51a7pJC39QHn4&s=QrVXwzF8VWuHX6jMT0o55WM4TWn8OZweq2V3A470WJU&e=>, or unsubscribe <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ACK47O25RYWFEF2HA3VAUJLRZWRK7ANCNFSM4OPU2KRQ&d=DwMCaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=l04SnaQVzqcT8bIQZnZVN5_lqiW2O2HHogtrrMBx2YI&m=cNwYr-ioyJp7zSH-vQWWYAxDMlwnLP51a7pJC39QHn4&s=Moenq4W8octlIEz0NCEI6muMTX-JfugA1l7fCJDXfEU&e=>.

[SoonyangZhang]

client side:

    gettimeofday(&timestamp,NULL);
    sprintf(tmp, "%ld.%06d, %llu\n", timestamp.tv_sec, timestamp.tv_usec, pdu->seq);
    clientLog << tmp;

    pkt = (sendPkt *) malloc(sizeof(sendPkt));
    pkt->pdu = pdu;
    pkt->seconds = timestamp.tv_sec;
    pkt->millis = timestamp.tv_usec;

this code use the receipt time and send the packet back to server.
server side:

//https://github.com/yzaki/verus/blob/master/src/verus_server.cpp#L658  
gettimeofday(&receivedtime,NULL);
delay = (receivedtime.tv_sec-pdu->seconds)*1000.0+(receivedtime.tv_usec-pdu->millis)/1000.0;

The delay is the one way delay from client to server. it is not the rtt signal.

[CooleyTukey]

@SoonyangZhang the client sends pkt->pdu to the server, not pkt