https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199754
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org
--
You are
If you want to run some experiments, though, you could look at running
PTPd
on 3 servers (master, and two slaves) which will get you decent
synchronization
among the three. Where decent is less than the typical RTT of a TCP
packet on a
1Gbps LAN.
Best,
George
On 30 Apr 2015, at 14:48, Karlis
Yes, you are correct, I meant to write "relative OWD". As David Hayes put
it - "Relative OWD measurements are easier, and clock drift is not usually
a problem over the time it takes to send and receive an ACK".
Thank you for the correction!
On Thu, Apr 30, 2015 at 4:19 PM, Eggert, Lars wrote:
>
On 2015-4-30, at 15:04, Karlis Laivins wrote:
> I have yet to solve the issue of
> how to get the One Way Delay for the ACK message (the time it takes ACK to
> arrive from receiver of the ACK'ed data sender) correctly.
That won't work without synchronized clocks, which you can't really assume to
Hello,
If I will be able to implement the idea described in the publication
correctly, I will share the source code. At the moment, though, I am still
far away from the implementation, since I have yet to solve the issue of
how to get the One Way Delay for the ACK message (the time it takes ACK to
Howdy,
I have added support for a DTrace SDT to the SIFTR module in HEAD. What
this means is that you can
now get SIFTR data filtered out of the kernel directly. I also added a
simple script (share/dtrace/siftr) to
show how this works. The test script is very wordy and only an example
of ho
Are you planning to put the source to this up on a repo (github) or send
along patches?
It would be good to get a look at this new algorithm.
Thanks,
George
On 21 Apr 2015, at 5:30, Karlis Laivins wrote:
Hi,
Thank you very much for such a comprehensive description of how to
properly
create