optimize: latencyString shows realLatency(+offset)

[luochen1990]

Background

this PR make latencyString() shows latency like realLatency(+offset) instead of latencyAfterOffset(latencyBeforeOffset)

Checklist

• The Pull Request has been fully tested
• There's an entry in the CHANGELOGS
• There is a user-facing docs PR against https://github.com/daeuniverse/dae

Full Changelogs

• [Implement ...]

Issue Reference

Closes #[issue number]

Test Result

[mzz2017]

虽然可以……但为什么每次都要把 map 里的 offset 取出来存进 o 成员里？

[luochen1990]

虽然可以……但为什么每次都要把 map 里的 offset 取出来存进 o 成员里？

umm, 不确定你指的具体是哪一行。

如果是指 127~128 行的话， 那是因为 l 和 o 在排序和显示的时候都会用到，所以就直接放进 alive 里？

[mzz2017]

直接用 offset 变量也可以？

[mzz2017]

如果是显示的话，可以调 map 再拿一遍

[luochen1990]

直接用 offset 变量也可以？

具体是哪一段，可以指定行评论咩？

[mzz2017]

LGTM.

[mzz2017]

经过测试，排名第三的节点有着更低的时延。但它似乎并不能很直观地显示出来最终的时延和排名是什么样的。如果能够在排序的时候有更直观的方式，例如： 1. Node 1 （727ms=227ms+500ms） 我认为是更直观的。

另外，在我勾选的结果来看，它选择了第三个节点，这似乎是非预期行为？

[luochen1990]

Node 1 （727ms=227ms+500ms）

Node 1 227ms（+500ms=727ms） 这样展示你觉得如何？

[luochen1990]

它选择了第三个节点，这似乎是非预期行为？

看起来是的， 我不确定是否是我这个变更引入的问题，请问我应该怎么本地测试比较推荐？

[mzz2017]

Node 1 （727ms=227ms+500ms）

Node 1 227ms（+500ms=727ms） 这样展示你觉得如何？

可以。

[mzz2017]

它选择了第三个节点，这似乎是非预期行为？

看起来是的， 我不确定是否是我这个变更引入的问题，请问我应该怎么本地测试比较推荐？

这是因为 re-selects 的时候是使用的 .l 而不是 .l+.o，请检查一下所有的引用。

实际上，我们没有必要改变之前的行为，没有必要引入 .o，只需要去掉 epsilon 那部分的 >0 判断即可。

[mzz2017]

本地测试：

make ebpf
go run -exec sudo . run -c /etc/dae/config.dae

[luochen1990]

这是因为 re-selects 的时候是使用的 .l 而不是 .l+.o，请检查一下所有的引用。

实际上，我们没有必要改变之前的行为，没有必要引入 .o，只需要去掉 epsilon 那部分的 >0 判断即可。

OK, 我尝试修复一下

[mzz2017]

@luochen1990 我看了一下代码，因为有 clamp（钳制到 Timeout 以内），所以想要 reverse 回去按照原来的思路似乎是不可行的。需要保存之前的 latency，使用你的这套代码是正确的。

[luochen1990]

因为 re-selects 的时候是使用的 .l 而不是 .l+.o，请检查一下所有的引用

确认一下， re-selects 是在 calcMinLatency 这里么？

[mzz2017]

因为 re-selects 的时候是使用的 .l 而不是 .l+.o，请检查一下所有的引用

确认一下， re-selects 是在 calcMinLatency 这里么？

是的。

[luochen1990]

我感觉可能需要重构一下， 因为涉及 latency 的地方有点多，我打算引入一个 SortingLatency 的计算属性，来替代之前引用 latency 的地方，可能是像这样:

func (a *AliveDialerSet) SortingLatency(d *Dialer) time.Duration {
	return a.dialerToLatency[d] + a.dialerToLatencyOffset[d]
}

你觉得 OK 么？ 因为这个动作可能有点大， 我不确定你觉得是否OK

[mzz2017]

@luochen1990 没问题

[mzz2017]

LGTM. 待 PR Build #307 运行完毕后，你也可以测试一下。

[mzz2017]

LGTM. 非常感谢！

[luochen1990]

感谢你分享这么好用的软件， 非常荣幸能贡献代码 :）

[dae-prow]

🧪 Since the PR has been fully tested, please consider merging it.