Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #233787 > unrolled thread

FPGA jemand?

Back to article view | Back to de.sci.electronics

Contents

  FPGA jemand? Heinz Schmitz <HeinzSchmitz@gmx.net> - 2017-10-16 23:01 +0200
    Re: FPGA jemand? Rafael Deliano <rafael_deliano@arcor.de> - 2017-10-17 05:58 +0200
      Re: FPGA jemand? Heinz Schmitz <HeinzSchmitz@gmx.net> - 2017-10-17 15:01 +0200
      Re: FPGA jemand? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-17 15:20 +0200
    Re: FPGA jemand? Joerg <news@analogconsultants.com> - 2017-10-17 08:05 -0700
      Re: FPGA jemand? Heinz Schmitz <HeinzSchmitz@gmx.net> - 2017-10-17 17:40 +0200
        Re: FPGA jemand? Joerg <news@analogconsultants.com> - 2017-10-17 13:21 -0700
          Re: FPGA jemand? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-18 01:10 +0200
            Re: FPGA jemand? Joerg <news@analogconsultants.com> - 2017-10-17 17:01 -0700
              Re: FPGA jemand? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-18 13:39 +0200
                Re: FPGA jemand? Joerg <news@analogconsultants.com> - 2017-10-18 07:46 -0700
                  Re: FPGA jemand? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-18 21:37 +0200
                    Re: FPGA jemand? Joerg <news@analogconsultants.com> - 2017-10-18 16:15 -0700
                      Re: FPGA jemand? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-19 01:25 +0200
                        Re: FPGA jemand? Joerg <news@analogconsultants.com> - 2017-10-18 16:50 -0700
                          Re: FPGA jemand? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-19 09:01 +0200
                            Re: FPGA jemand? Joerg <news@analogconsultants.com> - 2017-10-19 07:21 -0700
                              Re: FPGA jemand? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-19 23:12 +0200
                                Re: FPGA jemand? Joerg <news@analogconsultants.com> - 2017-10-19 15:34 -0700
          Re: FPGA jemand? Heinz Schmitz <HeinzSchmitz@gmx.net> - 2017-10-18 12:54 +0200
            Re: FPGA jemand? Chris Jones <lugnut808@spam.yahoo.com> - 2017-10-18 22:25 +1100
              Re: FPGA jemand? Heinz Schmitz <HeinzSchmitz@gmx.net> - 2017-10-18 14:48 +0200
                Re: FPGA jemand? Hanno Foest <hurga-news2@tigress.com> - 2017-10-18 15:33 +0200
                  Re: FPGA jemand? Heinz Schmitz <HeinzSchmitz@gmx.net> - 2017-10-19 13:20 +0200
                    Re: FPGA jemand? Hanno Foest <hurga-news2@tigress.com> - 2017-10-19 13:46 +0200
                    Re: FPGA jemand? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-19 13:49 +0200
                Re: FPGA jemand? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-10-18 19:59 +0000
                  Re: FPGA jemand? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-18 22:04 +0200
                    Re: FPGA jemand? Joerg <news@analogconsultants.com> - 2017-10-19 11:57 -0700
                      Re: FPGA jemand? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-19 21:14 +0200
                        Re: FPGA jemand? Joerg <news@analogconsultants.com> - 2017-10-19 12:22 -0700
            Re: FPGA jemand? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-18 13:57 +0200
              Re: FPGA jemand? Gerhard Hoffmann <gerhard@hoffmann-hochfrequenz.de> - 2017-10-18 14:50 +0200
              Re: FPGA jemand? Heinz Schmitz <HeinzSchmitz@gmx.net> - 2017-10-18 14:52 +0200
                Re: FPGA jemand? Gerhard Hoffmann <gerhard@hoffmann-hochfrequenz.de> - 2017-10-18 15:05 +0200
                  Re: FPGA jemand? Andreas Neumann <an5275@sedo.com> - 2017-10-18 19:42 +0200
                    Re: FPGA jemand? Gerhard Hoffmann <gerhard@hoffmann-hochfrequenz.de> - 2017-10-18 20:50 +0200
                      Re: FPGA jemand? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-18 20:54 +0200
                        Re: FPGA jemand? Gerhard Hoffmann <gerhard@hoffmann-hochfrequenz.de> - 2017-10-18 21:31 +0200
                          Re: FPGA jemand? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-18 22:01 +0200
                            Re: FPGA jemand? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-19 01:00 +0200
                              Re: FPGA jemand? Gerhard Hoffmann <gerhard@hoffmann-hochfrequenz.de> - 2017-10-19 05:40 +0200
                                Re: FPGA jemand? Heinz Schmitz <HeinzSchmitz@gmx.net> - 2017-10-19 13:56 +0200
                              Re: FPGA jemand? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-19 07:49 +0200
                                Re: FPGA jemand? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-19 08:48 +0200
                                  Re: FPGA jemand? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-19 10:37 +0200
                                    Re: FPGA jemand? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-19 10:57 +0200
                                      Re: FPGA jemand? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-19 11:13 +0200
                                        Re: FPGA jemand? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-19 13:37 +0200
                                          Re: FPGA jemand? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-19 13:52 +0200
                                            Re: FPGA jemand? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-19 23:37 +0200
                                              Re: FPGA jemand? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-20 08:16 +0200
                                                Paging [was: FPGA jemand?] Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-20 13:17 +0200
                                                  Re: Paging [was: FPGA jemand?] Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-20 13:29 +0200
                                                    Re: Paging [was: FPGA jemand?] Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-20 16:55 +0200
                                                      Re: Paging [was: FPGA jemand?] Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-21 18:25 +0200
                                  Re: FPGA jemand? Klaus Butzmann <k.butzmann.usenet@online.de> - 2017-10-21 10:54 +0200
                                    Re: FPGA jemand? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-21 18:28 +0200
    Re: FPGA jemand? Reinhardt Behm <rbehm@hushmail.com> - 2017-10-18 06:28 +0800
      Re: FPGA jemand? Heinz Schmitz <HeinzSchmitz@gmx.net> - 2017-10-18 12:44 +0200
        Re: FPGA jemand? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-18 13:47 +0200
          Re: FPGA jemand? Heinz Schmitz <HeinzSchmitz@gmx.net> - 2017-10-18 14:11 +0200
        Re: FPGA jemand? Reinhardt Behm <rbehm@hushmail.com> - 2017-10-18 21:23 +0800
    Re: FPGA jemand? Bart Fox <bartfox@gmx.net> - 2017-10-20 18:07 +0200
      Re: FPGA jemand? Heinz Schmitz <HeinzSchmitz@gmx.net> - 2017-10-21 14:58 +0200

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#233939

Am 18.10.2017 um 22:01 schrieb Gerrit Heitsch:
> On 10/18/2017 09:31 PM, Gerhard Hoffmann wrote:

> 3TB heisst, daß die Bridge Sektoren mit 4096 Bytes liefern muss damit 
> das USB-Protokoll funktioniert. Mit 512 Bytes pro Sektor wäre bei 2 TB 
> Schluss. Schliesst man die Platte ohne die Bridge an den PC an, dann 
> versucht der sich natürlich mit 512er Sektoren und das gibt Müll weil 
> alle Einträge in der Partitionstabelle und im Filesystem um den Faktor 8 
> danebenliegen...

Stecken die Parameter des Laufwerks nicht in der Information, die beim 
Formatieren draufgeschrieben wird?

Wenn bei LBA mit der falschen Sektorgröße gelesen wird, dann liegen die 
Positionen nicht daneben, es werden aber immer nur die ersten 512 Bytes 
eines Sektors gelesen, statt 4096. Dann fängt der Ärger schon mit der 
FAT und der MFT an, denen 7/8 fehlen.

> Wenn man dem SATA-Controller (oder dem Treiber dahinter) klarmachen kann 
> auch 4096er Sektoren zu verwenden sollten die Daten lesbar sein.
> 
> Das Problem hast du übrigens mit allen externen HDs mit mehr als 2TB die 
> über USB angeschlossen sind. Es gibt Bridges die bei HDs bis 2TB die 
> üblichen 512er Sektoren verwenden und bei HDs mit über 2TB auf 4096 
> umschalten. Ich hab damit schon rumgespielt und Linux is ja in 'dmesg' 
> sehr gesprächig wenn man eine HD anstöpselt. Es meldet da auch die 
> Sektorgröße.

Was hindert dann ein System daran, diese verfügbare Information einfach 
zu verwenden?

DoDi

[toc] | [prev] | [next] | [standalone]

#233945

Am 19.10.2017 um 01:00 schrieb Hans-Peter Diettrich:

> Was hindert dann ein System daran, diese verfügbare Information einfach 
> zu verwenden?

Weil man absolut nicht wissen kann, ob die Interfaceplatine sich
z.B. ein paar Blöcke für Firmware-Updates reserviert, oder für
eigene Statistiken oder für $TOLLES_BACKUP_FEATURE.
Das wäre alles voll ok, das wird als externe USB3-Platte verkauft
und nicht als Laufwerk.

Man bekommt die Platte nur mit roher Gewalt auf; warum soll
man annehmen, dass sich das USB3/Sata-Mapping transparent verhält?
Statt einer SATA-Platte hätte genauso gut etwas völlig krankes
drinnen sein können.

Das eigentliche Laufwerk war eben nicht so mal eben zu mounten.
Die Größe schien grob zu stimmen, der Inhalt war lesbar, aber halt
kein gültiges EXT4-Filesystem.

Da ist der schnellste Weg zur Klarheit, sich ins Auto zu setzen,
dem Hersteller nochmal €1?? in den Rachen zu stopfen und das
4 Tage neuere Exemplar auf der Stelle zu schlachten.

Immerhin verschafft das eine gewisse Befriedigung, so wie
wenn man früher "format c: /u" getippt hat.

[toc] | [prev] | [next] | [standalone]

#233986

Gerhard Hoffmann wrote:

>Das eigentliche Laufwerk war eben nicht so mal eben zu mounten.
>Die Größe schien grob zu stimmen, der Inhalt war lesbar, aber halt
>kein gültiges EXT4-Filesystem.

Mein Laufwerk hat 1TB - das schrieb ich auch. Angeschlossen, läuft.
War schon ab Werk formatiert - mit NTFS.

Grüße,
H.

[toc] | [prev] | [next] | [standalone]

#233947

On 10/19/2017 01:00 AM, Hans-Peter Diettrich wrote:
> Am 18.10.2017 um 22:01 schrieb Gerrit Heitsch:
>> On 10/18/2017 09:31 PM, Gerhard Hoffmann wrote:
> 
>> 3TB heisst, daß die Bridge Sektoren mit 4096 Bytes liefern muss damit 
>> das USB-Protokoll funktioniert. Mit 512 Bytes pro Sektor wäre bei 2 TB 
>> Schluss. Schliesst man die Platte ohne die Bridge an den PC an, dann 
>> versucht der sich natürlich mit 512er Sektoren und das gibt Müll weil 
>> alle Einträge in der Partitionstabelle und im Filesystem um den Faktor 
>> 8 danebenliegen...
> 
> Stecken die Parameter des Laufwerks nicht in der Information, die beim 
> Formatieren draufgeschrieben wird?

Nicht die Blockgröße und damit fällt alles andere.


> Wenn bei LBA mit der falschen Sektorgröße gelesen wird, dann liegen die 
> Positionen nicht daneben, es werden aber immer nur die ersten 512 Bytes 
> eines Sektors gelesen, statt 4096. Dann fängt der Ärger schon mit der 
> FAT und der MFT an, denen 7/8 fehlen.

Nein, die Platte liefert schon alle Daten, aber eben nicht 4096 Bytes 
pro angefordertem Block sondern 512. Due kannst, egal wie du sie 
ansprichst, die volle Kapazität benutzen. Nur eben nicht über USB, da 
wäre wegen Adressierung mit 512 Bytes pro Block bei 2 TB Schluss.

Heutige Platten fahren, wenn man es ihnen nicht anders sagt, eine 
Emulation. Physikalisch haben sie 4096 Bytes pro Block, aber logisch nur 
512. Jeder Block auf der HD enthält also 8 logisch Blocks.


>> Wenn man dem SATA-Controller (oder dem Treiber dahinter) klarmachen 
>> kann auch 4096er Sektoren zu verwenden sollten die Daten lesbar sein.
>>
>> Das Problem hast du übrigens mit allen externen HDs mit mehr als 2TB 
>> die über USB angeschlossen sind. Es gibt Bridges die bei HDs bis 2TB 
>> die üblichen 512er Sektoren verwenden und bei HDs mit über 2TB auf 
>> 4096 umschalten. Ich hab damit schon rumgespielt und Linux is ja in 
>> 'dmesg' sehr gesprächig wenn man eine HD anstöpselt. Es meldet da auch 
>> die Sektorgröße.
> 
> Was hindert dann ein System daran, diese verfügbare Information einfach 
> zu verwenden?

Nichts... tut es bei USB ja auch, die Bridge sagt der HD, daß sie mit 
4096 laufen soll... Aber wenn die HD direkt am SATA-Port hängt meldet 
sie sich mit der 512er-Emulation. Da muss der Controller/Treiber der HD 
erst Bescheid sagen, daß er 4096 will.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#233954

Am 19.10.2017 um 07:49 schrieb Gerrit Heitsch:
> On 10/19/2017 01:00 AM, Hans-Peter Diettrich wrote:

>> Wenn bei LBA mit der falschen Sektorgröße gelesen wird, dann liegen 
>> die Positionen nicht daneben, es werden aber immer nur die ersten 512 
>> Bytes eines Sektors gelesen, statt 4096. Dann fängt der Ärger schon 
>> mit der FAT und der MFT an, denen 7/8 fehlen.
> 
> Nein, die Platte liefert schon alle Daten, aber eben nicht 4096 Bytes 
> pro angefordertem Block sondern 512. Due kannst, egal wie du sie 
> ansprichst, die volle Kapazität benutzen. Nur eben nicht über USB, da 
> wäre wegen Adressierung mit 512 Bytes pro Block bei 2 TB Schluss.

Danke an alle für die Erklärungen, so tief bin ich in die moderne 
Hardware noch garnicht eingestiegen. Irgendwie fühle ich mich in die 
Zeit zurückversetzt, als man dem System noch mitteilen mußte, wieviele 
Tracks und Sektoren eine Platte hat. Da hoffe ich einfach mal, daß die 
neue Größenordnung bei Platten bald in allen Systemen richtig verankert 
sein wird, und bin bis dahin mit meinen <1TB Platten völlig zufrieden.

DoDi

[toc] | [prev] | [next] | [standalone]

#233971

On 10/19/2017 08:48 AM, Hans-Peter Diettrich wrote:
> Am 19.10.2017 um 07:49 schrieb Gerrit Heitsch:
>> On 10/19/2017 01:00 AM, Hans-Peter Diettrich wrote:
> 
>>> Wenn bei LBA mit der falschen Sektorgröße gelesen wird, dann liegen 
>>> die Positionen nicht daneben, es werden aber immer nur die ersten 512 
>>> Bytes eines Sektors gelesen, statt 4096. Dann fängt der Ärger schon 
>>> mit der FAT und der MFT an, denen 7/8 fehlen.
>>
>> Nein, die Platte liefert schon alle Daten, aber eben nicht 4096 Bytes 
>> pro angefordertem Block sondern 512. Due kannst, egal wie du sie 
>> ansprichst, die volle Kapazität benutzen. Nur eben nicht über USB, da 
>> wäre wegen Adressierung mit 512 Bytes pro Block bei 2 TB Schluss.
> 
> Danke an alle für die Erklärungen, so tief bin ich in die moderne 
> Hardware noch garnicht eingestiegen. Irgendwie fühle ich mich in die 
> Zeit zurückversetzt, als man dem System noch mitteilen mußte, wieviele 
> Tracks und Sektoren eine Platte hat. Da hoffe ich einfach mal, daß die 
> neue Größenordnung bei Platten bald in allen Systemen richtig verankert 
> sein wird, und bin bis dahin mit meinen <1TB Platten völlig zufrieden.

Oh, dein SATA-Controller im Rechner hat damit keine Probleme, dessen 
LBA-Verfahren hat genug Adressbits, daß er noch lange mit 512 Byte 
Blöcken arbeiten kann und die Festplatten werden das deshalb noch lange 
unterstützen, auch wenn es eine Emulation ist.

Das Problem hier ist USB, dort hat das Feld für die Blocknummer eben 
nicht genug Bits und müsste überarbeitet werden. Da es mit der 
Verwendung von 4K-Blocks einen Workaround gibt ist damit nicht zu rechnen.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#233972

Am 19.10.2017 um 10:37 schrieb Gerrit Heitsch:
> On 10/19/2017 08:48 AM, Hans-Peter Diettrich wrote:
>> Am 19.10.2017 um 07:49 schrieb Gerrit Heitsch:
>>> On 10/19/2017 01:00 AM, Hans-Peter Diettrich wrote:
>>
>>>> Wenn bei LBA mit der falschen Sektorgröße gelesen wird, dann liegen 
>>>> die Positionen nicht daneben, es werden aber immer nur die ersten 
>>>> 512 Bytes eines Sektors gelesen, statt 4096. Dann fängt der Ärger 
>>>> schon mit der FAT und der MFT an, denen 7/8 fehlen.
>>>
>>> Nein, die Platte liefert schon alle Daten, aber eben nicht 4096 Bytes 
>>> pro angefordertem Block sondern 512. Due kannst, egal wie du sie 
>>> ansprichst, die volle Kapazität benutzen. Nur eben nicht über USB, da 
>>> wäre wegen Adressierung mit 512 Bytes pro Block bei 2 TB Schluss.
>>
>> Danke an alle für die Erklärungen, so tief bin ich in die moderne 
>> Hardware noch garnicht eingestiegen. Irgendwie fühle ich mich in die 
>> Zeit zurückversetzt, als man dem System noch mitteilen mußte, wieviele 
>> Tracks und Sektoren eine Platte hat. Da hoffe ich einfach mal, daß die 
>> neue Größenordnung bei Platten bald in allen Systemen richtig 
>> verankert sein wird, und bin bis dahin mit meinen <1TB Platten völlig 
>> zufrieden.
> 
> Oh, dein SATA-Controller im Rechner hat damit keine Probleme, dessen 
> LBA-Verfahren hat genug Adressbits, daß er noch lange mit 512 Byte 
> Blöcken arbeiten kann und die Festplatten werden das deshalb noch lange 
> unterstützen, auch wenn es eine Emulation ist.

Neben der eingebauten Platte benutze ich an meinem Notebook auch externe 
(USB) Laufwerke, insofern wäre ich da schon betroffen.

> Das Problem hier ist USB, dort hat das Feld für die Blocknummer eben 
> nicht genug Bits und müsste überarbeitet werden. Da es mit der 
> Verwendung von 4K-Blocks einen Workaround gibt ist damit nicht zu rechnen.

Aha.

Ein Bekannter hat eben mit einer Speicherkarte aus einer Kamera zu tun, 
die ist mit EXTFAT auf eine Clustergröße von 128KB formatiert. Das hat 
zwar nichts mit einer Sektorgröße zu tun, die bei solid-state Speicher 
so garnicht existiert, aber angesichts der aktuellen Speicherkapazitäten 
erscheinen mir Transfers in 512 Byte Häppchen doch etwas veraltet. Das 
RAM wird ja schon länger in 4KB Seiten verwaltet, da könnten auch bald 
größere Seiten ins Haus stehen.

DoDi

[toc] | [prev] | [next] | [standalone]

#233975

On 10/19/2017 10:57 AM, Hans-Peter Diettrich wrote:
> Am 19.10.2017 um 10:37 schrieb Gerrit Heitsch:
>> On 10/19/2017 08:48 AM, Hans-Peter Diettrich wrote:
>>> Am 19.10.2017 um 07:49 schrieb Gerrit Heitsch:
>>>> On 10/19/2017 01:00 AM, Hans-Peter Diettrich wrote:
>>>
>>>>> Wenn bei LBA mit der falschen Sektorgröße gelesen wird, dann liegen 
>>>>> die Positionen nicht daneben, es werden aber immer nur die ersten 
>>>>> 512 Bytes eines Sektors gelesen, statt 4096. Dann fängt der Ärger 
>>>>> schon mit der FAT und der MFT an, denen 7/8 fehlen.
>>>>
>>>> Nein, die Platte liefert schon alle Daten, aber eben nicht 4096 
>>>> Bytes pro angefordertem Block sondern 512. Due kannst, egal wie du 
>>>> sie ansprichst, die volle Kapazität benutzen. Nur eben nicht über 
>>>> USB, da wäre wegen Adressierung mit 512 Bytes pro Block bei 2 TB 
>>>> Schluss.
>>>
>>> Danke an alle für die Erklärungen, so tief bin ich in die moderne 
>>> Hardware noch garnicht eingestiegen. Irgendwie fühle ich mich in die 
>>> Zeit zurückversetzt, als man dem System noch mitteilen mußte, 
>>> wieviele Tracks und Sektoren eine Platte hat. Da hoffe ich einfach 
>>> mal, daß die neue Größenordnung bei Platten bald in allen Systemen 
>>> richtig verankert sein wird, und bin bis dahin mit meinen <1TB 
>>> Platten völlig zufrieden.
>>
>> Oh, dein SATA-Controller im Rechner hat damit keine Probleme, dessen 
>> LBA-Verfahren hat genug Adressbits, daß er noch lange mit 512 Byte 
>> Blöcken arbeiten kann und die Festplatten werden das deshalb noch 
>> lange unterstützen, auch wenn es eine Emulation ist.
> 
> Neben der eingebauten Platte benutze ich an meinem Notebook auch externe 
> (USB) Laufwerke, insofern wäre ich da schon betroffen.

Muss man nur wissen, dann kann man Vorsorge treffen. Bis incl. 2 TB 
benutzen die USB/SATA-Bridges üblicherweise 512 Byte Blocks.


> Ein Bekannter hat eben mit einer Speicherkarte aus einer Kamera zu tun, 
> die ist mit EXTFAT auf eine Clustergröße von 128KB formatiert. Das hat 
> zwar nichts mit einer Sektorgröße zu tun, die bei solid-state Speicher 
> so garnicht existiert, aber angesichts der aktuellen Speicherkapazitäten 
> erscheinen mir Transfers in 512 Byte Häppchen doch etwas veraltet. Das 
> RAM wird ja schon länger in 4KB Seiten verwaltet, da könnten auch bald 
> größere Seiten ins Haus stehen.

Tun sie schon lange. Nennt sich 'large pages' und liegen im Bereich von 
Megabytes (x86: 2 oder 4 MB). Hat aber auch Nachteile. Man wird 
weiterhin die normalen Pages von 4 oder 8 KB brauchen weil sonst jeder 
Kleinkram gleich Megabytes an Speicher anfordern müsste. Damit ergibt 
sich mit der Zeit eine gewisse Fragmentierung des Speichers und sobald 
nicht mehr genug freier Speicher am Stück vorhanden ist um eine 
angeforderte large Page zu erzeugen muss aufgeräumt werden ('defrag' 
aufs RAM :)). Das kostet Zeit und wenn schneller neue large pages 
angefordert werden als aufgeräumt werden kann wird das System langsam 
obwohl es eigentlich noch genug freies RAM hat. Wenn man das nicht weiss 
kann das Debuggen länger dauern.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#233981

Am 19.10.2017 um 11:13 schrieb Gerrit Heitsch:
> On 10/19/2017 10:57 AM, Hans-Peter Diettrich wrote:

>> Das RAM wird ja schon länger in 4KB Seiten verwaltet, 
>> da könnten auch bald größere Seiten ins Haus stehen.
> 
> Tun sie schon lange. Nennt sich 'large pages' und liegen im Bereich von 
> Megabytes (x86: 2 oder 4 MB).

Technisch gibt es die schon lange, aber werden sie auch schon benutzt?

> Hat aber auch Nachteile. Man wird 
> weiterhin die normalen Pages von 4 oder 8 KB brauchen weil sonst jeder 
> Kleinkram gleich Megabytes an Speicher anfordern müsste. Damit ergibt 
> sich mit der Zeit eine gewisse Fragmentierung des Speichers und sobald 
> nicht mehr genug freier Speicher am Stück vorhanden ist um eine 
> angeforderte large Page zu erzeugen muss aufgeräumt werden ('defrag' 
> aufs RAM :)).

Tatsächlich unterschiedliche Seitengrößen im RAM?

DoDi

[toc] | [prev] | [next] | [standalone]

#233985

On 10/19/2017 01:37 PM, Hans-Peter Diettrich wrote:
> Am 19.10.2017 um 11:13 schrieb Gerrit Heitsch:
>> On 10/19/2017 10:57 AM, Hans-Peter Diettrich wrote:
> 
>>> Das RAM wird ja schon länger in 4KB Seiten verwaltet, da könnten auch 
>>> bald größere Seiten ins Haus stehen.
>>
>> Tun sie schon lange. Nennt sich 'large pages' und liegen im Bereich 
>> von Megabytes (x86: 2 oder 4 MB).
> 
> Technisch gibt es die schon lange, aber werden sie auch schon benutzt?

Schon lange, je nach OS eben... Das unten beschriebene Problem hatte ich 
schon öfters auf Solaris. Gibt Workarounds und Patches dafür.



>> Hat aber auch Nachteile. Man wird weiterhin die normalen Pages von 4 
>> oder 8 KB brauchen weil sonst jeder Kleinkram gleich Megabytes an 
>> Speicher anfordern müsste. Damit ergibt sich mit der Zeit eine gewisse 
>> Fragmentierung des Speichers und sobald nicht mehr genug freier 
>> Speicher am Stück vorhanden ist um eine angeforderte large Page zu 
>> erzeugen muss aufgeräumt werden ('defrag' aufs RAM :)).
> 
> Tatsächlich unterschiedliche Seitengrößen im RAM?

Jup. Die Hardware kann es, warum nicht benutzen?

Rein 'large pages' und jedes kleine Kommando würde megabyteweise 
Speicher fressen auch wenn es nur ein paar KB braucht.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#234051

Am 19.10.2017 um 13:52 schrieb Gerrit Heitsch:
> On 10/19/2017 01:37 PM, Hans-Peter Diettrich wrote:
>> Am 19.10.2017 um 11:13 schrieb Gerrit Heitsch:

>>> Hat aber auch Nachteile. Man wird weiterhin die normalen Pages von 4 
>>> oder 8 KB brauchen weil sonst jeder Kleinkram gleich Megabytes an 
>>> Speicher anfordern müsste. Damit ergibt sich mit der Zeit eine 
>>> gewisse Fragmentierung des Speichers und sobald nicht mehr genug 
>>> freier Speicher am Stück vorhanden ist um eine angeforderte large 
>>> Page zu erzeugen muss aufgeräumt werden ('defrag' aufs RAM :)).
>>
>> Tatsächlich unterschiedliche Seitengrößen im RAM?
> 
> Jup. Die Hardware kann es, warum nicht benutzen?

Du hast ja selbst die daraus resultierenden Probleme beschrieben.

> Rein 'large pages' und jedes kleine Kommando würde megabyteweise 
> Speicher fressen auch wenn es nur ein paar KB braucht.

Was ist bei "großen Kommandos" anders? Woran sind die erkennbar?

Beim Paging wird ja nur das eingelagert, was tatsächlich benötigt wird. 
Dann muß für ein kurzes Unterprogramm in einem großen Kommando die große 
Seite eingelagert werden, auch wenn davon anschließend nur ein paar 
Bytes benutzt weren.


Genaugenommen sehe ich aber garkein Problem mit einem Mix von 
Seitengrößen, wenn jeder Prozess (Thread...) grundsätzlich große Seiten 
zugeordnet (reserviert) bekommt, die er dann nach Lust und Laune am 
Stück oder als viele kleine Seiten benutzen (laden...) darf. Wieviele 
große Seiten sind denn verfügbar, und wieviele "Kommandos" laufen 
gleichzeitig auf dem Rechner?

DoDi

[toc] | [prev] | [next] | [standalone]

#234064

On 10/19/2017 11:37 PM, Hans-Peter Diettrich wrote:
> Am 19.10.2017 um 13:52 schrieb Gerrit Heitsch:
>> On 10/19/2017 01:37 PM, Hans-Peter Diettrich wrote:
>>> Am 19.10.2017 um 11:13 schrieb Gerrit Heitsch:
> 
>>>> Hat aber auch Nachteile. Man wird weiterhin die normalen Pages von 4 
>>>> oder 8 KB brauchen weil sonst jeder Kleinkram gleich Megabytes an 
>>>> Speicher anfordern müsste. Damit ergibt sich mit der Zeit eine 
>>>> gewisse Fragmentierung des Speichers und sobald nicht mehr genug 
>>>> freier Speicher am Stück vorhanden ist um eine angeforderte large 
>>>> Page zu erzeugen muss aufgeräumt werden ('defrag' aufs RAM :)).
>>>
>>> Tatsächlich unterschiedliche Seitengrößen im RAM?
>>
>> Jup. Die Hardware kann es, warum nicht benutzen?
> 
> Du hast ja selbst die daraus resultierenden Probleme beschrieben.

Ja, aber die treten eher selten auf. Im Normalfall überwiegt der Vorteil 
der großen Pages. Wenn die eigene Anwendung ein solcher Sonderfall ist, 
dann muss man dieses Feature eben abschalten oder zumindest den Teil der 
den 'defrag' erledigt. Dann gibts bei Anforderung eben keine große Page 
sondern viele kleine wenn keine große frei ist.


> 
>> Rein 'large pages' und jedes kleine Kommando würde megabyteweise 
>> Speicher fressen auch wenn es nur ein paar KB braucht.
> 
> Was ist bei "großen Kommandos" anders? Woran sind die erkennbar?

Das sind die, die Speicher in großen Mengen brauchen. Datenbanken oder 
SAP z.B. Das meiste andere braucht Speicher nur in kleineren Mengen. 
Webserver z.B. parallelisiert man eher als alles über einen 
Monsterprozess abzuhandeln.


> Beim Paging wird ja nur das eingelagert, was tatsächlich benötigt wird. 
> Dann muß für ein kurzes Unterprogramm in einem großen Kommando die große 
> Seite eingelagert werden, auch wenn davon anschließend nur ein paar 
> Bytes benutzt weren.

Eben, und deshalb macht man Mischbetrieb.


> Genaugenommen sehe ich aber garkein Problem mit einem Mix von 
> Seitengrößen, wenn jeder Prozess (Thread...) grundsätzlich große Seiten 
> zugeordnet (reserviert) bekommt, die er dann nach Lust und Laune am 
> Stück oder als viele kleine Seiten benutzen (laden...) darf. Wieviele 
> große Seiten sind denn verfügbar, und wieviele "Kommandos" laufen 
> gleichzeitig auf dem Rechner?

Die Anzahl der Prozesse kann schonmal vierstellig werden wenn ein Server 
gut ausgelastet ist.

Die Unterteilung einer großen Page in viele kleine wäre bei deiner Idee 
aber Aufgabe des Prozesses selbst und würde deshalb einen Umbau im Code 
bedingen. Meinst du das macht einer wenn die Hardware Mischbetrieb kann?

  Gerrit

[toc] | [prev] | [next] | [standalone]

#234122 — Paging [was: FPGA jemand?]

Am 20.10.2017 um 08:16 schrieb Gerrit Heitsch:
> On 10/19/2017 11:37 PM, Hans-Peter Diettrich wrote:
>> Am 19.10.2017 um 13:52 schrieb Gerrit Heitsch:
>>> On 10/19/2017 01:37 PM, Hans-Peter Diettrich wrote:
>>>> Am 19.10.2017 um 11:13 schrieb Gerrit Heitsch:
>>
>>>>> Hat aber auch Nachteile. Man wird weiterhin die normalen Pages von 
>>>>> 4 oder 8 KB brauchen weil sonst jeder Kleinkram gleich Megabytes an 
>>>>> Speicher anfordern müsste. Damit ergibt sich mit der Zeit eine 
>>>>> gewisse Fragmentierung des Speichers und sobald nicht mehr genug 
>>>>> freier Speicher am Stück vorhanden ist um eine angeforderte large 
>>>>> Page zu erzeugen muss aufgeräumt werden ('defrag' aufs RAM :)).
>>>>
>>>> Tatsächlich unterschiedliche Seitengrößen im RAM?
>>>
>>> Jup. Die Hardware kann es, warum nicht benutzen?

Die Hardware kann auch Segmentierung. Man muß nicht alles benutzen, was 
geht, und vor allem nicht gleichzeitig.


>>> Rein 'large pages' und jedes kleine Kommando würde megabyteweise 
>>> Speicher fressen auch wenn es nur ein paar KB braucht.
>>
>> Was ist bei "großen Kommandos" anders? Woran sind die erkennbar?
> 
> Das sind die, die Speicher in großen Mengen brauchen.

Ich meinte: woran erkennt das System, welche Seitengröße benutzt werden 
soll?


> Die Anzahl der Prozesse kann schonmal vierstellig werden wenn ein Server 
> gut ausgelastet ist.

Die Speicherverwaltung etc. unterliegt unterschiedlichen Anforderungen, 
auf Servern, Workstations und kleinen privaten Rechnern. Entsprechend 
werden die Ressourcen unterschiedlich verwaltet, Verfahren parametriert, 
optimiert usw. Daran hat sich seit meinem Studium (70er Jahre) 
eigentlich nichts geändert.


> Die Unterteilung einer großen Page in viele kleine wäre bei deiner Idee 
> aber Aufgabe des Prozesses selbst und würde deshalb einen Umbau im Code 
> bedingen. Meinst du das macht einer wenn die Hardware Mischbetrieb kann?

Solange das Paging mit einheitlicher Seitengröße (4KB) lief, hatten die 
Programme keinen Einfluß darauf. Mich interessiert daher, wie das heute 
bei gemischten Seitengrößen gemanagt wird.

Ein Umbau des Codes ist bei Paging jedenfalls nicht notwendig, das war 
höchstens bei Segmentierung der Fall. Sollen jetzt die Fehler, die bei 
der Verwaltung in Segmenten gemacht wurden, nun beim Paging wiederholt 
werden?

DoDi

[toc] | [prev] | [next] | [standalone]

#234124 — Re: Paging [was: FPGA jemand?]

On 10/20/2017 01:17 PM, Hans-Peter Diettrich wrote:
> Am 20.10.2017 um 08:16 schrieb Gerrit Heitsch:
>> On 10/19/2017 11:37 PM, Hans-Peter Diettrich wrote:
>>> Am 19.10.2017 um 13:52 schrieb Gerrit Heitsch:
>>>> On 10/19/2017 01:37 PM, Hans-Peter Diettrich wrote:
>>>>> Am 19.10.2017 um 11:13 schrieb Gerrit Heitsch:
>>>
>>>>>> Hat aber auch Nachteile. Man wird weiterhin die normalen Pages von 
>>>>>> 4 oder 8 KB brauchen weil sonst jeder Kleinkram gleich Megabytes 
>>>>>> an Speicher anfordern müsste. Damit ergibt sich mit der Zeit eine 
>>>>>> gewisse Fragmentierung des Speichers und sobald nicht mehr genug 
>>>>>> freier Speicher am Stück vorhanden ist um eine angeforderte large 
>>>>>> Page zu erzeugen muss aufgeräumt werden ('defrag' aufs RAM :)).
>>>>>
>>>>> Tatsächlich unterschiedliche Seitengrößen im RAM?
>>>>
>>>> Jup. Die Hardware kann es, warum nicht benutzen?
> 
> Die Hardware kann auch Segmentierung. Man muß nicht alles benutzen, was 
> geht, und vor allem nicht gleichzeitig.

Segmentierung ist eine Eigenheit des x86 und die sollte schon länger tot 
sein. Die Hardware kann es noch, aber wer benutzt es?


>>>> Rein 'large pages' und jedes kleine Kommando würde megabyteweise 
>>>> Speicher fressen auch wenn es nur ein paar KB braucht.
>>>
>>> Was ist bei "großen Kommandos" anders? Woran sind die erkennbar?
>>
>> Das sind die, die Speicher in großen Mengen brauchen.
> 
> Ich meinte: woran erkennt das System, welche Seitengröße benutzt werden 
> soll?

Das musst du beim jeweiligen OS nachschlagen. Ich bin mir sicher, daß 
sich solche Details zwischen Windows, Linux, Solaris... unterscheiden.

Möglich wäre das Prinzip 'Der Prozess fordert Speichermenge X an, wenn 
das mehr als eine large Page ist gibts die, wenn nicht gibts Kleinkram'. 
Der Prozess sieht ja nicht die Pages, der bekommt vom OS gesagt, daß er 
ab Adresse Y seine Speichermenge X finden kann. Die Verwaltung der Pages 
erledigt das OS.



>> Die Anzahl der Prozesse kann schonmal vierstellig werden wenn ein 
>> Server gut ausgelastet ist.
> 
> Die Speicherverwaltung etc. unterliegt unterschiedlichen Anforderungen, 
> auf Servern, Workstations und kleinen privaten Rechnern. Entsprechend 
> werden die Ressourcen unterschiedlich verwaltet, Verfahren parametriert, 
> optimiert usw. Daran hat sich seit meinem Studium (70er Jahre) 
> eigentlich nichts geändert.

Dafür gibt es inzwischen Automatismen bei denen man nur noch selten 
eingreifen muss.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#234165 — Re: Paging [was: FPGA jemand?]

Am 20.10.2017 um 13:29 schrieb Gerrit Heitsch:
> On 10/20/2017 01:17 PM, Hans-Peter Diettrich wrote:
>> Am 20.10.2017 um 08:16 schrieb Gerrit Heitsch:

> Möglich wäre das Prinzip 'Der Prozess fordert Speichermenge X an, wenn 
> das mehr als eine large Page ist gibts die, wenn nicht gibts Kleinkram'. 
> Der Prozess sieht ja nicht die Pages, der bekommt vom OS gesagt, daß er 
> ab Adresse Y seine Speichermenge X finden kann. Die Verwaltung der Pages 
> erledigt das OS.

Ein Prozess fordert lokalen Speicher an. Dabei hat es sich als 
vorteilhaft erwiesen, große Blöcke vom System anzufordern und diese dann 
selbst zu verwalten, ohne daß weitere teure Systemaufrufe notwendig 
werden. Deshalb ist die angeforderte Größe kein Indiz dafür, wie groß 
oder klein die Bereiche sein werden, die vom Programm in diesem Block 
angelegt werden.


>>> Die Anzahl der Prozesse kann schonmal vierstellig werden wenn ein 
>>> Server gut ausgelastet ist.
>>
>> Die Speicherverwaltung etc. unterliegt unterschiedlichen 
>> Anforderungen, auf Servern, Workstations und kleinen privaten 
>> Rechnern. Entsprechend werden die Ressourcen unterschiedlich 
>> verwaltet, Verfahren parametriert, optimiert usw. Daran hat sich seit 
>> meinem Studium (70er Jahre) eigentlich nichts geändert.
> 
> Dafür gibt es inzwischen Automatismen bei denen man nur noch selten 
> eingreifen muss.

Weil sie vom System bereits so vorkonfiguriert werden, daß weitere 
Eingriffe meist nicht mehr notwendig sind. Die Standard-Konfiguration 
eines Server-Systems ist aber eine andere als die eines Home- oder 
Echtzeit-Systems.

DoDi

[toc] | [prev] | [next] | [standalone]

#234210 — Re: Paging [was: FPGA jemand?]

On 10/20/2017 04:55 PM, Hans-Peter Diettrich wrote:
> Am 20.10.2017 um 13:29 schrieb Gerrit Heitsch:
>> On 10/20/2017 01:17 PM, Hans-Peter Diettrich wrote:
>>> Am 20.10.2017 um 08:16 schrieb Gerrit Heitsch:
> 
>> Möglich wäre das Prinzip 'Der Prozess fordert Speichermenge X an, wenn 
>> das mehr als eine large Page ist gibts die, wenn nicht gibts 
>> Kleinkram'. Der Prozess sieht ja nicht die Pages, der bekommt vom OS 
>> gesagt, daß er ab Adresse Y seine Speichermenge X finden kann. Die 
>> Verwaltung der Pages erledigt das OS.
> 
> Ein Prozess fordert lokalen Speicher an. Dabei hat es sich als 
> vorteilhaft erwiesen, große Blöcke vom System anzufordern und diese dann 
> selbst zu verwalten, ohne daß weitere teure Systemaufrufe notwendig 
> werden. Deshalb ist die angeforderte Größe kein Indiz dafür, wie groß 
> oder klein die Bereiche sein werden, die vom Programm in diesem Block 
> angelegt werden.

Das interessiert die Speicherverwaltung des OS aber nicht. Das sieht nur 
eine Anforderung für X Bytes. Die liefert es (wenn noch genug Speicher 
frei ist).


>>>> Die Anzahl der Prozesse kann schonmal vierstellig werden wenn ein 
>>>> Server gut ausgelastet ist.
>>>
>>> Die Speicherverwaltung etc. unterliegt unterschiedlichen 
>>> Anforderungen, auf Servern, Workstations und kleinen privaten 
>>> Rechnern. Entsprechend werden die Ressourcen unterschiedlich 
>>> verwaltet, Verfahren parametriert, optimiert usw. Daran hat sich seit 
>>> meinem Studium (70er Jahre) eigentlich nichts geändert.
>>
>> Dafür gibt es inzwischen Automatismen bei denen man nur noch selten 
>> eingreifen muss.
> 
> Weil sie vom System bereits so vorkonfiguriert werden, daß weitere 
> Eingriffe meist nicht mehr notwendig sind. Die Standard-Konfiguration 
> eines Server-Systems ist aber eine andere als die eines Home- oder 
> Echtzeit-Systems.

Muss nicht sein. MS macht das mit Windows so, aber weder bei Linux noch 
bei Solaris fällt mir ein Unterschied ein. Ich kann die Defaults 
natürlich später ändern wenn ich meine das zu brauchen.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#234198

Am 19.10.2017 um 08:48 schrieb Hans-Peter Diettrich:
> Irgendwie fühle ich mich in die 
> Zeit zurückversetzt, als man dem System noch mitteilen mußte, wieviele 
> Tracks und Sektoren eine Platte hat.
Und die BTT vom Aufkleber ablesen und für die Formatierung eintippen :-)


Butzo

[toc] | [prev] | [next] | [standalone]

#234211

On 10/21/2017 10:54 AM, Klaus Butzmann wrote:
> Am 19.10.2017 um 08:48 schrieb Hans-Peter Diettrich:
>> Irgendwie fühle ich mich in die Zeit zurückversetzt, als man dem 
>> System noch mitteilen mußte, wieviele Tracks und Sektoren eine Platte 
>> hat.
> Und die BTT vom Aufkleber ablesen und für die Formatierung eintippen :-)

Es gab eine Zeit da standen die Parameter leider nicht auf der HD drauf. 
Die musste man sich unverständlicherweise erst irgendwie zusammensuchen. 
War ohne Internet gar nicht so einfach.

Ich hab bei jeder erfolgreich eingerichteten HD diese Parameter immer 
mit Marker auf die Platte geschrieben.

Zum Glück war das irgendwann mit IDE durch als das BIOS endlich dazu 
überging die HD nach ihren Parametern zu fragen.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#233853

AT Tuesday 17 October 2017 05:01, Heinz Schmitz wrote:

> Wer kann die Qual der Wahl verringern und mir das "schönste"
> Entwicklungsboard empfehlen? Digikey hat so viele im Angebot,
> dass sie schon wieder obsolet sind, bevor ich mir das Passende
> ausgesucht habe :-(.
> Neben der Hardware braucht es ja auch die Tool-Chain, und da
> fangen meist die Probleme mit der Lizenz an. Es scheint auch nicht
> viel für Linux gemacht zu werden.
> "Das Projekt" ist ein Bus-Sniffer (aka Logik-Analysator). Anfangs
> dachte ich, die gelesenen Daten in einem Ram zu speichern und
> anschliessend langsam auszulesen (an den PC). Natürlich wäre
> ein Flash-Drive bequemer, oder ein Lan-Interface, aber wie schnell
> sind die?
> Die Boat-Anchor-LAs leiden imho alle unter zu wenig Speicher -
> 1 bis 2 kB sind heute ja fast nichts mehr.
> 
> Mit Dank und Gruß,
> E.

Spar die Arbeit nimm den hier für 50$:
<http://dangerousprototypes.com/docs/Open_Bench_Logic_Sniffer>

-- 
Reinhardt

[toc] | [prev] | [next] | [standalone]

#233870

Reinhardt Behm wrote:

>Spar die Arbeit nimm den hier für 50$:
><http://dangerousprototypes.com/docs/Open_Bench_Logic_Sniffer>

Sehr guter Tip, danke. Allerdings:

http://dangerousprototypes.com/docs/Hardware_design_overview
	"SUMP is a sampling logic analyzer. It reads the state of the
	 input pins and stores the samples in internal ram. It then
	 dumps the samples back to the computer client for analysis.
	 The number of samples possible is limited by the RAM in the
	 FPGA."
Nach längerem Suchen fand ich endlich
	"32 channels with 4k sample depth.   ...
	 Our future design plans do include working on adding 
	 32-64Mb of SDRAM memory."

Dann:
	" You can get the Butterfly Platform at the Gadget Factory now
	 for $99."
Click "the Butterfly Platform" and get

http://shop.gadgetfactory.net/index.php?main_page=product_info&cPath=1&products_id=5
		"This store is currently unavailable due to
		 maintenance. It should be available again shortly."

Das heisst imho, dass ich mich damit auf Trial-and-Error-Land begebe, 
so gut die Leistung auch im Einzelfall sein mag.

Ich hatte zuvor schon dieses gefunden:
http://dreamsourcelab.com/index.html
	"DSLogic"
Aber ich finde keine Namen und keine Adresse, und auf meine Mail mit
Frage danach (und in welchem Format die Daten im PC ankommen und
wie getriggert werden kann) kam keine Antwort. Dann 100 Euro über
PayPal ins All zu schiessen geht über meine rote Linie :-).

Die Frage ist also, ob ich mit einem passenden Development-Board
nicht auf festerem Boden stehe - natürlich mit dem Risiko, dass ich's
nicht hinkriege :-).

Grüße,
H.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | de.sci.electronics

csiph-web