Date: Tue, 30 Jan 2018 13:06:08 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 225535] Delays in TCP connection over Gigabit Ethernet connections; Regression from 6.3-RELEASE Message-ID: <bug-225535-2472-AohihjTfec@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-225535-2472@https.bugs.freebsd.org/bugzilla/> References: <bug-225535-2472@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225535 --- Comment #7 from Aleksander Derevianko <aeder@list.ru> --- I have now running tests on Moxa DA-820 with kern.eventtimer.periodic=3D1. One interesting thing: if you look on tests with 6.3-RELEASE, 98% of sample= s is 1115322 send_sync 0 0 0 0=20 =3D send(small data) recv(small data) send(40Kb) recv(40Kb) - so every send() and recv() call is executed in <1ms. 7% of samples have=20 73629 send_sync 0 1 0 0=20=20 - so first recv() have 1ms execution time, but it's OK because it is first recv() after nanosleep(~200ms) - and we can't expect that nanosleep() will = act exactly the same on different computers. Moreover, nanosleep() period is evaluated from two local calls to clock_gettime( CLOCK_MONOTONIC, ...) and subtraction operation. But, for 10.3-RELEASE we have approximatelly even division between: 155042 send_sync 0 0 0 0 122890 send_sync 0 0 0 1 case with delay on first recv() - less then 0.02% 147 send_sync 0 1 0 0 This last 1 is for second recv() - and in this case, we have already syncronised computers over first small recv(). P.S. Test with kern.eventtimer.periodic=3D1 produce the following results f= or short test time: root@fspa2:~/clock/new_res # grep times periodic.txt | awk '{print $3 " " $= 4 " " $6 " " $8 " " $10 ;}' | sort | uniq -c 1484 send_sync 0 0 0 0 1314 send_sync 0 0 0 1 1 send_sync 0 0 0 230 4 send_sync 0 1 0 0 root@fspa1:~/clock/new_res # grep times periodic.txt | awk '{print $3 " " $= 4 " " $6 " " $8 " " $10;}' | sort | uniq -c 1698 send_sync 0 0 0 0 1134 send_sync 0 0 0 1 1 send_sync 0 0 0 229 11 send_sync 0 1 0 0 Very quick very huge delay. One moment: fspa1: times 2550: send_sync 0 recv_sync 0 send_data 0 recv_data 1 eval 52 sleep 2= 47 times 2551: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 2= 48 times 2552: send_sync 0 recv_sync 0 send_data 0 recv_data 1 eval 52 sleep 2= 47 times 2553: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 2= 47 times 2554: send_sync 0 recv_sync 0 send_data 0 recv_data 229 eval 52 sleep= 19 times 2555: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 2= 48 times 2556: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 2= 47 times 2557: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 2= 47 times 2558: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 2= 48 times 2559: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 2= 47 fspb: times 2550: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 2= 48 times 2551: send_sync 0 recv_sync 0 send_data 0 recv_data 1 eval 52 sleep 2= 47 times 2552: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 2= 48 times 2553: send_sync 0 recv_sync 0 send_data 0 recv_data 1 eval 52 sleep 2= 47 times 2554: send_sync 0 recv_sync 0 send_data 0 recv_data 230 eval 52 sleep= 18 times 2555: send_sync 0 recv_sync 0 send_data 0 recv_data 1 eval 52 sleep 2= 47 times 2556: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 2= 47 times 2557: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 2= 48 times 2558: send_sync 0 recv_sync 0 send_data 0 recv_data 1 eval 52 sleep 2= 47 times 2559: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 2= 47 The problem arise on the SAME cycle in both computers! How it is possible? Seems like in one of computers both send and receive was blocked (buffered) on some level. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-225535-2472-AohihjTfec>