Le 12/12/10 19:50, Rémy Sanchez a écrit : > On 12/12/2010 07:36 PM, Jérôme Nicolle wrote: >> Waip, alors je faisait ça ya 4 ans, et c'est loin d'être optimal en >> ML-PPP. Il a du mal a prendre en compte la disparité des débits des >> liens, tout comme tu l'aurais avec du bonding sur des /dev/tap. > > Étrange, quand tu regardes la RFC ça explique justement que ça a été > écrit pour ce genre de cas...
Waip, mais dans pppd sous Linux, on a jamais réussi à le faire marcher correctement > Tu faisais ça avec que logiciel ? Pour l'instant je suis parti sur MPD > [1], et concrètement c'est le seul que j'ai trouvé à avoir l'air de > gérer ça... Ah oui, intéressant... Niveau jigue et compression, il s'en sort comment ? >> Par contre, pour le coup, tu peux compresser ce qui passe sur le tunnel, >> dans ton cas c'est pas anodin (si c'est bien pour MAIZ) > > Ouais, plus après mettre un proxy distant et tenter de booster la > connexion avec lui (genre jouer avec les paramètres TCP, garder les > connexions ouvertes entre le proxy local et le proxy distant, ...). Tu as peu de chance de voir le MTU varier, donc tu peux le fixer aux extrémités du tunnel pour être sur de ne pas fragmenter, ça peut aider. Mais pour rappel, et pour la liste, on est là dans un cas particulier : 150 utilisateurs intensifs derrière deux ADSL 1Mbps et une SDSL du même acabit. Donc aucun produit du marché ne saurait tenir ce taux de contention ;) > > [1] http://mpd.sourceforge.net/ > Merci, tiens moi au jus ;) -- Jérôme Nicolle 06 19 31 27 14
signature.asc
Description: OpenPGP digital signature
