Frage an alle HS3-Besitzer: Anzeige bei Übertragung

[MatthiasS]

Ihr verwechselt da RAM und Flash. HS3 64 MB, FS 256 MB Flash! RAM HS3 128 MB, FS 512 MB.

[gunnar]

Das passt doch irgendwie nicht...

Unterschiedliche Hardware-Revisionen? Die 64MB Angabe stimmt definitiv nicht mehr. In den Dingern ist mehr Speicher. Bei michel38 scheinen mir 128MB drinnen zu sein. Bei den anderen könnten es vielleicht 96MB sein.

-Gunnar

[tmaccoy]

also, bei dieser ganzen Speichergeschichte ist mir gerade folgendes aufgefallen: Es hieß doch mal irgendwo, dass der HS 64 MB hat. MemTotal von DJGockel sind 90504 kB (HS3?). Bei meinem HS3 werden 90532 kB angezeigt, also ungefähr das gleiche. Und beim HS2 von Michel38 114552 kB? Das passt doch irgendwie nicht...

tmaccoy

[gunnar]

Könnten das auch Bausteine sein, die den Speicher verbraten? Wie sieht es nach einem Neustart aus, ist der Speicher dann auch schon so voll?

Kann man eigentlich mit Telnet/SSH auf dem HS zugreifen?

[DJGockel]

Hi Uwe,
bei Dir wird unter MemFree mehr wie 20000 angezeigt somit hast Du kein Problem

[michel38]

Hallo Olaf, Manuel,

Ich bin immer noch im Zweifel, das die ganannten Punkte etwas mit Euren Problemen zu tun haben.

Hier mal ein paar Eckdaten von meinem HS2: Visu 1024x768 enthält 110 Seiten + 36 popup Seiten, Iphon Visu enthält 55 Seiten + 25 popup Seiten. Dazu kommen noch 85 Webabfragen, sowie total überfüllte Daten-Archive (eine neue Baustelle gefunden )

Ich habe keine Probleme mit meinen HS.

[Hightech]

Hallo Manuel!

Das meine ich ja auch - und unsere Häuschen sind jetzt ja nicht so riesig groß! Bin doch ehrlich etwas enttäuscht von den Speicherkapazitäten des HS...

Hatte immer gedacht "ach, knapp über 20 % Projektgröße, da kannst ja noch viel machen" - denkste!

In meinem Projekt sind (wenn auch in einem Design zusammengefasst) Visuseiten für das 15'' und für das iphone - also quasi "2 Designs". Man stelle sich jetzt mal vor, man hätte Displays mit unterschiedlicher Auflösung, dann wäre endgültig Ende mit Speicher!

Ein paar Punkte, die ich auch noch an Gira/Dacom schicken werde, über die man vielleicht in einer der nächsten Firmwareversionen mal nachdenken sollte (ich weiß, es gibt einen extra Thread dafür...):

• die Grafiken sollten in einem zentralen Repository gehalten werden, dass allen Desings zur Verfügung steht - sonst werden sie scheinbar für jedes Design separat abgelegt und fressen Speicher
• vielleicht sollte man über ein Frameset nachdenken - bei mir musste ich zahlreiche Seiten "doppeln" - bspw. unterscheiden sich zwei Seiten nur dadurch, dass auf der einen das Raumtemperaturdiagramm für den aktuellen Tag und auf der anderen für den ganzen Monat angezeigt wird. Mit einem Frameset könnte man die Hauptseite definieren und dann den "Diagrammframe" variabel einbetten!
• es sollten nicht nur die Speicherauslastung des Projektspeichers angezeigt werden, weil die irreführend ist! Warum nicht auch die anderen Speicherbereiche anzeigen?

Und zu guter letzt der Hardwareaspekt: Speicher kostet doch heute gar nichts mehr - warum nicht mal richtig aufrüsten (selbst 256 MB beim FS sind in der heutigen Zeit eher sparsam!)

Olaf

[DJGockel]

ja das mit >23MB hab ich schonmal irgendwo gehört, hatte deswegen schon einige Webabfragen rausgeschmissen und auch Symbole verkleinert, sowie Hintergründe reduziert.
Hat aber nur etwas den MemFree Speicher erhöht.
Ich weiß so langsam nicht mehr was ich noch machen soll und nur wegen dieser Probleme nen FS kaufen kann auch nicht ganz die Lösung sein.

[Hightech]

@ Matthias:

Immer wieder beeindruckend, dass Du mehr Infos hast als Gira :-)

Ganz schlau werde ich bzgl. der Speicherverwaltung des HS aber noch nicht so wirklich.....

@ Manuel:

Der Memfree muss lt. Gira > 23 MB sein, liegt er darunter, kann es zu Übertragungsproblemen kommen...

@ all:

Habe inzwischen auch eine Antwort von Gira:
Es liegt wohl an meinem vielen Webabfragen (u.a. TVMovie mit jedem Fernsehsender einzeln plus jeweils Details zu den Sendungen) - die werden wohl in den RAM geschrieben und dort vorgehalten. Wie lange sie vorgehalten werden, konnte man mir nicht sagen, gab mir aber den Tip sie weniger haufig auszuführen (was für mich darauf hindeutet, dass das Ergebnis einer Abfrage nicht sofort gelöscht wird, wenn die Abfrage erneut ausgeführt wird und durchlauft)

Werde also heute abend mal fleißig meine Webabfragen ausbauen/reduzieren (und parallel wohl doch irgendwie schauen, wie ich meinen HS gegen einen FS upgraden kann...

Olaf

[DJGockel]

da ich auch immer noch mit Übertragungsproblemen zu kämpfen habe,
hier mal meine Daten vond er Debugseite:
total: used: free: shared: buffers: cached:
Mem: 92676096 74526720 18149376 0 8110080 13598720
Swap: 0 0 0
MemTotal: 90504 kB
MemFree: 17724 kB
MemShared: 0 kB
Buffers: 7920 kB
Cached: 13280 kB
Active: 4356 kB
Inact_dirty: 16844 kB
Inact_clean: 0 kB
Inact_target: 8 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 90504 kB
LowFree: 17724 kB
SwapTotal: 0 kB
SwapFree: 0 kB

LOAD: 0.14 0.09 0.08 30/72 167

UP : 927.22 650.69

[MatthiasS]

High-Level Statistics

• MemTotal: Total usable ram (i.e. physical ram minus a few reserved bits and the kernel binary code)
• MemFree: Is sum of LowFree+HighFree (overall stat)
• MemShared: 0; is here for compat reasons but always zero.
• Buffers: Memory in buffer cache. mostly useless as metric nowadays
• Cached: Memory in the pagecache (diskcache) minus SwapCache
• SwapCache: Memory that once was swapped out, is swapped back in but still also is in the swapfile (if memory is needed it doesn't need to be swapped out AGAIN because it is already in the swapfile. This saves I/O)

Detailed Level Statistics
VM Statistics

VM splits the cache pages into "active" and "inactive" memory. The idea is that if you need memory and some cache needs to be sacrificed for that, you take it from inactive since that's expected to be not used. The vm checks what is used on a regular basis and moves stuff around.
When you use memory, the CPU sets a bit in the pagetable and the VM checks that bit occasionally, and based on that, it can move pages back to active. And within active there's an order of "longest ago not used" (roughly, it's a little more complex in reality). The longest-ago used ones can get moved to inactive. Inactive is split into two in the above kernel (2.4.18-24.8.0). Some have it three.

• Active: Memory that has been used more recently and usually not reclaimed unless absolutely necessary.
• Inact_dirty: Dirty means "might need writing to disk or swap." Takes more work to free. Examples might be files that have not been written to yet. They aren't written to memory too soon in order to keep the I/O down. For instance, if you're writing logs, it might be better to wait until you have a complete log ready before sending it to disk.
• Inact_clean: Assumed to be easily freeable. The kernel will try to keep some clean stuff around always to have a bit of breathing room.
• Inact_target: Just a goal metric the kernel uses for making sure there are enough inactive pages around. When exceeded, the kernel will not do work to move pages from active to inactive. A page can also get inactive in a few other ways, e.g. if you do a long sequential I/O, the kernel assumes you're not going to use that memory and makes it inactive preventively. So you can get more inactive pages than the target because the kernel marks some cache as "more likely to be never used" and lets it cheat in the "last used" order.

Memory Statistics

• HighTotal: is the total amount of memory in the high region. Highmem is all memory above (approx) 860MB of physical RAM. Kernel uses indirect tricks to access the high memory region. Data cache can go in this memory region.
• LowTotal: The total amount of non-highmem memory.
• LowFree: The amount of free memory of the low memory region. This is the memory the kernel can address directly. All kernel datastructures need to go into low memory.
• SwapTotal: Total amount of physical swap memory.
• SwapFree: Total amount of swap memory free.
• Committed_AS: An estimate of how much RAM you would need to make a 99.99% guarantee that there never is OOM (out of memory) for this workload. Normally the kernel will overcommit memory. That means, say you do a 1GB malloc, nothing happens, really. Only when you start USING that malloc memory you will get real memory on demand, and just as much as you use. So you sort of take a mortgage and hope the bank doesn't go bust. Other cases might include when you mmap a file that's shared only when you write to it and you get a private copy of that data. While it normally is shared between processes. The Committed_AS is a guesstimate of how much RAM/swap you would need worst-case.

[MatthiasS]

Ob das als Müll zu bewerten ist, ist eben die Frage. Das kann nur Dacom beantworten, aber die lassen sich mit einer Beschreibung der Debug-Seite seit Jahren zeit - leider.

Gerade mal in verfügbare HS3 geschaut: dirty zwisch 16 MB und 11 MB.

Ich behaupte - ohne es beweisen zu können - dass dieser Wert nichts mit deinen Problemen zu tun hat.

[Hightech]

Bei meinem FS 23 MB, glaube nicht, dass das relevant ist.

Hmm, wenn ich einen FS hätte, hätte ich die Probleme wohl auch nicht.....wenn aber beim HS bei einem Speicher von 64 MB fast ein Viertel mit "Müll" belegt ist, finde ich das schon kritisch (zumal noch weitere 13 MB Cache dazukommen).

Die Gira-Hotline hatte bisher auch keine Erklärung für den inact_dirty-Bereich....

Gruß

Olaf

[makki]

Dito, HS3 (2.2): Inact_dirty: 20020 kB

Keine Probleme (zumindest nicht diese)

Makki

[MatthiasS]

Bei meinem FS 23 MB, glaube nicht, dass das relevant ist.