Neuer kombinierter MMC Treiber + neue Philips Verkabelung

Sklaventreiber
satsuse
Interessierter
Interessierter
Beiträge: 21
Registriert: Samstag 12. Mai 2007, 19:12

Neuer kombinierter MMC Treiber + neue Philips Verkabelung

Beitrag von satsuse »

Servus,

habe mal einen kombinierten mmc Treiber (mmccombo.o) gemacht und die Sourcen heute eingecheckt. Hier eine Auflistung von (neuen) Eigenschaften:

- unterstützt die mmc Verkabelung
- unterstützt die mmc2 Verkabelung
- Unterstützt eine weitere neue Verkabelung über PB[16:19] - damit geht auch in der Philips die SD, ohne PA8 und PA9 von der tts/1 zu klauen. Die 1er Vekabelung ist hier nicht möglich, PB22 und PA7 sind nicht aus der CPU-landingzone raus geroutet, PB23 hängt am FP.
- Leseoptimierungen aus dem mmc2 auch auf die anderen Verkabelungen übertragen.
- Schreiboptimierung für 1er und 4er Verkabelung ist deutlich schneller (1/3 und mehr), als im mmc Treiber
- Treiber unterstützt die IO Routinen aus dem mmc Treiber oder die optimierten über opt=[0:1] mit default zu 1
- Treiber nimmt keine Resourcen, die der CPM zugeschlagen sind ohne dazu über forcehw=1 (default zu0) "gezwungen" zu werden. - Also mmc2 Verkabelung üblicherweise nur mit forcehw=1
- Treiber kann für eine bestimmte Verkabelung gestartet werden oder automatisch die verwendete Variante ermitteln über wiringopt=[0:4], wobei 0 für die Automatik (default) steht und 3 nicht unterstützt wird (der Vollständigkeit halber dem mmc3test entnommen).

Bei der Arbeit am Treiber fiel mir ein Problem im Zusamenhang mit der cam.o auf, die bei Ihrem Init (ich denke) unnötigerweise den kompletten Port-B nullt. Dadurch werden in allen mmc Verkabelungen die SD_CS Leitung low gezogen und die SD Karte damit selektiert, weitere Portspielereien können dann leicht zu Fehlverhalten führen, wenn der mmc Treiber vor dem cam.o gestartet wurde. Ich habe in der cam.c eine Änderung diesbezüglich gemacht, die bei mir auf einer Nokia problemlos läuft. Habe es selbst noch nicht auf Sagem und Philips getestet. Daher noch nicht ins CVS eingecheckt. Hänge es mal hier an, wer mag, kann es dann ja auf Sagem und Philips testen. Die Änderung betrifft nur den Treiber Init, wenn also der µCode im SEC ist, dann ist alles glatt gegangen.

cam.rar


Folgend noch ein paar Infos zu Anschluß und Belegung:

Code: Alles auswählen


//
//                     ----------------
//                    / 1 2 3 4 5 6 7 x| MMC/SC Card
//                    |x               |
//

1 SD_CS 
2 SD_DI
3 GND
4 +3.3V
5 SD_CLK
6 GND
7 SD_DO 

Connect a 50k to 100k resistor as pullup between SD_DO and +3.3V (7 to 4)

NOKIA MODEMCON:

//
//     |
//    _----------------------------------------
//   | |        dbox2 tuner                   |
//    ~----------------------------------------
//     |
//     |
//     |        1  3  5  7  9 11 13 15 17 19
//     |        2  4  6  8 10 12 14 16 18 20
//     |

01 GND
02 PB17
03 PC15
04 PB18
05 PB23
06 PB16
07 NC
08 +5V
09 RST(6) (not sure about index)
10 GND
11 PA8
12 PA9
13 PC4
14 PA7
15 GND
16 +3V
17 PB19
18 PB22
19 GND
20 SLEEP(1)

PHILIPS MODEMCON:

[power  supply]

 DCD 12 11 PA09 
 RTS 10 09 PA08 
  NC 08 07 PB17 
toFP 06 05 PB16 
 GND 04 03 NC 
 GND 02 01 5V 


Softmodem {
PB17 = DTR
PC15 = DCD
PA08 = TXD
PA09 = RXD
PC04 = RTS
}

IDE-IF {
PC15 = IRQ (standard, alternative IRQ = 6 -> not on modem-connector, RI of RS232)
}

mmc1 wiring {
PB23 = SD_CS
PA07 = SD_DO
PB19 = SD_DI
PB22 = SD_SCL
}

mmc2 wiring {
PB16 = SD_CS
PA09 = SD_DO
PA08 = SD_DI
PB17 = SD_CLK
}

mmc3 wiring {
PB22 = SD_CS
PA09 = SD_DO
PA08 = SD_DI
PA07 = SD_CLK
}

mmc4 wiring {
PB16 = SD_CS
PB18 = SD_DO
PB19 = SD_DI
PB17 = SD_CLK
}
PB[18:19] sind in der Philips hier zu finden:

Bild

Hier noch eine Schreibtimingübersicht:

1er und 4er Verkabelung:
Bild
2er Verkabelung:
Bild

Der Weg aus dem PPC Core zu den GPIOs ist leider 5 clocks lang, ich habe keine Ahnung, ob das durch einem speziellen (eigenen) µCODE im CPM umgehbar wäre, kenne mich da noch nicht so aus, ist eine Art Anfängerprojekt. Also ist von Portänderung zu Portänderung mit einem minimum Delay von etwa 75ns zu rechnen. Das heißt für das schreiben in der 1er und 4er Verkabelung mit gleichzeitigem setzen von clock low und SD_DI geht es nicht unter 150ns pro Bit. Im combotreiber ist das aktuell nicht erreicht, im standalone aber sehr wohl. Hatte noch keine Zeit herauszufinden wieso. Hier lässt sich aber sicherlich in der äußeren Schleife für den Block was optimieren. - Am Ende kommen beide Treiber aber auf ähnliche Geschwindigkeiten, da der Overhead beim Standalone (siehe weiter unten) höher ist. Mal zur Vollständigkeit auch dazu ein Auszug:

Bild

Ein circa Vergleich der verschiedenen low-level Teile:

Code: Alles auswählen

mmc driver continuous write:
- clocking 8 Bits to card 4860ns
- inbetween bytes 920ns
- byte total 5780ns
-> write benchmark 1.00

mmc driver continuous read:
- clocking 8 Bits out of card 4840ns
- inbetween bytes 960ns
- byte total 5800ns
-> read benchmark 1.00

mmc_opt driver continuous write:
- clocking 8 Bits to card 1040ns
- inbetween bytes 620ns
- byte total 1660ns
-> write benchmark 3.48

mmc_opt driver continuous read:
- clocking 8 Bits out of card 1590ns
- inbetween bytes 290ns
- byte total 1880ns
-> read benchmark 3.09

mmc2 driver continuous write:
- clocking 8 Bits to card 1660ns
- inbetween bytes 630ns
- byte total 2290ns
-> write benchmark 2.52

mmc2 driver continuous read:
- clocking 8 Bits out of card 1630ns
- inbetween bytes 310ns
- byte total 1940ns
-> read benchmark 2.99
Optimierte Treiber für 1er und 4er Verkabelung stehen auch standalone zur Verfügung, machen aber wenig Sinn und sind recht oberflächliche Arbeitsversionen:

Standalone für 1er Verkabelung
Standalone für 4er Verkabelung


Damit steht also auch für die 1er Verkabelung ein optimierter Treiber zur Verfügung, die ja auch von der kommenden d2µSD Platine für den Nokia Abgriff verwendet wird:
Bild


Viel Spaß damit und noch einen schönen Sonntag.
Zuletzt geändert von satsuse am Sonntag 27. Mai 2007, 08:13, insgesamt 3-mal geändert.
sagemol
Einsteiger
Einsteiger
Beiträge: 193
Registriert: Donnerstag 11. Mai 2006, 09:26

Beitrag von sagemol »

Du bist mein Held ! :D

Jetzt mal testen ....

Danke !

Greez !
sagemol
Einsteiger
Einsteiger
Beiträge: 193
Registriert: Donnerstag 11. Mai 2006, 09:26

Beitrag von sagemol »

Erster Bericht:

Sagem 64MB, 75MHz
Standalone Typ 1:

Schreiben:

time cat /prco/kcore > /mmc/testfile01
real 8m 53.26s
user 0m 0.33s
sys 1m 4.18s

Das macht bei resultierender Filegrösse von 98873344
mal eben 180kB/s schreibenderweise.
Mit original mmc.o bin ich hier nicht über 130kB/s gekommen.

Lesen:
time cat testfile01 > /dev/null
real 4m 1.15s
user 0m 0.24s
sys 3m 6.88s

Das sind dann mal schlappe 400kB/s.

Du bist wirklich mein Held ! :-)

Schreibend geht wohl nicht mehr bei Typ1 Verdrahtung, oder ?
Naja, irgendwann mauss man auch mal zufrieden sein ... :D

Edit:
unnötig zu sagen, dass die cam.o von Dir auf der Sagem HWrev 21 keine Probleme macht...

Greez !
Zuletzt geändert von sagemol am Sonntag 20. Mai 2007, 20:40, insgesamt 2-mal geändert.
PauleFoul
Wissender
Wissender
Beiträge: 1839
Registriert: Sonntag 17. August 2003, 01:39

Beitrag von PauleFoul »

@ satsuse

Sag ma wo bekomm ich den diese geile Platine für die Nokia her??? :wink:

Ansonsten wirklich absolut geniale Arbeit von Dir!

Du hast nicht zufällig auch ein IDE-Interface.... :D :D


Gruß
____Paule
sagemol
Einsteiger
Einsteiger
Beiträge: 193
Registriert: Donnerstag 11. Mai 2006, 09:26

Beitrag von sagemol »

Entweder in der Bucht, oder aber da:

w*w*w.digi-buy.de

Aber Vorsicht, da gibts auch die "bösen" Sachen...

Greez !
satsuse
Interessierter
Interessierter
Beiträge: 21
Registriert: Samstag 12. Mai 2007, 19:12

Beitrag von satsuse »

@ sagemol,

Danke für die Info zur cam.o -

Schreiben geht schneller, hier sind 200k :D gemessen worden, hängt aber zum Teil auch von der Organisation der Karte ab.

Gerade, wo Du auf 75MHz übertaktet hast. Testweise sind mit normaler Clock (und das hier hängt 1:1 mit der Clock zusammen) etwa 200k schreibend und etwa 300k lesend gemessen worden. Habe mich aber selber damit gar nicht so beschäftigt, habe nur auf das low-level Timing geachtet.

Mir ist noch eingefallen, dass die Standalones noch keinen Workaround für das cam.o Problem haben, hier kann es Probleme geben. Werde daran aber erst mal nicht mehr basteln.

Edit 1:

Fühle mich geehrt :D - Aber Helden gibt es hier ganz Andere. Das ist nur ein kleines Anfängerprojekt um mich erst mal zurecht zu finden. Aber natürlich schön, wenn es ankommt ;)
Zuletzt geändert von satsuse am Sonntag 20. Mai 2007, 21:25, insgesamt 1-mal geändert.
satsuse
Interessierter
Interessierter
Beiträge: 21
Registriert: Samstag 12. Mai 2007, 19:12

Beitrag von satsuse »

@ PauleFoul,

die Platine wird es ab KW23, vielleicht KW22 geben. Derzeit nur an der von Sagemol genannten Stelle zum vergünstigten Vorverkaufspreis, noch nicht in der Bucht.

Danke für die Blumen. Wünsche auch Dir viel Spaß mit den Treibern.
sagemol
Einsteiger
Einsteiger
Beiträge: 193
Registriert: Donnerstag 11. Mai 2006, 09:26

Beitrag von sagemol »

Ähm nur noch mal zur Info:
mit dem Combo komm ich nur auf 140kB/s schreibend.
Ich probiers aber nochmal...

Greez !
satsuse
Interessierter
Interessierter
Beiträge: 21
Registriert: Samstag 12. Mai 2007, 19:12

Beitrag von satsuse »

@ sagemol,

na gut, werde mich gleich noch mal ein wenig mit dem Schreiben beschäftigen, dass es nicht optimal ist, sagte ich ja schon.

Die Werte, die Du da gemessen hast sind aber nicht unbedingt belastbar, es sei denn die sind ohne "Pufferung" entstanden. Da ich nicht weiß, wie ich die Pufferung abschalten kann, habe ich so auch nie gemessen, sondern immer nur den Analyzer bemüht. - Will heißen, wenn ich was auf die mmc schicke, dann habe ich u.U. lange bevor ein realer Hardwarezugriff passiert schon die "fertig" Rückmeldung. Die Daten werden dann teilweise ettliche Sekunden später geschrieben. Als Linux Neuling, übersehe ich hier allerdings möglicherweise etwas total naheliegendes ;)

Edit 1:

Übrigens: Auf Deine Art gemessen, komme ich bei einer 20MB File auf 233879 Bytes/s mit der 1er Verkabelung.
sagemol
Einsteiger
Einsteiger
Beiträge: 193
Registriert: Donnerstag 11. Mai 2006, 09:26

Beitrag von sagemol »

@satsuse

Linux Neuling ? Cool ! :D :D

Ja, da wird natürlich kräftig gepuffert, aber das kannst Du nicht wirklich abschalten, weil da u.U. viele "Pufferer" beteiligt sind.
Deshalb musst Du zum realen Testen Datenmengen nehmen, die auf alle Fälle grösser als der vorhandene Arbeitsspeicher sind.
Bei einem 20MB File ist das noch etwas ungenau, weil da die ersten
10-16MB erstmal ganz schnell im Buffer verschwinden :-)
Deswegen nehm ich immer grössere Sachen,
dauert zwar länger, aber ist genauer.


Greez !
Gorcon
Tuxboxer
Tuxboxer
Beiträge: 5873
Registriert: Samstag 23. Februar 2002, 22:46

Beitrag von Gorcon »

Kurze zwischenfrage:
mit dem alten Treiber und Standardbelegung bei der Nokia konnte ich mp3s mit 128kbit/s gerade so ungestört abspielen. geht jetzt mehr? (wegen prozessorlast usw. kann man ja nicht die volle Datenrate nutzen)

Gruß Gorcon
satsuse
Interessierter
Interessierter
Beiträge: 21
Registriert: Samstag 12. Mai 2007, 19:12

Beitrag von satsuse »

@ Gorcon,

natürlich geht jetzt mehr, der low-level Teil braucht halt weniger Zeit. Während eines Blockzugriffes wird der Treiber vom Kernel eh nicht unterbrochen (wenn ich das richtig verstehe), das heißt je weniger Zeit für den low-level Teil benötigt wird, desto weniger Prozessorlast bei gleicher Datenmenge. Gerade im Read sollte sich das deutlich bemerkbar machen.

Im write sieht es da schon etwas anders aus, ...

@ sagemol and all,

Habe die Zeit für das shiftout eines Bytes nun von 1590ns auf 1300ns runter, da geht auch noch ein wenig mehr. Das ist aber alles unsinnige Kosmetik, denn die Hauptzeit geht ganz woanders drauf. (Ich habe aber eine Idee, auch da anzusetzen, das braucht aber Zeit und die habe ich gerade eigentlich nicht ;) ).

Kurz zur Info:
All diese schönen Karten nutzen NAND Flash, der ist schön günstig, hat aber einen Nachteil. Um diese zu beschreiben muss die ganze "Page" gelöscht und neu geschrieben werden. Das machen SD Karte intern (haben einen eigenen µ dafür). Je nachdem also, wie die Karte organisiert ist (Pagesize) und der Geschwindigkeit, mit der der µ die Page löschen und neu beschreiben kann, variert auch die real erreichbare Schreibzeit.

1 Byte schreiben heißt trotzdem eine ganze Page löschen und neuschreiben. Es geht also immer eine Menge Zeit für Dinge drauf, die wir gar nicht wollen. Um das mal deutlich zu machen, wo die Zeit drauf geht, hier mal eine Übersicht über low-level blockwrites. A nach B ist das gesamte SD_CS Fenster und X bis Y ist der Anteil, der Datenübertragung an die Karte, der Rest ist verschwendete Prozessorlast und Zeit. Das geht besser (weil man es ja weiß und sich darauf einrichten kann).

Bild

Werde noch versuchen den low-level Byteshift Zeitrahmen etwas weiter zu drücken und mich dann noch mal mit einer Testversion melden.

Edit 1:

So,

habe 1 Byte->Out nun bei 1260ns, das sind gerade noch 60ns (4 instruction cycles oder besser clocks) für die Schleife. Das ganze sieht dann so aus:

Bild

Ist eingecheckt.
Zuletzt geändert von satsuse am Montag 21. Mai 2007, 10:38, insgesamt 1-mal geändert.
sagemol
Einsteiger
Einsteiger
Beiträge: 193
Registriert: Donnerstag 11. Mai 2006, 09:26

Beitrag von sagemol »

@Gorcon

Na klar geht da mehr, wenn Du Dir mal anschaust, dass ich mit 400kByte/s lesen kann...
Allerdings hat doch da (wenn ich mich recht erinnere) der Audioplayer ein Problem, ich glaube da ist bei 192 kBit/s Schluss, oder ?
Muss allerdings noch dazu sagen, dass meine Karten immer ext2 formatiert sind.

@satsuse

Ich versteh zwar normalerweise nur ungefähr 25% von dem was Du bzgl. der Hardware schreibst,
aber so langsam fange ich an, zu begreifen... :D
Absolut cool, dass Du Dich da reinhängst, vor allem, weil Du auch noch das Glück hast, das entsprechende Equipment zu besitzen :D :D

Wenn Du irgendetwas zu testen hast, dann immer her damit.
Ich habe immer ne Testbox da stehen, die man mal schnell plätten kann.

Greez !
satsuse
Interessierter
Interessierter
Beiträge: 21
Registriert: Samstag 12. Mai 2007, 19:12

Beitrag von satsuse »

@ sagemol,

hatte sich gerade überschnitten, das (nahezu) Maximum bei der aktuellen Herangehensweise ist mit 1260ns pro Byte nun erreicht. Aktuelle Version ist im Repository.

Ansatz:
Der Treiber wird immer nur zum schreiben von einem 512 Byte Block aufgerufen (wenn es mehr wären, dann würde auch ein kleiner Fehler in der mmc_write_block zum tragen kommen, denn dann würde nämlich nr_sectors-mal der erste Sektor geschrieben).

Ich überlege dann doch noch mal an einer Idee. / Bräuchte dazu aber einen Rückruftimer und weiß nicht, ob es soetwas für ein Kernelmodul gibt (hoffe aber doch).
sagemol
Einsteiger
Einsteiger
Beiträge: 193
Registriert: Donnerstag 11. Mai 2006, 09:26

Beitrag von sagemol »

Danke !

Aber hättest Du vielleicht noch ne binary ?
Ich kann im Moment grade nix bauen...

Greez !
Gorcon
Tuxboxer
Tuxboxer
Beiträge: 5873
Registriert: Samstag 23. Februar 2002, 22:46

Beitrag von Gorcon »

Na klar geht da mehr, wenn Du Dir mal anschaust, dass ich mit 400kByte/s lesen kann...
Allerdings hat doch da (wenn ich mich recht erinnere) der Audioplayer ein Problem, ich glaube da ist bei 192 kBit/s Schluss, oder ?
Muss allerdings noch dazu sagen, dass meine Karten immer ext2 formatiert sind.
Deswegen frag ich ja. Von HDD spiele ich auch mp3s mit höheren Datenraten als 192kbit/s ab.

Gruß Gorcon
satsuse
Interessierter
Interessierter
Beiträge: 21
Registriert: Samstag 12. Mai 2007, 19:12

Beitrag von satsuse »

@ sagemol,

eine binary zum letzten check in habe ich gerade nicht mehr :oops:

Habe Dir hier eine Binary zu meiner aktuellen Bastelversion abgelegt.

Ich denke ich kann das ganze so umkrempeln, dass es noch ein wenig was an Geschwindigkeitsvorteil bringt (je nach Fragmentierung der Karte und Größe der File [je Größer desto trotz] bis zu 200% schnelleres write [rechnerisch hochgestecktes Ziel] ;) ).

[/url]
sagemol
Einsteiger
Einsteiger
Beiträge: 193
Registriert: Donnerstag 11. Mai 2006, 09:26

Beitrag von sagemol »

Also 200% wäre ja traumhaft, ich nehm aber auch 100% :D

Deine Bastelverson bin ich grade am Testen, die gibt auf der Console
während meiner Schreib-Leseoperation ab und an mal "mmc: Callback" aus.
Ist aber immerhin mit ca. 176kB/s beim Schreiben und ca. 375kB/s beim Lesen
auch schon Spitze.

Was ich noch nicht ganz verstehe:
Beim volle Pulle lesen aus der SD bleibt die Box trotz des wesentlich höheren Datendurchsatzes bedienbar, beim Schreiben nicht.
Aber dass ich das nicht ganz verstehe, liegt wohl am mangelnden Vorwissen meinerseits :D :D

Edit:
Kann heute leider nicht mehr weiter testen, muss wech....

Greez !
satsuse
Interessierter
Interessierter
Beiträge: 21
Registriert: Samstag 12. Mai 2007, 19:12

Beitrag von satsuse »

:cry: hat leider nicht geklappt mit den 200%, sorry.

Sind nur etwa 100% geworden :D

Das Relevante vorneweg:

1er Verkabelung, Nokia, normaler CPU Takt (hier sind teilweise noch Debug-Ausgaben mit in der Zeitmessung):

lesen: 336,4 K/s
schreiben: 393,6 K/s (kein Schreibfehler ;) - SanDisk 512er)

Zeit für 191,32 MB verteilt über 50 Dateien über FTP. Reboot zwischen Up- und Download.

Noch nicht mit anderen Verkabelungen getestet. Wenn genügend Rückmeldung da ist, werde ich eine Version mit den neuen Routinen auch einchecken.

Hier ein Downloadlink für die Testversion.


Das dumme am lernen ist ja, dass einem dann zuviel des Alten nicht mehr gefällt und man das dann nicht mehr so lassen will (kann). .....

Also vorneweg. Ich denke der Treiber braucht sehr viel Liebe, Zuwendung und Arbeit. Da hapert es an so vielen Stellen, da müsste soviel umgestrickt werden .... - Ich weiß nicht, ob ich das noch mal machen werde, eher nicht.

Das Teil ist weit davon entfernt, soetwas ähnliches wie korrekt zu sein. Der Codestruktur ist nicht schön, es gibt viele Fehler (die sich nicht auswirken), einiges ist halbherzig umgesetzt. Es kann nicht mit allen SD Karten laufen (Blockgröße ist zum Beispiel fix auf 512 Byte im Moment) und wenn ich mir ansehe, was noch so alles zu einem Blockdevicetreiber gehört (oder gehören kann) .......

Aber solange es schneller ist...

Doch nun erst mal viel Spaß beim testen.

Bis dann
sagemol
Einsteiger
Einsteiger
Beiträge: 193
Registriert: Donnerstag 11. Mai 2006, 09:26

Beitrag von sagemol »

ÄHHHHHH !!!!!
Wie, da war nix mit 200% ?????

Habe gerade getestet:

Code: Alles auswählen

/mmc/test # time cat /proc/kcore > testfile01
real    1m 55.51s
user    0m 0.20s
sys     0m 22.37s
/mmc/test # ls -la
drwxr-xr-x    2 root     root         1024 May 25 16:25 .
drwxr-xr-x    5 root     root         1024 May 25 16:24 ..
-rw-r--r--    1 root     root     64823296 May 25 16:26 testfile01
Das macht nach Adam Riese

SATTE 545 kB/s !!!

Und das auf einer nicht hochgetakteten Nokia 32MB Box
mit einer 512er Avant SD, eigentlich ne "noname"...

Das absolut Geile daran ist, dass die Box WÄHREND des Schreibens sogar noch BEDIENBAR ist !!!
Ich bin noch ganz feucht.... mit Tränen in den Augen...

DU BIST DEFINITIV MEIN HELD !!!

Ich teste gleich noch mit meiner 75MHz/64MB Sagem...


Greez !
satsuse
Interessierter
Interessierter
Beiträge: 21
Registriert: Samstag 12. Mai 2007, 19:12

Beitrag von satsuse »

Na ja,

das hängt von verschiedenen Faktoren ab.

1) Fragmentierung der Karte
2) Pagesize der Karte
3) Verteilung der Datenmenge auf wieviele Files (ich hatte 191 MB auf 50 Files)
4) Ich hatte noch mit Debug-Ausgaben getestet (die kosten auch Zeit)

Aber da musst Du doch nicht gleich weinen ;)

Freue mich auf weitere Testergebnisse ...


Edit 1:

Die Sache mit der Bedienbarkeit war gewollt ;) - 2 Probleme, eine Ursache und Lösung ...
sagemol
Einsteiger
Einsteiger
Beiträge: 193
Registriert: Donnerstag 11. Mai 2006, 09:26

Beitrag von sagemol »

Gut kannste gerne haben, mir ist nur eben die "liebe Arbeit" dazwischen gekommen.

Hier erstmal das Lesen auf der 32er Nokia, natürlich wie immer Typ1 verkabelt:

Code: Alles auswählen

/mmc/test # ls -la
drwxr-xr-x    2 root     root         1024 May 25 16:25 .
drwxr-xr-x    5 root     root         1024 May 25 16:24 ..
-rw-r--r--    1 root     root     64823296 May 25 16:26 testfile01
/mmc/test # time cat testfile01 > /dev/null
real    2m 42.28s
user    0m 0.15s
sys     1m 46.83s
Macht ca. 391kB/s lesenderweise. Völlig ausreichend ! :D :D :D
Jetzt klemm ich die Sagem an....

Greez !
sagemol
Einsteiger
Einsteiger
Beiträge: 193
Registriert: Donnerstag 11. Mai 2006, 09:26

Beitrag von sagemol »

So, jetzt die Sagem 64MB 75MHz, Typ1 Verdrahtung, Transcend 1GB SD, frisch formatiert ext2.
Wobei genau DIESE Karte immer Performanceprobleme hatte, sich sogar z.T. beim formatieren aufgehängt hatte etc.

Code: Alles auswählen

mke2fs 1.38 (30-Jun-2005)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
122112 inodes, 243838 blocks
12191 blocks (5.00%) reserved for the super user
First data block=0
8 block groups
32768 blocks per group, 32768 fragments per group
15264 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376

Writing inode tables: done                        
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 37 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
/mmc # 
/mmc # time cat /proc/kcore > testfile01
real    2m 20.64s
user    0m 0.27s
sys     0m 14.26s
/mmc # ls -la
drwxr-xr-x    3 root     root         4096 May 25 19:26 .
drwxr-xr-x   16 root     root            0 Jan  1  1970 ..
drwx------    2 root     root        16384 May 25 19:23 lost+found
-rw-r--r--    1 root     root     98471936 May 25 19:28 testfile01
/mmc # time cat testfile01 > /dev/null
real    3m 26.30s
user    0m 0.26s
sys     2m 42.66s
/mmc #
Das macht beim Schreiben mal wieder FETTE 531kB/s und beim Lesen ebenso FETTE 467kB/s.

Auf derselben Box mit einer Hama 1GB:
Nahezu identisches Ergebnis. Die 2 Sekunden Unterschied tu ich als Messfehler ab. :D :D

Ich find das so tierisch gut, dass man jetzt endlich wirklich mit ner SD _richtig_ arbeiten kann ....

VERY BIG THX !

Greez !
satsuse
Interessierter
Interessierter
Beiträge: 21
Registriert: Samstag 12. Mai 2007, 19:12

Beitrag von satsuse »

Freut mich, dass es Dich freut ;)

... und das sind doch mal Zahlen,

hört sich wirklich so an, als werde das langsam sinnvoll einsetzbar. Gut, dass es da jetzt auch eine passende plug'n play Platine in Form der d2µSD gibt ;)

Bei diesen Datenraten ist aber auch ohne zusätzliche Hardware nun nicht mehr viel Steigerung machbar. Um aber mehr Flash in die Box zu bekommen ohne mechanisch laufende Teile einsetzen zu müssen, ist das ja absolut ausreichend. Für Tools, Plugins, EPG, µCODEs (Samba, X-Server - ich beliebe zu scherzen) ist das, so denke ich, aktuell -die- Lösung.

Weitere Testergebnisse vor allem 2er Verkableung (beim Schreiben nicht so viel Durchsatz erwarten) sind weiterhin gerne gesehen.
sagemol
Einsteiger
Einsteiger
Beiträge: 193
Registriert: Donnerstag 11. Mai 2006, 09:26

Beitrag von sagemol »

satsuse hat geschrieben: Bei diesen Datenraten ist aber auch ohne zusätzliche Hardware nun nicht mehr viel Steigerung machbar.
Neee, muss auch nicht !

Du wirst lachen, das wird gerade mit swap getestetet und das geht anscheinend AUCH.... :D :D :D
Und dann liegste da gar nicht mehr soooo falsch mit dem X-Server (pruust).

Zur 2er Verkabelung komm ich heut nicht mehr, ich will die Löte heute auslassen.
Aber gibts denn dann überhaupt noch ne Lebensberechtigung für die 2er,
wenn die 1er eh die bessere (sprich schnellere) ist ?

EDIT: Ja, das war ein wenig kurz gedacht...
Klar die zweier brauchts ja für die Philips und die nicht-löt-variante in der Sagem...

Greez !
Antworten