On Jun 9, 2016, at 4:47 PM, Guenter Ebermann
wrote:
> They are only delivered to the socket on which the packet was sent, not to
> all PF_PACKET sockets.
Then Christian can't get what I think he wants with libpcap - or anything else
doing PF_PACKET socket capturing on Linux - without doing so
> Am 10.06.2016 um 01:35 schrieb Guy Harris :
>
> On Jun 9, 2016, at 4:09 PM, Guenter Ebermann
> wrote:
>
>>
>>> Am 10.06.2016 um 00:13 schrieb Guy Harris :
>>>
>>> But that doesn't mean that the packets time stamped by the hardware when
>>> transmitted will be delivered to the PF_PACKET so
On Jun 9, 2016, at 4:09 PM, Guenter Ebermann
wrote:
>
>> Am 10.06.2016 um 00:13 schrieb Guy Harris :
>>
>> But that doesn't mean that the packets time stamped by the hardware when
>> transmitted will be delivered to the PF_PACKET sockets used by libpcap *with
>> the hardware time stamp as th
> Am 10.06.2016 um 00:13 schrieb Guy Harris :
>
> But that doesn't mean that the packets time stamped by the hardware when
> transmitted will be delivered to the PF_PACKET sockets used by libpcap *with
> the hardware time stamp as the time stamp*.
>
> In order make that happen, if hardware tra
On Jun 9, 2016, at 1:19 PM, Guenter Ebermann
wrote:
>> Am 09.06.2016 um 15:47 schrieb Michael Richardson :
>>
>> Guenter Ebermann wrote:
>>> Hardware timestamping of sending/receiving buffer descriptors is done
>>> by NIC.
>>
>> Receiving I understand.
>>
>> Are you sure that the hardware is
> Am 09.06.2016 um 15:47 schrieb Michael Richardson :
>
> Guenter Ebermann wrote:
>> Hardware timestamping of sending/receiving buffer descriptors is done
>> by NIC.
>
> Receiving I understand.
>
> Are you sure that the hardware is going to timestamp sent packets, and then
> turn around and se
The experiments I made today actually suggest that in my case tcpdump
uses the hardware clock for incoming packages and the software/unix
clock for outgoing packages.
I changed the System clock of one Server with date -s and then looked at
the capture of Ping packages.
Incoming packages on the
Guenter Ebermann wrote:
> Hardware timestamping of sending/receiving buffer descriptors is done
> by NIC.
Receiving I understand.
Are you sure that the hardware is going to timestamp sent packets, and then
turn around and send the back to the kernel?
--
] Never tell me th
Yes, the exact same packet.
Am 08.06.2016 um 22:40 schrieb Guy Harris:
On Jun 8, 2016, at 1:29 PM, Christian Rupp
wrote:
The Timestamp when tcpdump grabs the package off of the receiver is 36 seconds(
+/- innaccuracy, here roughly +/- 5-10 µs) after the timestamp when tcpdump
grabs the pa
> Am 08.06.2016 um 23:10 schrieb Michael Richardson :
>
> Christian Rupp wrote:
>> The Timestamp when tcpdump grabs the package off of the receiver is 36
>> seconds( +/- innaccuracy, here roughly +/- 5-10 µs) after the timestamp when
>> tcpdump grabs the package of the sender. resulting in an a
Christian Rupp wrote:
> The Timestamp when tcpdump grabs the package off of the receiver is 36
> seconds( +/- innaccuracy, here roughly +/- 5-10 µs) after the timestamp
when
> tcpdump grabs the package of the sender. resulting in an alleged One
> Way
> Delay of 36 seconds wh
On Jun 8, 2016, at 1:29 PM, Christian Rupp
wrote:
> The Timestamp when tcpdump grabs the package off of the receiver is 36
> seconds( +/- innaccuracy, here roughly +/- 5-10 µs) after the timestamp when
> tcpdump grabs the package of the sender.
"The" packet in the sense that you have two tcp
The Timestamp when tcpdump grabs the package off of the receiver is 36
seconds( +/- innaccuracy, here roughly +/- 5-10 µs) after the timestamp
when tcpdump grabs the package of the sender. resulting in an alleged
One Way Delay of 36 seconds which wouldn't make any sense in that
scenario, giv
On Jun 8, 2016, at 5:53 AM, Christian
wrote:
> Now, my results in itself make sense and would give me the desired results,
> but they have a big offset to them. 36 seconds to be exact.
So you're saying there's a 36-second offset between which two times?
Yes, one tcpdump entity per server, after Both are started I start a
Package Generator which sends a 900kbs Trace.
There shouldn't be a big buffering effect, if I'm not using the hardware
timestamp options the one way delay is at a few 100 µs, or am I
misunderstanding something?
The 36 seconds
{please keep it on the list for archival purposes}
Christian wrote:
> between sender and receiver
> so from the point when tcpdump grabs the time off of the Sender and to the
> point where tcpdump grabs the time off of the receiver.
So you are running a tcpdump on sender, using the t
Christian wrote:
> My Setup:
> 2 directly connected identical Servers.
> Linux: Debian 3.16.7
> Network Interface: Intel i350-T4
> Used tcpdump command:
> sudo /usr/sbin/tcpdump -i eth4 -s 59 port 3 -x -n -tt -v -j
> adapter_unsynced --time-stamp-precision=nano -w
Hello,
(Sorry if this shows up twice, I wasn't registered for the List, when I
first sent my request.
And sorry if this is the wrong place for this kind of question.)
I'm currently working on my Bachelors Thesis.
The aim of my project is to accuratly and precisely timestamp
Packages(it has to
18 matches
Mail list logo
