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=225535 --- Comment #7 from Aleksander Derevianko <aeder@list.ru> --- I have now running tests on Moxa DA-820 with kern.eventtimer.periodic=1. One interesting thing: if you look on tests with 6.3-RELEASE, 98% of samples is 1115322 send_sync 0 0 0 0 = send(small data) recv(small data) send(40Kb) recv(40Kb) - so every send() and recv() call is executed in <1ms. 7% of samples have 73629 send_sync 0 1 0 0 - 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=1 produce the following results for 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 247 times 2551: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 248 times 2552: send_sync 0 recv_sync 0 send_data 0 recv_data 1 eval 52 sleep 247 times 2553: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 247 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 248 times 2556: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 247 times 2557: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 247 times 2558: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 248 times 2559: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 247 fspb: times 2550: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 248 times 2551: send_sync 0 recv_sync 0 send_data 0 recv_data 1 eval 52 sleep 247 times 2552: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 248 times 2553: send_sync 0 recv_sync 0 send_data 0 recv_data 1 eval 52 sleep 247 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 247 times 2556: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 247 times 2557: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 248 times 2558: send_sync 0 recv_sync 0 send_data 0 recv_data 1 eval 52 sleep 247 times 2559: send_sync 0 recv_sync 0 send_data 0 recv_data 0 eval 52 sleep 247 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. -- 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>