Uebertragungsdauer auf PC

[FireBird]

Da gibt es einige Delay-Routinen in der Firmware.

[quote=""Harvey""]Ich wollte eigentlich schon immer mal die Firmware übertakten, aber ich komme ja zu nix. [/quote]
Schluss mit Lustig. Der General soll Dich vergattern und dann gibt es keine Ausreden sondern ein Tuning-TAP. :

[Kobold]

Gibt's diesen "Torbomode" auch ohne TAPs? Ich habe bisher weder am Topf noch in Altair eine Möglichkeit zur schnelleren Übertragung gefunden.

Gruß, Kobold

[hgdo]

Das hat mit Taps nichts zu tun.

In Altair istr der Turbo-Button eigentlich nicht zu übersehen.

[Alter Sack]

[quote=""hgdo""]In Altair istr der Turbo-Button eigentlich nicht zu übersehen.[/quote]

Stimmt eigentlich .

[Kobold]

Tatsächlich! Jetzt sehe ich ihn auch. Hurra!

[stief]

Mal blöd gefragt, da ich die Übertragungsgeschwindigkeit auch für stark verbesserungsbedürftig halte:
irgendeiner muss doch wissen, was der Flaschenhals ist?
Und falls es wirklich die CPU ist, würde es dann nicht Sinn machen, diese zumindest in den neuen Geräten durch eine schnellere CPU zu ersetzen? Das kann doch nicht so teuer sein, oder?

[satgerd]

dummy

[satgerd]

Das will ich stark befürworten. Dann könnte man auch die Bilder, die man per PC auf den Topf bringt, nicht mehr so lahm anschauen können. So teuer sind die bißchen schnelleren Prozessoren doch heute nicht mehr. Bei 600 €, die ich für den Topf 5000 bezahlt habe, ginge der Aufpreis im Rauschen unter.
Irgendwas hat sich jetzt aufgehängt, Hoffentlich steht das jetzt nicht zweimal drin.

[hgdo]

[quote=""stief""]Und falls es wirklich die CPU ist, würde es dann nicht Sinn machen, diese zumindest in den neuen Geräten durch eine schnellere CPU zu ersetzen? Das kann doch nicht so teuer sein, oder?[/quote]
Gibt es denn zu der verwendeten CPU einen pinkompatiblen, schnelleren Typ?

[Kobold]

Altair mit Turbomode: 8 Minuten pro GByte. Ist das in Ordnung?

[Bonni]

[quote=""Kobold""]Altair mit Turbomode: 8 Minuten pro GByte. Ist das in Ordnung?[/quote]
Absolut OK...

[hagge]

[quote=""satgerd""]Das will ich stark befürworten. Dann könnte man auch die Bilder, die man per PC auf den Topf bringt, nicht mehr so lahm anschauen können. So teuer sind die bißchen schnelleren Prozessoren doch heute nicht mehr. Bei 600 €, die ich für den Topf 5000 bezahlt habe, ginge der Aufpreis im Rauschen unter.[/quote]
Da denkst Du leider etwas falsch. In einem solchen Gerät ist kein x86-Prozessor drin, von dem es zig verschiedenen Versionen in allen Geschwindigkeitsklassen gibt. Sondern es ist ein Microcontroller. Das sind zwar auch CPUs, aber die haben dazu schon jede Menge eingebaute Peripherie auf dem Chip mit dabei. Im Fall von Topfield ist das ein Chip mit dem Codename Emma2, und das ist ein auf MIPS basierender Microcontroller von NEC. Und der hat zum Beispiel schon den kompletten MPEG-Decoder in Hardware mit drauf. In dieser Beziehung kann der Chip weit mehr als ein x86-Prozessor, da er sozusagen schon Features mit drin hat, die beim PC von der Grafikkarte erledigt werden müssen. Aber davon gibt es eben *keine* anderen Varianten als genau die, die in den Töpfen verbaut sind.

Und weil eben bei so einem Microcontroller viel von der Arbeit durch spezialisierte Hardware erledigt wird, braucht die eigentliche CPU gar nicht mehr sehr schnell sein. Und genau darum stellt für so eine CPU dann eine so hohe Datenrate, wie sie USB2.0 theoretisch bietet, ein unüberwindbares Hindernis dar. Ich habe gerade die Taktrate der CPU vom Topf nicht mehr genau im Kopf, aber ich glaube es waren unter 200 MHz. Wie will man da Daten mit 60 MByte pro Sekunde übertragen? Das wären ja gerade mal 3 Takte pro Byte, also 3 Maschineninstruktionen. Nene, ein bisschen mehr muss ein Programm da schon machen, um die Daten von der Festplatte zu lesen und zum USB-Port durchzureichen.

Oft ist auch gar nicht die Taktrate des Prozessors selbst die Bremse, sondern die Taktrate des Busses. Und die beträgt oft nur 33, 50, 66 oder 100 MHz. Und die müssen sich *alle* verschiedenen Peripheriegeräte teilen, also z.B. MPEG-Decoder, CPU, DMA, IDE-Interface, usw. Und wenn eben schon ein Großteil der Bandbreite durch die Peripherie draufgeht, kann die CPU eben nur noch einen gewissen kleinen Anteil davon abbekommen. Und was ist bei einem Bruchteil von 100MHz Busbandbreite dann noch übrig? Garantiert nicht genug, um 60 MByte/s (=480 MBit/s) zu übertragen. Da finde ich die erreichten 20 MBit/s schon gar nicht so übel...

Besser wird das erst, wenn der Microcontroller dann USB-Device oder den Ethernet-Controller auch gleich mit an Bord hat, so dass diese direkt per DMA auf die Daten zugreifen können. Aber ob es solche Microcontroller gibt, ist halt die Frage. Ohne ein Non-Disclosure-Agreement bekommt man nicht mal diese Information von den entsprechenden Firmen wie NEC.

Gruß,

Hagge

[hgdo]

Kompliment Hagge, ein fundierter Beitrag

[Bonni]

[quote=""hgdo""]ein fundierter Beitrag[/quote]
Allerdings, hat hagge oft, sollte alles im wiki gesammelt werden!

[Harvey]

Wenn der Compiler mal was optimieren würde könnte es durchaus schneller gehen.

Hier ein Beispiel, dass Wörter zum USB-Controller schickt (ich bin da nicht drüber gestolpert, das war Firebird).

Code: Alles auswählen

}{putToUSBCrtl:                                                             ???
     0r	addiu	$sp,-32			
     4r	sw	$s5,20($sp)		
     8r	sw	$s6,24($sp)		
     cr	sw	$fp,28($sp)		
    10r	move	$fp,$a0			
    14r	move	$s6,$a1			
    18r	sltiu	$at,$fp,32=0x0020	
    1cr	bne	$at,0,58r		
    20r	nop				
    24r	lui	$t9,0xbf40		
    28r	lhu	$s5,0($t9)		# bf400000 @EMMA_USB_RegAddrPtr
    2cr	lui	$t8,0xbf40		
    30r	andi	$t7,$fp,0xff		
    34r	sh	$t7,0($t8)		# bf400000 @EMMA_USB_RegAddrPtr
    38r	lui	$t6,0xbf40		
    3cr	andi	$s6,0xff		
    40r	sh	$s6,2($t6)		# bf400002 @EMMA_USB_RegData
    44r	lui	$t9,0xbf40		
    48r	andi	$s5,0xff		
    4cr	sh	$s5,0($t9)		# bf400000 @EMMA_USB_RegAddrPtr
    50r	beq	0,0,6cr			
    54r	nop				
    58r	sll	$t9,$fp,1		
    5cr	lui	$t8,0xbf40		
    60r	addu	$t9,$t8			
    64r	andi	$s6,0xff		
    68r	sh	$s6,0($t9)		
    6cr	lw	$s5,20($sp)		
    70r	lw	$s6,24($sp)		
    74r	lw	$fp,28($sp)		
    78r	addiu	$sp,32			
    7cr	jr	$ra			
    80r	nop				

Warum das Umkopieren nach von a0 und a1 nach fp und s6?
t-Register müssen nicht gesichert werden und eigen sich für so kurze Codesegmente besser.
Warum das mehrfache Laden von bf400?

So sollte es auch klappen (falls frei von Rechtschreibfehlern):

Code: Alles auswählen

}{putToUSBCrtl:                                                             ???
     0r	sltiu	$at,$a0,32=0x0020	
     4r	bne	$at,0,34r		
     8r	lui	$t9,0xbf40		
     cr	lhu	$t8,0($t9)		# bf400000 @EMMA_USB_RegAddrPtr
    10r	andi	$t7,$a0,0xff
    14r	nop			
    18r	sh	$t7,0($t9)		# bf400000 @EMMA_USB_RegAddrPtr
    1cr	andi	$t6,$a1,0xff		
    20r	nop			
    24r	sh	$t6,2($t9)		# bf400002 @EMMA_USB_RegData
    28r	andi	$t8,0xff		
    2cr	jr	$ra			
    30r	sh	$t8,0($t9)		# bf400000 @EMMA_USB_RegAddrPtr
    34r	sll	$t8,$a0,1		
    38r	addu	$t9,$t8			
    3cr	andi	$t7,$a1,0xff		
    40r	jr	$ra			
    44r	sh	$t7,0($t9)		

die obere Hälfte (a0>32) benötigt 13 statt 28 Taktzyklen
die untere Hälfte (a0<=32) benötigt 8 statt 20 Taktzyklen

In diesem Fall weiss ich allerdings nicht, ob es was bringt die USB-Seite zu optimieren, weil der ATA-Controller auch nicht der schnellste ist. Vielleicht probiere ich das mal über Ostern aus.

Die Reihenfolge des Codes sieht übrigens deshalb so merkwürdig aus, weil der einem Sprungbefehl folgende Befehl schon in der Pipeline ist und deshalb noch vor der Sprungausführung durchgeführt wird.


Edit: 2 NOP sind leider doch notwendig, weil der Chip nicht weniger als 18ns verkraftet. Laut SPEC (Net2272) ist es eigentlich noch mehr (28ns Erholung); vielleicht ist deshalb die USB-Verbindung nicht die stabilste.

[ibbi]

Na denn, Firmware patchen, ausprobieren und berichten.

Ein Fast-USB-Patch wird weggehen wie warme Semmeln. :

[Bonni]

Was ist eigentlich aus der Geschichte von Kimi geworden (non-debug-Version tfbulk.sys)?

[Harvey]

Ist mir zwar kein Begriff, das wird aber nicht die Bremse sein.

Wie ich herausgefunden habe müsste ich wo anders patchen (dort wo bf40000a gelesen/geschrieben wird), und da läßt sich in der innersten Schleife nur 33% einsparen. Die Routinen von oben Laufen in äußeren Schleifen und sind damit nicht den Aufwand Wert.

Außerdem sind die 33% nur theoretischer Natur, denn die Plattenzugriffe brauchen auch seine Zeit.

[aledoe]

[quote=""Harvey""]Ist mir zwar kein Begriff, das wird aber nicht die Bremse sein.

Wie ich herausgefunden habe müsste ich wo anders patchen (dort wo bf40000a gelesen/geschrieben wird), und da läßt sich in der innersten Schleife nur 33% einsparen. Die Routinen von oben Laufen in äußeren Schleifen und sind damit nicht den Aufwand Wert.

Außerdem sind die 33% nur theoretischer Natur, denn die Plattenzugriffe brauchen auch seine Zeit.[/quote]
Jetzt nicht kneifen. Wir wollen den Fast-USB-Firmware-Patsch!

[Harvey]

Man kann es ausrechnen
2MB/s isses jetzt, sind ca. 1 Millionen Wörter/s
Einsparen kann man pro Wort (2 Bytes) 5 Instruktionen macht
5/166 * 100% = 3%

Dafür die Mühe?