On Thu, Feb 24, 2011 at 17:37:03 +0000, Luca Bigliardi wrote: > > I don't know how a real switch works, but I think this > > component should aim to be as fast as possible and possibly take under > > control every real aspect to reproduce. > > I'm not an expert in how switches/routers queuing works either, if we're > planning to improve this we should put some effort in documenting > ourselves. Did you consider alternative queuing systems other than > changing the timeout parameters? For instance while designing the vde 3 > proposal we opted for a separate queuing settings for each port. The > rationale behind this is that different ports/connections have different > traffic capacity, hence it might be unfair to use the same timeout > parameters for slow and fast links.
AFAIK, at least for the "average Cisco switch" on which I have had some experience, the default behaviour is per-interface tail-drop. That is, each egress interface has a buffer. When it's full, new packets are dropped and there's no timeout -- enqueuing will happen again when some old packets are delivered. Alternatives are variants of RED/WRED algorithms, which start dropping random packets before the queue gets full, trying to address some issues of tail-dropping especially for TCP traffic (global synchronization is one of them). If you go up with the price (or to layer 3 switching) you get more refined QoS settings which are usually performed by the software (while the tail-drop queue is handled by the hardware), but I think they're out of scope here. Usually, it's possible to have different policies for different ports, but again (AFAIK) there's no "timeout". Once a packet gets assigned to an output interface and it's enqueued, it has to be sent, either if it's a simple hardware-based tail-drop or a complex software-handled QoS algorithm. I'm sure that this design choice (drop and never timeout) has been initially taken for hardware simplicity reasons. I don't know if it's still like this today because it's still the simplest thing to build or because there's actually not much point in having timeouts in the output buffer. Ludovico -- <l...@dovi.co> IRC: garden@freenode OpenPGP: 1024D/63D2D5D907F89BB8 Jabber/gtalk: garde...@gmail.com ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ vde-users mailing list vde-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vde-users