[SoB] hitparade van 9 maart

[Cpt00kirk]

Of de problemen bij AnandTech te maken hebben met de Java problemen of dat de ondersteuning tot 9 maart duurde? 1 ding is zeker we pakken ze al het gehele weekend en dat heerlijk!!

Als nu ook nog de Stampede hier komt dan kunnen we voor de #1 overall gaan!

oke oke .. .hierbij de cijfertjes

SoB user daily stats (9 March 2008) Flushing users: 51 / 458 = 11%
	pos	daily (k)		user	total (m)	overall	tests
1.	(1)	8.966.272.812		Team_Aggression	3.337.934.389	(1)	8
2.	(1)	6.507.073.962		DukeBox	1.339.367.187	(8)	7
3.	(3)	4.480.717.070		DeApen	270.174.355	(22)	5
4.	(3)	4.010.861.119		[DPC] Team Switch	1.077.440.837	(10)	7
5.	(1)	3.958.946.161		Grutte Pier [Wa Oars]	1.767.355.870	(6)	4
6.	(2)	2.410.219.548		[DPC]NGS	2.649.814.437	(2)	4
7.	(2)	2.187.797.789		uncureable	465.326.868	(16)	4
8.	(2)	1.943.273.234		Division Brabant	1.904.507.801	(5)	1
9.	(8)	1.773.406.380		Frederik	280.481.279	(21)	3
10.	(5)	1.305.380.946		Graasland	2.559.666.881	(4)	2
11.	(1)	1.188.330.308		SKiLLa	17.499.869	(78)	0
12.	(311)	1.004.247.974		Geessina	222.017.754	(26)	1
13.	(330)	879.887.122		mineral	25.349.113	(69)	1
14.	(120)	823.518.265		Farmill	1.158.208	(223)	1
15.	(3)	689.511.727		Joh14vers6	876.287.796	(11)	0
16.	(3)	675.123.331		Team_Elteor_Borislavj	296.418.117	(20)	0
17.	(3)	524.320.244		MOA	166.802.878	(29)	1
18.	(1)	501.227.913		Team_Kwakende_kip	159.831.281	(31)	1
19.	(328)	487.408.468		THIJS	44.285.441	(55)	1
20.	(5)	446.682.481		HappyHour	12.461.212	(98)	0
21.	(2)	362.158.359		vwasthename2	5.474.487	(139)	0
22.	(2)	324.548.035		scramble	156.535.023	(32)	2
23.	(2)	321.952.121		Dijkhuis	69.590.388	(45)	0
24.	(8)	289.877.836		Michielhaisma	24.506.731	(70)	0
25.	(3)	264.153.465		Schnautzi	350.039.982	(18)	0
26.	()	146.735.104		[DPC]Ben	537.017.112	(14)	0
27.	()	146.215.797		KurtHaegeman	751.074	(251)	0
28.	(9)	140.199.985		zoetericky	61.674.633	(47)	0
29.	(18)	119.476.290		Warmachine	377.869.677	(17)	0
30.	(17)	112.713.990		tico87	1.459.869	(210)	0
more
	total:	48.011.755	(m)
SoB user overall stats (9 March 2008)
	pos	total (m)		user	daily (k)	daily	tests
1.	()	3.337.934.389		Team_Aggression	8.966.272.812	(1)	2208
2.	()	2.649.814.437		[DPC]NGS	2.410.219.548	(6)	4202
3.	()	2.627.440.612		Los Alcoholicos	49.482.486	(40)	3157
4.	()	2.559.666.881		Graasland	1.305.380.946	(10)	1309
5.	()	1.904.507.801		Division Brabant	1.943.273.234	(8)	1742
6.	()	1.767.355.870		Grutte Pier [Wa Oars]	3.958.946.161	(5)	1987
7.	()	1.378.281.474		[DPC] Team_RC	85.447.803	(34)	2502
8.	()	1.339.367.187		DukeBox	6.507.073.962	(2)	1193
9.	()	1.104.484.620		[DPC] Team Boonanza	66.494.841	(37)	1427
10.	()	1.077.440.837		[DPC] Team Switch	4.010.861.119	(4)	1059
11.	()	876.287.796		Joh14vers6	689.511.727	(15)	1316
12.	()	828.540.098		Team Newton	0	(-)	375
13.	()	736.136.004		fsfikke	40.992.711	(42)	837
14.	()	537.017.112		[DPC]Ben	146.735.104	(26)	1004
15.	()	536.779.316		The Anarchist	0	(-)	1213
16.	()	465.326.868		uncureable	2.187.797.789	(7)	540
17.	()	377.869.677		Warmachine	119.476.290	(29)	524
18.	()	350.039.982		Schnautzi	264.153.465	(25)	132
19.	()	320.050.199		De OnTspoorde Koeien	83.244.057	(35)	269
20.	()	296.418.117		Team_Elteor_Borislavj	675.123.331	(16)	281
21.	()	280.481.279		Frederik	1.773.406.380	(9)	242
22.	()	270.174.355		DeApen	4.480.717.070	(3)	291
23.	()	256.048.427		Sparerib	0	(-)	144
24.	()	254.772.931		DPCDrastix	0	(-)	536
25.	()	246.764.144		TeamBSE	0	(-)	709
26.	()	222.017.754		Geessina	1.004.247.974	(12)	233
27.	()	197.949.783		phsmit	0	(-)	99
28.	()	174.087.664		bollewolle	0	(-)	146
29.	()	166.802.878		MOA	524.320.244	(17)	295
30.	()	163.882.035		neOx	0	(-)	312
more
	total:	31.068.065.557	(m)
SoB team daily stats (9 March 2008) Flushing teams: 86 / 530 = 16%
	pos	daily (m)		team	total (m)	overall	tests
1.	()	48.011.755		Dutch_Power_Cows	31.068.065.557	(2)	53
2.	()	45.915.271		TeamGoobee	12.911.747.982	(7)	65
3.	()	40.785.486		Anandtech	25.911.156.357	(3)	42
4.	()	27.485.464		TeamPrimeRib	36.560.900.073	(1)	35
5.	()	19.680.366		The_Knights_Who_Say_Ni!	13.329.096.967	(6)	9
6.	(1)	11.963.011		Russia	8.471.682.314	(10)	15
7.	(3)	10.518.541		Busty_Seventeen	10.339.027.379	(9)	7
8.	(2)	9.783.710		FreeDC	21.039.223.788	(4)	7
9.	(1)	8.070.029		TeamRetro	15.410.879.261	(5)	8
10.	(1)	7.707.170		TeamHaiku	6.449.474.476	(11)	8
more
	total:	282.596	(g)
SoB team overall stats (9 March 2008)
	pos	total (m)		team	daily (m)	daily	tests
1.	()	36.560.900.073		TeamPrimeRib	27.485.464	(4)	94709
2.	()	31.068.065.557		Dutch_Power_Cows	48.011.755	(1)	36701
3.	()	25.911.156.357		Anandtech	40.785.486	(3)	53316
4.	()	21.039.223.788		FreeDC	9.783.710	(8)	25915
5.	()	15.410.879.261		TeamRetro	8.070.029	(9)	36425
6.	()	13.329.096.967		The_Knights_Who_Say_Ni!	19.680.366	(5)	9229
7.	()	12.911.747.982		TeamGoobee	45.915.271	(2)	21928
8.	()	10.677.365.659		US-Distributed	3.714.906	(14)	16198
9.	()	10.339.027.379		Busty_Seventeen	10.518.541	(7)	14442
10.	()	8.471.682.314		Russia	11.963.011	(6)	12360
more
	total:	270.050.917	(g)

SoB team Last 40 days output (9 March 2008)

SoB team Last 40 days total history (9 March 2008)

SoB team Last 40 days tests history (9 March 2008)

.
SoB team When do you get them stats (9 March 2008)
Based on weekly average of 71.314.557.527 k cEMs per day
	team	day(s)	average output (k)
	TeamPrimeRib	120,04	25.556.889.399 cEMs
.
SoB team When do they get you stats (9 March 2008)
Based on weekly average of 71.314.557.526.529 k cEMs per day
	team	day(s)	average output (k)
	Anandtech	590,61	80.045.998.690 cEMs

	SoB user Milestones and targets (9 March 2008) Ordered by size
	user	milestone (k)	next target (k)
	mineral	25.000.000.000 cEMs	30.000.000.000 cEMs
	Farmill	1.000.000.000 cEMs	1.250.000.000 cEMs
	jutenjul	1.000.000.000 cEMs	1.250.000.000 cEMs
	KurtHaegeman	750.000.000 cEMs	1.000.000.000 cEMs
	[DPC] Fatal Error Group	400.000.000 cEMs	500.000.000 cEMs

	SoB user Megaflush top 5 (9 March 2008) Updated once a day (the highest flush per user is counted)
	pos	user	date	output (k)
	1.	Graasland	(2007-07-20)	621.214.447.829 cEMs
	2.	Grutte Pier [Wa Oars]	(2007-06-01)	472.394.916.365 cEMs
	3.	Los Alcoholicos	(2007-03-21)	391.304.247.365 cEMs
	4.	DukeBox	(2007-01-31)	222.272.617.476 cEMs
	5.	[DPC] Team_RC	(2005-05-29)	161.916.610.763 cEMs
	more

	SoB Links
	SoB Homepage QiK SoB stats Speedkikker SoB stats SoB Stats FAQ Official FAQ Official Stats Official forum SoB news

offtopic: RML SoBstats engine 1.4 by Dukebox

[TPbasMIE]

hmmm............ondanks de problemen bij Anandtech is de score van DPC ook wel enorma aan het inzakken hoor. We deden de hele maand februari gemiddeld denk ik tussen de 60-70T en nu onder de 50T....

Maar nog steeds stukken beter dan de 15-20T van vorig jaar

[WolterB]

Ik ben vandaag begonnen met wat testruns voor de stampede en het valt mij op dat de verschillen tussen beide clients op mijn dualcore-bakken erg groot zijn. Is dit normaal en/of valt hier wat aan te doen?

Op dit moment heb ik de volgende cEMs/sec:
AMD Athlon X2 4200+ (@2.21GHz):
Client 1: ~1.709.000
Client 2: ~1.952.000
Hier lijken beide scores mij sowieso aan de lage kant

C2D 2140 (@2.00GHz):
Client 1: ~2.608.000
Client 2: ~3.135.000

[Frentik]

WolterB schreef op maandag 10 maart 2008 @ 12:30:
Ik ben vandaag begonnen met wat testruns voor de stampede en het valt mij op dat de verschillen tussen beide clients op mijn dualcore-bakken erg groot zijn. Is dit normaal en/of valt hier wat aan te doen?

Op dit moment heb ik de volgende cEMs/sec:
AMD Athlon X2 4200+ (@2.21GHz):
Client 1: ~1.709.000
Client 2: ~1.952.000
Hier lijken beide scores mij sowieso aan de lage kant

C2D 2140 (@2.00GHz):
Client 1: ~2.608.000
Client 2: ~3.135.000

Intel is zowieso sneller dan AMD op dit project. Daarnaast is de snelheid ook afhankelijk van de k/n waardes. bij gelijkblijvende k zal met toenemende n de snelheid stijgen. Bij een gelijke n-waarde kan de snelheid per k-waarde verschillen: b.v. de testen van k=55459 zijn altijd langzamer dan die van k=10223 (als n ongeveer gelijk is).

[WolterB]

Frentik schreef op maandag 10 maart 2008 @ 13:10:
[...]

Intel is zowieso sneller dan AMD op dit project. Daarnaast is de snelheid ook afhankelijk van de k/n waardes. bij gelijkblijvende k zal met toenemende n de snelheid stijgen. Bij een gelijke n-waarde kan de snelheid per k-waarde verschillen: b.v. de testen van k=55459 zijn altijd langzamer dan die van k=10223 (als n ongeveer gelijk is).

Ik doelde eigenlijk op het verschil tussen de clients op één pc, dat daar belachelijk grote verschillen lijken te zijn.
De k- en n-waarden zijn bij beide clients nagenoeg gelijk, dus daar zou het verschil niet vandaan horen te komen.

[Frentik]

WolterB schreef op maandag 10 maart 2008 @ 13:26:
[...]
Ik doelde eigenlijk op het verschil tussen de clients op één pc, dat daar belachelijk grote verschillen lijken te zijn.
De k- en n-waarden zijn bij beide clients nagenoeg gelijk, dus daar zou het verschil niet vandaan horen te komen.

Als de k-waarde verschillend is kan het nog steeds, het is volgens mij niet zo dat een kleinere k een snellere test geeft...de exacte reden hiervoor kan ik ook niet uitleggen. Ik heb hier wel ooit e.e.a. over gelezen op het SoB forum maar dat ging me toch allemaal net iets tever om te willen begrijpen .

[Bubbles]

Ter vergelijking, ik heb op mijn 4200+ (@ 4600+) de clients lopen op 2,31 en 2,29 McEMs/s, terwijl de k-waarde behoorlijk verschillend is. WolterB heeft het ook niet over hoe snel een block klaar is, maar over het enorme verschil in cEMs/s tussen 2 clients op dezelfde SMP-bak. Logisch gezien zou je verwachten dat dat ongeveer hetzelfde zou moeten zijn (zoals bij mij wel duidelijk het geval is).

[DukeBox]

Bubbles schreef op maandag 10 maart 2008 @ 13:37:
Ter vergelijking, ik heb op mijn 4200+ (@ 4600+) de clients lopen op 2,31 en 2,29 McEMs/s, terwijl de k-waarde behoorlijk verschillend is. WolterB heeft het ook niet over hoe snel een block klaar is, maar over het enorme verschil in cEMs/s tussen 2 clients op dezelfde SMP-bak. Logisch gezien zou je verwachten dat dat ongeveer hetzelfde zou moeten zijn (zoals bij mij wel duidelijk het geval is).

Het hangt er ook nogal vanaf hoe groot de L2 cache van de cpu is.. als de test kleiner is gaat deze ook sneller omdat er minder gemapped moet worden naar het L3 geheugen.

[Frentik]

Dat snap ik..maar het aantal cEMS/sec bepaalt nu eenmaal hoe snel een block (en dus de hele test) af. En aangezien er geen lineair verband is tussen k-waarde (of n-waarde) en de "maximale" snelheid is en blijft het vergelijken van cEMs/sec moeilijk.
Daarnaast is PC gebruik ook van invloed op de snelheid, eventjes je PC belasten en je snelheid kan makkelijk 0.1 cEMs/sec dalen.

Maar als je twijfels hebt zou ik het ff op het forum posten daar zitten de mensen die er echt verstand van hebben.

[duarf]

Als ik mijn laptop laat crunchen begint hij een zeer hoog gepiep te produceren (onregelmatig),iemand heeft me gezegt dat dit de CPU whine is, maar ik dacht dat dat alleen bij cpu's in idle staan....
Kan dit dan kwaad om hem verder te laten crunchen?

[Bubbles]

Persoonlijk vind ik het sowieso nooit een goed idee om DC te doen op laptops, aangezien die dingen er niet echt op gemaakt zijn om continu 100% belast te worden.

[duarf]

op zich, voor de warmte moet ik niet klagen, hij haalt nog geen 50 graden

[DukeBox]

Bubbles schreef op maandag 10 maart 2008 @ 14:04:
Persoonlijk vind ik het sowieso nooit een goed idee om DC te doen op laptops, aangezien die dingen er niet echt op gemaakt zijn om continu 100% belast te worden.

Onzin.. ze worden juiste getest met 100% belasting over langere tijd.
Tuurlijk is het zo dat fan's e.d. eerder slijten dan wanneer je laptop minder warm moet afvoeren maar het is niet zo dat ze niet gemaakt zijn op 100% belasting.

[WolterB]

Frentik schreef op maandag 10 maart 2008 @ 13:32:
[...]
Als de k-waarde verschillend is kan het nog steeds, het is volgens mij niet zo dat een kleinere k een snellere test geeft...de exacte reden hiervoor kan ik ook niet uitleggen. Ik heb hier wel ooit e.e.a. over gelezen op het SoB forum maar dat ging me toch allemaal net iets tever om te willen begrijpen .

Ik heb het eea doorgelezen op verschillende fora en kan nergens hetzelfde probleem vinden. Ik heb ter verduidelijking een screenshot gemaakt van mijn taskmanager en beide SoB-clients. Hier is ook goed te zien dat één van beide clients meer dan 50% van mijn CPU gebruikt:
Hier heeft client 1 idd een kleinere k, wat het verschil zou kunnen verklaren, maar is dit een realistisch verschil?


Hier zijn beide k-waarden even groot, is het CPU-gebruik bij beide clients gelijk, maar is er nog steeds een groot verschil in output:


Hieronder is mijn output van sobsvc -d:

code:

CPU Affinity = Separate, 2 Clients
AutoRestart OFF
TrueIdle = TRUE
NormalizeXP = 40da34
Monitor and Restart = FALSE
Restart Stuck Clients = TRUE
Keep Icons Visible = TRUE
WU Queue Size = 0
Autodial Type = 0
Periodic Restart = 0

[ Voor 13% gewijzigd door WolterB op 10-03-2008 16:20 ]

[joh14vers6]

WolterB schreef op maandag 10 maart 2008 @ 16:15:
[...]

Ik heb het eea doorgelezen op verschillende fora en kan nergens hetzelfde probleem vinden. Ik heb ter verduidelijking een screenshot gemaakt van mijn taskmanager en beide SoB-clients. Hier is ook goed te zien dat één van beide clients meer dan 50% van mijn CPU gebruikt:
Hier heeft client 1 idd een kleinere k, wat het verschil zou kunnen verklaren, maar is dit een realistisch verschil?
[afbeelding]

Hier zijn beide k-waarden even groot, is het CPU-gebruik bij beide clients gelijk, maar is er nog steeds een groot verschil in output:
[afbeelding]

Hieronder is mijn output van sobsvc -d:

code:

CPU Affinity = Separate, 2 Clients
AutoRestart OFF
TrueIdle = TRUE
NormalizeXP = 40da34
Monitor and Restart = FALSE
Restart Stuck Clients = TRUE
Keep Icons Visible = TRUE
WU Queue Size = 0
Autodial Type = 0
Periodic Restart = 0

Grappig.

Ik denk toch dat k=10223, de snelste in deze range, de boosdoener is van dit verschijnsel. De hogere FFT veroorzaakt dat de CPU bij k=55459 meer swaptijd gebruikt en waardoor er cputijd vrij komt voor de test met k=10223.

[Anoniem: 167389]

Verlies nog steeds elke systeem opstart het werkstuk, maar heb nu wel denk ik uitgedokterd wat het juiste moment is om het afgebroken werkstuk te expireren zonder punt aftrek (of dat komt nog een in de toekomst)....en nee alle permissies zijn in orde. Deze miz hmmmm heb ik nog nooit ergens eerder meegemaakt, maar voor alles is een eerste keer.... de 2e 150k cEMs paal moet in fabricage zijn.

kletch u laeter

[Theadalus]

WolterB schreef op maandag 10 maart 2008 @ 16:15:
Ik heb het eea doorgelezen op verschillende fora en kan nergens hetzelfde probleem vinden.

Dan heb je niet goed gezocht, ik heb hier ook al eens een vraag over gesteld op het SoB-forum.
Schijnbaar heeft een hogere k-waarde (bij gelijke n-waarde) een lagere output (in cEMs/sec) tot gevolg, iets met FFT boundaries...

WolterB schreef op maandag 10 maart 2008 @ 16:15:
Hier heeft client 1 idd een kleinere k, wat het verschil zou kunnen verklaren, maar is dit een realistisch verschil?

Ja, het verschil tussen 2 clients kan redelijk oplopen.
Houd er ook rekening mee dat de 2 cores van een C2D shared cache hebben, hierdoor kunnen ze elkaar flink in de weg zitten wanneer beide cores cache-intensieve taken uitvoeren (bv. SoB-client).

[NLSchutP]

Ik denk dat je ook algemeen moet meenemen dat Windows ook nog eens gebruik maakt van 1 van beide cores. Bij mij thuis zie ik op de laptop van mijn vrouw een soortgelijk probleem: de laptop draait momenteel alleen SoB, geen andere applicaties, toch gaat client 2 achterlopen. Dit komt waarschijnlijk doordat Windows applicaties heeft draaien op de achtergrond, welke na verloop van tijd toch een bepaalde hoeveelheid resources wegneemt van je computer.

[WolterB]

Dank voor de uitleg. Ik laat het in ieder geval maar zo doorlopen, eens kijken wat ik er uit kan halen dagelijks.