On Wednesday 16 November 2011 05:50:12 Michel Py wrote:
> > Rémy Sanchez a écrit:
> > J'objecte, ce qui disent les graphes (en moyenne) :
> > - 10% du serveur
> > - 33% en P2P
> > - 57% en cache
> > Donc ok seulement 1/3 du trafic est P2P, mais en fait ça fait
> > un bon gros 3/4 des échanges réseau quand même.
>
> Ca c'est de l'interpolation approximative sans avoir les vraies données. Tu
> arrives à des conclusions hâtives qui sont plus du domaine de la boule de
> cristal que des statistiques. Je ne dis pas que c'est faux, mais ça reste
> des devinettes.
>
> Regarde les chiffres: 57% viennent du cache. En anglais, on dit qu'il y a
> un éléphant dans la pièce et que tu ne le vois pas.
>
> Le cache de Spotify est prédictif (en anglais: read-ahead, ceux qui
> configurent des cartes RAID seront familiers) (pour de bonnes raisons);
> par exemple, 30 secondes avant qu'un morceau commence à jouer, le logiciel
> prédit que c'est le prochain morceau qui va jouer, et commence à charger
> les donnés. Il est donc facile de comprendre qu'une partie conséquente des
> requêtes servies par le cache n'ont été transférées dans le cache que
> quelques secondes avant que l'utilisateur ne les demande, ce qui est le
> but du cache prédictif. On lit en avance, comme ça quand le réseau à un
> hoquet, l'utilisateur ne s'en rend pas compte.
>
> En simplifiant à mort, la raison pour laquelle on n'a pas 95% ou 98% de
> cache, c'est les mecs qui zappent comme des malades.
Pour citer le papier, « Most playbacks (61%) occur in a predictable sequence,
i.e. because the previous track played to its end, or because the user pressed
the forward button. »
Et « For t = 10, 30, the next scheduled track was played in 94%, and 92% of
cases, respectively »
Donc dans plus de 90% des cas la musique lue provient du prefetch. Et au
passage personne n'écoute sa musique en zapant comme un gogol, je veux bien
prendre les gens pour des cons, mais y'a des limites...
> Là où tes conclusions sont du domaine de la boule de cristal, c'est que tu
> n'as aucune donnée qui te dit quel est le pourcentage du cache qui est
> rempli avec le P2P et celui qui est rempli avec le serveur (pardon, le
> "claoude"). Encore une fois, fais-moi voir des données réelles, pas du
> vent. P'têt ben que c'est la même chose, p'têt ben qu'non.
À priori on n'a pas compris le papier pareil. Pour vérifier j'ai envoyé un
mail à l'auteur, comme ça on est sûr:
« With prefetching there are essentially two cases, either the prefetched
track begins playing or it does not.
When it plays, prefetched data is accounted for as the source it arrives
from, so it is already included in the network traffic reported.
When it does not, I am not 100% sure off hand if that is included or not in
our measurement. This case is fairly rare however (as we show that our
threshold for prefetching are such that in 92% of cases, the user does begin
playback of the next track) so I would not expect it to make a difference to
ballpark statistics on the order of 1/4. If you're interested in the answer
also for this case as well, just ask and I'll dig a bit. »
Donc à priori, les 3/4 de trafic générés par P2P ne sont pas délirants.
> >> J'aimerais bien voir les stats de Spotify en ce qui concerne la
> >> répartition intra-AS / extra-AS car jusqu'à présent j'ai rien vu de
> >> bien concret. Là ou Spotify est bon c'est sur la qualité et ne pas
> >> tuer l'upstream, mais en ce qui concerne l'optimisation du trafic...
> >
> > Spotify ne fait pas le tri directement en fonction de l'ASN, ils
> > donnent une note d'utilité à chaque peer et s'en servent quand ils
> > doivent supprimer des peers.
>
> C'est là ou je ne suis pas convaincu. Pour le FAI, ce qui compte c'est la
> partie qui reste à l'intérieur de son AS, rien d'autre.
Oui ça je sais, je supposais juste que le mécanisme pouvait éventuellement
aider, au moins un chouilla.
Mais effectivement je viens de vérifier, j'ai 2 peers du même FAI à tout
casser sur la cinquentaine de peers connectés. Par contre ils sont
majoritairement en France.
> > Par contre regarde le RFC 5632, Comcast a bel et bien
> > réussi ce genre de montage.
>
> RFC5632, c'est comme IPv6. Quand plus de zéro pourcent du trafic sera
> optimisé par RFC5632, réveilles-moi. Entre un pair en Australie, un à
> Trifouilly-les-Oies (pas tellement moins loin, pour moi) et un à 50 km
> dans l'AS de mon FAI, je vais t'expliquer comment ça marche: la solution
> P2P qui ne me donne que les 50Kpbs du mec a coté de chez moi, je vais la
> dégager vite fait aux dépens de la solution qui suce en plus le Mbps de
> Toto de Trifouilly-les-Oies et les 500Kbps de Bob de Sydney.
On discute de la viabilité du concept ou alors de sa mise en production ?
Comcast l'a testé et ça marche, pas besoin de chercher midi à 14h.
C'est pas pour autant que tout le monde devrait l'avoir déployé depuis, ça
demande encore du travail qui est actuellement effectué par le groupe ALTO ou
le groupe PPSP
