end-to-end delay

223 views
Skip to first unread message

baskara

unread,
Jan 26, 2005, 3:53:04 AM1/26/05
to tekno...@googlegroups.com
Saya punya sebuah project yang salah satunya adalah mengukur
end-to-end delay dari puluhan ribu paket yang saya kirim dari satu
node ke satu node lainnya. Di dua komputer itu sudah saya pasang ntpd.
Ntpd sudah jalan. Sayangnya, waktu yang ada di 2 komputer itu tidak
pernah bisa untuk benar-benar SAMA (saya rasa ini wajar).

Pengukuran dilakukan dengan mencatat waktu saat paket dikirim di satu
node, dan juga mencatat waktu saat paket diterima di node yang lain.

Saat saya coba mulai pengukuran, hasilnya mengecewakan. Selisihnya
selalu minus, sebuah hasil yang tidak mungkin terjadi kalau waktunya
benar-benar sama. Kalau hasilnya selalu plus mungkin saja saya tertipu
saat pengukuran. Untung saja minus. :-)

Ada ide lainnya? Pemakaian ping/ICMP tidak dianjurkan karena
pengukuran hingga application layer (tidak hanya network/transport
layer).

Husni

unread,
Jan 26, 2005, 4:19:46 AM1/26/05
to tekno...@googlegroups.com
1. di antara node2 itu ada apa? hub/switch doang?
2. jarak antar node berapa meter?
3. paketnya macam apa? sembarang UDP/ICMP atau punya pola khusus?
4. dll (infonya kurang jelas sih :)

Kalau yang mau diukur adalah performance router/hub atau benda2
semacamnya coba pake smartbits ajah
http://www.spirentcom.com/analysis/product_line.cfm?pl=33&wt=2
Suruh lab mu beli. Mainan lumayan tuh.

-husni-

baskara

unread,
Jan 26, 2005, 4:36:44 AM1/26/05
to tekno...@googlegroups.com
On Wed, 26 Jan 2005 09:19:46 -0000, Husni <ahth...@gmail.com> wrote:
>
> 1. di antara node2 itu ada apa? hub/switch doang?
> 2. jarak antar node berapa meter?
> 3. paketnya macam apa? sembarang UDP/ICMP atau punya pola khusus?
> 4. dll (infonya kurang jelas sih :)

1. Ada 1 router dan 1 hub doang.
2. Jarak bisa diabaikan karena panjang kabel2 hanya 1-2 m.
3. Paket 1 macam saja: UDP. Satu arah. Ukurannya ada yang konstan, ada
yang variabel (tergantung jenis percobaan).
4. Tujuan pengukuran: mengukur latency aplikasi/sistem saat paket
mulai dikirim hingga diterima. Berbagai hasil percobaan hanya
dibandingkan selisihnya saja nanti. Jadi, sesederhana itu. :-)

> Kalau yang mau diukur adalah performance router/hub atau benda2
> semacamnya coba pake smartbits ajah
> http://www.spirentcom.com/analysis/product_line.cfm?pl=33&wt=2
> Suruh lab mu beli. Mainan lumayan tuh.

Profesor saya punya prinsip yang berbeda. Seni risetnya tidak ada
kalau memakai alat seperti itu. Dia lebih melihat seberapa kreatif
mahasiswanya kalau menemukan masalah.

*sudah dipaksa-paksa untuk beli G5 satu lagi*

adi

unread,
Jan 26, 2005, 4:39:01 AM1/26/05
to tekno...@googlegroups.com
On Wed, Jan 26, 2005 at 05:53:04PM +0900, baskara wrote:
> Di dua komputer itu sudah saya pasang ntpd.

coba pakai clockspeed: http://cr.yp.to/clockspeed.html

> Pengukuran dilakukan dengan mencatat waktu saat paket dikirim di satu
> node, dan juga mencatat waktu saat paket diterima di node yang lain.

kalibrasi hasilnya dengan clockdiff.

> Ada ide lainnya? Pemakaian ping/ICMP tidak dianjurkan karena
> pengukuran hingga application layer (tidak hanya network/transport
> layer).

ya diukur di satu mesin saja :-) kirim - tunggu reply - hitung.
atau, dihitung throuput, mesin A kirim, mesin B terima, hitung
saat pertama paket diterima dan saat terakhir.

Salam,

P.Y. Adi Prasaja


Husni

unread,
Jan 26, 2005, 4:57:37 AM1/26/05
to tekno...@googlegroups.com
Jadi mau ngukur kinerja si router toh?

node -ifA----------------ifB- router
| ifD | ifC
+-------------------------------+

Pasang IP address di ifA (IPa) , ifB, dan ifC. ifD biarin engga punya
IP address.
Node kirim paket dari IPa ke IPd.
Tipu router dengan pasang ARP statis bahwa IPd punya MAC address ifD.
Jalanin 2 proses tcpdump di ifA dan ifD (non-promisc).

gak butuh sinkronisasi waktu 'kan?
masak make SmartBits ga kreatif? :)

-husni-

baskara

unread,
Jan 26, 2005, 4:58:57 AM1/26/05
to tekno...@googlegroups.com
On Wed, 26 Jan 2005 16:39:01 +0700, adi <adi.p...@gmail.com> wrote:

> ya diukur di satu mesin saja :-) kirim - tunggu reply - hitung.
> atau, dihitung throuput, mesin A kirim, mesin B terima, hitung
> saat pertama paket diterima dan saat terakhir.

Perbandingan ukuran paket yang dikirim dan ukuran reply packet sangat
besar. Jadi, sistem menunggu reply tidak bisa diandalkan.
Menghitung delay rata-rata adalah solusi terakhir saya nanti kalau
dinamika sepanjang waktu sulit diperoleh (minimal sudah ada alasan).
:-)
Clockspeed-nya nanti akan saya coba (meskipun tidak yakin bisa banyak
menolong).
Saya bukannya ingin prefect, tapi masalahnya ini untuk thesis. Saya
bisa dibanting nanti kalau metodenya ngawur. he3x.

adi

unread,
Jan 26, 2005, 4:59:16 AM1/26/05
to tekno...@googlegroups.com
On Wed, Jan 26, 2005 at 04:39:01PM +0700, adi wrote:
> ya diukur di satu mesin saja :-) kirim - tunggu reply - hitung.
> atau, dihitung throuput, mesin A kirim, mesin B terima, hitung
> saat pertama paket diterima dan saat terakhir.

sorry, maksudnya throughput, pengukuran dilakukan di mesin B.
misalnya seperti yang dipakai oleh program brutal copy. saya pakai
program ini untuk mengukur bandwidth efektif.

http://atrey.karlin.mff.cuni.cz/~clock/twibright/bcp/index.html

Salam,

P.Y. Adi Prasaja


adi

unread,
Jan 26, 2005, 5:17:48 AM1/26/05
to tekno...@googlegroups.com
On Wed, Jan 26, 2005 at 06:58:57PM +0900, baskara wrote:
> Clockspeed-nya nanti akan saya coba (meskipun tidak yakin bisa banyak
> menolong).

saya kurang tahu, sampai seberapa akurasi dan sampai seberapa
lama akurasi ini bisa dijaga pakai clockspeed (dugaan saya sih
bergantung mesin yang kita pakai juga). barangkali bisa dicek
pakai clockdiff (clockdiff seingat saya bagian dari iputils yang
memang dibuat u/ linux. maaf ingatnya cuman segitu lah wong skrg
pakai linux).

clockspeed menggunakan cara yang berbeda u/ melakukan kalibrasi
waktu.

> Saya bukannya ingin prefect, tapi masalahnya ini untuk thesis. Saya
> bisa dibanting nanti kalau metodenya ngawur. he3x.

clockspeed bisa dibaca sourcenya :-))

btw, lebih baik dibanting karena metodenya ngawur dibandingkan dibanting
karena yang ngebanting ngawur he..he.. pernah lihat sendiri kok yang
kayak gini di program doktoral :-) everybody make mistake ...

Salam,

P.Y. Adi Prasaja


Yulian F. Hendriyana

unread,
Jan 26, 2005, 7:30:46 AM1/26/05
to tekno...@googlegroups.com
Merujuk email Husni tanggal 26-Jan-2005:
>
> Jadi mau ngukur kinerja si router toh?
>
> node -ifA----------------ifB- router
> | ifD | ifC
> +-------------------------------+

berantakan diagramnya
hehe, coba bikin diagramnya di console dulu, pake font monospace
baru dipaste ke gmail, terus send

atau hack userContent.css Firefox biar baca mail di gmail
menggunakan font monospace


--
Suatu kaum atau seseorang yang hidupnya penuh kebencian dan permusuhan tak
akan pernah tenang, terhormat dan berjaya selain hina dan menderita. --MQ


Andika Triwidada

unread,
Jan 27, 2005, 10:49:23 PM1/27/05
to tekno...@googlegroups.com
On Wed, 26 Jan 2005 17:53:04 +0900, baskara <bas...@gmail.com> wrote:
>
> Saya punya sebuah project yang salah satunya adalah mengukur
> end-to-end delay dari puluhan ribu paket yang saya kirim dari satu
> node ke satu node lainnya. Di dua komputer itu sudah saya pasang ntpd.
> Ntpd sudah jalan. Sayangnya, waktu yang ada di 2 komputer itu tidak
> pernah bisa untuk benar-benar SAMA (saya rasa ini wajar).

ftp://ftp.ee.lbl.gov/pathchar/pathchar-a1-linux-2.0.30.tar.gz
di file README dikatakan
" the PC pathchar has to be run on a pentium or better -- it will
run but give useless numbers on a 386 or 486. this is because
pathchar requires a very high resolution clock (1us or better)
and the pentium is the first intel chip with a halfway decent
clock."

Entah apakah masih valid pernyataan di atas? (Termasuk
ekstrapolasinya ke P4 dst).

Kalau masih valid, berarti perlu dicoba testingnya di
platform bukan x86, agar potensi ketelitian NTP
bisa terwujud.

--
.''`. Andika Triwidada <and...@gmail.com>
: :' : just another Debian admin
`. `'` http://andika-lives-here.blogspot.com/
`- Debian - when you have better things to do than fixing a system

baskara

unread,
Jan 27, 2005, 10:57:10 PM1/27/05
to tekno...@googlegroups.com
On Fri, 28 Jan 2005 10:49:23 +0700, Andika Triwidada <and...@gmail.com> wrote:
>
> Kalau masih valid, berarti perlu dicoba testingnya di
> platform bukan x86, agar potensi ketelitian NTP
> bisa terwujud.

Saya menjalankan ntp di mesin PPC G4 dan G5, dan juga 1 mesin x86 P4.
Kalau melihat log-file-nya, nge-drift setiap saat.
Akhirnya saya putuskan untuk mengukur kinerja di satu mesin saja
(hasilnya sudah saya dapatkan).

(jadi ingat kalau balapan nge-drift belum tuntas)
Reply all
Reply to author
Forward
0 new messages