Matthew Luckie wrote:
The motivation for this patch was to obtain something resembling the
timestamp closest to when a packet I generated and transmitted hit the
wire, to infer a more accurate RTT with an associated response packet.
That's certainly a worthy goal, but the patch might not help muc
This is probably a pointless optimization, as you probably relatively
rarely have multiple BPF devices bound to the same interface receiving
the bulk of the packets (as opposed to some daemon with a filter that
passes only the packets it's interested in), but would there be any
advantage to hav
In some email I received from Guy Harris, sie wrote:
> On Sep 8, 2004, at 2:26 AM, Bruce M Simpson wrote:
>
> > Here's a patch against 5.3 to add a per-instance switch which allows
> > the user to specify if captured packets should be timestamped (and,
> > if so, whether microtime() or the faster
(Noise to defeat the duplicate-message detector for
[EMAIL PROTECTED])
Guy Harris wrote:
This is probably a pointless optimization,
"This" referring not to Bruce's proposed change, but to my proposed
change to have one time stamp call per packet.
-
This is the tcpdump-workers list.
Visit https:/
On Sep 8, 2004, at 2:26 AM, Bruce M Simpson wrote:
Here's a patch against 5.3 to add a per-instance switch which allows
the user to specify if captured packets should be timestamped (and,
if so, whether microtime() or the faster but less accurate
getmicrotime() call should be used).
This is probabl
Here's a patch against 5.3 to add a per-instance switch which allows
the user to specify if captured packets should be timestamped (and,
if so, whether microtime() or the faster but less accurate
getmicrotime() call should be used).
Comments/flames/etc to the usual...
BMS
Index: bpf.c
===
