Tôi cho rằng bất kỳ hướng dẫn khai thác Rx Vega nào tốt cần phải thảo luận và đánh giá một cách khách quan về các tùy chọn phần mềm khai thác Vega nổi bật…. cả hai đều có lượng người theo dõi trung thành trong cộng đồng Vega Mining. Điều này sẽ đưa ra một đánh giá trung thực và khách quan. Bắt đầu!
(Lưu ý:Tôi không biết ai sẽ là người chiến thắng khi tôi viết phần giới thiệu này… Hãy xem điều này diễn ra như thế nào)

Kẻ phản đối

Ở Góc số 1 - CastXMR ver 0.7 (Lưu ý:ver 0.8.1 hiện đã ra mắt, không chắc về delta hiệu suất)
Công ty tự xưng là “Người khai thác nhanh nhất cho dòng GPU AMD Radeon RX Vega”. CastXMR là phần mềm mã nguồn đóng và có phí phát triển là 1,5%.

Ở Góc số 2 - XMR-STAK phiên bản 2.0.0. (Lưu ý:phiên bản 2.2.0 hiện đã ra mắt, + 40 giờ / giây trên phiên bản 64)
XMR-STAK không có tính năng điều chỉnh nội bộ đặc biệt cho GPU Vega nhưng cung cấp các tùy chọn tệp cấu hình cho phép tự điều chỉnh. Một số cấu hình luồng kép đã trở thành khá chuẩn đến nỗi tôi nghĩ rằng thật công bằng khi gọi nó là “Vega đã được điều chỉnh” theo quan điểm của so sánh này. XMR-Stak là mã nguồn mở và có phí phát triển mặc định là 2% (cao hơn 0,5%).

Thảo luận về Bias:

Dưới đây là sự thật về thành kiến ​​của tôi khi đi vào điều này… Tôi đã thử với cả hai chương trình khi lần đầu tiên thiết lập công cụ khai thác của mình. Tôi nghĩ rằng hầu hết sẽ đồng ý rằng CastXMR thân thiện hơn một chút với người dùng noob ở chỗ lệnh bắt đầu là một dòng duy nhất và phần điều chỉnh được tích hợp sẵn trong phần mềm. Tôi là một noob, người cũng sẵn sàng chỉnh sửa vì vậy trọng tâm ban đầu của tôi chủ yếu là các tính năng và hiệu suất. Kết quả ban đầu của tôi mang lại một lợi ích hiệu suất nhỏ đáng kể cho xmr-stak nhưng yếu tố quyết định thực sự đối với tôi là giao diện web. Ban đầu tôi đã giải quyết một số vấn đề về hash drop với cả hai chương trình và đánh giá cao xmr-stak cho phép tôi nhanh chóng kiểm tra trạng thái thợ đào trên điện thoại của mình…. người ta có thể gọi nó là một cơn nghiện :-). Dù sao, như nhiều người trong số các bạn đã biết, ngoài việc hash drop đối với tôi bây giờ hiếm khi xảy ra hơn, đã có hai thay đổi lớn kể từ những ngày "đầu tiên" đó:

1. JJs_HashMonitor làm cho băm Vega không thường xuyên giảm xuống không đều. Việc có một giao diện web được định dạng tốt ít quan trọng hơn vì màn hình tự phát hiện sự sụt giảm hàm băm và đặt lại các công cụ khai thác về tốc độ tối đa. Đáng kinh ngạc! (Tôi hy vọng bạn có tất cả mách nước cho JJ để lưu số băm của bạn!).
2. CastXMR phiên bản mới ngày 11/29 đã thêm khả năng giám sát từ xa (Woot!). Mặc dù JJs_HashMonitor chưa được định cấu hình để hỗ trợ CastXMR… điều đó chỉ đơn giản là một ngã ba và do đó tôi sẵn sàng gieo nó như một khả năng hiện có cho mục đích so sánh này.

Tôi không quan tâm đến một trong hai phần mềm nên công bằng mà nói đây là một đánh giá trung thực vì với (1) và (2) ở trên, tôi không biết động cơ của mình cho sự thiên vị là gì. Giống như những người khác, tôi chỉ đang cố gắng tìm ra phần mềm hiệu quả nhất cho hệ thống của mình.

Trước khi đi xa hơn, tôi cũng muốn nói rằng tôi khuyên bạn nên xem bài đăng này như một hướng dẫn về phương pháp bạn có thể sử dụng để đánh giá hiệu suất cho thiết bị cụ thể của mình . Mỗi giàn đều khác nhau. Phân tích dưới đây sẽ thảo luận về phương pháp của tôi và các con số của tôi… Sẽ không còn thiếu sót khi đưa ra bất kỳ đề xuất nào vì như mọi khi… YMMV.

Thảo luận về các giá trị được báo cáo của CastXMR:

Tôi phải bắt đầu bằng một cuộc thảo luận về một số điểm bất thường liên quan đến thác nước tỷ lệ băm cuộn trên màn hình CastXMR. Các số liệu dưới đây là từ một phiên khai thác Monero bắt đầu lúc 9:55 tối. Tôi để chương trình chạy không bị cản trở trong khoảng 15 phút để đảm bảo mọi thứ đã ổn định và sau đó chụp ảnh màn hình.

Khi nó đang chạy, một số con số khá đẹp được hiển thị, điều này rõ ràng góp phần vào danh tiếng rực rỡ của CastXMR. Vega 64 của tôi (không phục vụ màn hình) là GPU 0, trong Hình 1, hiển thị các số 2020,9, 2018,6, 2012,9, 2013,5 và 2013,1 h / s.

2020 h / s chắc chắn bật ra rất ấn tượng khi xét đến tốc độ ổn định của năm 2002 mà tôi thấy khi tôi khai thác Monero bằng xmr-stak. Mức trung bình của những con số đó thấp hơn một chút 2015.8h / s nhưng vẫn rất ấn tượng. Điểm một cho CastXMR… nhưng hãy đợi đã… Vấn đề sẽ xuất hiện trong hình tiếp theo. Khi bạn nhập “s” để nhận báo cáo băm từ castXMR, bạn nhận được như sau:

Tỷ lệ băm trung bình cho GPU 0 là 1994,6?!?!. Làm thế nào có thể được vì tôi đã xem màn hình lướt qua và không có trường hợp nào khi giá trị GPU0 thấp hơn khi đó là 1994,6 h / s, chưa nói đến đủ thấp để ghép nối với 2020,9 h / s để tạo ra mức trung bình là 1994,6 h /S. Mức trung bình đó (1994,6) thấp hơn toàn bộ 20h / s so với mức trung bình mà chúng tôi tính được từ Hình 1 (2015,8). Tò mò. Có lẽ khó hiểu hơn là ngay sau báo cáo tóm tắt đó, nó lại quay trở lại công việc kinh doanh hiển thị những con số hấp dẫn như 2029,4 h / s. Xmr-stak và đó là năm 2002 giờ / giây không thể cạnh tranh với 2029,4 giờ / giây… nhưng so sánh khá thuận lợi với năm 1994,6 giờ / giây. Đó là cái nào?

Coi rằng mức trung bình của 5 GPU được tính từ cuối hình 2 là (2029,4 + 1930,0 + 1931,0 + 1944,7 + 1958,5) / 5 =1958,7 h / s. Ngược lại, mức trung bình được báo cáo trong “báo cáo được chấp nhận chia sẻ” màu lục lam ngay trên nó là 1935,1 h / s khiêm tốn hơn. Tôi thực sự không biết phải tạo ra những con số không trung bình nên tôi bỏ qua chúng…

Những con số trên không phải là anh đào được chọn… Đây là những hình ảnh điển hình của hiệu suất castXMR trên máy của tôi và nó khiến tôi phải vò đầu bứt tai một chút. Tôi không nghi ngờ có bất kỳ trò chơi xấu nào ở đây. Tôi nghi ngờ con số là từ tính toán thực nhưng có thể không đại diện cho giá trị mà chúng tôi giả định là chúng. Có lẽ chúng hiển thị hàm băm nhanh nhất tuyệt đối được tính trong khoảng thời gian hiển thị… và giá trị trung bình được cung cấp “s” là tỷ lệ băm trung bình thực sự trong một khoảng thời gian nào đó? Thật sự rất khó để biết nhưng có một điều chắc chắn là… castXMR có tiếng là “nhanh”. Trên thực tế, nó có thể nhanh hơn… chúng tôi sẽ không biết cho đến khi chúng tôi đi đến cuối bài đăng này, nhưng bất kể trường hợp nào, nó không NHANH CHÓNG như danh tiếng được phát triển bởi số lượng cuộn trên màn hình sẽ gợi ý. Tập trung vào các giá trị trung bình được hiển thị trong báo cáo tóm tắt (“s”) và trong báo cáo định kỳ xảy ra khi “chia sẻ được chấp nhận” được báo cáo.

Được rồi, bây giờ chúng ta hãy bắt đầu…

Sân chơi

Tôi có 5 Vegas. Hai chiếc Vega 64 và 3 chiếc Vega 56’s. Một Vega 64 (GPU 3 / Luồng 6 &7) cung cấp một dongle HDMI nên hiệu suất của nó không đáp ứng được hiệu suất của Vega 64 khác (GPU 0 / Luồng 0/1). Vega Miner được thiết lập theo hướng dẫn đã xuất bản với ba ngoại lệ / làm rõ sau:

• Hầu hết hướng dẫn được viết khi người khai thác của tôi có 4 chiếc Vega và 1 chiếc Nvidia GTX 750. Tôi giải thích trong hướng dẫn rằng tôi đã mua một chiếc Rx Vega 56 khác để thay thế GTX-750… và tôi đã bổ sung những gì tôi đã học được từ đó kinh nghiệm để hướng dẫn. Một số bạn có thể đã không đọc nó kể từ đó, vì vậy tôi muốn lặp lại nó cho rõ ràng.
• Trong hướng dẫn (và khi khai thác trong đời thực), tôi thực hiện khai thác CPU song song với Khai thác Vega. Vì CastXMR không đi kèm với trình khai thác CPU nên tôi không khai thác xmr-stak với CPU trong quá trình thử nghiệm này (hóa ra nó không tạo ra sự khác biệt nhưng tôi không chắc chắn)
• Trong hướng dẫn, tôi đề nghị những người có màn hình / thiết bị bảo vệ được gắn vào khai thác của Vega sử dụng cường độ 1800 trên cả hai luồng của Vega cụ thể đó để có được sự ổn định .. và sau đó làm việc từ đó (so với tiêu chuẩn của tôi 1932/1932) . Hệ thống GPU3 của tôi là Rx Vega 64 phục vụ dongle HDMI của tôi và nó ổn định với cường độ 1908 và 1800. Đó là những giá trị bạn sẽ thấy trên GPU 3 (luồng 6 + 7) khi xmr-stak đang khai thác.

Quy trình kiểm tra:

1. Khởi động lại máy tính.
2. Đã đăng nhập qua Chrome Remote Desktop
3. Khởi động JJ’s Hash Monitor để nó sẽ khởi động lại Vega của tôi và áp dụng các thông số OverdriveNTool của tôi (một lần nữa, các thông số chính xác từ hướng dẫn)
4. JJs_HashMonitor đã đóng và công cụ khai thác được liên kết
5. Đã mở trình quản lý tệp Windows
6. Nhấp đúp vào tệp cmd để gửi cho trình khai thác các lệnh mà nó cần để bắt đầu
   • cast_xmr đã bao gồm cờ –remoteaccess
   • xmr-stak bao gồm cờ –noCPU và –noNVIDIA
7. Sau khi trình khai thác được khởi động, tôi đã đóng cửa sổ quản lý tệp để mở cửa sổ duy nhất là cửa sổ khai thác và không có gì khác.
8. Tôi đã kết thúc phiên Chrome Remote Desktop
9. Tôi đã lấy tất cả các giá trị từ một máy tính riêng trong mạng của mình qua giao diện web
   • Lưu ý rằng castXMR không hiển thị các giá trị ở định dạng web đẹp mắt nhưng dữ liệu ở đó và có thể truy cập được nên đây dường như là cách tốt nhất để có được hiệu suất "máy tính không đầu".

Điều tôi không làm được:Tôi đã không sử dụng JJs Hash Monitor trong quá trình thử nghiệm (vì tôi không muốn đặt lại Vega's giữa các lần thử nghiệm. Vì vậy, tôi đã không đặt lại Vega's giữa hai phiên khai thác Monero. Tôi đã không đăng ký lại OverdriveNTool tham số giữa hai phiên.

Kết quả

Kết quả chính thức sẽ dựa trên tỷ lệ băm hiệu quả trung bình. Tỷ lệ băm hiệu quả được tính bằng cách lấy tỷ lệ băm trung bình của phần mềm khai thác đã báo cáo và khử xếp hạng theo tỷ lệ cổ phiếu bị từ chối. (Ví dụ:trong 20 phút chạy được trình bày trong Hình 2 ở trên, CastXMR đã báo cáo năng suất 95%). Cả hai công cụ khai thác đều được trỏ vào pool.supportXMR:7777 (thời gian ping trung bình =15ms).

Kết quả CastXMR

CastXMR đã chạy khoảng 30 phút trước khi tôi thăm dò ý kiến ​​trên giao diện web và chụp Hình 3:

Vì vậy, CastXMR hiển thị tốc độ trung bình ban đầu là 9809 h / s nhưng với 3,2% cổ phiếu bị từ chối và phí phát triển 1,5%, tỷ lệ băm hiệu quả thu được là 9809 x 96,8% x 98,5% = năng suất 9353,7 h / s
Lưu ý: Mặc dù giao diện web không cung cấp lý do từ chối ngoài “num_outdated”, việc quan sát quá trình chạy trước (Hình 2 ở trên) có thể khiến các lượt chia sẻ bị từ chối vì:“Đã lỗi thời vì thay đổi công việc”. Mặc dù điều này có vẻ giống như một vấn đề chung so với một vấn đề phần mềm khai thác, nhưng thực tế là tôi thường xuyên sử dụng xmr-stak với supportxmr và không bị từ chối như vậy… nhưng chúng xảy ra mỗi khi tôi chạy cast_xmr. Tôi kết luận rằng đó là do xử lý công việc phần mềm và vì tôi biết không có nút thắt nào nên tôi có thể xoay w.r.t. đối với vấn đề này, tôi chỉ cần so sánh nó với nó thông qua "tỷ lệ băm hiệu quả".

Kết quả XMR-Stak:

Xmr-stak chạy khoảng 30 phút trước khi tôi thăm dò ý kiến ​​trên giao diện web và chụp Hình 4 và 5:

Vì vậy, XMR-stak có tốc độ trung bình ban đầu là 9734,7 h / s nhưng với năng suất 100%, tốc độ băm hiệu quả vẫn đạt năng suất đầy đủ là 9734,7 h / s. XMR-Stak đi kèm với phí phát triển mặc định 2%, do đó, năng suất hiệu quả giảm xuống còn 9540 h / s .

Kết luận

Nó đã được chứng minh rằng các giá trị tỷ lệ băm hiển thị trên thác nước của các con số trong màn hình CastXMR sẽ bị bỏ qua để thay thế cho mức trung bình được báo cáo của CastXMR.

XMR-stak báo cáo tốc độ băm trung bình là 99,2% tốc độ băm được CastXMR báo cáo (khoảng 15 giờ / s trên mỗi Vega). Tuy nhiên, khi so sánh lợi suất hiệu quả sau khi tính đến cổ phiếu bị mất và chênh lệch phí phát triển, lợi suất XMR-stak tốt hơn CastXMR 2%. Đó là sự cải thiện khoảng 185 h / s so với XMR-stak (lưới khoảng 35 h / s mỗi Vega).

Kiểm tra độ bền

Tôi lo ngại rằng có lẽ khoảng thời gian thử nghiệm ngắn của mình đã khiến CastXMR không công bằng nên tôi đã chạy thử nghiệm kéo dài 8 giờ / ngày để xem liệu số lượng cổ phiếu “Lỗi thời” có được giải quyết hay không. Thật không may, sản lượng vẫn tương tự (kém hơn một chút).

Đã có 1082 cổ phiếu được gửi trong thời gian thử nghiệm kéo dài và Hình 6 cho thấy 41 cổ phiếu bị từ chối là “lỗi thời” (3,9% Lãng phí). CastXMR dường như đạt mức trung bình 9813,8 giờ / giây nhưng khi tính đến cổ phiếu bị mất và phí phát triển, năng suất hiệu quả giảm xuống còn 9289,6 giờ / giây…. năng suất đã hiệu chỉnh cho thấy rằng stak-xmr một lần nữa đánh bại CastXMR. Lợi nhuận 2,7% ủng hộ stak-xmr dẫn đến 250 giờ / giây trên hệ thống 5 Vega của tôi… ~ 50 giờ / giây mỗi Vega.

Hình 6:CastXMR đã mất 3,9% nỗ lực để chia sẻ "Đã lỗi thời" trong bài kiểm tra độ bền 8,3 giờ

Có lẽ cần phải nhắc lại những gì tôi đã nói ở trên… Tôi khuyên bạn nên xem bài đăng này như một hướng dẫn về phương pháp bạn có thể sử dụng để đánh giá hiệu suất cho thiết bị cụ thể của bạn . Mỗi giàn đều khác nhau. Phân tích là một cuộc thảo luận về phương pháp của tôi và những con số của tôi… YMMV.

Cảm ơn tất cả những người mắc kẹt với con số này đã đăng đầy đủ bài phân tích cho đến tận cùng. Không hẳn là một công cụ lật trang nhưng hy vọng bạn thấy nó công bằng, khách quan và hữu ích. Vui lòng chuyển điều này cho bất kỳ ai đang tranh luận về ưu và nhược điểm của các phần mềm khai thác khác nhau!