Sounds good.
Best,
George
On 1 May 2015, at 1:21, Karlis Laivins wrote:
Hello George,
Thank you for the tip! I have set up a virtual test environment with
IMUNES
(interesting tool, by the way) and now I am running validation tests,
to
see, if the results there are at least similar to those
Hello George,
Thank you for the tip! I have set up a virtual test environment with IMUNES
(interesting tool, by the way) and now I am running validation tests, to
see, if the results there are at least similar to those that can be
achieved on a physical testbed.
I will let you know if and when th
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
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
Hi,
Thank you very much for such a comprehensive description of how to properly
create a loadable Kernel module, this does the trick - I was able to create
the module successfully, load it into Kernel and set it as the congestion
control algorithm used via sysctl net.inet.tcp.cc.algorithm=new (new
Hi,
On 04/18/2015 16:59, Karlis Laivins wrote:
Hello,
I have read an interesting publication about a proposed modification of TCP
Congestion Control algorithm that would allow to improve it (the CC) by
dynamic bandwidth estimation. The idea seems so interesting that I would
like to try to imple
On Sat, Apr 18, 2015 at 09:59:01AM +0300, Karlis Laivins wrote:
> Hello,
>
> I have read an interesting publication about a proposed modification of TCP
> Congestion Control algorithm that would allow to improve it (the CC) by
> dynamic bandwidth estimation. The idea seems so interesting that I wo
Hello,
I have read an interesting publication about a proposed modification of TCP
Congestion Control algorithm that would allow to improve it (the CC) by
dynamic bandwidth estimation. The idea seems so interesting that I would
like to try to implement it by modifying the NewReno code.
Do I under
11 matches
Mail list logo
