Un post de Rani sur proxad.free.adsl au sujet de la répartition de la bande passante FreeBox et de quelques corrections de bugs est à lire ci-dessous.
Path : news.free.fr !spooler3.proxad.net !feeder2-1.proxad.net !news1-1.free.fr !not-for-mail
Newsgroups : proxad.free.adsl.tv
From : Rani Assaf
Subject : Re : y a-t-il un vrai journaliste dans = ?iso-8859-1 ?Q ?l’=E9quipage ?=
?
References : <3fe48f0e$0$22336$626a54ce@news.free.fr>
Organization : A poorly-maintained Debian GNU/Linux InterNetNews site
Reply-To : rani@corp.free.fr
Message-ID :
Mime-Version : 1.0
Content-Type : text/plain ; charset=iso-8859-1
Content-Transfer-Encoding : 8bit
User-Agent : slrn/0.9.8.0 (Linux)
Date : 20 Dec 2003 19:18:06 GMT
Lines : 51
NNTP-Posting-Date : 20 Dec 2003 20:18:06 MET
NNTP-Posting-Host : 213.228.1.65
X-Trace : 1071947886 news1-1.free.fr 17126 213.228.1.65:52552
X-Complaints-To : abuse@proxad.net
Xref : news.free.fr proxad.free.adsl.tv:15661
On Sat, 20 Dec 2003 19:03:54 +0100, Laurent H. wrote :
> Chez Free ca ne marche pas du tout comme ça. Mais ca ne lie en rien
> la qualité de TV au débit Internet, mais bien au débit de la boucle
Si, si, on a pas réinventé la roue non plus… Il y a un 4 VC ATM entre
le dslam et la fbx classés par niveau de priorité :
1) RTP (téléphone)
2) Multicast (video)
3) Management (MGCP phone, html de la télé, etc.)
4) Internet (trafic du PC client)
Côté dslam, il y a des files d’attente (queuing) par niveau et la
priorité est gérée en absolu (i.e. tant qu’il y a des paquets dans un
niveau de priorité donné, on envoit ces paquets et c’est uniquement après
qu’on passe à la priorité suivante).
Le RTP (le canal audio d’une conversation téléphonique) passe en premier
devant la télé car c’est bcps plus sensible au jitter (l’équivalent du
lag pour les gamers) même si le débit est très faible (64kbps)…
Il n’y a pas de réservation de bande passante par canal car ça n’a aucun
intérêt (sauf si on voulait justement bridé le canal Internet pour que
les gens ne puissent pas surfer au-delà d’un certain débit quand la télé
est éteinte mais c’est pas le choix que nous avons fait).
> débit avec lequel FT aura probablement autant de problèmes…
Si vous saviez tous les bruits de chiottes qui courent dans le milieu sur
le terminal Sagem…
> Reste les bugs de la solution DSLAM de Free, qui seront surement vites
> corrigés.
Il y avait un bug lié à un remplissage des buffers de transmission côté
dslam par des paquets qui n’étaient jamais libérés et au bout d’un moment
tous les buffers étaient pleins. Ce bug a été corrigé. Pour l’instant,
j’ai pas vu se reproduire des cas de manque de buffers.
Par contre, y a eu des plaintes concernant des chutes de débit liées à la
réception de trafic à destination d’autres abonnés qu ceux pour qui c’est
destiné. On est entrain de regarder mais on a pas réussi à le reproduire
ici. Anyway, on va déployer une version qui droppe le trafic s’il n’y pas
une cohérence entre la ligne et l’ip de destination.
> Est-ce du matériel cisco ? Si oui Cisco doit plancher avec Free sur le
Nop, les dslams sont des dslams freebox.
A+
Rani