Hardware-Ecke - Druckversion +- Bronies.de (https://www.bronies.de) +-- Forum: Off-Topic (https://www.bronies.de/forumdisplay.php?fid=11) +--- Forum: Internet & Technik (https://www.bronies.de/forumdisplay.php?fid=54) +--- Thema: Hardware-Ecke (/showthread.php?tid=8922) Seiten:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
|
RE: Hardware-Ecke - Captain Gulasch - 19.11.2015, 18:35 Ein FX8320 hat ein wenig weniger Singlethread Leistung als ein Phenom 980. Im Mulitcore kommt er auf die Leistung des 4460, wenn er denn alle 8 Threads ausspielen kann, was meist nicht der fall ist. RE: Hardware-Ecke - Pandora51 - 19.11.2015, 18:47 Der 965er ist ziemlich lahm. In Kombination mit einer 7750 merkt das nicht aber bei starken Grafikkarten kommt die Cpu nicht mehr mit. Mit X4 965 + r9 390 ist flüssiges Spielen natürlich möglich aber die Gpu wird dann oft ausgebremst auf höheren Einstellungen und bei manchen Spielen hat man vielleicht große Probleme. Aber ja die Grafikkarte sollte zuerst geupradet werden. Das ist klar. RE: Hardware-Ecke - Captain Gulasch - 19.11.2015, 18:52 Es gab mal einen Test dazu, wann limitiert was, ist schon etwas her, aber eine GTX570 bzw. 6970 ging noch, danach fängt die CPU an zu limitieren. Kommt sicher auch das Spiel an, aber sinnig eine 390 oder Fury bzw. 970 oder 980 mit einem Phenom zusammen zu packen ist es sicher nicht. RE: Hardware-Ecke - Nic0 - 19.11.2015, 19:11 (19.11.2015)elitecat schrieb: Wenn er lieber Amd mag dann lasst ihn doch. Es geht aber doch darum das beste Preis/Leistungsverhältnis auszunutzen. Da gibt es momentan nicht wirklich viel mit Präferenzen. Mag sein, dass die FX ausreichend sind, aber wenn man wirklich die maximale Leistung für den gleichen Preis haben will, sollte man sich einen Intel holen. Das Argument mit Intel's Preispolitik halte ich für unsinnig, da 1. der eine nicht-kauf garantiert nichts daran ändern wird und 2. die Preise der Prozessoren in den letzten Jahren doch sehr stabil geblieben sind. RE: Hardware-Ecke - LightningGear - 19.11.2015, 19:13 Ich beginne mich langsam auch etwas darüber zu ärgern, anstelle des FX-8350, den ich vor einem Jahr gekauft habe, nicht lieber zu einem etwas teureren Core i5-4670k gegriffen zu haben. Wohl extrem limitiertes Budget... Jedenfalls würde ich zurzeit niemandem einen AMD-Prozessor empfehlen. Nvidia unterstütze ich auch nicht, trotz höherer Leistungsaufnahme würde ich nur zu AMD-Karten greifen. Aber wenn es sich irgendwann im nächsten Jahr lohnt, den Prozessor mal wieder auszuwechseln, gehe wahrscheinlich auch ich zu Intel. RE: Hardware-Ecke - Nic0 - 19.11.2015, 19:16 Oh, und btw.: Spoiler (Öffnen) A handful of NOPE. RE: Hardware-Ecke - LightningGear - 19.11.2015, 19:47 Was ich mich jedoch frage, ist der Sinn über das Wechseln der Grafikkarte in absehbarer Zeit. Ich hab eine R9 280X. In Auflösungen jenseits der 1080p spiele ich ohnehin nicht, und reproduzierbare Messungen in 3DMark Fire Strike zeigen klar und deutlich (etwa anhand des "Brawn"-Achievements) dass die GPU aufgrund der CPU bisher noch nicht einmal ihr volles Leistungspotential entfalten konnte. Würde es sich hier lohnen, in absehbarer Zeit (das heißt binnen der nächsten 12 Monate) eine neue Karte zu kaufen? Oder reicht auch einfach ein gescheiter Prozessor? RE: Hardware-Ecke - Captain Gulasch - 19.11.2015, 20:04 Ist natürlich die frage wie Pacsal oder Artic Island wird, das kann dir keiner sagen. Von einer 280x auf eine Fury umsteigen macht nur wenig sinn, speziell bei dem Preis. CPU hingegen macht jetzt schon sinn, zumindest von einem FX. RE: Hardware-Ecke - Pandora51 - 19.11.2015, 20:38 Wie siehts denn mit Übertakten aus? Sonst warte ab. Was kommt kann keiner so genau sagen.. RE: Hardware-Ecke - Conqi - 19.11.2015, 21:19 Und was sagen die werten Herren so zur 380X? Ich bin ja schon recht enttäuscht, was die Performance angeht. Die Lücke zwischen 380 und 390 schließt die Karte aus meiner Sicht nicht zufriedenstellend, dafür ist sie zu nah an der 380 ohne X. Stromsparender als die 280X und etwas moderner vom Chip her, aber performancemäßig nur auf einer Stufe. Hatte mir mehr erhofft. RE: Hardware-Ecke - mowny - 19.11.2015, 23:28 (19.11.2015)Conqi schrieb:(18.11.2015)mowny schrieb: Das ist doch einfach. Die vom System als unbenutzt markierten Bereiche werden irgendwann wieder zum Schreiben genutzt, der Gesamtspeicher wird ja aus Systemsicht nicht mehr, auch wenn die SSD mehr Blöcke hat als sie mindestens bräuchte und die lustig kreuz und quer gemappt werden. Daher können nur maximal so viele Blöcke aus SSD-Sicht in Benutzung sein, wie die SSD aus Systemsicht groß ist. Mit jedem Schreibvorgang wird also ein Block aus dem Reservepool geholt und einer wieder freigegeben.Aber ich dachte die SSD verteilt die Daten selbst, um gleichmäßige Schreiblast zu erzielen. Also nicht dass das System fest sagt "schreibe das in Block 25", sondern "schreibe das irgendwohin" und die SSD entscheidet dann, wohin damit. Oder habe ich da bereits was falsch verstanden? Denn wenn das so abläuft, dann wäre die SSD ja gar nicht in der Lage zu erkennen, ob sie Daten gefahrlos überschreiben kann. Wenn hingegen das System entscheidet, wohin geschrieben wird, dann bräuchte die SSD ja keine Intelligenz bzgl. der gleichmäßigen Verteilung von Schreibvorgängen. Das System sieht eigentlich die SSD nur als Speichermedium mit $GANZVIEL Sektoren und sagt der SSD "schreibe das in Sektor $bla bis Sektor $blubb", und wenn das System SSD-aware ist und die echte Blockgröße der SSD rausfinden kann, dann richtet es eine Schreibvorgänge möglichst an den Blockgrenzen der SSD aus, um das Beschreiben von Teilblöcken zu vermeiden (weil das zu den bereits beschriebenen Problemen führt; etwas nicht ganz unähnliches passiert beim nicht korrekt ausgerichteten Schreibzugriff auf Platten, die intern 4K-Sektoren haben aber nach außen so tun als hätten sie herkömmliche 512byte große). Die SSD hat aber eine interne Blockverwaltung, die dann halt sagt "Der Block von Sektor $bla bis Sektor $rhabarber ist jetzt in dem Chip da drüben, dritte Reihe links, der hat noch nicht so viele Zyklen runter; dafür ist der Platz wo der Block vorher hingemappt war jetzt wieder frei". Auf diese Blockverwaltung hat das System normalerweise keinen Zugriff, dafür sind sehr spezielle Tools notwendig. Die dazugehörige Mappingtabelle (die idR auch gleich die Defektmarkierung miterledigt) ist natürlich immens wichtig - egal ob die irgendwo am Stück liegt oder jeder Block seinen Datenanteil selber trägt; wenn darin ein Fehler auftritt, ist die SSD erstmal hin, mit etwas Glück ist die SSD mit Erase noch wiederbelebbar, aber die Daten sind weg ... Bei einer neuen SSD ist anfangs noch gar kein Block belegt, auf einen beliebigen Lesezugriff antwortet die SSD nur mit Nullen. Ähnlich wie bei einem sparse file. Das funktioniert normalerweise auch umgekehrt: Wenn man einen Block nur mit Nullen beschreibt, sagt man damit der SSD, daß dieser Block frei ist, auch ohne TRIM. Das sollte man aber nur mit ganzen Blöcken tun, einfach den gesamten freien Platz mit Nullen beschreiben kann aber je nach Granularität der Blockverwaltung suboptimal sein, weil man damit der SSD ggf. einen Löschzyklus für alle teilbelegten Blöcke aufzwingt. Diese teilbelegten Blöcke sind aber auch mit TRIM ein Problem, weil sie bei zunehmender Fragmentierung dazu führen, daß irgendwann alle im Rahmen der Nennkapazität belegbaren Blöcke auch belegt sind und die SSD von TRIM kaum noch profitiert, weil nur noch selten ein kompletter Block frei wird und zurück in den Pool kann. In diesem Fall ist der Pool, genau wie bei einem System ohne TRIM nach mindestens einmaligem Schreiben in alle Blöcke, auf die Reservekapazität beschränkt. (19.11.2015)Leon schrieb: TRIM hat übrigens keinen direkten Einfluss auf die Lebensdauer Indirekt schon - wenn der Pool größer ist, weil auch mal wieder Blöcke zurückkommen ohne daß neue belegt werden, kann die SSD besser wear leveling machen. Zitat:sondern nur auf die Performance. Moderne SSDs haben angeblich auch bei Systemen ohne TRIM keinen deutlichen Performanceverust wie die alten Generationen, wobei ich nicht genau weiß, wie das dann gelöst wurde. Verbessertes wear leveling, größerer Reservepool (und wenn es nur so ist, daß der absolut größer geworden ist durch die insgesamt vergrößerte Kapazität heutzutage). Andererseits, heutzutage haben die SSDs ja häufig nicht mehr Vielfache von 30GB als Kapazität, sondern von 32, beides allerdings in "Plattenherstellerzählung", so daß immer noch Reserve bis zu den "echten" 32GB auf den Flashchips ist; dadurch hat eine SSD mit 64GB Nennkapazität absolut knapp mehr Reserveblöcke als eine mit 30GB. Sieht erstmal günstiger aus weil mehr nutzbare GB fürs Geld, rächt sich aber, wenn wie oben ausgeführt alle Blöcke belegt sind und der Pool durch defekte Blöcke sowieso schon kleiner wird. RE: Hardware-Ecke - Der Unbekannte - 20.11.2015, 00:54 (19.11.2015)Conqi schrieb: Und was sagen die werten Herren so zur 380X? Ich bin ja schon recht enttäuscht, was die Performance angeht. Die Lücke zwischen 380 und 390 schließt die Karte aus meiner Sicht nicht zufriedenstellend, dafür ist sie zu nah an der 380 ohne X. Stromsparender als die 280X und etwas moderner vom Chip her, aber performancemäßig nur auf einer Stufe. Hatte mir mehr erhofft. Sehr enttäuschend, die 290 wurde in einigen Tests nicht mehr mit rein genommen, obwohl die 380x gegen diese Konkurieren sollte. Der Gap zwischen der 380x und der 390 sollte ja anders verlaufen als bei der 280x und 290, war auch nicht der fall. Aber das was ich gesehen habe sieht nicht gut aus, die 380x wenn sie mal ein Optimiertes Spiel bekommt, und keins mit nVidia Shitwörks etc dann wird diese von der 280x besiegt, auch sonst ist der Leistungsunterschied zwischen der 280x und 380x nicht sehr hoch, ich bezweifel das die 380x überhaupt an einer 290 rankommt. Vielleicht fehlt auch einfach nur die Treiber Optimierung, wer weiß. Die 380x gibt es für 250 € +, eine gute 380 [4GB] ab 210 €, dabei ist die 380x durchschnittlich 7-10 % stärker. Ob das nun die knappe 40-50 €, je nach Modell, aufpreis rechtfertigt, ich weiß ja nicht. RE: Hardware-Ecke - LightningGear - 20.11.2015, 00:58 Hab aus Interesse mal den 32-bit-Test von Geekbench 3 gemacht, und das Ergebnis ist teils ernüchternd. Spoiler (Öffnen) RE: Hardware-Ecke - 404compliant - 20.11.2015, 01:37 (19.11.2015)mowny schrieb: und wenn das System SSD-aware ist und die echte Blockgröße der SSD rausfinden kann, dann richtet es eine Schreibvorgänge möglichst an den Blockgrenzen der SSD aus, um das Beschreiben von Teilblöcken zu vermeiden Hast du dafür eine Quelle? Sinnvoll wäre eine Ausrichtung der Schreibvorgänge an den Zellengrößen, nur hab ich meine Zweifel, dass die Dateisysteme tatsächlich schon so weit sind, und solche Meta-Blockgrößen abseits der üblichen 4k schon beherrschen. Andererseits, die SSD sortiert ja eh alles um, wird vermutlich keinen allzu großen Unterschied machen. (19.11.2015)mowny schrieb: Diese teilbelegten Blöcke sind aber auch mit TRIM ein Problem, weil sie bei zunehmender Fragmentierung dazu führen, daß irgendwann alle im Rahmen der Nennkapazität belegbaren Blöcke auch belegt sind und die SSD von TRIM kaum noch profitiert, weil nur noch selten ein kompletter Block frei wird und zurück in den Pool kann. Die SSD hätte immerhin die Möglichkeit, mehrere wenig belegte Blöcke zu einem zusammen zu legen, und so die anderen frei zu geben. Worst case, wenn kein ganzer Block frei ist, kann die SSD immer noch einen fast freien Block nehmen und neu schreiben, und kann die ungenutzte Kapazität des Blocks komplett für andere Daten nutzen. Ohne Trim hingegen muss die Platte letztlich irgendwann davon ausgehen, dass jeder Block zu 100% mit wichtigen Daten gefüllt ist, d.H. auch wenn nur ein Sektor geschrieben wird, muss die SSD den ganzen Block lesen, den einen Sektor ändern, und alles zurück schreiben, auch wenn es vielleicht nur noch Datenreste ohne Wert sind. RE: Hardware-Ecke - Leon - 20.11.2015, 15:39 (20.11.2015)404compliant schrieb: Hast du dafür eine Quelle? Sinnvoll wäre eine Ausrichtung der Schreibvorgänge an den Zellengrößen, nur hab ich meine Zweifel, dass die Dateisysteme tatsächlich schon so weit sind, und solche Meta-Blockgrößen abseits der üblichen 4k schon beherrschen.Windows unterstützt (native) 4k-Blöcke übrigens erst ab Windows 8. Windows 7 und viele Raid-Controller benötigten emulierte 512-byte-Blöcke, was bei fast allen Festplatten derzeit der Fall ist. RE: Hardware-Ecke - mowny - 20.11.2015, 21:48 (20.11.2015)404compliant schrieb: Hast du dafür eine Quelle? Sinnvoll wäre eine Ausrichtung der Schreibvorgänge an den Zellengrößen, nur hab ich meine Zweifel, dass die Dateisysteme tatsächlich schon so weit sind, und solche Meta-Blockgrößen abseits der üblichen 4k schon beherrschen. Nicht so sehr das Dateisystem (okay, zfs und ähnliche Exoten können wahrscheinlich auch sowas), aber zumindest dem lvm kann man ne passende Blockgröße mitgeben. Zitat:Die SSD hätte immerhin die Möglichkeit, mehrere wenig belegte Blöcke zu einem zusammen zu legen, und so die anderen frei zu geben. Dafür muß die SSD sich aber auch die Subblockbelegung merken können. Machen die das wirklich, oder halten die solche Daten nur in ihrem RAM? Immerhin wäre das gerade bei subblock merging eine ganze Menge Speicher, der auch noch besonders belastbar sein muß ... (20.11.2015)Leon schrieb: Windows unterstützt (native) 4k-Blöcke übrigens erst ab Windows 8. Windows 7 und viele Raid-Controller benötigten emulierte 512-byte-Blöcke, was bei fast allen Festplatten derzeit der Fall ist. Auf der Bootplatte vielleicht. Zusätzliche Platten konnten sogar schon unter DOS mehr als 512 Byte pro Sektor haben. Womit außer DOS selbst allerdings nicht alles klargekommen ist. Mein olles MO-Laufwerk hat zB 2048-Byte-Sektoren. DVD-RAM auch. RE: Hardware-Ecke - LightningGear - 20.11.2015, 21:54 Heute mal wieder das eigene Glück mit Hackintosh versucht, und obwohl es besser lief als zuvor, läuft beileibe nicht alles perfekt. Nachdem sowohl Audio als auch Grafik (mit zwei Behelfstreibern) sich problemlos installieren ließen, fiel mir regelmäßig der Netzwerktreiber aus, was am Ende zu einer vollständig Neuinstallation mit Disk permissions-Reperatur führte. Auch Spiele funktionieren. Es gibt jedoch ein kleines Problem, und das bemerkt man, wenn man sich die Geekbench 3-Werte erneut anschaut: Spoiler (Öffnen) Zum gegebenen Zeitpunkt lässt selbst ein MacBook Air meinen Prozessor völlig hinter sich. RE: Hardware-Ecke - 404compliant - 20.11.2015, 23:05 (20.11.2015)Leon schrieb: Windows unterstützt (native) 4k-Blöcke übrigens erst ab Windows 8. Windows 7 und viele Raid-Controller benötigten emulierte 512-byte-Blöcke, was bei fast allen Festplatten derzeit der Fall ist. Da wirfst du etwas durcheinander. Du meinst 4k-Sektoren, die von der Festplatte als kleinste Einheit gemeldet werden. Die wurden vor 30 Jahren mal unter DOS unterstützt, sind dann irgendwie verloren gegangen, und werden jetzt wieder unterstützt. Dateisysteme hingegen verwenden intern schon seit Ewigkeiten als kleinste Einheit mindestens 4k große Cluster. Das geht auch bis zu seligen DOS-Zeiten zurück, und gilt auch für fast alle anderen Dateisysteme, weil sie so zur 4k-Speicherseiten-Größe der Prozessoren passt, ein Cluster belegt so immer ganze Speicherseiten, das macht das swappen und die memory mapped files leichter. Seit Windows 7 (glaube ich) achten sie auch auf das Alignment, d.H. ein Cluster beginnt auch immer auf einer glatten 4k-Adresse, ältere Dateisysteme haben die 4k-Cluster gerne mal um 512 Byte verschoben gespeichert. Das strafen aber moderne Festplatten und SSDs mit Performance-Verlusten ab. RE: Hardware-Ecke - Leon - 21.11.2015, 00:31 Ja, ich meinte Sektoren (der Festplatte), keine Blöcke (des Dateisysems). Korrekt ausgerichtete Partitionen bei Festplatten mit emulierten 512-Byte-Sektoren kann übrigens bereits Windows Vista SP1 erstellen. Bei Windows XP ging es dagegen nur mit Zusatztools. RE: Hardware-Ecke - mowny - 21.11.2015, 03:45 (20.11.2015)404compliant schrieb: Dateisysteme hingegen verwenden intern schon seit Ewigkeiten als kleinste Einheit mindestens 4k große Cluster. Das geht auch bis zu seligen DOS-Zeiten zurück, und gilt auch für fast alle anderen Dateisysteme, weil sie so zur 4k-Speicherseiten-Größe der Prozessoren passt, ein Cluster belegt so immer ganze Speicherseiten, das macht das swappen und die memory mapped files leichter. Nope. DOS hat damals 2 oder 4 Sektoren benutzt, und mußte dank FAT16 bei höheren Kapazitäten größere Blöcke machen, bis zu 16KB. FAT32 hat per default 4 Sektoren genommen, ein Kompromiß zwischen FAT-Größe und Speicherverschwendung durch kleine Fisseldateien. Mit swap und mmap hat das gar nix zu tun, weil beide auf Dateiebene operieren und damit ein paar Ebenen über Sektoren und Clustern. |