Mining Latency

يجهّز المجمّع مهمة لبيتر ويرسلها إلى برنامج التعدين. وقد يمرّر البرنامج الرسالة عبر وسيط، أي ⁦proxy⁩، إلى ⁦ASIC⁩، وهي شريحة مصمّمة للتعدين. المهم هو التحوّل الفعلي إلى المهمة الجديدة، لا مجرد وصول الرسالة إلى الحاسوب. ثم ترسل الآلة ⁦shares⁩، وهي نتائج جزئية تثبت عملها للمجمّع. في ⁦Stratum V2⁩، بروتوكول اتصال أجهزة التعدين، يربط ⁦channel_id⁩ و⁦job_id⁩ الرسائل بالقناة والمهمة الصحيحتين. ومن دون هذا الربط قد نقيس بداية عمل ونهاية عمل آخر. [1]

يجرّب بيتر ⁦ping⁩ وفق إرشادات التشخيص لدى ⁦Braiins⁩. بذلك يعرف هل يردّ الخادم، وكم تستغرق رحلة الطلب ذهابًا والرد إيابًا: ⁦RTT⁩، أي ⁦round-trip time⁩. إنها خطوة أولى مفيدة. لكن الاتجاهين قد يسلكان مسارين مختلفين ويواجهان طوابير مختلفة، لذلك لا تقيس القسمة على اثنين التأخير في اتجاه واحد. كما لا يبيّن ⁦ping⁩ وقت إعداد المجمّع للمهمة أو بدء ⁦ASIC⁩ بها. لذا قد تكون النتيجة جيدة مع بقاء تبديل المهام بطيئًا. [2] [3]

في مثالنا، يسجل المرسل ⁦Tsend = 1000 ms⁩ والمستقبل ⁦Trecv = 1040 ms⁩. الفرق هو ⁦40 ms⁩، لكن ساعة المستقبل قد تكون متقدّمة بمقدار ⁦30 ms⁩. عندها لا يعطي الطرح البسيط مدة النقل الحقيقية. تعني ⁦ms⁩ ميلي ثانية، أي جزءًا من ألف من الثانية. لذلك يأخذ معيار قياس الشبكات ⁦RFC7679⁩ في الحسبان عدم اليقين في مزامنة الساعات ومكان تسجيل الطابع الزمني. ومن دون هذه المعلومات، لا يثبت الفرق بين الخوادم تحسّن السرعة؛ فقد يعكس فقط اختلاف ضبط الساعات. [3]

لتجنّب انتظار المهمة كاملة بعد كتلة جديدة، يسمح ⁦Stratum V2⁩ بإرسال ⁦Future Job⁩ مسبقًا. إنها مهمة معدّة للارتباط بحالة مستقبلية للسلسلة، وليست أمرًا بالبدء فورًا. يفعّلها ⁦SetNewPrevHash⁩ مع المرجع الصحيح للكتلة السابقة و⁦job_id⁩ المطابق. إذا احتوت المهمة على معاملات، فقد تجعل الكتلة الجديدة بعضها غير صالح لإعادة الاستخدام، مثلًا لأنها تحتويها بالفعل. تقليل التأخير لا يبرر تجاهل هذا التعارض. فالبدء السريع بعمل خاطئ ليس توفيرًا مفيدًا للوقت. [1]

يرى بيتر أن ⁦share⁩ أُرسلت، لكن تأكيدها يصل لاحقًا. في ⁦Stratum V2⁩ يمكن لـ⁦SubmitShares.Success⁩ تلخيص عدة ⁦shares⁩ مقبولة معًا؛ فالتجميع المتعمّد يقلّل عدد الرسائل. لذلك لا يمكن نسب مدة الانتظار كلها إلى النقل أو الجزم بأن المجمّع لم يعرف النتيجة طوالها. وقد يأتي ⁦SubmitShares.Error⁩ أيضًا بعد فحص لاحق. يساعد ⁦sequence_number⁩ في ربط الردود بالنتائج المرسلة. وعند البحث عن عطل، نفرّق بين الاستلام والفحص والإبلاغ. [1]

يحتاج التعدين أيضًا إلى معرفة نشر كتلة بسرعة. وهذه مرحلة مختلفة عن اتصال الآلة بالمجمّع. يقلّل ⁦BIP152⁩ البيانات المنقولة بين العقد: في وضع ⁦high-bandwidth⁩ تستطيع العقدة إرسال ⁦cmpctblock⁩ مباشرة، وهو وصف مختصر للكتلة. يستكمل المستقبل معظم المعاملات من بياناته، ويطلب الناقص عبر ⁦getblocktxn⁩ ويتلقّاه في ⁦blocktxn⁩، مما قد يضيف تبادلًا آخر. إذن تقليل البيانات لا يعني غياب الانتظار، ولا يحلّ محل التحقق الكامل من جميع قواعد الكتلة. [4]

يهتم بيتر بالتشغيل المعتاد وبالأوقات التي تتعثر فيها الأمور. ⁦p50/p95⁩ هي قيم مئينية تعرض أجزاء مختلفة من توزيع الأزمنة المقاسة بدلًا من متوسط واحد. عند ترتيب الأزمنة من الأقصر إلى الأطول، تقع ⁦p50⁩ قرب المنتصف و⁦p95⁩ قرب الطرف الأبطأ: نحو ⁦50%⁩ من القيم دون الحد الأول و⁦95%⁩ دون الثاني. وهكذا يمكن التمييز بين الانتظار المعتاد والتأخيرات الطويلة. لكن يجب توضيح كيفية التعامل مع الرسائل التي لم تصل. يستخدم ⁦RFC7679⁩ حدّ انتظار هو ⁦Tmax⁩؛ وتجاوزه ليس قياسًا سريعًا عاديًا. وفي حساب القيم المئينية لديه، تُرتّب التأخيرات غير المعرّفة كما لو كانت لا نهائية. حذفها من دون بيان يحسّن الصورة على الورق فقط. والعينة الفارغة لا تعني تأخيرًا صفريًا، بل غياب أساس للاستنتاج. [3]

يقارن بيتر المراحل نفسها تحت حمل متشابه وخلال فترات متساوية الطول. ولكل قياس بوحدة ⁦ms⁩ يسجّل مكان الطابع الزمني وعدم يقين الساعات و⁦job_id⁩ المعني، ويُبقي ⁦ping⁩ و⁦RTT⁩ منفصلين. ويضيف الانقطاعات والنتائج المرفوضة كي لا يخفي متوسط سريع ضعف الاعتمادية. عندها يمكنه بحث ما إذا كان خادم أو شبكة أو إعداد آخر للآلة سيفيد. الهدف هو تقليل الوقت على عمل تجاوزته الأحداث، لا الوعد بالعثور على كتلة. التأخير المنخفض لا يغيّر عشوائية التعدين ولا قواعد الصلاحية. [1] [2] [3]