Autotuning

⁦ASIC⁩ شريحة متخصصة في حسابات التعدين. توضح ⁦Braiins⁩ أن فروقًا صغيرة تنشأ أثناء التصنيع، ثم تؤثر حالة الشريحة وحرارتها في التشغيل أيضًا. لذلك يستطيع ⁦Mining Firmware⁩، أي البرنامج الذي يدير الجهاز، اختبار الشرائح منفردة. يحدد التردد وتيرة العمل، ويؤثر الجهد في ظروفه الكهربائية. بعض الشرائح تتحمل حملًا أكبر، وأخرى يناسبها حمل أخف. يشبه ذلك توزيع المهام وفق قدرات العاملين بدل مطالبة الجميع بالوتيرة نفسها. فلا ينبغي تعميم نتيجة جهاز تلقائيًا على جهاز آخر. [1]

قد يريد أندرو ⁦hashrate⁩ أعلى، أي محاولات تجزئة أكثر في الثانية، أو طاقة أقل للعمل نفسه، تُعبّر عنها ⁦J/TH⁩ (جول لكل تيراهاش، أي الطاقة اللازمة لتريليون محاولة هاش). وقد يحتاج إلى الالتزام بالقدرة الكهربائية المتاحة في موقعه. هذه أهداف مختلفة. تضبط ⁦Braiins⁩ الجهاز لمستوى استهلاك مختار، بينما تميز ⁦LuxOS⁩ بين القدرة المطلوبة والقيود. ⁦Autotuning⁩ ليس مرادفًا لـ⁦Overclocking⁩، أي رفع تردد التشغيل؛ إذ يمكن استخدامه مع إعداد أوفر للطاقة أيضًا. ومهما كان الهدف، تبقى حدود ⁦PSU⁩، مزوّد الطاقة، والتبريد والدائرة الكهربائية سارية. [1] [5] [6]

يختبر البرنامج أولًا ما تتحمله الشرائح، ولذلك ليست السرعة المؤقتة هي النتيجة النهائية. تذكر ⁦Braiins⁩ في إجابات الأسئلة الشائعة (⁦FAQ⁩) أن المدة تعتمد على الطراز ولوحة التحكم وقد تصل إلى عدة ساعات. تعني ⁦Stable⁩ أن الضبط استقر في ذلك النمط، لا وعدًا بتشغيل خالٍ من المشكلات إلى الأبد. ويتحقق أندرو من لوحات الحساب منفردة أيضًا: فقد تعكس حالة ⁦disabled⁩ (متوقف) الإجمالية لوحة واحدة معطلة أو متوقفة، بينما تكون اللوحات الأخرى مستقرة. لذلك تُقرأ علامة الحالة مع بيانات المكونات، لا بمفردها. [2]

يعرض ⁦Braiins FAQ⁩ مثال ⁦S19⁩ بهدف ⁦3000 W⁩ مع لوحة حساب واحدة فقط تعمل. يخصص التوزيع المبني على اللوحات الثلاث المتوقعة ⁦1000 W⁩ لتلك اللوحة. وهذا لا يعني أن الضبط يجب أن ينقل كامل ⁦3000 W⁩ إلى اللوحة المتبقية. غياب العتاد يغير قدرة التجميعة كلها. لذلك لا يعد أندرو انخفاض الاستهلاك تلقائيًا عطلًا في الضبط، ولا يحاول تعويض الأداء المفقود متجاهلًا الحدود. حدود اللوحة و⁦PSU⁩ والدائرة الكهربائية ما زالت قائمة. [2]

تميز ⁦Braiins⁩ بين الملف التقليدي المحفوظ و⁦Continuous Tuning⁩، الذي يحمل وصف ⁦beta⁩ عند هذه المراجعة. يحتوي الملف على جهود وترددات مختارة. ويمكن لـ⁦DPS⁩، أو ⁦Dynamic Performance Scaling⁩، الانتقال بين مستويات القدرة، لكن الانتقال وحده لا يعيد ضبط الملف الأصلي لحرارة جديدة. أما الضبط المستمر فيواصل تعديل الإعدادات وفق الظروف. وفي هذا النمط تتقدم السلامة الحرارية على هدف الأداء. إذن كلمة تلقائي لا تخبر أندرو وحدها إن كان البرنامج يبحث عن إعدادات جديدة أم يستخدم إعدادات محفوظة. [3]

لـ⁦LuxOS AutoTuner⁩ حدود خاصة به. فهو لا يعدل ⁦custom profiles⁩، أي الملفات المخصصة التي يحدد المستخدم فيها التردد والجهد صراحة، لأنه اختار تلك التركيبة بنفسه. ولا يعمل ⁦power targeting⁩، التحكم بحسب الاستهلاك المستهدف، بالتزامن مع الضبط القائم على الملفات. وعندما يكون ⁦power targeting⁩ نشطًا، لا تتاح أيضًا أوامر التردد والجهد اليدوية. لذلك لا يستطيع أندرو افتراض أن تعليمات برنامج آخر أو تجربته معه تنطبق هنا. النمط النشط ودعم الطراز المحدد هما ما يحددان السلوك. [4]

يميز أمر ⁦LuxOS powertargetset⁩ بين ⁦power_target⁩، الاستهلاك المطلوب، و⁦power_limit⁩، الحد الأعلى، و⁦power_min⁩، الحد الأدنى للتنظيم. أما المعامل الأقدم ⁦power⁩ فيضبط الهدف والسقف معًا. لذلك لا يعني تغيير الهدف بالضرورة تغيير كل القيود. يشبه الأمر سرعة مختارة ونطاقًا مسموحًا: هما مرتبطان لكنهما مختلفان. تساعد الأسماء في قراءة الوثائق، ولا يحتاج المبتدئ إلى تنفيذ أوامر لفهم الفرق. والإعداد النشط نفسه تعليمات للبرنامج، وليس قياسًا دقيقًا لاستهلاك الجهاز كاملًا من المقبس. [5]

في الحساب التالي، ترمز ⁦W⁩ إلى القدرة المستهلكة بالواط، وترمز ⁦TH/s⁩ إلى عدد التيراهاش في الثانية. لنأخذ نموذجًا توضيحيًا بسيطًا: ⁦3000 W / 100 TH/s = 30 J/TH⁩. بعد التغيير يصبح ⁦2700 W / 90 TH/s = 30 J/TH⁩. انخفض الاستهلاك ومحاولات الثانية بالنسبة نفسها، فلم تتغير الكفاءة. قد تكون الفاتورة الأقل مرغوبة، لكن العمل الحسابي نفسه ما زال يتطلب الطاقة نفسها. يقارن أندرو النتائج في ظروف حرارية متقاربة ويقيس مكوّنات الجهاز نفسها في كل مرة. ويتحقق أيضًا من العمل الذي يقبله المجمّع، وهو خدمة تجمع العمل الحسابي للمعدّنين. فتقدير السرعة الذي يعرضه الجهاز وحده لا يكفي. لا يضمن ⁦Autotuning⁩ ولا ⁦Stable⁩ توفيرًا أو ربحًا؛ فالنتائج المقاسة والأخطاء ووقت التشغيل الفعلي هي الفيصل. [2] [4] [7]