[Click] DelayUnqueu and DelayShaper blocking a lot

Javier Sánchez javier.recacha at gmail.com
Thu Apr 24 08:04:59 EDT 2008


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: print_time.cc
Type: application/octet-stream
Size: 1615 bytes
Desc: not available
Url : https://pdos.csail.mit.edu/pipermail/click/attachments/20080424/d6f41654/attachment-0004.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: print_time.hh
Type: application/octet-stream
Size: 859 bytes
Desc: not available
Url : https://pdos.csail.mit.edu/pipermail/click/attachments/20080424/d6f41654/attachment-0005.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: delayunqueue2.cc
Type: application/octet-stream
Size: 2922 bytes
Desc: not available
Url : https://pdos.csail.mit.edu/pipermail/click/attachments/20080424/d6f41654/attachment-0006.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: delayunqueue2.hh
Type: application/octet-stream
Size: 1335 bytes
Desc: not available
Url : https://pdos.csail.mit.edu/pipermail/click/attachments/20080424/d6f41654/attachment-0007.obj 


More information about the click mailing list