Fold All / Expand All

2008年2月6日 星期三

Small Is Not Always Beautiful::IPTPS 2008

DISCLAIMER: This review is written by a non-native speaker of English. There might be mistakes, misunderstandings, and errors.

可看點在section 4 Discussion,其他都算common sense吧。

這篇在討論BitTorrent的piece size對performance的影響,基本上是設越小越有利,理由是BitTorrent必須完整下載一個piece後才能對其他人宣佈擁有這個piece,所以piece切越小,可分享的piece數當然比較多,整體的diversity會比較大。然而,piece size越小,代表torrent檔內的hash值也越多,使得torrent檔的大小增加,而且peer之間在溝通時,其bitfield message也要比較大,HAVE message傳送的次數也要比較多,簡言之就是communication overhead增加。

在這裡先講一下作者的實驗方法,用Mainline BitTorrent 4.0.2,設定值都照預設,upload slot是四個,1個seed與40個leecher,leecher同時進場,一完成就閃,在PlanetLab上面跑,下載不限速,上傳seed是200kB/s,leecher是20~200kB/s做uniform distribution。實驗的torrent大小從1MB到100MB,piece size從16kB到2048kB,block size (subpiece size)固定為16kB。

在檔案大小只有5MB的時候,把piece size設為16kB可以得到最好的效果(越小越好),而100MB時,則是256kB最佳(所耗時間呈V字型,即太大太小都不好)。

而作者在Discussion提出一個論點,當檔案大小較大時,piece size越小越好不成立的主因,不是因為communication overhead,實際跑的結果,overhead從1%變成9%,作者認為這不是最主要的原因。在Discussion提出兩個可能性,一個是piece size太小時,block(subpiece)數量少,則原本BitTorrent提出subpiece概念之「減低request delay」功能大幅下滑;另一個則是TCP effect,當檔案大小較大,固定對同一peer下載的話,TCP window可以穩定向上增加,如果piece size小,可能導致常常換peer下載,TCP windows沒辦法有效上升,進而影響效能。

至於subpiece is unnecessary when content size is small這點就很爛,本來BitTorrent設計就不是為小檔(文中以5MB為例)。此論點就實用性而言是零,學術上的話,可以當作是為求完整性的論點。

沒有留言: