On Tue, Apr 1, 2014 at 8:38 PM, YAMAMOTO Takashi wrote:
>>> +ovs-appctl time/warp 4000
>>> AT_CHECK([ovs-ofctl mod-flows br0 in_port=1,actions=drop])
>>> -sleep 2
>>> +# At this point the table would looks like:
>>> +# in_port seconds to expire
>>> +# 113
>>> +# 2
>> +ovs-appctl time/warp 4000
>> AT_CHECK([ovs-ofctl mod-flows br0 in_port=1,actions=drop])
>> -sleep 2
>> +# At this point the table would looks like:
>> +# in_port seconds to expire
>> +# 113
>> +# 211
> This seems to be 12s to expire. And I realize that I made
On Tue, Apr 1, 2014 at 6:20 PM, YAMAMOTO Takashi wrote:
>>> # Sleep and modify the one that expires soonest
>>> -sleep 2
>>> +ovs-appctl time/warp 3000
>>> AT_CHECK([ovs-ofctl mod-flows br0 in_port=1,actions=drop])
>>
>> at this point, flow table would be:
>> hard_timeout=12, in_port=1 actions=d
>> # Sleep and modify the one that expires soonest
>> -sleep 2
>> +ovs-appctl time/warp 3000
>> AT_CHECK([ovs-ofctl mod-flows br0 in_port=1,actions=drop])
>
> at this point, flow table would be:
> hard_timeout=12, in_port=1 actions=drop
> hard_timeout=11, in_port=2 actions=drop
> hard_timeout=13
On Tue, Apr 1, 2014 at 1:12 PM, YAMAMOTO Takashi wrote:
>>> # Sleep and modify the one that expires soonest
>>> -sleep 2
>>> +ovs-appctl time/warp 2
>>
>> I think we should warp as small as possible to verify precision.
>> What do you think about warp 12000?
>
> i agree smaller is better.
> h
>> # Sleep and modify the one that expires soonest
>> -sleep 2
>> +ovs-appctl time/warp 2
>
> I think we should warp as small as possible to verify precision.
> What do you think about warp 12000?
i agree smaller is better.
how about the following?
YAMAMOTO Takashi
commit b4a624761fe90aa0
On Mon, Mar 31, 2014 at 03:24:30PM +0900, YAMAMOTO Takashi wrote:
> Bump timeout differences, because timeouts different by 1s might end up
> to have the same position in the heap as rule_eviction_priority() uses
> 1024ms as a unit.
>
> Also, use time/stop to avoid relying on how long an add-flow
On Mon, Mar 31, 2014 at 2:24 PM, YAMAMOTO Takashi
wrote:
> Bump timeout differences, because timeouts different by 1s might end up
> to have the same position in the heap as rule_eviction_priority() uses
> 1024ms as a unit.
>
> Also, use time/stop to avoid relying on how long an add-flow would tak
Bump timeout differences, because timeouts different by 1s might end up
to have the same position in the heap as rule_eviction_priority() uses
1024ms as a unit.
Also, use time/stop to avoid relying on how long an add-flow would take.
These tests were introduced by commit 6d56c1f1.
("ofproto: Upda