wawan bahtiar wrote:
ini juga tergantung kebijakan network yg anda manage. kalau anda menerapkan bandwidth yg pasti, artinya beli satu depet satu ya pake kosep HTB//CBQ, kalau anda ingin meberikan bonus lebih ke client dalam artian "beli satu dapet sepuluh" ya anda bisa pake system delaypool squid . dalam hal ini jika object cache sudah ada di squid , si client dapet kecepatan full tanpa pembatasan, dan jika ada request object baru (fresh) delaypool baru bekerja. dan perlu pertimbangan dan perhitungan yg matang, jika anda menerapkan delaypool dengan HTB/CBQ, karena di sisi ISP akan rancu dalam menerapkan bandwidth limiting yg fair. itu bisa jadi kalo client bisa ngakalin dapet bandwidth yg lebih besar dari alokasi bandwidth yg telah disediakan oleh anda. seperti pada saat koneksi bersamaan di satu client melakukan download lewat http dan ftp, berapa client dapat bandwidth ? jika sebelumnya di
Kalau di alokasikan 64 kbps ... ya 64 kpbs
delaypool di descripsikan dapet 64kbps dan di htb di set 64kbps , berarti di client dapet 128kbps untuk koneksi yg bersamaan dengan koneksi protokol yg berbeda.
Uh? ... kok bisa?, kalo dialokasikan _total_bandwidth_ utk client 64 kbps, kemudian di limit (delaypool?) per service (http, ftp, whatever seperti kasus diatas) dengan HTB/CBQ, bahkan kalaupun per service (http, ftp) dialokasikan 64 kbps, sampe copot mousenya pun client gak
bakalan dapat lebih dari 64 kbps total, kecuali _salah_config_ :P
-- rumy
-- Unsubscribe: kirim email kosong ke [EMAIL PROTECTED] Arsip, FAQ, dan info milis di http://linux.or.id/milis Tidak bisa posting? Baca: http://linux.or.id/problemmilis http://linux.or.id/tatatertibmilis
