设置和观察
我有一台配备 Intel i350 T2 NIC 的 PC，我想使用 tcpdump 在两个接口(interface)上同时捕获。两个接口(interface)都连接到一个 100mbit HUB(原文如此!)，它“同时”将来自外部流量源的各种流量转发到两个接口(interface)，因此我可以测量各个以太网 MAC 完成的时间戳的差异。
同时捕获:
user@rt:~$ sudo tcpdump -j adapter --time-stamp-precision nano -B 1048576 -i eth2 -w test_eth2.pcap
user@rt:~$ sudo tcpdump -j adapter --time-stamp-precision nano -B 1048576 -i eth3 -w test_eth3.pcap
之后，我将两个文件合并在一起以比较时间戳:
user@rt:~$ mergecap -F nseclibpcap -w merged.pcap test_eth2.pcap test_eth3.pcap
然后 Wireshark 向我显示，对于几个数据包，我得到了大约 20-40 纳秒的重复帧的时间戳差异(这对我的应用程序来说已经足够了!)。 但也有很多帧在比较各自的副本时显示出高达几十微秒的差异。
环境
user@rt:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 15.04
Release: 15.04
Codename: vivid
user@rt:~$ uname -r
3.19.0-28-generic
user@rt:~$ lscpu | grep "Model name"
Model name: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz
问题
- 适配器时钟如何/由谁同步到 CLOCK_REALTIME(我推测)
- 这种同步多久发生一次。
- 是否有一些可以在不付出太多努力的情况下进行调整的空间？
- 是否可以使用例如
phc2sys将所有适配器时钟同步到 CLOCK_REALTIME？ - (4) 会干扰 (1) 完成的机制吗？
感谢帮助或指出我的错误!
最佳答案
快速浏览一下 igb_ethtool.c，您的 NIC 似乎确实能够进行硬件时间戳。您观察到的抖动 (20-40ns) 正好在从同步到以太网时钟的预期 PHY 抖动范围内。 (对于 100Mbit，时钟为 25MHz 或 40ns。)
到目前为止看起来很棒，感谢英特尔。没有多少 NIC/驱动程序具有此功能。
现在是不好的部分:我怀疑目前是否有任何东西正在将 CLOCK_REALTIME 同步到 NIC 适配器时钟。时钟可能以稍微不同的频率自由运行。这些振荡器通常指定为 50ppm，典型漂移约为 5ppm，这意味着它们每秒漂移约 5us，随室温而变化。使用纳秒精度时请记住这一点。如果您的系统使用 NTP，您甚至可能会看到发生 NTP 漂移调整。
但好消息是您可能不需要同步它们，除非您真的想要绝对时间戳。您的 NIC 完全支持硬件时间戳的主要原因可能是为了支持 IEEE1588 PTP(精确时间协议(protocol))。如果您需要亚微秒精度的绝对时间，您应该查看此协议(protocol)和/或购买 GPS 接收器。
如果您只需要相对时间戳，您可以尝试使用 -j adapter_unsynced 而不是 -j adapter，或者您可以尝试阻止 NTP 尝试漂移校正你的系统时钟。如果这一切都失败了，你可以尝试启动 linuxptp ，即使您没有 PTP 网络，它也可以正确同步 NIC 和系统时间。
最后...您正在使用 HUB，这意味着以太网以半双工模式运行，这意味着...冲突。除非你的 NIC 绝对安静。我想理论上这应该无关紧要，因为您在两个 NIC 中观察到相同的冲突，并且帧不会延迟或排队，具体取决于它们采用的路径。但是，由于如今半双工非常罕见，因此 NIC 时间戳支持可能并未考虑到这一点。这种实现中的典型错误是例如返回前一帧的时间戳而不是当前帧。
关于wireshark - 使用 tcpdump 捕获时以太网适配器时钟同步，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32970988/