[Click] DelayUnqueu and DelayShaper blocking a lot

[Eddie Kohler]

BASIC BUG REPORT ETIQUETTE
--------------------------
Always include the version of the software for which you are reporting a bug.

This is relevant here because the current source has a fix for this bug.  It 
is different from your fix, and thus might not behave as well.  Please try the 
current version of Click (accessible via Git or CVS) and let us know

Eddie


Javier Sánchez wrote:
> Hello,
> 
> I have observed that these elements can block other script elements a little
> ms.
> 
> For example, this  listener wifi script, indicates the times of data and ack
> packets observed during a transmision of stations (p.e. pings from sta1 to
> sta2)
> 
> FromDevice(ath2)
> -> RadiotapDecap() -> FilterPhyErr() -> FilterTX() -> WifiDupeFilter()
> -> wifi_cl :: Classifier(0/08%0c,0/d4); //data and ack
> // Data
> wifi_cl[0] -> Print_Time() -> PrintWifi ("Data listened") -> Discard();
> //acks
> wifi_cl[1] -> Print_Time() -> PrintWifi("ACK listened") -> Discard();
> 
> times observed are:
> 
> actual time: ( 1209077769 / 440613 ) - ( SECONDS / MICROSECONDS )
> Data listened:  120 |  5.5Mb ...
> 
> actual time: ( 1209077769 / 440860 ) - ( SECONDS / MICROSECONDS )
> ACK listened:   12 |  2Mb ...
> 
> The diference between data and ack is only 240 us, click has very good
> resolution !!
> 
> But, if i use DelayUnqueu or DelayShaper somewhere on the script, for
> example:
> 
> FromDevice(ath2)
> -> RadiotapDecap() -> FilterPhyErr() -> FilterTX() -> WifiDupeFilter()
> -> wifi_cl :: Classifier(0/08%0c,0/d4); //data and ack
> // Data
> wifi_cl[0] -> Print_Time() -> PrintWifi ("Data listened") -> Queue ->
> DelayUnqueue2 (0.02s)-> Queue -> Discard();
> //acks
> wifi_cl[1] -> Print_Time() -> PrintWifi("ACK listened") -> Discard();
> 
> The times observed are:
> 
> actual time: ( 1209078025 / 337237 ) - ( SECONDS / MICROSECONDS )
> Data listened:  120 |  5.5Mb ...
> 
> actual time: ( 1209078025 / 341279 ) - ( SECONDS / MICROSECONDS )
> ACK listened:   12 |  2Mb ...
> 
> The Diference is 4042 us !! (repeated on more packets) thats a lot gap
> between data and ack. And i think its DelayUnqueue fault (at concrete the
> reschedule Task)
> 
> Doing this little modification in DelayUnqueue.cc solves the problem for me.
> 
> 83  -  } else if (diff.sec() == 0 && diff.subsec() <
> Timestamp::usec_to_subsec(100000))
> 83  +  } else if (diff.sec() == 0 && diff.subsec() <
> Timestamp::usec_to_subsec(300))
> 
> Now the times observed are:
> 
> actual time: ( 1209078571 / 453606 ) - ( SECONDS / MICROSECONDS )
> Data listened:  120 |  5.5Mb ...
> 
> actual time: ( 1209078571 / 453850 ) - ( SECONDS / MICROSECONDS )
> ACK listened:   12 |  2Mb ...
> 
> The diference is another time about 240 us.
> 
> So, i think this line of DelayUnqueue and DelayShaper are introducing a lot
> of ¿unnecessary? blocking in click scripts when you need good resolution
> times.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click