Underclocking

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

لنتخيل أن الشريحة تنفذ خطوات عمل أقل في الثانية. قد تنخفض الطاقة المرتبطة بعمليات التبديل داخلها. تبسّط Braiins العلاقة إلى ⁦W = a × F × V²⁩: ترمز ⁦W⁩ هنا إلى القدرة المستهلكة بالواط، و⁦F⁩ إلى التردد، و⁦V⁩ إلى الجهد. أما ⁦a⁩ فهو معامل في النموذج. وتدخل قيمة الجهد في هذه العلاقة بعد تربيعها. هذا تفسير للعلاقة، وليس حسابًا دقيقًا لاستهلاك منظومة التعدين كاملة. فالمراوح تستهلك كهرباء أيضًا، وتوجد خسائر في مزود الطاقة. لذلك لا يستطيع بول استنتاج فاتورة دقيقة من إعداد التردد وحده. [1] [7]

لنأخذ مثالًا توضيحيًا من إعدادنا: ⁦2000 W / 100 TH/s = 20 J/TH⁩. بعد التغيير نقيس ⁦1200 W / 50 TH/s = 24 J/TH⁩. تعني ⁦TH/s⁩ تيراهاش في الثانية، أي تريليونات محاولات الهاش في الثانية. وتعني ⁦J/TH⁩ جول لكل تيراهاش: الطاقة اللازمة لتريليون محاولة من هذه المحاولات. انخفضت القدرة المستهلكة بمقدار 40%، لكن الوضع الجديد يحتاج إلى طاقة أكثر بمقدار 20% للعدد نفسه من المحاولات. قد يفيد تخفيف حمل الدائرة الكهربائية رغم تراجع كفاءة الطاقة. هذه أرقام تعليمية وليست إعدادات موصى بها لجهاز بعينه. يحتاج بول إلى قياس الاستهلاك والعمل المنجز معًا. [1] [5] [6] [7]

الاستجابة الفورية عند تعديل الإعداد تؤكد استلام التعليمة، لا بلوغ الهدف بالضرورة. تصف LuxOS انتقالًا تدريجيًا عند استخدام frequencyset. يمكن التحقق من التردد الحالي عبر frequencyget، أو معرفة استمرار الانتقال بواسطة IsRamping. كما أن S9 لا يدعم إلا درجات تردد محددة. لذلك يعرض حقل Frequency في الرد أقرب هدف مدعوم، وقد لا يساوي الرقم المطلوب تمامًا. وحتى هذا الهدف لا يثبت وحده أن الشرائح تعمل عليه بالفعل. [2]

ليس على بول بدء كل تغيير يدويًا. تستخدم LuxOS نظام ATM، أي Advanced Thermal Management، لتنظيم التشغيل حسب الحرارة. يمكنه خفض التردد عند السخونة ورفعه مجددًا ضمن الحدود المسموحة بعد التبريد. يجب أن تسمح جميع مدخلات الحرارة المتاحة بالزيادة، لا مجرد لوحة أكثر برودة. بحسب العتاد، تشمل المدخلات حرارة الشرائح وحرارة الماء الداخل في الأجهزة المبردة بالماء. الفكرة بسيطة: برودة مكوّن واحد لا تعني أن الجهاز كله بلغ حرارة آمنة. [3]

لا يضمن Underclocking تشغيلًا متواصلًا مهما ساء التبريد. في LuxOS، يحدد Minimum Profile أدنى ملف مسموح لنظام ATM، بينما يضع power_min الحد الأدنى في وضع استهداف القدرة. إذا رفع بول هذا الحد أكثر من اللازم واستمر ارتفاع الحرارة، فلن يبقى مجال لمزيد من الخفض. عندئذ قد يوقف البرنامج الجهاز. الحد الأدنى ليس وعدًا بأن الجهاز سيواصل إنتاج هذا القدر في كل الظروف؛ الحماية الحرارية تسبق الأداء المطلوب. [3]

تستخدم Braiins نظام DPS، أي Dynamic Performance Scaling، لتغيير أهداف القدرة أو hashrate وفق الظروف. Hashrate هو عدد محاولات الهاش في الثانية. تعتمد العودة إلى مستوى أعلى على الإصدار والوضع والشروط الزمنية. تراعي DPS Memory استجابات الجهاز السابقة لمنع التبديل السريع ذهابًا وإيابًا. لذلك لا يعني انخفاض أداء ASIC تلقائيًا وجود عطل، حتى إذا عرضت الواجهة ملفًا أعلى. يفحص بول الحرارة والسجلات أولًا لمعرفة السبب. تعطيل الحماية لمجرد رفع الرقم لا يعالج ذلك السبب. [4]

يمكن أن يبقي Underclocking التعدين نشطًا ولكن بوتيرة أبطأ. تعليق الحسابات بالكامل حالة مختلفة، ولا يعني بالضرورة استهلاكًا صفريًا؛ فقد يستمر التحكم أو التبريد في طلب الكهرباء. يقارن بول فترات متساوية بظروف حرارية متشابهة، وقدرة المنظومة كلها عند المقبس، والأخطاء، والعمل الذي يقبله مجمع التعدين، وهو خدمة تنسق بين المعدّنين. تقدير البرنامج ليس قياسًا مستقلًا. تكشف هذه البيانات مجتمعة هل تحقق الهدف. الإبطاء وحده لا يعد بتوفير أو عمر أطول أو ربح. [1] [5]