* [musl] on aarch64, dns A/AAAA queries has high probability of having same dns transaction ID, causing 5s delay
@ 2021-01-05 13:44 王志强
2021-01-07 1:38 ` [musl] " 王志强
0 siblings, 1 reply; 2+ messages in thread
From: 王志强 @ 2021-01-05 13:44 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 951 bytes --]
Hi guys,
I am having lots of dns 5s delay on a arm/aarch64 platform, after tcpdump capturing dns packages, I found that the delay always happened when A/AAAA queries happened to have same dns transaction id.
network/res_mkquery.c
...
/* Make a reasonably unpredictable id */
clock_gettime(CLOCK_REALTIME, &ts);
id = ts.tv_nsec + ts.tv_nsec/65536UL & 0xffff;
q[0] = id/256;
q[1] = id;
...
time/clock_gettime.c
...
r = __syscall(SYS_clock_gettime, clk, ts);
if (r == -ENOSYS) {
if (clk == CLOCK_REALTIME) {
__syscall(SYS_gettimeofday, ts, 0);
ts->tv_nsec = (int)ts->tv_nsec * 1000;
return 0;
}
r = -EINVAL;
}
return __syscall_ret(r);
....
On aarch64, gettimeofday yields current time with low accuracy, the smallest unit is 1e-6, (I think)
Could we add some trick to make sure that the parallel A/AAAA queries got different id?
Thanks
David
[-- Attachment #2: Type: text/html, Size: 2006 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* [musl] Re:[musl] on aarch64, dns A/AAAA queries has high probability of having same dns transaction ID, causing 5s delay
2021-01-05 13:44 [musl] on aarch64, dns A/AAAA queries has high probability of having same dns transaction ID, causing 5s delay 王志强
@ 2021-01-07 1:38 ` 王志强
0 siblings, 0 replies; 2+ messages in thread
From: 王志强 @ 2021-01-07 1:38 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]
After re-check the test, I realization that the dns client was accually using glibc while the server was running in alpine container using musl library, when retest the client within alpine container, there is no dns 5s delay detected.
musl uses clock_gettime first and my aarch64 env supports clock_gettime with clock id 0, the accuracy is in nanoseconds, the probability of transaction id collision within same connection is very low.
Hence the issue is about glibc on aarch64, not alpine.
Sorry about the error report.
But I still do not understand the reasoning of choosing time to generate dns transation id, why not use some random source?
Thanks
David
At 2021-01-05 21:44:32, "王志强" <00107082@163.com> wrote:
Hi guys,
I am having lots of dns 5s delay on a arm/aarch64 platform, after tcpdump capturing dns packages, I found that the delay always happened when A/AAAA queries happened to have same dns transaction id.
network/res_mkquery.c
...
/* Make a reasonably unpredictable id */
clock_gettime(CLOCK_REALTIME, &ts);
id = ts.tv_nsec + ts.tv_nsec/65536UL & 0xffff;
q[0] = id/256;
q[1] = id;
...
time/clock_gettime.c
...
r = __syscall(SYS_clock_gettime, clk, ts);
if (r == -ENOSYS) {
if (clk == CLOCK_REALTIME) {
__syscall(SYS_gettimeofday, ts, 0);
ts->tv_nsec = (int)ts->tv_nsec * 1000;
return 0;
}
r = -EINVAL;
}
return __syscall_ret(r);
....
On aarch64, gettimeofday yields current time with low accuracy, the smallest unit is 1e-6, (I think)
Could we add some trick to make sure that the parallel A/AAAA queries got different id?
Thanks
David
[-- Attachment #2: Type: text/html, Size: 3629 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-01-07 1:39 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-05 13:44 [musl] on aarch64, dns A/AAAA queries has high probability of having same dns transaction ID, causing 5s delay 王志强
2021-01-07 1:38 ` [musl] " 王志强
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).