Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am developing an application which requires intricate testing involving exact time stamps of various events.

As an example, lets say we have two hosts: h1 and h2.

Now if I run a tcpdump on h1, I get an associated timestamp. Same goes for h2.

Now, suppose h1 sends an ICMP packet to h2. The packet should, as I understand be logged on h1's tcpdump at the time it leaves h1 and on h2's tcpdump when h2 receives the same.

Now I am simulating the hosts as Ubuntu machines using VirtualBox.

So I have two questions:

One, are my assumptions about tcpdump correct?

Second, can I be absolutely certain about the central time being the same for both the virtual machines. I know that this is not possible in a physical network. However, since Virtual machines share a common system, I was wondering whether the same holds true. If not, is there any other way to ensure synchronization while testing?

[CONCLUDING REMARKS]: For those who may be curious, VirtualBox comes configured with NTP and if you have a similar task, setting up NTP can be stricken off your to-do list.

share|improve this question
Use ntp? It's made for this. Virtualbox VMs will pull their time from the system clock, but while running maintain their own. – Nathan C Jun 14 '13 at 18:22
up vote 5 down vote accepted

Your assumptions about tcpdump are correct-ish. A tcpdump capture grabs the raw packets.
The timestamp values you'll have access to when processing the dump are therefore the timestamp values in the packets (which are entered by the sending system).

If you're logging the packets on the receiver your logs can include both timestamps (the sender's timestamp from the packet, and the receiver's timestamp from the local clock).
They talked about this in a little detail way back in 1981, in RFC 781.

Regarding time synchronization, the answer is always NTP.

VMs can synchronize the virtual hardware clock with the host's idea of what the time is, but the operating system may not be obsessively checking the hardware clock. Modern operating systems (unix/linux at least) keep an OS time that is semi-independent of the hardware clock and is occasionally written back to it.

NTP disciplines the system's idea of "what time it is" and accounts for natural drift in the hardware clock/timing subsystem. Synchronizing your VM clocks with NTP is the best way to ensure that they agree on time to the extent practical in the real world.

VMs shouldn't be used for anything time-critical though* -- Virtual Machines are really lousy time keepers. Even the best commercial hypervisors can gain or lose time depending on system workload and other factors. VirtualBox is workstation-class virtualization, and is even more susceptible to such issues.
I've seen VirtualBox VMs without NTP or other timekeeping helpers lose up to a minute an hour on my workstation. That's definitely beyond my bounds of acceptable accuracy.

share|improve this answer
Ah thanks a lot for your reply. It was very helpful. I have a quick follow up to make sure I understand correctly: 1) So the timestamps in tcpdump correspond to the time at which the packet is SENT. Assuming NTP isn't active, does that mean that the timestamps in tcpdump may be terribly incorrect (they are based on system time right?) eg. I would imagine a ping to a server in a different country would lead to problems (which it does not - so I must be wrong). I'm a bit confused here. 2) I'm planning to use Wireshark soon instead of tcpdump. Do you know if it logs time in a similar fashion? – spiritusozeans Jun 14 '13 at 19:27
(1) The timestamps sent in a packet are based on the sending system's idea of time (Think logically: What else could they be based on?). If you read the RFC I linked to you'll understand why time zones don't matter. (2) There should be no difference in terms of what is captured - data on the wire doesn't know or care how you're recording it. Wireshark's log/display format may include the local time though. – voretaq7 Jun 14 '13 at 21:37
Thanks again, it's quite clear now. I have just one more question: As you mentioned, I would need to log the packets on the receiver myself. Are you aware if tcpdump has a similar option? If not, what else can I use keeping in mind that I need to parse the packets as well (therefore it would be great if I could get an output which is readable by tcpdump/similar tools). Thank you so much! – spiritusozeans Jun 14 '13 at 22:33
The answer to that is in the documentation... – voretaq7 Jun 14 '13 at 22:35

I would agree with voretaq7 In everything but one point, don't use ntp! Use sntp. Ntp is a great protocol, but it is inappropriate for virtual machines. Ntp assumes that clocks are measurable and predictable, and uses this assumption to make them more accurate by measuring their inaccuracies. This produces a robust, accurate, fault tolerant time measurement. However it breaks on virtual machines for which the clock has neither property confusing the ntp server on the vm guest (remember ntp is a peer to peer protocol). This is not a a problem with most windows guest as they use sntp and call it ntp, but it is a problem with linux guests as they often do have a ntp server available if not included standard. This is also a nonissue with ntpdate. I do however recommend running a full ntp server on the host as it does have a measurable hardware clock that is predictable.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.