Firmware yang dimodifikasi untuk semua ASIC IceRiver, menambahkan kontrol jam dan voltase, grafik sensor, login dan akses API yang diamankan dengan benar, dan fitur lainnya.
OC/OV yang dapat disesuaikan, biaya kecil yang menguntungkan komunitas, tidak ada perubahan yang tidak perlu pada perangkat Anda.
File firmware dapat diunduh dari bagian Rilis di sisi kanan halaman ini.
Jika Anda mengalami masalah apa pun, menemukan saya (pbfarmer) di Kaspa Discord mungkin akan menghasilkan respons/resolusi tercepat.
Tak satu pun dari firmware ini akan mungkin terjadi tanpa upaya sejumlah orang dalam pengujian dan umpan balik.
Namun, ada satu orang yang telah mengorbankan mesinnya sejak awal, memberi saya akses langsung untuk pengembangan, memungkinkan saya mengambil risiko mesinnya saat menguji fitur-fitur baru, dan mengalami banyak gangguan penambangan selama pembaruan dan restart yang sering dilakukan.
Orang ini menggunakan akun Discord Onslivion - akan sangat bagus jika Anda bisa mengucapkan terima kasih kepadanya di Kaspa Discord, dan bahkan mungkin mengiriminya tip atau beberapa hashrate Anda:
kaspa:qzh2xglq33clvzm8820xsj7nnvtudaulnewxwl2kn0ydw9epkqgs2cjw6dh3y
Pengaturan jam dan voltase telah ditambahkan ke halaman 'Penambang'. Jam dapat ditingkatkan/dikurangi ke nilai integer apa pun (dalam batas perangkat keras). Perubahan akan langsung berlaku tanpa memulai ulang, namun perhatikan bahwa peningkatan jam diterapkan secara bertahap dengan peningkatan 25Mhz per 30 detik. Akibatnya, mungkin diperlukan beberapa waktu untuk mencapai kecepatan penuh, bahkan mungkin ~10 menit, tergantung pada seberapa besar offset yang Anda pilih.
Tegangan juga dapat dinaikkan/diturunkan ke nilai integer apa pun (dalam batas perangkat keras), dan perubahan akan segera berlaku. Pengaturan akan dibulatkan ke bawah ke kelipatan terdekat yaitu 6,25mV secara internal untuk semuanya kecuali KS0 Pro. Model sederhana yang perlu diingat adalah bahwa untuk setiap kenaikan 25mv, kenaikan yang tepat adalah 7mv-6mv-6mv-6mv, atau misalnya, 7, 13, 19, 25 untuk 25mv pertama.
Untuk KS0 Pro, tegangan dapat disesuaikan dengan penambahan 2mV.
KONTROL TEGANGAN TIDAK TERSEDIA UNTUK KS3/M/L SAAT INI.
PENTING: SAAT INI TIDAK ADA GUARDRAIL, DAN TIDAK ADA BATAS YANG DIBERLAKUKAN OLEH PERANGKAT LUNAK INI BAIK PADA JAM ATAU TEGANGAN, JADI GUNAKAN DENGAN HATI-HATI.
Mode kipas baru telah ditambahkan yang secara otomatis menyesuaikan kecepatan kipas untuk mempertahankan suhu chip hash dan papan maksimum. Suhu dibaca setiap 10 detik dan kecepatan kipas disesuaikan seperlunya.
Harap diperhatikan, pengaturan ini tidak menjamin suhu yang disetel. Suhu ini mungkin terlampaui hingga ~5C selama permulaan atau periode dinamis lainnya, namun suhu tersebut harus stabil pada atau mendekati suhu yang diminta.
Jika Anda menemukan suhu target terlampaui melebihi kenyamanan Anda selama pengaktifan atau periode dinamis lainnya, Anda harus meningkatkan kecepatan kipas minimum.
Kecepatan kipas tetap sekarang juga akan diterapkan kembali saat startup, setelah penundaan ~1-2m, meskipun ini hanya diterapkan satu kali. Artinya, jika perangkat lunak IceRiver yang mendasarinya memutuskan untuk mengubah kecepatan kipas lagi karena alasan tertentu, mode ini tidak akan menerapkan kembali pengaturan Anda. Pertimbangkan untuk menggunakan mode 'Target Temp' dengan kecepatan kipas minimum yang sesuai sebagai alternatif.
Grafik dua jam telah ditambahkan untuk semua metrik chip, dengan filter untuk ringkasan (per papan min/maks/rata-rata), papan, atau semua chip.
Suhu chip 80c tampaknya menghasilkan kinerja hashrate yang ideal (meskipun ini mungkin sulit pada KS0/Pro tanpa mod pendingin.) Tidak ada panduan yang diberikan oleh IceRiver mengenai batas suhu chip yang aman, tetapi perangkat lunak penambang mereka tampaknya membatasi kenaikan jam di atas 95C , dan sebenarnya akan membatasi jam di atas 110C. Setidaknya mengikuti panduan umum dari G/CPU mungkin merupakan tindakan yang bijaksana (misalnya zona peringatan >90C, zona bahaya >95C, zona kritis >105C).
Perlu diingat bahwa tegangan real-time tidak akan pernah sesuai dengan pengaturan Anda - driver yang berada di bawah beban mengalami penurunan tegangan, artinya tegangan yang berjalan akan selalu berada di bawah pengaturan tegangan Anda, dengan beban yang lebih banyak menyebabkan penurunan yang lebih besar. Tegangan chip akan digantikan oleh penarikan daya untuk KS5L/M, karena tidak tersedia pembacaan tegangan chip. Batas perangkat lunak sebesar 3350W diberlakukan pada model ini, di mana inti akan dinonaktifkan dalam kelompok 4 orang jika Anda melebihi batas ini.
Grafik suhu papan telah ditambahkan untuk semua model, yang mencakup suhu sensor masuk dan buang, serta suhu tahap daya (pengemudi) untuk KS0/Pro/Ultra, KS1, dan KS2. Dalam mode ringkasan, suhu tingkat daya maksimum ditampilkan untuk setiap papan, sedangkan dalam mode papan, suhu tingkat daya maksimum ditampilkan untuk setiap grup/pengontrol (PSG). Suhu pengoperasian maksimum yang disarankan adalah 125C menurut dokumentasi chip, meskipun mungkin bijaksana untuk menjaga margin yang sehat di bawah suhu ini.
Perlu diketahui, bahwa suhu bukanlah satu-satunya pertimbangan untuk pengoperasian yang sehat. Penarikan daya/arus juga menjadi perhatian, yang saat ini kami belum memiliki visibilitas atau spesifikasinya.
Grafik hashrate (serta statistik judul) kini mencakup pelacakan 30 menit dan 2 jam, dan juga mencakup pemfilteran tingkat papan.
Tooltip mouseover telah disinkronkan di seluruh grafik, untuk membantu mendiagnosis masalah/anomali.
Nilai sesaat ditampilkan dalam legenda, dan masing-masing baris dapat dinonaktifkan/diaktifkan dengan mengklik labelnya. Skala grafik tidak lagi berbasis nol, dan menyesuaikan bergantung pada garis mana yang ditampilkan, yang berarti garis tersebut tidak lagi diratakan secara artifisial karena resolusi yang buruk, dan Anda sebenarnya dapat melihat variabilitas dalam setiap pengukuran.
Mudah-mudahan ini membantu memperjelas bagaimana sebenarnya pembacaan variabel 5m.
Waktu aktif tanpa gangguan, dan tingkat penerbitan pekerjaan ditambahkan ke bagian statistik kumpulan. Tingkat pekerjaan hanyalah indikator kesehatan tambahan dari koneksi kumpulan - saat ini tingkat pekerjaan untuk jaringan Kaspa harus sekitar 1 per detik (akan segera menjadi 10/dtk dengan penerapan Rust) dengan variasi sekitar +/- 15%. Meskipun tingkat pekerjaan yang secara konsisten lebih tinggi atau lebih rendah dari ini seharusnya tidak secara teknis mempengaruhi penghasilan Anda karena kebijakan penerimaan blok Kaspa (dengan asumsi kumpulan tersebut tidak menolak saham 'lama' secara tidak perlu), ini merupakan sinyal bahwa kumpulan tersebut mungkin tidak berfungsi dengan baik, dan Anda mungkin ingin memberi tahu operator kumpulan, atau mungkin mencari opsi lain.
Telah dikomunikasikan oleh operator kaspa-pool bahwa mereka sengaja mengurangi tingkat pekerjaan untuk membatasi biaya overhead, dan hal ini tidak mempengaruhi tingkat pembagian yang basi dalam kasus mereka.
Beberapa indikator status telah ditambahkan ke bagian kumpulan untuk membantu mendiagnosis berbagai masalah jaringan/kumpulan. Ikon abu-abu sibuk (berputar) menunjukkan asic mencoba terhubung ke pool. Ikon sibuk berwarna hijau menunjukkan koneksi jaringan, namun belum ada koneksi strata. Ikon peringatan berwarna kuning menunjukkan koneksi strata berhasil, namun tidak ada pekerjaan yang diterima.
Meskipun API yang tersedia sebelumnya pada port 4111 masih tersedia, API baru yang dirasionalisasi termasuk semua fitur tambahan dari UI kini tersedia melalui https (port 443).
Dokumentasi lengkap tersedia dalam format json.
Sejumlah fitur telah ditambahkan ke bangunan 'komersial' terpisah yang ditujukan untuk hosting atau penerapan besar lainnya. Versi ini menyertakan 'c' setelah nomor versi (misalnya pbv081c_ks5mupdate.bgz ), dan saat ini dikenakan biaya tambahan sebesar 0,33% (1,33% vs standar 1%).
Selain pengguna utama/admin standar, beberapa pengguna dengan izin akses berbeda dapat ditambahkan. Hal ini memungkinkan pengaturan di mana, misalnya, pemilik mesin dapat diberikan akses langsung ke mesin, dengan izin untuk melihat halaman pemantauan utama dan mengubah konfigurasi kumpulan, sekaligus dilarang mengubah parameter jaringan, kipas, atau jam/tegangan.
Hashpower ASIC dapat dibagi menjadi beberapa titik akhir berdasarkan persentase yang dapat dikonfigurasi, untuk memungkinkan pengaturan biaya hosting. Jumlah pemisahan tidak dibatasi, namun harap diingat bahwa firmware akan mempertahankan koneksi kumpulan/stratum untuk setiap pemisahan, yang melipatgandakan lalu lintas masuk.
Fitur ini juga dapat digunakan untuk membagi hashrate di beberapa koin KHeavyHash sekaligus
Logo 'PbFarmer' dapat diganti dengan gambar branding pilihan Anda. Format gambar harus PNG 112x60.
Loop pemeriksaan kesehatan dijalankan pada ketersediaan kumpulan utama. Jika penambang telah beralih ke salah satu kolam sekunder karena alasan apa pun, Anda akan dialihkan kembali ke kolam utama segera setelah kolam tersebut tersedia kembali.
Mengganti server web stok dengan versi yang diperbarui dan ditargetkan pada lingkungan produksi, menambahkan konfigurasi kontrol cache/memori, dan memperbaiki kebocoran memori. Hal ini akan mengatasi masalah yang dilihat oleh pengguna HiveOS dan alat pemantauan eksternal lainnya yang menyebabkan server web mogok setelah terlalu banyak memuat halaman (yang mengakibatkan UI ASIC tidak tersedia.)
Kontrol otentikasi dan otorisasi telah sepenuhnya diganti, dan semua lalu lintas dialihkan melalui https. Ini berarti meneruskan lalu lintas http melalui firewall Anda untuk pemantauan di luar situs akan jauh lebih aman (walaupun saya tetap tidak akan merekomendasikan hal ini - hanya karena praktik keamanan terbaik...) Login tidak lagi dikirimkan melalui http yang tidak aman, dan orang tidak dapat lagi membajak asic Anda hanya dengan menyetel cookie untuk melewati login. Pesan acak 'login salah' karena kerusakan sistem file juga seharusnya sudah berlalu. Harap diingat ini berarti kata sandi Anda akan diatur ulang ke default bawaan setelah instalasi pertama. Selain itu, booting pertama setelah instalasi akan memakan waktu 2+ menit, karena mesin menghasilkan sertifikat TLS.
Selain itu, API yang didesain ulang telah diamankan dengan token akses, yang melaluinya izin terperinci dapat diberikan. Token harus disertakan dengan permintaan API di header formulir 'Otorisasi: Pembawa <token>'.
Sama seperti Anda memperbarui kata sandi login, HARAP HAPUS/GANTI TOKEN API INI jika Anda berencana untuk mengekspos mesin Anda secara publik, karena ini sama di semua mesin secara default.
Sertifikat TLS (dan otoritas sertifikat) untuk https dibuat secara otomatis di ASIC, artinya sertifikat tersebut akan menyebabkan peringatan 'Tidak aman' di browser Anda karena tidak berasal dari otoritas terkenal. Meskipun tidak berbahaya, peringatan ini dapat mengganggu, sehingga firmware menyediakan kemampuan untuk mengunduh sertifikat CA sehingga dapat diunggah ke penyimpanan sertifikat browser Anda.
Untuk melakukannya di Chrome, misalnya, buka chrome://settings/security, klik 'Kelola Sertifikat', pilih tab 'Otoritas Sertifikasi Root Tepercaya' (atau hanya 'Otoritas' untuk Linux), dan klik impor tombol. Setelah memulai ulang browser, Anda tidak akan lagi melihat peringatan 'Tidak aman'.
Jika Anda memiliki beberapa ASIC, Anda akan memiliki CA yang berbeda untuk masing-masing ASIC secara default. Namun, alih-alih menambahkan masing-masing file ini ke browser atau perangkat lain, Anda dapat menyebarkan satu CA ke semua ASIC dengan mengunduh sertifikat CA dan kunci CA dari satu ASIC, mengunggah kedua file ke semua ASIC Anda yang lain, kemudian membuat ulang sertifikat pada masing-masing ASIC lainnya.
Jika Anda mengakses ASIC melalui nama domain atau beberapa IP, Anda juga dapat menambahkannya ke sertifikat TLS dengan mencantumkannya di bidang 'Buat ulang sertifikat' dan klik 'buat ulang'.
Loop pemeriksaan kesehatan telah ditambahkan, yang secara otomatis akan memulai ulang penambang atau server web jika mogok karena alasan apa pun.
Selain itu, executable 'reset' yang ditemukan menghilang secara acak dari mesin orang (bahkan pengaturan stok), sekarang dikemas dengan firmware, dan loop healthcheck telah ditambahkan untuk mengganti/me-restart file jika perlu. Hal ini seharusnya mengatasi loop reboot 30m yang dialami banyak orang.
JANGAN menginstal firmware xyys (termasuk merek tswift) pada model KS0 Ultras atau KS5*. Harap pastikan untuk mengikuti instruksi penghapusan instalasinya sebelum menginstal firmware ini atau firmware lainnya!
Ini adalah paket pembaruan firmware standar, termasuk/meningkatkan firmware IceRiver terbaru, dan diterapkan sebagaimana firmware resmi. Menerapkan pembaruan sebelumnya akan berfungsi untuk model KS0/Pro, KS1, KS2, dan KS3*. Menerapkan kelebihan stok, atau versi sebelumnya dari firmware ini juga dapat digunakan untuk model KS0 Ultra dan KS5*.
Namun jika Anda mengalami masalah, coba proses berikut:
Selain itu, pastikan untuk mengulangi pengaturan kumpulan Anda, karena pengaturan tersebut akan diatur ulang ke alamat default Kaspa Dev Fund.
Catu daya laptop untuk model KS0/Pro/Ultra umumnya harus 19,5V dengan konektor 5,5mm x 2,5mm, tetapi nilai amp dapat bervariasi tergantung pada target OC Anda. Namun, konektor barel dengan ukuran ini cenderung memiliki nilai 5 atau 10a, dan IceRiver kemungkinan tidak menggunakan opsi 5a, jadi wajar saja jika mereka menggunakan 10a (7,5a adalah kemungkinan lain). Artinya, adaptor apa pun dengan daya lebih dari 200W kemungkinan besar melebihi daya soketnya, sehingga stekernya bisa meleleh atau bahkan terbakar, jika tidak didinginkan secara aktif (bahkan risikonya tetap ada). Harap berhati-hati jika Anda memilih untuk menggunakan salah satu opsi pengisi daya laptop berdaya tinggi.
Sangat disarankan agar Anda memasang pengukur daya pada mesin Anda, untuk memastikan Anda berada dalam batas PSU Anda. Hal ini terutama berlaku untuk model KS3* dan KS5*, yang memiliki ruang kepala PSU yang sangat kecil bahkan pada pengaturan stok, serta model KS0* karena beragamnya pasokan daya.
Model KS0 Pro dan Ultra memerlukan perhatian khusus pada pendinginan. Tahapan daya pada perangkat ini sudah berjalan sangat panas, jadi modifikasi perangkat keras untuk meningkatkan pendinginan sangat disarankan - termasuk heatsink, dan aliran udara yang lebih baik.
Chip hash pada semua model cenderung memiliki performa terbaik pada rentang 75-80c, namun hal ini terutama berlaku untuk KS0 Ultra, yang meskipun diturunkan dari 80c ke 75c, saya mengalami penurunan hashrate 2 jam sebesar > 3%.
PERSENTASE OFFSET JAM DAN PERSENTASE PENINGKATAN HASHRATE HARUS SAMA PADA MESIN YANG SEHAT.
Misalnya jika offset jam Anda adalah 30% pada KS1, maka hashrate Anda harus 1,3TH/s, atau 30% lebih tinggi dari default 1 TH/s. Jika hal ini tidak terjadi (pada jendela pengukuran yang sesuai), maka itu berarti chip Anda kekurangan tegangan.
Penyetelan yang tepat adalah proses yang membutuhkan waktu. Menggunakan pengaturan orang lain umumnya bukan ide bagus, karena setiap mesin berbeda. Praktik terbaiknya adalah memulai dengan offset jam konservatif yang menghasilkan peningkatan hashrate yang sesuai tanpa perubahan voltase. Saat Anda menaikkan jam lebih lanjut sedikit demi sedikit (misalnya 25mhz atau kurang), setelah Anda tidak lagi melihat respons hashrate 1:1 (atau bahkan mungkin mulai turun), ini merupakan indikasi bahwa diperlukan lebih banyak voltase.
Pada titik itu, naikkan voltase satu langkah (2mv untuk KS0 Pro, 7 atau 6mv bergantung pada level arus untuk semua model lainnya), lalu lihat apakah hashrate merespons. Jika ya, dan sekali lagi sama dengan offset jam dalam persentase, kembali ke menaikkan jam. Lanjutkan ini bolak-balik antara offset jam dan voltase hingga Anda mencapai hashrate yang diinginkan, sambil tetap memperhatikan batas suhu dan daya.
Meskipun hashrate 5m dan 30m di GUI merupakan alat yang berguna untuk panduan arah setelah mesin memiliki waktu untuk melakukan peningkatan, pengukuran hashrate akhir harus dilakukan dalam jangka waktu yang lama. Pembacaan hashrate 5 menit cukup bervariasi, dan bahkan pembacaan hashrate 30 menit pun tidak bagus, karena Anda masih dapat memiliki variabilitas beberapa persen. Pembacaan 2 jam di UI seharusnya memiliki variabilitas kurang dari 1% dari pengalaman saya (mungkin sedikit di atas 1% pada KS5L/M dan KS0Ultra), meskipun tidak memperhitungkan kesalahan perangkat keras/penolakan kumpulan.
Dan terakhir, jika Anda mencoba meniru hasil OC dari firmware lain...
Semua firmware OC, termasuk yang ini, hanya mengontrol jam dan voltase. Menurut pengalaman saya, dengan voltase yang diperlukan, hashrate merespons secara linear dengan basis 1:1 terhadap perubahan jam, berdasarkan persentase. Namun pada akhirnya, yang bisa kita lakukan hanyalah mengubah waktu dan berharap ASIC merespons dengan perubahan hashrate yang diharapkan.
Pembacaan hashrate di ASIC UI tidak seperti pada penambangan CPU/GPU. ASIC IceRiver tidak menghitung hash sebenarnya - mereka hanya memperkirakan hashrate berdasarkan jumlah pembagian yang diproduksi * tingkat kesulitan. Ini persisnya cara suatu kumpulan mengukur hashrate Anda, namun masalahnya adalah sebagian besar kumpulan memutuskan untuk menggunakan tingkat kesulitan yang terlalu tinggi untuk ASIC IceRiver, yang mencegah pengukuran hashrate jangka pendek yang dapat diandalkan - dengan perbedaan yang tinggi, tingkat pembagiannya rendah, yang berarti perubahan liar dalam hashrate. Hasilnya, IceRiver merilis pembaruan firmware yang mulai menggunakan tingkat kesulitan internal yang lebih rendah dan berbeda untuk pengukuran hashrate di dasbor mereka sendiri.
Oleh karena itu, bahkan untuk jangka waktu yang sama persis, Anda tidak dapat membandingkan pengukuran hashrate kumpulan dengan hashrate ASIC UI secara andal - keduanya tidak menggunakan data yang sama. Untuk lebih memperburuk hal ini, karena mesin IceRiver menghasilkan sejumlah besar bagian yang tidak valid sejak awal, sejumlah kumpulan memutuskan untuk berhenti melaporkan bagian yang ditolak kembali ke ASIC sehingga pengguna akan berhenti mengeluh (atau berpindah kumpulan), dan sebagai gantinya melaporkannya sebagai diterima , sambil tetap diam-diam menolaknya. Bergantung pada tingkat penolakan sebenarnya, hal ini dapat berarti perbedaan yang signifikan antara hashrate ASIC dan hashrate kumpulan, meskipun keduanya diukur menggunakan jangka waktu dan tingkat kesulitan yang sama.
Terlepas dari perbedaan yang dipilih, pengukuran hashrate berdasarkan pembagian * tingkat kesulitan dapat diubah berdasarkan keberuntungan. Semakin rendah jumlah share (semakin tinggi perbedaannya), semakin besar keberuntungan yang mempengaruhi hashrate, dan semakin liar ayunannya. Oleh karena itu, untuk mendapatkan pengukuran hashrate yang bermakna secara statistik, Anda memerlukan pembagian yang cukup untuk mengurangi efek keberuntungan sebanyak mungkin. Pembacaan 5m pada ASIC tidak cocok untuk ini, terutama ketika mencoba memverifikasi hasil perubahan OC satu digit, dan pembacaan kumpulan jangka pendek bahkan lebih buruk.
Anda memerlukan 1.200 lembar saham hanya untuk mendapatkan varians yang diharapkan sebesar +/- 10% dengan keyakinan 99%. Misalnya untuk hashrate yang diharapkan sebesar 1TH/s, dalam pengukuran 99/100 setelah 1200 kali dibagikan, Anda akan mendapatkan pembacaan antara 0,9TH/s dan 1,1TH/s. Anda memerlukan 4800 saham untuk mengurangi varians tersebut menjadi +/- 5%. Banyak kumpulan yang menggunakan tingkat kesulitan yang menghasilkan tingkat pembagian dalam kisaran ~5 pembagian/menit. Oleh karena itu, hanya untuk mendapatkan pembacaan hashrate dengan variansi yang diharapkan <= +/- 10%, Anda memerlukan pembacaan 1200/5 = 240 menit, atau 4 jam. Jika Anda menginginkan pembacaan dengan variansi yang diharapkan +/- 5%, Anda memerlukan data lebih dari 16 jam. Anda tidak akan pernah bisa memastikan hasil level OC di bawah varians yang diharapkan dalam jangka waktu tertentu. Misalnya, Anda tidak mungkin menentukan apakah OC 5% berfungsi dengan baik dalam jendela pembagian 4 jam/1200 yang memiliki variansi yang diharapkan 10%. Bahkan pada 16 jam / 4800 saham, varians yang diharapkan dapat sepenuhnya membatalkan OC 5%.
Dan hal ini mengarah pada inti masalahnya - sebagian besar kumpulan tidak memberikan pengukuran yang lebih tinggi dari 24 jam, yang mana pada ~5 pembagian/menit berarti sekitar 7200 pembagian, yang masih merupakan variansi yang diharapkan sebesar 4%. Anda memerlukan 10 ribu lembar saham hanya untuk variansi 3,3%, dan sekitar 100 ribu lembar saham untuk variansi 1%. Pembacaan 30 menit di ASIC UI seharusnya memiliki varians sekitar 2%, dan pembacaan 2 jam yang baru seharusnya memiliki varians kurang dari 1%, namun tidak mencerminkan kumpulan penolakan. Oleh karena itu, satu-satunya solusi adalah menemukan kumpulan yang memungkinkan Anda mengatur tingkat kesulitan Anda sendiri, sehingga Anda dapat menghasilkan jumlah pembagian yang relevan secara statistik untuk jangka waktu yang tersedia. Herominers adalah salah satu kelompok yang memungkinkan hal ini.
Pilihan terbaik untuk mengatur perbedaan Anda sendiri dan melihat jangka waktu pengukuran yang cukup lama adalah penambangan solo ke node Anda sendiri dan jembatan kaspa-stratum. Pengaturan vardiff default akan menghasilkan minimal 20 share/menit, yang cukup untuk memiliki <= +/- 5% variansi dalam 4 jam, dan dasbor (grafana) memungkinkan pengukuran dalam jangka waktu/resolusi apa pun yang Anda inginkan, termasuk jangka waktu yang jauh lebih lama daripada 24 jam.
Sebagai contoh nyata perbedaan antara pengukuran valid dan tidak valid (serta bagaimana kaspa-stratum-bridge dapat membantu), berikut pembacaan hashrate dari 3 mesin menggunakan perbedaan yang menghasilkan >= 30 share/mnt, KS0 pada 51% OC, KS1 pada 37% OC, dan KS3M pada 1% OC. Pengukurannya adalah, dari atas ke bawah, 24 jam (>= 43K share), 1 jam (>= 1800 share), dan 30m (> 900 share). Anda dapat melihat seberapa berbeda pengukuran tersebut dari perkiraan dalam jangka waktu yang lebih pendek:
Singkatnya, jika Anda mencoba mengonfirmasi efek OC kecil pada UI ASIC, Anda perlu menggunakan pembacaan 2 jam, namun Anda tidak akan tahu apakah Anda menghasilkan pembagian yang akan ditolak. Untuk mendapatkan gambaran lengkap, Anda memerlukan pengukuran jangka panjang dari kumpulan yang memungkinkan tingkat pembagian yang tinggi - dan tidak ada opsi yang dapat saya tunjukkan yang dapat melakukan hal ini saat ini, selain menambang ke node Anda sendiri + kaspa-stratum -menjembatani.