[Click] Blocking queue element?

[John Bicket]

It would get blocked - linux will buffer a small number of
packets per socket before blocking it (even if it's not tcp), and this 
will fill up if a device queue is marked as busy.  This is why 
you can't really do udp tests at userlevel when using fromhost 
configurations - you end up sending so many packets, and they 
all get dropped when they hit click's queue.

--john


Eddie Kohler [kohler at cs.ucla.edu] wrote:
>Hmm.  I'm not sure that your ping process would get blocked without 
>Click, would it?  I mean Click's queue happens below the IP layer.
>
>However, it is true that Click's "device queue" is not being reflected 
>in its "device".  What you want is for Click's FromHost element to mark 
>itself as "busy", if the Click Queue is relatively full.
>
>Are you up for some hacking?  You could hack FromHost to mark itself 
>busy when the particular downstream Queue is full -- or even just 
>change it to mark itself busy randomly, and see whether this blocks the 
>upstream ping process.  If it _would_ block that process, then we can 
>work on making FromHost "do the right thing".
>
>Eddie
>
>
>Charles Reis wrote:
>>Thanks--
>>  It looks like that would work for TCP connections (which adjust when 
>>they see dropped packets), but my current experiment involves sending 
>>a ping flood.  With either Queue or RED, most of the packets will end 
>>up dropped unless the ping process is blocked (as it normally would be 
>>without Click).
>>
>>  Any other thoughts?  I'll probably try the InfiniteSource element as 
>>an alternative to ping, but this issue seems like it could come up in 
>>many contexts.
>>
>>Thanks,
>>Charlie
>>
>>
>>Beyers Cronje wrote:
>>
>>>Hi,
>>> 
>>>Have a look at RED  http://www.pdos.lcs.mit.edu/click/doc/RED.n.html 
>>>and http://www.pdos.lcs.mit.edu/click/doc/AdaptiveRED.n.html 
>>>AdaptiveRED elements.
>>>"Random Early Detection (RED) is a congestion avoidance mechanism 
>>>designed for packet switched networks that aims to control the 
>>>average queue size by indicating to the end hosts when they should 
>>>temporarily stop sending packets." 
>>>http://www.cisco.com/warp/public/732/Tech/red/
>>> 
>>>
>>>------------------------------------------------------------------------
>>>*From:* click-bounces at amsterdam.lcs.mit.edu on behalf of Charles Reis
>>>*Sent:* Wed 2004/09/22 09:25 PM
>>>*To:* click at amsterdam.lcs.mit.edu
>>>*Subject:* [Click] Blocking queue element?
>>>
>>>Hi--
>>>   I'm using Click and the stripped madwifi driver, with a click
>>>configuration based on the gen_config_pseudo_ibss.pl script that comes
>>>with the driver.
>>>
>>>   I've noticed that any packets sent out while the Queue element is
>>>full are simply dropped.  Are there any elements that cause the sender
>>>to block instead if the queue is full?
>>>
>>>Thanks,
>>>Charlie Reis
>>>_______________________________________________
>>>click mailing list
>>>click at amsterdam.lcs.mit.edu
>>>https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>
>>>This is an email from CS Holdings. It is confidential to the ordinary 
>>>user of the email address to which it is addressed and may contain 
>>>copyright and/or legally privileged information. No one else may 
>>>read, print, store, copy, forward or act in reliance upon all or any 
>>>part of it or its attachments. If you received this email in error 
>>>please notify its sender.
>>>
>>_______________________________________________
>>click mailing list
>>click at amsterdam.lcs.mit.edu
>>https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>
>_______________________________________________
>click mailing list
>click at amsterdam.lcs.mit.edu
>https://amsterdam.lcs.mit.edu/mailman/listinfo/click