i5 7600K Bottelneck?

Bei mir werden 15-16 Cores angezeigt?
Ich glaub da hänge ich. Es werden von mir 24 Cores angezeigt, weil die Vorhanden sind^^
ausgelastet, benutzt (was weiß ich).

Du kannst dir natürlich die Mühe machen und die die schnelleren Core ausfindig machen und deine Spiele an diese Corepriorität pappen, aber auch das hat Nachteile. Wahrscheinlich hast du pro CCD sogar die Hälfte, also 3 schnellere. Gut selektiert.
 
Ich schalte per Taskmanager Cores für BF5 ab (Zugehörigkeit), und wenn die FPS einbrechen, dann hab ich zu wenig Kerne für die Anwendung. So einfach isses doch am Ende. Wie die Verteilt sind ist ja für die Betrachtung eher zweitranging. Denn jemand der weniger Kerne hat, der muss sein Windows doch auch in die vorhanden Kerne quetschen, d.h. dessen Systemleistung wird am Ende noch schneller zusammenbrechen.
 
Ich schalte per Taskmanager Cores für BF5 ab (Zugehörigkeit), und wenn die FPS einbrechen, dann hab ich zu wenig Kerne für die Anwendung. So einfach isses doch am Ende.
Klar, so is'es. Nur hast du keinen Zugriff darauf wie Windows die Setpriority anpasst (reatime bis low, ausser du machst es manuell) und ab einer bestimmten Anzahl an Cores, wirst du nicht mehr FPS mit noch mehr Cores generieren. Da kann sich AMD aber CPU intern erlauben die Threads über mehr Cores die niedriger Takten zu verteilen, spart ja letztendlich Energie, wird nicht so warm usw.. Bei so einer großen Anzahl ist der Boostclock doch irrrelevant, Hauptsache die niedrig getakten Cores schaffen das gleiche wie ein hochgetakter.

Schnelle Cores können letztlich auch weniger verbrauchen, wenn ich nicht zwei oder drei für mehr parallele Threads aktivieren muss, liegt dann allein am Energiemanagement, Hardwearesheduler inklusive Arbitrator.

Ab 12 Threads generiert man unter BFV nicht mehr fps, kannst es gerne ausprobieren. Letztlich ist ein 7600k dafür nicht mehr ausreichend, egal wie man auf ihn einprügelt. Zu einer 2080 passt er sicherlich nicht.
 
Aber genau das zeigt doch mein Video^^
Zwischen 12 und 16 Threads hört die Skalierung auf. Du hast Dich also an den 16 Threads aufgehangen die ich genannt habe? Hätte ich eher eine von-bis Zahl nennen sollen? Meine Betrachtung ist ja auch nur auf die eine einzelne Stelle begrenzt. Da geb ich lieber ein bisschen Spielraum.
 
Aber genau das zeigt doch mein Video^^
Zwischen 12 und 16 Threads hört die Skalierung auf. Du hast Dich also an den 16 Threads aufgehangen die ich genannt habe? Hätte ich eher eine von-bis Zahl nennen sollen? Meine Betrachtung ist ja auch nur auf die eine einzelne Stelle begrenzt. Da geb ich lieber ein bisschen Spielraum.
Nein.^^

Der Sheduler unter W10 kann keinen einzelnen Core eines CCD als schnellsten auslesen (für ihn ist das CCD der schnellste Core), er will auch immer (min) zwei Cores für sich um die Threads über diese aufzuteilen. Da der Master die schnellsten Cores anders ermittelt (einzeln) als Windows, aktivierst du CPPC. Für Windows liegt die Priorität auf Core 0 und 1, für den Master auf 13 und 14 (weil die schnellsten Cores). Um zu vermeiden das Windows von Core 1 zu 14, also über vier CCD springt, ist das vollkommen legitim, nur muss man wissen, dass es dann über mehr Cores "float" 'et als notwendig.

Aber ist schon o.k., sowieso fern des Themas.
 
Komisch, warum konzentriert dann der Sheduler in Windows seine Arbeit auf die Kerne 13-15 die bei mir als "bester" CCX im Ryzen Master angegeben werden, wenn der Sheduler das gar nicht kann.

Du hast mitbekommen dass das Update von Windows 1909 genau diese Funktionalität nachgepatched hat? Vorher konnter der Sheduler das tatsächlich nicht.


A CPU may have multiple “favored” cores (logical processors of the highest available scheduling class). To provide better performance and reliability, we have implemented a rotation policy that distributes work more fairly among these favored cores.

What's new in Windows 10, version 1909 - Windows Insider Program | Microsoft Docs


Das Windows einen Thread zwischen zwei Kernen eines CCX hin und her springen lässt, damit der CCX dabei nicht gewechselt wird, was zusätzlichen Overhead verursacht, stelle ich doch gar nicht in Abrede.
 
Du hast mitbekommen dass das Update von Windows 1909 genau diese Funktionalität nachgepatched hat? Vorher konnter der Sheduler das tatsächlich nicht.
Weil das CPPC so meldet. Das liegt nur daran das man anfänglich umhergeheult hat, man würde den höchten Boostclock nicht erreichen, klar wenn Windows an Core 0 und 1 pappt und irgendwelche Singlecorebenchmarkstools dann an diesem Core hängen, der schnellste aber wie bei dir 13 oder 15 ist.

CPPC nutz mehr CCD, vor allem zuerst die schnellsten Cores jedes CCD. Einer also der Singleboostcore ist der schnellste, dann die zwei, drei, vier usw.. genau deshalb wurde nachgepacht, so das Windows auch diese Core anspricht. Seit dem ist auch Global C-states und CPPC im UEFI auf "auto" gesetzt. Den Rest weiß ich, ja.

...ein Core-Chiplet wird allerdings nicht mehr in zwei CCX aufgetrennt (damit ungeteilter L3-Zugriff über das komplette Core-Chiplet)
AMD spricht erste Details zu "Zen 3" an | 3DCenter.org
 
Bei mir ist gar nicht der 15er der schnellste, ich hab nur selbst Hand angelegt damit er der schnellste ist.
Der "Beste" wird scheinbar nicht über die Geschwindigkeit definiert.
Und ja, meine beiden besten CCX liegen beide auf dem gleichen CCD. Und trotzdem wird erst das eine CCX und dann das andere belastet.

Ich meine ist ja alles schön und gut was Du mir erklären möchtest, aber beobachten kann ich etwas anderes.
 
Schalte CPPC doch einfach mal ab. Der Beste kann nicht der Beste sein, weil Windows schon zwei braucht und sie sich auch genehmigt. Einfache Rechnung, 16-2 sind schon mal 14, was hast du noch aktiv? Irgendwann kommt man für das Spiel schon auf 12 Threads. Die 2 zusätzlichen Core könnten an CPPC liegen.

Mehr wollte ich damit gar nicht schreiben und mache ich jetzt auch nicht mehr. Der 7600k ist das Bottleneck.
 
Damit solltest du bei gut programmierten Spielen in den nächsten Jahren nicht so schnell in CPU Limit kommen. Ein paar Single core games die jede CPU rösten wie Arma 3 wird leider wohl noch länger geben.
 
Bei Arma 3 ist es aber eher der Code und der Scheduler, weniger die CPU. Ist ja nicht so, dass irgendein kern bei Arma am Limit laufen würde.
 
Zurück