Répartition de la bande passante FreeBox

0

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 : <[email protected]>

Organization : A poorly-maintained Debian GNU/Linux InterNetNews site

Reply-To : [email protected]

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 : [email protected]

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

Share.

Comments are closed.