嗯~ WU來自assign server, 換不同assign server 是可能拿到不同WU

至於為什麼換IP後可能會換到不同WU, 除了相同assign server可能給出不同任務之外,

另一個可能就是你移到了不同的assign server. 為什麼會有這種現象? 小弟野人獻曝

講一下server load balance 的作法, 通常巨量的網路存取, 已經遠超過一台主機的負荷量

管理者會考慮使用負載平衡器來對多台主機做資源分配, 像F@H這種全球性的計畫, 伺服器

少說都是幾十台在跑, 負載平衡設備你不見得能ping得到它或看得到它,但是它可以針對不同

的server loading 狀態分配不同的主機給client去使用. 怎麼分配client的的演算法有很多

種, round robin/weighted round robin/hash(source&destination IP)

session sticky, cookie...etc. 當存取端的資料有變化的時候, server load balancer就可能會有

新的決定, 例如你換新的IP, SLB若使用來源與目的IP為參數來分配assign server給你,

那換IP就可能觸發新的演算結果, 讓你連上新的伺服器,拿新的WU. 這個IP是指public IP.

如果你使用分享器的, NAT出去的public IP永遠是WAN IP, 你可能網卡的IP換過好幾次

也發現完全沒有換WU的作用,那也是很正常的.


由於史丹佛的WU不是在同一時間僅有一種WU, 所以嘗試換新WU, 自然是有可能取得不同

的任務. 不過, 這也是基於嘗試而得到的現象解讀, 基本上個人還是認為成員無法直接控制

所取得的WU. 只是可以換, 多換幾次的確有較高機率換到不同的/想要的WU.

不過,稍微OK的顯卡一天都算好幾個WU去了, 算到中途切掉也很可惜. 大家就自己決定吧~

測試環境OS：XP PRO ,驅動：185.20 ,F@H:V6.23 tray,兩張9800gx2
測試時間：台北時間2009年03月17日 02:00 - 2009年03月18日 02:00
全程未關機，未刪work資料夾，未重起程式。

GPU0
捷徑："C:\Program Files\Folding@home\Folding@home-gpu\Folding@home.exe" -gpu 0 -verbosity 9 -forcegpu ati_r600 -advmethods
cfg extra_parms：空白
LOG:http://shinnshinn.myweb.hinet.net/F...180200_GPU0.TXT

GPU1
捷徑"C:\Program Files\Folding@home\Folding@home-gpu\Folding@home.exe" -gpu 1 -verbosity 9 -forcegpu nvdia_g80 -advmethods
cfg extra_parms：空白
LOG:http://shinnshinn.myweb.hinet.net/F...180200_GPU1.TXT

GPU2
捷徑："C:\Program Files\Folding@home\Folding@home-gpu\Folding@home.exe" -gpu 2 -verbosity 9 -forcegpu ati_r600
cfg extra_parms：空白
LOG:http://shinnshinn.myweb.hinet.net/F...180200_GPU2.TXT

GPU3
捷徑："C:\Program Files\Folding@home\Folding@home-gpu\Folding@home.exe" -gpu 3 -verbosity 9 -forcegpu nvdia_g80
cfg extra_parms：空白
LOG:http://shinnshinn.myweb.hinet.net/F...180200_GPU3.TXT


結果除了測試一開始未算完的wu590*之外，
24小時內4個G92，一個wu590*都沒收到，47**收了一堆。
續下篇.

隔了幾分鐘更變設定各GPU設定，重新啟動F@H程式
測試時間：台北時間2009年03月18日 02:22 - 2009年03月19日 02:22
全程未關機，未刪work資料夾，未重起程式。

GPU0
捷徑："C:\Program Files\Folding@home\Folding@home-gpu\Folding@home.exe" -gpu 0 -verbosity 9 -forcegpu nvdia_g80 -advmethods
cfg extra_parms：-gpu 0 -verbosity 9 -forcegpu nvdia_g80 -advmethods
LOG:http://shinnshinn.myweb.hinet.net/F...190222_GPU0.TXT

GPU1
捷徑："C:\Program Files\Folding@home\Folding@home-gpu\Folding@home.exe" -gpu 1 -verbosity 9 -forcegpu nvdia_g80 -advmethods
cfg extra_parms：-gpu 1 -verbosity 9 -forcegpu nvdia_g80 -advmethods
LOG:http://shinnshinn.myweb.hinet.net/F...190222_GPU1.TXT

GPU2
捷徑："C:\Program Files\Folding@home\Folding@home-gpu\Folding@home.exe" -gpu 2 -verbosity 9 -forcegpu nvdia_g80 -advmethods
cfg extra_parms：-gpu 2 -verbosity 9 -forcegpu nvdia_g80 -advmethods
LOG:http://shinnshinn.myweb.hinet.net/F...190222_GPU2.TXT

GPU3
捷徑："C:\Program Files\Folding@home\Folding@home-gpu\Folding@home.exe" -gpu 3 -verbosity 9 -forcegpu nvdia_g80 -advmethods
cfg extra_parms：-gpu 3 -verbosity 9 -forcegpu nvdia_g80 -advmethods
LOG:http://shinnshinn.myweb.hinet.net/F...190222_GPU3.TXT


除了一開始未算完的wu47**，
之後連續24小時一個wu47**都沒收到，
wu590*收了一堆..

從上面的log以及前兩篇的log以我的認知對assign server 發wu的程序分成兩階段 ，
client先連到http://assign-GPU.stanford.edu:8080/
驗證client 的類型，
接下來client會收到指令連線到下面三台(可能更多)其中之一的主機接收wu，
http://171.64.65.102:8080/ (發57**)
http://171.64.65.103:8080/ (發47**)
http://171.64.65.70:8080/ (發59**)

client 的類型在現階段我認為是可以藉由人為改變的，
至於怎麼用什麼機制改變，我不清楚。
我的目的呈現這個事實給大家，進而討論倒出結果
讓大家想跑59**就跑59**，想跑其他就跑其他的。
有的人擔心電流的問題，有的人擔心溫度的問題，讓大家可以各取所需，如此而已。

現在學乖了

有空就給他PAUSE幾小時...

休息是為了走更遠的路

我根本不管他, 操到死 !

這就是終保的終極用途啊~

雖然很謝謝SHINN兄花時間嘗試
我也看得出來cfg有無設參數，在你電腦上的確可以影響是否收到WU59xx

但是在我電腦上就是不動聲色，Stanford已經把我的IP綁給http://171.64.65.70:8080/ (發59**)的樣子

嗯~ 這個官網的聯結可以看到F@H server list :

http://fah-web.stanford.edu/serverstat.html

assign server 的確是有辨識client端的作用, 從上表也可以看出這數十台server各有不同任務

有的給SMP, 有的給GPU, 有的給PS3....etc.

WU就像是水果, 可能當季盛產的某幾種比較多, 有幾個攤位(伺服器)比較常買得到(下得到)

不過, 是不是某個攤位只能賣出一種水果, 這就要多加長時間驗證.

在這一點上,個人持非常保守的態度. 我自己不同台跑分機都是連不同的伺服器, 但我印象中

每一台什麼WU都跑過, 不限於雷WU, 就如同Zuchen兄的狀態, 總是連到某一台伺服器.

單機的PPD日產卻一陣陣的有高也有低. 故推論單台伺服器上存放有多種WU.


至於回過頭來看各個參數的意義:

-gpu 0 :單機多核下, 指定核心

-verbosity 9 :紀錄詳細log

-forcegpu nvdia_g80 :通用辨識nvidia G80以上 GPU

這三個參數顯然是跟WU沒有關聯. 原本就已經存在的, 那就剩下最近的 -advmethods :

這個參數最早(一年前)出現在ATi beta test 的討論串.

近期官網forum上面關於advmethods 的user comment:

-advmethods has nothing to do with the size of the WU's. What it does is give a preference to WU's that are late-beta (After the beta test, but before general release).

另一位:

All non-advmethods projects (regardless of size) were once advmethods projects, and all advmethods projects become standard projects unless they are withdrawn due to some problem.

So....有無 advmethods 參數也不會改變是否會接到特定WU. 最終都會是標準任務.


當assign server辨識出大的分類(SMP/CPU/GPU/PS3)之後, 任務包應該就是無差別執行.

而辨識的方法, 應不是靠client上的參數, 而是靠client本身. 上面那四大分類都是使用不同client.

server上有什麼WU就丟什麼出來給client. client中參數的影響則沒有看到很solid的證據.

雖然說穿了我也不知道真相是什麼, 只能旁敲側擊的去分析與大家分享討論而已.


回歸實務面, 因為取消WU進行refresh 重拿,的確是有可能因而拿到不同種任務,

如果試得很有效, 那就很恭喜嘍, 至於能不能長期有效....可能只有時間可以給出答案.

總之, 大家測試辛苦啦~ 目前連續破百萬日產 可要持續下去啊~ 今年目標是150萬 PPD.

其實59XX 系列我還真的跑很開心
因為ppd差不多就是之前各wu的平均
但是耗電量跟溫度就差很多了
縱使他電流高高低低..
壞掉是沒在怕..反正手邊隨時準備一張備份卡
保固內就別客氣操下去吧...XD