Woher kommt eine leichte Variation der RAM Größe

[honky-tonk]

Hallo,
Ich beschäftige mich gerade mit Eigenschaften von Smartphones anhand derer einzelne Geräte eindeutig identifiziert werden können. Hierzu zählt beispielsweise MAC Adresse, IP, Betriebssystem Version und unter anderem auch RAM Größe. Gutes Beispielprojekt auf github ist FingerprintJS.

Zum Testen habe ich 4x Pixel 4a identisch konfiguriert mit FingerprintJS app. Bei FingerprintJS in der Unterkategorie "Total memory" also RAM Kapazität haben 2 Geräte jeweils dieselbe Kapazität (in bytes angegeben). Die Werte der jeweils andern 2 Geräte unterscheiden sich hier nur um wenige kB. In der Praxis kaum der Rede wert, im Hinblick auf FingerprintJS aber einer von vielen Indikatoren. Selbes Muster mit der RAM Größe setzt sich bei 3x iPhone X fort.

Meine Frage:
Woher kommt die Varianz in der Speicher Größe genau? Es sieht für mich so aus, als ob die verbauten DRAM Chips in ihrer tatsächlichen Größe variieren können.

 

[e_Lap]

Vermutlich weil nicht alle Chips exakt die gleiche Menge an heilen / funktionsfaehigen Sektoren haben.

Fuer normale User wird das dann einfach gerundet angegeben, da es defakto keinen Unterschied in der Bedienung macht.

 

[honky-tonk]

@e_Lap hatte ich auch schon vermutet wenn man mal unter dem punkt "Row and column redundancy" auf wiki schaut steht, dass defekte reihen ersetzt werden, es geht aber weniger in die Richtung von overprovisioning. Klingt für mich eher nach fester Anzahl an Reihen und nur defekte werden ersetzt, die Adressbreite bleibt aber gleich.

 

[SpamBot]

Es könnten auch verschiedene RAM Hersteller sein, bzw. Verschiedene RAM Module

 

[GrumpyCat]

Bei RAM wird kein Overprovisioning oder Redundanz oder ähnliches gemacht, ihr verwechselt da FlashROM mit DRAM.

Die Redundanz-Geschichte auf Wikipedia gilt nur ab Werk um den Yield zu erhöhen. Jeder ausgelieferte RAM-Baustein hat exakt die angegebene Größe, und geht da was während der Lebensdauer kaputt, ist der Baustein halt hin. Wear Levelling wie bei FlashROM o.ä. wird nicht gemacht, da DRAM vergleichsweise ewig hält.

Der Fingerorinting-Kram ist in Kotlin geschrieben und läuft entsprechend in der Android-JVM und hat keinen direkten Zugriff auf die Hardware.

 

[honky-tonk]

Der Fingerorinting-Kram ist in Kotlin geschrieben und läuft entsprechend in der Android-JVM und hat keinen direkten Zugriff auf die Hardware.

Jap, keinen direkten ram Zugriff, aber er nimmt den Wert den das Betriebssystem bereitstellt. In iOS übrigens selbe Problematik.

Was mir allerdings aufgefallen ist, dass der ram nie glatte bytes sind, vll ist da auch etwas für Peripherie wie Grafikkarte reserviert?

 

[GrumpyCat]

Ich bin jetzt zu faul, in den Code zu schauen, würde aber mal tippen, dass der nur sowas wie für die JVM bereitstehendes RAM abruft und das dann eben nicht das RAM insgesamt ist oder dass es RAM minus Framebuffer der Grafik ist oder sowas.

 

[honky-tonk]

ch bin jetzt zu faul, in den Code zu schauen, würde aber mal tippen, dass der nur sowas wie für die JVM bereitstehendes RAM

hab mal rein geschaut...hier wird der RAM abgerufen in der android doku hierzu steht

The total memory accessible by the kernel. This is basically the RAM size of the device, not including below-kernel fixed allocations like DMA buffers, RAM for the baseband CPU, etc.

interessant nur, dass das selbe geräte, selbe software unterschiedlich viel RAM für DMA etc reserviert

 

[GrumpyCat]

Das ist häufig nicht ganz so deterministisch wie man denken sollte, weil z.B. beim Booten die Geräte nicht immer alle in der gleichen Reihenfolge initiatisiert werden und dann die Speichergrenzen leicht anders fallen können. Oder die Geräte andere Firmwares/-Versionen für die Coprozessoren haben und so weiter.