From: Tuong L. T. <tuo...@de...> - 2020-03-11 10:34:14
|
Resend this... It seemed to be dropped somehow... BR/Tuong -----Original Message----- From: Tuong Lien <tuo...@de...> Sent: Wednesday, February 19, 2020 2:42 PM To: tip...@li...; jm...@re... Cc: tip...@de...; Tuong Lien <tuo...@de...> Subject: [PATCH] ptts: fix tipcTS failure in case of latency The 'ptts' test keeps failed when testing under high traffic with some network latency. This is because the 'tipcTS' server side doesn't wait long enough at its 'select()' call, just 1s+ and gets timeout. The time variable is also not re-initiated after the 1st timeout, so the next attempts just return shortly i.e. timeout = 0: ./tipcTS -v ... Received on 0 sockets in subtest 6, expected 2 Received on 0 sockets in subtest 6, expected 2 Received on 0 sockets in subtest 6, expected 2 ===>Finished SubTest 7: received 0 msgs of sz -1 at 2 sockets (40 per socket) TEST FAILED Received wrong number of multicast messages The commit fixes the issue by increasing the timeout value to 3s and also re-initiating it correctly. Signed-off-by: Tuong Lien <tuo...@de...> --- test/ptts/tipc_ts_server.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/test/ptts/tipc_ts_server.c b/test/ptts/tipc_ts_server.c index 3a2f96f..e102c94 100644 --- a/test/ptts/tipc_ts_server.c +++ b/test/ptts/tipc_ts_server.c @@ -610,7 +610,7 @@ void server_mcast rcvbuf = malloc(66000); buf = rcvbuf; recvSyncTIPC (TS_SYNC_ID_3); /* wait for client to tell us to start */ - timeout.tv_sec = 1; + timeout.tv_sec = 3; timeout.tv_usec = 0; dbg1("===>Starting SubTest %d\n", st); @@ -625,12 +625,12 @@ void server_mcast while (sk_cnt < exp_sks ) { fds = *readfds; num_ready = select(FD_SETSIZE, &fds, NULL, NULL, &timeout); + timeout.tv_sec = 3; if (!num_ready) { printf("Received on %u sockets in subtest %u, expected %u\n", sk_cnt, st, exp_num[numSubTest]); break; } - timeout.tv_sec = 1; for (i = 0; i < TIPC_MCAST_SOCKETS; i++) { if(!FD_ISSET(sd[i], &fds)) -- 2.1.4 |