RAM-Baustein

[HaWe]

wenn du nicht den "Schaffner" (Server) selber auch schreiben lassen willst, sondern der nur dazu da ist, eine "Fahrkarte" (Token) für die Zugriffsrechte zu vergeben und weiterzureichen, kann man auch einen "Token Ring" ohne Schaffner aufbauen. Hier reicht dann jeder Client, wenn er dran war und wenn er dann fertig ist, seinen Token an den nächsten im Netwerk-"Ring" weiter, sodass immer nur max. 1 den Token als Schreibberechtigung hat.
Aber ein Server, der die Tokens verwaltet, ist tatsächlich sicherer gegen Ausfälle und Störungen, das stimmt: es ist dann eine abgepeckte Variante meines oben skizzierten sternförmigen Server-Client-Netzes.
Beide Systeme können sich aber dennoch leicht aufhängen:
Der Token Ring, wenn irgendein beliebiger Client im Ring irgendwo ausfällt,
und im Stern, wenn der Server ausfällt.
Nur TCP/IP-Netze mit multiplen Knoten sind da ausfallsicherer.

[Moppi]

Die Teilnehmer untereinander zu verbinden, das wäre natürlich gut, weil man theor. beliebig viele miteinander verketten kann. Daran gefiel mir aber nicht, dass sich jeder Teilnehmer noch um die Absprache kümmern muss. Max. würde ich 2 Signalleitungen dafür verwenden, Eine rein und Eine raus, zum Nächsten. Bevor hier eine Entscheidung gefallen ist, muss das Signal alle Teilnehmer passiert haben. Außerdem kann man nicht ermitteln, ob ein im Ring weiter entfernter Teilnehmer, eher dran sein müsste, als andere.
Diese serielle Kommunikation gefällt mir irgendwie auf dieser Ebene nicht, ob I2C oder was anderes. Ich möchte möglichst kurze Latenzzeiten im System, sonst macht das für mich keinen Sinn - nur wenn ich eine bestimmte Datenverarbeitungsrate erreichen würde.

[HaWe]

ich fürchte fast, da hast du falsche Vorstellungen über die Geschwindigkeitsproblematik, denn ein Token hin oder her oder weiter zu reichen, das geht weit schneller als dann die Daten selber über ICs und GPIO Pins in dein externes RAM zu schreiben.
Da würde ich mal einen Geschwindigkeitstest machen, verschiedene große Datenpakete 1000x lesen und schreiben, mit chksum-Überprüfung!

PS,
du kannst auch 2x UART zur Kommunikation bei kleinen AVRs verwenden, einmal Serial() und einmal SoftwareSerial(), auch z.B. das eine für den Vorgänger und das andere für den Nachfolger im Ring (im Stern sicher eher I2C mit 400k) !

[Moppi]

Das Maximum bei paralleler Datenübertragung, mit einem 16MHz Atmega328 konnte ich mit etwa 25 bis 27kByte pro Sekunde bestimmen

Wieviel ist es denn bei I2C mit einem 16MHz Atmega328?

[HaWe]

habe ich mit Bytes noch nicht exakt getestet, aber als Hausnummer (!) bei 100kHz mit chksum Test auf master und slaves:
32byte-arrays jew. ca. alle 5ms, also 32*1000/5=6.4kB/s, bei 400kHz oder einzelnen Bytes sicher noch schneller (aber ntl. nicht mehr bytes, wenn du einzeln sendest).
Aber da gibt es sicher verlässliche, validierte Tests, wenn du es genau wissen willst. (Der Prozessortakt ist ja dafür nicht ausschlaggebend, nur I2C Bus-Takt.)
Ich meinte aber auch nicht nur die reine parallele Datenübertragung, sondern auch getestete physikalische Lese-/Schreibaktionen auf dem RAM, auch mit chksum Test.

[Moppi]

Per I2C: 27kByte / Sekunde. Von daher wäre das gleich oder sogar etwas schneller, als mit einem Atmega328 parallel Daten zu übertragen.

sondern auch getestete physikalische Lese-/Schreibaktionen auf dem RAM

Der RAM benötigt ca. 55 bis 70ns, je nach Ausführung, dann ist es gelesen oder geschrieben, dann ist er damit fertig, inklusive allem, was er benötigt, um Daten abzulegen oder hervorzugraben und stabil zur Verfügung zu stellen.

Aber wenn ich Dich richtig verstehe, möchtest Du dann gerne zusätzlich noch einen Zusatz-RAM für Prüfbits dazupacken, bzw. am besten ganze Checksummen berechnen, beim Auslesen und Schreiben, und das dann überprüfen?
Bei einer Geschwindigkeit von unter 20MHz? Bei SRAM? Dann nehme ich an, wirst Du sicher auch bei andern Datenträgern immer ein Raid-System installiert haben?

[HaWe]

Aber wenn ich Dich richtig verstehe, möchtest Du dann gerne zusätzlich noch einen Zusatz-RAM für Prüfbits dazupacken, bzw. am besten ganze Checksummen berechnen, beim Auslesen und Schreiben, und das dann überprüfen?
Bei einer Geschwindigkeit von unter 20MHz? Bei SRAM? Dann nehme ich an, wirst Du sicher auch bei andern Datenträgern immer ein Raid-System installiert haben?

Kein Zusatz-RAM, aber bei sensitiven Daten einen Check mindestens nach jedem Lesen, ggf auch Rückmeldung an den Sender wenn Daten fehlerhaft sind zum erneuten schreiben/senden.
Bei i2c, UART und BT habe ich immer ein Startbyte (255), dann ein chksum-Byte (sum ab 3.byte), by I2C dann die Slave-Addr, der Rest Datenbytes. Bei ungeschirmten, längeren Kabeln oder WL kommen oft unerwartete Fehler zustande.
Bei jedem Lesevorgang wird die chksum neu berechnet und mit der mitgeschickten chksum verglichen, erst dann weiterverarbeitet oder verworfen.
Fürs Schreiben wird nur die chksum berechnet und ins 2. byte hineingeschrieben, dann verschickt (geschrieben), der Empfänger prüft dann ja auf Konsistenz (bei dir notfalls immer zusätzliches zurücklesen zum Check, wenn es sensitive Daten sind).

Beruflich hatte ich aber tatsächlich ein hot-swap RAID System bei mir, das stimmt schon, hat aber vor allem was mit Ausfallsicherheit zu tun.

Dass paralleles Senden aber grundsätzlich schneller ist als serielles (bei gleichem Takt und gleich großen Datenpaketen), ist eigentlich doch kein Wunder, die Frage ist nur auch, wieviele Bytes einzeln oder gemeinsam bewegt und gecheckt werden müssen.

Wenn ich mit meinem Raspi allerdings auf SD Karte weniger sensitive Daten schreibe oder auch auf USB-HD, dann allerdings mache ich keine extra file-checks, das überlasse ich stillschweigend Linux.