Mining Latency

Pool menyiapkan pekerjaan untuk Petr dan mengirimkannya ke perangkat lunak penambangan. Perangkat lunak itu mungkin meneruskan pesan melalui perantara, yaitu proxy, hingga ASIC, cip yang dirancang untuk menambang. Yang penting adalah peralihan nyata ke pekerjaan baru, bukan sekadar pesan tiba di komputer. Mesin kemudian mengirim shares, hasil sebagian yang membuktikan pekerjaannya kepada pool. Dalam Stratum V2, protokol komunikasi perangkat penambangan, channel_id dan job_id menghubungkan pesan dengan kanal serta pekerjaan yang benar. Tanpa hubungan ini, kita bisa mengukur awal satu pekerjaan dengan akhir pekerjaan lain. [1]

Petr mencoba ping sesuai panduan diagnosis Braiins. Ia memeriksa apakah server merespons dan berapa lama permintaan pergi serta jawaban kembali: RTT, atau round-trip time. Ini langkah awal yang berguna. Namun kedua arah dapat melalui rute dan antrean berbeda, sehingga membagi hasilnya dengan dua tidak mengukur keterlambatan satu arah. Ping juga tidak menunjukkan waktu pool menyiapkan pekerjaan atau ASIC mulai menjalankannya. Jadi hasil yang bagus bisa tetap disertai pergantian pekerjaan yang lambat. [2] [3]

Dalam contoh kita, pengirim mencatat Tsend = 1000 ms dan penerima Trecv = 1040 ms. Selisihnya 40 ms, tetapi jam penerima mungkin lebih maju 30 ms. Pengurangan sederhana itu bukan lagi waktu pengiriman sebenarnya. ms berarti milidetik, seperseribu detik. Karena itu standar pengukuran jaringan RFC7679 memperhitungkan ketidakpastian sinkronisasi jam dan lokasi pencatatan waktu. Tanpa informasi tersebut, selisih antarserver bukan bukti peningkatan kecepatan; mungkin hanya pengaturan jamnya yang berbeda. [3]

Agar tidak harus menunggu pekerjaan lengkap setelah blok baru, Stratum V2 memungkinkan Future Job dikirim lebih awal. Pekerjaan ini disiapkan untuk sambungan rantai berikutnya, bukan perintah untuk langsung mulai. SetNewPrevHash mengaktifkannya dengan rujukan blok sebelumnya yang benar dan job_id yang cocok. Jika pekerjaan tersebut berisi transaksi, blok baru dapat membuat sebagian transaksi tidak bisa digunakan kembali, misalnya karena transaksi itu sudah tercantum di dalamnya. Keinginan mengurangi latensi tidak membenarkan pengabaian konflik itu. Cepat memulai pekerjaan yang salah bukan penghematan waktu yang berguna. [1]

Petr melihat share sudah dikirim, tetapi konfirmasinya baru tiba kemudian. Dalam Stratum V2, SubmitShares.Success dapat merangkum beberapa shares yang diterima sekaligus; pengelompokan sengaja ini mengurangi lalu lintas pesan. Jadi seluruh waktu tunggu tidak bisa dianggap sebagai waktu pengiriman, atau bukti bahwa pool belum mengetahui hasil selama itu. SubmitShares.Error juga bisa menyusul setelah pemeriksaan tambahan. sequence_number membantu menghubungkan jawaban dengan hasil yang dikirim. Saat mencari gangguan, pisahkan penerimaan, pemeriksaan, dan pemberitahuan. [1]

Penambangan juga perlu segera mengetahui bahwa seseorang telah menerbitkan blok. Ini tahap berbeda dari hubungan mesin dengan pool. BIP152 mengurangi data yang dikirim antarnode: dalam mode high-bandwidth, node dapat langsung mengirim cmpctblock, gambaran ringkas sebuah blok. Penerima melengkapi sebagian besar transaksi dari datanya sendiri. Transaksi yang kurang diminta melalui getblocktxn dan diterima dalam blocktxn, yang mungkin menambah satu pertukaran lagi. Lebih sedikit data bukan berarti tanpa menunggu, dan tidak menggantikan validasi penuh atas seluruh aturan blok. [4]

Petr ingin mengetahui operasi sehari-hari sekaligus saat sesuatu tersendat. p50/p95 adalah persentil: keduanya menunjukkan bagian berbeda dari sebaran waktu yang diukur, bukan hanya satu rata-rata. Jika waktu diurutkan dari yang terpendek hingga terpanjang, p50 berada kira-kira di tengah dan p95 mendekati ujung yang lebih lambat: sekitar 50% nilai berada di bawah batas pertama dan 95% di bawah batas kedua. Dengan begitu, waktu tunggu yang biasa dapat dibedakan dari penundaan panjang. Namun perlakuan terhadap pesan yang tidak sampai harus dijelaskan. RFC7679 memakai batas tunggu Tmax; melampauinya bukan pengukuran cepat biasa. Dalam perhitungan persentilnya, keterlambatan yang tidak terdefinisi diurutkan sebagai tak terhingga. Menghapusnya diam-diam hanya memperbagus laporan. Sampel kosong juga bukan latensi nol, melainkan tidak adanya dasar untuk menyimpulkan. [3]

Petr membandingkan tahap yang sama, dengan beban serupa dan periode sama panjang. Untuk setiap pengukuran dalam ms, ia mencatat lokasi cap waktu, ketidakpastian jam, dan job_id terkait; ping serta RTT dicatat terpisah. Gangguan dan hasil yang ditolak juga disertakan agar rata-rata cepat tidak menutupi ketidakandalan. Barulah ia bisa menilai apakah server, jaringan, atau pengaturan mesin lain membantu. Tujuannya adalah mengurangi waktu pada pekerjaan usang, bukan menjanjikan penemuan blok. Latensi rendah tidak mengubah sifat acak penambangan ataupun aturan keabsahan. [1] [2] [3]