网络硬时间戳在何时何地打的？

分为几个部分阐述

1、linux时间系统

2、网卡工作原理

3、socket编程里的硬件时间戳选项

4、网络硬时间戳是什么时候打？在哪儿打的？

一、linux时间系统

陈莉君《深入分析linux内核源码》一篇很不错的文章：linux时间系统

linux有两个时钟源，分别是RTC和OS时钟。

RTC独立于操作系统，由电池供电，即使系统断电它也能维护自己的时钟。LINUX系统启动时从其中获得时间初始值。

OS时钟从可编程计数器（如intel的8524）获得时钟。如图1所示的输出脉冲是OS时钟工作的基础，因为是由它产生时钟中断的。

图1 8524工作示意图

图1 时钟机制

二、网卡工作原理 
发送数据时，网卡首先侦听介质上是否有载波（载波由电压指示），如果有，则认为其他站点正在传送信息，继续侦听介质。一旦通信介质在一定时间段内（称为帧间缝隙IFG=9.6微秒）是安静的，即没有被其他站点占用，则开始进行帧数据发送，同时继续侦听通信介质，以检测冲突。在发送数据期间。 
如果检测到冲突，则立即停止该次发送，并向介质发送一个“阻塞”信号，告知其他站点已经发生冲突，从而丢弃那些可能一直在接收的受到损坏的帧数据，并等待一段随机时间（CSMA/CD确定等待时间的算法是二进制指数退避算法）。在等待一段随机时间后，再进行新的发送。如果重传多次后（大于16次）仍发生冲突，就放弃发送。 
接收时，网卡浏览介质上传输的每个帧，如果其长度小于64字节，则认为是冲突碎片。如果接收到的帧不是冲突碎片且目的地址是本地地址，则对帧进行完整性校验，如果帧长度大于1518字节（称为超长帧，可能由错误的LAN驱动程序或干扰造成）或未能通过CRC校验，则认为该帧发生了畸变。通过校验的帧被认为是有效的，网卡将它接收下来进行本地处理。

linux网卡驱动程序框架

三、socket编程里的硬件时间戳选项

参考文章：硬件时间戳socket选项解析 

The existing interfaces for getting network packages time stamped are:
* SO_TIMESTAMP
  Generate time stamp for each incoming packet using the (not necessarily
  monotonous!) system time. Result is returned via recv_msg() in a
  control message as timeval_r(usec resolution).
* SO_TIMESTAMPNS
  Same time stamping mechanism as SO_TIMESTAMP, but returns result as
  timespec (nsec resolution).
* IP_MULTICAST_LOOP + SO_TIMESTAMP[NS]
  Only for multicasts: approximate send time stamp by receiving the looped
  packet and using its receive time stamp.
The following interface complements the existing ones: receive time
stamps can be generated and returned for arbitrary packets and much
closer to the point where the packet is really sent. Time stamps can
be generated in software (as before) or in hardware (if the hardware
has such a feature).
SO_TIMESTAMPING:
Instructs the socket layer which kind of information is wanted. The
parameter is an integer with some of the following bits set. Setting
other bits is an error and doesn't change the current state.
SOF_TIMESTAMPING_TX_HARDWARE:  try to obtain send time stamp in hardware
SOF_TIMESTAMPING_TX_SOFTWARE:  if SOF_TIMESTAMPING_TX_HARDWARE is off or
                               fails, then do it in software
SOF_TIMESTAMPING_RX_HARDWARE:  return the original, unmodified time stamp
                               as generated by the hardware
SOF_TIMESTAMPING_RX_SOFTWARE:  if SOF_TIMESTAMPING_RX_HARDWARE is off or
                               fails, then do it in software
SOF_TIMESTAMPING_RAW_HARDWARE: return original raw hardware time stamp
SOF_TIMESTAMPING_SYS_HARDWARE: return hardware time stamp transformed to
                               the system time base
SOF_TIMESTAMPING_SOFTWARE:     return system time stamp generated in
                               software
SOF_TIMESTAMPING_TX/RX determine how time stamps are generated.
SOF_TIMESTAMPING_RAW/SYS determine how they are reported in the
following control message:
struct scm_timestamping {
 struct timespec systime;
 struct timespec hwtimetrans;
 struct timespec hwtimeraw;
};
recvmsg() can be used to get this control message for regular incoming
packets. For send time stamps the outgoing packet is looped back to
the socket's error queue with the send time stamp(s) attached. It can
be received with recvmsg(flags=MSG_ERRQUEUE). The call returns the
original outgoing packet data including all headers preprended down to
and including the link layer, the scm_timestamping control message and
a sock_extended_err control message with ee_errno==ENOMSG and
ee_origin==SO_EE_ORIGIN_TIMESTAMPING. A socket with such a pending
bounced packet is ready for reading as far as select() is concerned.
If the outgoing packet has to be fragmented, then only the first
fragment is time stamped and returned to the sending socket.
All three values correspond to the same event in time, but were
generated in different ways. Each of these values may be empty (= all
zero), in which case no such value was available. If the application
is not interested in some of these values, they can be left blank to
avoid the potential overhead of calculating them.
systime is the value of the system time at that moment. This
corresponds to the value also returned via SO_TIMESTAMP[NS]. If the
time stamp was generated by hardware, then this field is
empty. Otherwise it is filled in if SOF_TIMESTAMPING_SOFTWARE is
set.
hwtimeraw is the original hardware time stamp. Filled in if
SOF_TIMESTAMPING_RAW_HARDWARE is set. No assumptions about its
relation to system time should be made.
hwtimetrans is the hardware time stamp transformed so that it
corresponds as good as possible to system time. This correlation is
not perfect; as a consequence, sorting packets received via different
NICs by their hwtimetrans may differ from the order in which they were
received. hwtimetrans may be non-monotonic even for the same NIC.
Filled in if SOF_TIMESTAMPING_SYS_HARDWARE is set. Requires support
by the network device and will be empty without that support.

SIOCSHWTSTAMP:
Hardware time stamping must also be initialized for each device driver
that is expected to do hardware time stamping. The parameter is defined in
/include/linux/net_tstamp.h as:
struct hwtstamp_config {
 int flags; 
 int tx_type; 
 int rx_filter; 
};
Desired behavior is passed into the kernel and to a specific device by
calling ioctl(SIOCSHWTSTAMP) with a pointer to a struct ifreq whose
ifr_data points to a struct hwtstamp_config. The tx_type and
rx_filter are hints to the driver what it is expected to do. If
the requested fine-grained filtering for incoming packets is not
supported, the driver may time stamp more than just the requested types
of packets.
A driver which supports hardware time stamping shall update the struct
with the actual, possibly more permissive configuration. If the
requested packets cannot be time stamped, then nothing should be
changed and ERANGE shall be returned (in contrast to EINVAL, which
indicates that SIOCSHWTSTAMP is not supported at all).
Only a processes with admin rights may change the configuration. User
space is responsible to ensure that multiple processes don't interfere
with each other and that the settings are reset.

enum {
 
 HWTSTAMP_TX_OFF,
 
 HWTSTAMP_TX_ON,
};

enum {
 
 HWTSTAMP_FILTER_NONE,
 
 HWTSTAMP_FILTER_ALL,
 
 HWTSTAMP_FILTER_SOME,
 
 HWTSTAMP_FILTER_PTP_V1_L4_EVENT,
 
};

DEVICE IMPLEMENTATION
A driver which supports hardware time stamping must support the
SIOCSHWTSTAMP ioctl and update the supplied struct hwtstamp_config with
the actual values as described in the section on SIOCSHWTSTAMP.
Time stamps for received packets must be stored in the skb. To get a pointer
to the shared time stamp structure of the skb call skb_hwtstamps(). Then
set the time stamps in the structure:
struct skb_shared_hwtstamps {
 
 ktime_t hwtstamp;
 ktime_t syststamp;
};
Time stamps for outgoing packets are to be generated as follows:
- In hard_start_xmit(), check if skb_tx(skb)->hardware is set no-zero.
  If yes, then the driver is expected to do hardware time stamping.
- If this is possible for the skb and requested, then declare
  that the driver is doing the time stamping by setting the field
  skb_tx(skb)->in_progress non-zero. You might want to keep a pointer
  to the associated skb for the next step and not free the skb. A driver
  not supporting hardware time stamping doesn't do that. A driver must
  never touch sk_buff::tstamp! It is used to store software generated
  time stamps by the network subsystem.
- As soon as the driver has sent the packet and/or obtained a
  hardware time stamp for it, it passes the time stamp back by
  calling skb_hwtstamp_tx() with the original skb, the raw
  hardware time stamp. skb_hwtstamp_tx() clones the original skb and
  adds the timestamps, therefore the original skb has to be freed now.
  If obtaining the hardware time stamp somehow fails, then the driver
  should not fall back to software time stamping. The rationale is that
  this would occur at a later time in the processing pipeline than other
  software time stamping and therefore could lead to unexpected deltas
  between time stamps.
- If the driver did not call set skb_tx(skb)->in_progress, then
  dev_hard_start_xmit() checks whether software time stamping
  is wanted as fallback and potentially generates the time stamp.

四、 linux如何获取高精度时间

在linux下通常可用的精度最高的时间接口是gettimeofday，它返回一个timeval结构，其精度为us，即10-6 秒，大多数情况这个精度已经够用了。不过有时为了更高的精度，比如纳秒级的时间精度，我们需求探索Linux为我们提供的时间调用。
首先介绍struct timespec结构，这个结构体有两个成员，一个是秒，一个是纳秒。
在librt库中，提供了高精度的时间函数，分别是：
long clock_gettime(clockid_t ,struct timespec*)
获取特定时钟的时间，时间通过fp结构传回，目前定义了6种时钟，分别是
CLOCK_REALTIME               系统当前时间，从1970年1.1日算起 
CLOCK_MONOTONIC              系统的启动时间，不能被设置 
CLOCK_PROCESS_CPUTIME_ID     进程运行时间 
CLOCK_THREAD_CPUTIME_ID      线程运行时间 
CLOCK_REALTIME_HR            CLOCK_REALTIME的高精度版本 
CLOCK_MONOTONIC_HR           CLOCK_MONOTONIC的高精度版本
获取特定时钟的时间精度：
long clock_getres(clockid_t )           
设置特定时钟的时间：
long clock_settime(clockid_t ,struct timespec*)                   
休眠time中指定的时间，如果遇到信号中断而提前返回，则由left_time返回剩余的时间：
long clock_nanosleep(clockid_t ,int flag,timespec* time,timespec* left_time)    

五、硬时间戳模块的物理实现

基于硬件时间戳的IEEE1588时间同步技术的一种实现方法

本地时间戳模块的计数器的工作频率越高，本地
时间戳的分辨率就越高。但在实际的工程中，这个频率受
FPGA器件本身的性能和本地晶振的限制，不可能无限制的
提高，否则不仅不能提高同步性能，甚至还会因为系统达
不到这个频率而无法正常工作。进而影响开发进度和开发
成本。本文采用FPGA设计硬件时间戳模块，在MAC和PHY
之间的GMlI接口处打时间戳，也就是图6所示的C点，图7
为硬件时间戳模块框图。

50Mhz晶振接入FPGA，经过FPGA内部的DCM倍频至

1OOMhz作为本地时间计数器的It,-t~~信号clk。在每个clk的
上升沿累加，每次累加值为1 Ons，也就是本地时间戳的分
辨率是1 Ons。开始上电时，时间戳模块需要初始时间，由
CPU发出更新时间的命令并将要更新的时间写入更新时间
寄存器，时间戳模块就能更新本地时间，然后在此基础上
开始累加。当CPU发出调整本地时间命令时，时间戳模块
通过读取时间偏差调整寄存器来更新本地时间以同步于主
时钟。该时间戳模块按照IEEE1 588的标准时间格式输出本
地时间供需要时间戳的模块使用。

拓展文献

1.基于IEEE1588协议的时间戳的生成与分析

2.浅谈时间函数gettimeofday的成本

3. linux 2.6的网络时间戳