On Thu, Feb 24, 2011 at 05:37:03PM +0000, Luca Bigliardi wrote: > On Thu, Feb 24, 2011 at 12:26 AM, Simone Abbakus wrote: > > > Hi, > > Hi Simone, >
Hi all. > > > 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. This is a good point. Separate queues are necessary. If applied on input "interfaces", they guarantee fairness among flows with different rates. For what concerns switch overloads, several techniques are normally adopted in real-life. I've also found some interesting documents: http://goo.gl/OggoF http://goo.gl/c3Qra I think it is worth an evaluation of a packet shaper on each output port, applying some well-known mechanism (for example a simple periodic shaper or even a token bucket). The ideal situation would be to try and determine the maximum rate achievable on the system vde_switch is running on, and then tune the output shapers on each port accordingly. I wonder if running output shapers in separate threads could also impact on performance and fairness (maybe getting some benefits from underlying kernel io scheduler). ciao -- Daniele ------------------------------------------------------------------------------ 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
