Posts by merlintwa

    About the STM32F405RGT6 availability: If you're planning just one KFF you could order a prototype board with one on it from ali chinaman and desolder it yourself.

    No volume manufacturer will go to such lengths of desoldering so the cost of those proto boards (made years ago, still witting in a warehouse somewhere) is not as ridiculous as the loose parts.

    I'd not personally expect much fake products there either, its just old excess stock they're trying to sell

    Meine besten kumpel hatte ich fast 20 jahre aus den auge verloren - bis etwa 10 jahre her. Nach ein get-together von den alten schulzeit C64 gruppe, hatten wir uns ofter und ofter wieder aufgesucht - und im letzten 8 jahre arbeiten wir zusammen an freelance software projecten, im proffesionelle raum. Macht also ganz viel spass!


    Jetzt suchen wir auch wieder zusammen neue projecten im web-develop mit embedded hardware welt, also die etwas weniger standart projecten.


    Mein kumpel viele 8 und 16 bit computer und consoles - ich selbe halts bei den C64.

    Nein, die Verstärkung wird nicht so schlecht, dass am Ende 10 V aus dem Regler kommen. Das liegt daran, dass die Schaltung im Regler durchlegiert ist und die Eingangsspannung direkt auf den Ausgang gegeben wird. Das hat nichts mit einem alternden Transistor und sich verschiebenden analogen Parametern zu tun. Dafür hat der 78xx ja eine Regelschaltung.

    Soweit ich weiß, ist keine MTBF für den Regler spezifiziert. Wo kommt denn dann überhaupt Dein 10x her? Das Problem ist die Temperatur in der Regel auch gar nicht. Temperaturwechsel sind eher kritisch, also häufig ein- und auschalten

    Tja alle electrische componenten haben ein MTBF, ob es specifieziert ist oder nicht. Im algemeine sinne, gilt fur alle componenten das wenn mann sie am rande des max-ratings gebracht die lebenstaur von componenten extrem stark reduziert wird. Es gibt hersteller die daruber eine aussage geben konnen, aber ob es spezifiziert ist oder nicht macht nichts aus - das effect tredt auf.

    Langdauer temperatur hat ein exponentielles effect auf MTBF, darum hatte ich ~10x geschrieben.

    Ein und ausschalter auch - aber bei LM7805 equivalente erwarte ich das bei C64 nicht,

    Alle Liniear-regler sind dieseble schaltung als modere LDO's, sie haben alle ungefahr dieselbe intrinsike probleme am ende von ihre lebenstauer, wobei einfach *alle* power transistoren slechter werden uber zeit durch material degradation - langdaurerig hohe temperatur mit hohen strohmdichtheit - vielleicht vindest du diese LDO analyze bei high-temperature gebrauch interessant. https://training.ti.com/sites/…easy-detroit_tech_day.pdf


    Das den regler nach 10V reglet, was du "durchlegiert" nennt, ist naturlich den end-power-stage transistor innerhalb des 7805, die slechter als transistor functioniert als vorher, durch material degradation. Also wir meinen dasselbe.


    Aber, transistoren, ICs usw max-ratings usw sind nicht so das man alles machen kann innerhalb diesen ratings ohne effecte auf lebensdauer, noise, usw. Den C64 netzteil fehler mode ist genau ein gutes beispiel von ein fehler type das nicht nur open/closed ist, sondern langsam -mehr-closed.

    Was ist für Dich ein Wedge-Netzteil? Ich meine die C=-Original-Netzteile. Wenn Du die meinst, was ist an den Dioden unterdimensioniert? Die sind für 1 A Dauerleistung ausgelegt. Mehr fließt da auch nicht im Integral. Wenn die Leiterplatte schwarz wird, wurde das Netzteil nicht gut belüftet und stand vieleicht eng eingepfercht in einer Ecke. Das ist natürlich ungeschickt.

    Tja, das problem hier ist nicht das es unterdimensioniert auf einzel teile oder wegen max-rating, aber das die 5V regler (einer der viele 7805-equivalenten) am hoheren-ende von den max-ratings fur langere zeiten gebracht wird, wodurch den MTBF von den 5V regler mit ~10x reduziert wird. Das bemerkt man dan bei C64 ofter als bei andere PSU's nach 30 jahren, lese ich hier auch im forum.


    Die 902503 PCB versionen mit nur 2 dioden wirden was ich gesehen habe immer schwarz - es gibt auch 4-dioden pcbs von diese 902503 die sind nicht so schwarz. Ist ja nur das den total strohm dan verteilt wird wodurch einzelcomponenten minder locale hitze producieren. (4 aparte hotspots statt 2)


    Kann sein das gute beluftung ein problem ist, aber ich hab auch hier im forum images von diese 902503 psu's gesehen mit schwartzen pcb.

    Die beluftung in generelle sinne ist nicht zureichend entworfen - und das wird dan noch erstarkt wenn man cartidges oft gebraucht durch den zustatzlichen strohm gebrauch.


    Dan was ist dan wirklich das problem: statt power-supply ausfall (kurzschluss oder keine spannung sind beide gut weil die dein C64 nicht beschadigen) nach 20 jahren, geht den 5V regler sehr oft im fail-closed mode. Das ist gerade das problem, den end-stufe transistor im 5V regler wird schlechter und schlechter hFE wird geringer und geringer, dadurch steigt die ausgangs spannung ober 5.5V - sogar bis 10V am ende.

    Ich glaube generell gesprochen haben alle Liniair-voltage-regler dieses problem, aber bei den C64 netzteile kommt es einfach viel ofter vor als andere retro gerate. Das kan nur sein weil das 5V regler teil einfach ein viel kurzere MTBF hat als andere retro gerate, aber die 5V regler vor verschiedene hersteller selbst unterscheiden einander nicht viel aus diese zeitalter.

    Die viel kurtzere MTBF mit fail-closed endstufe kann dan nur temperatur relatiert sein.


    Also am meisten solte mann dan den 5V regler auswechseln (schwerig weill volliig erklebt mit heatsink und trafo, sehr einfach den trafo to beschadigen) und den elcos auch mal ersatzen (leicht). Dan mal wenn moglich den 240V taps statt des 220-V taps von den trafo benutzen (wenn es die gibt).


    Find ich zufiel arbeit.

    So schlecht sind die Netzteile nicht. Bis auf den Überspannungsschutz simpel und robust aufgebaut, leicht zu reparieren.


    Auch in der Industrie gibt es noch Schaltungen, die 30 Jahre benutzt werden. Maschinensteuerungen gehören beispielsweise dazu.

    Die original "wedge" netzteile haben eine billig-schaltung mit unter-dimensionierten 2 dioden rectifier (immer schwartzen pcbs innerhalb des "wedge" c64 netzteile weil diese dioden viel zu heiss werden und den pcb beschadigen), unstabielen +0.1-0.2 volt aus ein 5V regler hohlen mit ein 300 Ohm widerstand im ground-connection. Diese 5V regler wird dan extrem heiss und dadurch ist die lebensdaur beperkt. Und sie sind nicht einfach zu reparieren, weil die 5V regler komplett verklebt ist mit den heatsink.

    Im industriellen bereich sind PCB's soweit ich weiss nicht fur mehr als 15-20 jahr entwurfen. Ganze machinen sind schon fur 50+ jahren entworfen aber die electronica in solche machinen wird schon beim aufbau als "replacement part" aufgenommen.

    Bei normale (professionelle) maintenance cycle wird dan alle electronica, sensors, power-supplies, jedes 1-5 jahr durchgemessen, wo es gefehlt oder ausser spec ist ersetzt, und jeden 10-20 jahr vollig erneut um schwer-zu-diagnostisieren problemen vor zu sein.


    Interessant wird es jetzt mit auto- electronica. Jeder hort horror-stories uber auto's von weniger als 10 jahre alt mit unendlich viel electronica probleme (meistens in nicht-essential sachen wie sensors/dashboard/multimedia, aber vollig kabel-baum replacement kommt zu viel vor). 100+ cpu's in ein auto kommt schon vor.

    Al diese electronica ist dan jetzt am ende entwurf-zeit fur autos rund 2000 (wo es nicht schon ersetzt ist).

    Wird es keine old-timer autos diese electronica-zeit geben, weil es nicht ersetzbar / emulierbar ist? Vielleicht.

    Sehr guten video, mit referenzen an wikipedia artikel. Fehlt fur mich nur eine aussprach wie oft welcher fehlermechanismus dan normaleweise vorkommt bei retro computing. Und C64-specifiieke sachen wie die ganz schlecht entworfen original netzteile (uberspannung) kommen naturich noch dabei.


    Generell: Alle retro chips sind langst im teil III von den bathtub-curve, und deshalb macht es den hersteller nichts mehr aus welches fehlermechanismus es dan exact ist was fehlt. Nur fur spezial anwendungen wie Raumfahrt und Militar bekummert mann noch nach 30 jahre uber functionieren. Fur die meisten practischen Militar anwendungen heute, hat man dieses process schon aufgegeben und versucht man normalen consumer-IC / consumer PCs mit externe mittel wie metal-enclosure, airconditioning, extra-stable power supply, und majority voting so zuverlassig zu machen als vorher mit speziel entwurfen einzel-ICs.

    Normalerweise macht man ein solides Design mit einem aufgebufferten Clock-Tree. Das hat viele Vorteile, unter anderem dass Elektromigration kein Problem ist.

    Das hatte das prototype auch, es war genau diese uberdimensionierte buffers im diistribuierten clock-tree die dann gebracht waren um hohere taktfrequenzen (faster rise/fall times) zu bekommen, die dan mit ein unacceptabel hohen ausfall percentage nach lifetime tests im ofen bekommen hat. Das konnten wir dan verbesseren durch hoheren metal-layer zu preferieren fur die clock-leitungen und wo moglich doppel-vias zu routen. Aber trotzdem gibt es tatzachlich ein nicht zu ignorieren percentage failure im feld von IC's durch electromigration.


    Ich kann mich dan vorstellen fur C64 IC's, nach den probleme in 1983 sind alle chips etwas anders geroutet oder vias grosser dimensioniert im exestierende mask-set. In diese jahre war den turn-around time von ein neue mask im mask-set (zb. nur alle vias grosser machen) ja wochen stat monate die es 10 jahr spater gebracht hat.


    Silicon production ist ja immer so das es einige von den milionen/milijarden vias in einer IC unter minimal-spec gefertigd werden durch production fehler. Diese tiele haben zum beispiel ein via het hohen wiederstand in einer stelle so dass den maximale taktfrequenz des teil etwas minder hoch ist, das wird dan hoffentlich im test phase im production schon detectiert (was nicht so oft wirklich gelingt) und nach binning als low-freq teil verkauft. Aber solche nicht-vollig-defecte vias, sind dan auch genau fur electromigration sehr gefulig und konnen ja dan im feld ausfallen.

    In factory-testen sind halb-functionierende transisor und hohere-widerstand via oft nich zu detectieren. Und den effect von ein halb-functionierende transistor oder schlecht geformte via sind nicht zu unterscheiden.

    Noch ein annekdote: electromigration war bei ein prototype chip woran ich gearbeitet hab, unerwartet im distribuierten clock-netz, nicht den power linien. Dieses clock-netz andert sich ja 2x pro takt, und hat ausserhalb des power-linien den grossten strohm. Aber, diese clock linien wurden alle minimal-abstand und minimal-width und nur 1 via geroutet - genau so wie alle andere spuren. Das haben wir dan im 1-woche ofen-test feststellen konnen, und reparieren konnen fur den production-variante.

    Sofern die Leitungen im IC nach gewissen Grundregeln designt wurden, ist das nicht der kritische Punkt. Der Effekt kommt dann zum Tragen, wenn ich an die Grenze gehe, was das Material gerade noch hergibt. Dann macht es in der Praxis einen Unterschied, ob Leitungen im IC abgerundete Ecken haben oder nicht. Wenn im normalen IC Elektromigration ein Ausfallschwerpunkt ist, wurde das Design falsch gemacht.

    Stimmt, aber CBM hat ja mit electromigration viel probleme gehat damit https://en.wikipedia.org/wiki/Electromigration

    "Electromigration due to poor fabrication processes was a significant cause of IC failures on Commodore's home computers during the 1980s. During 1983, the Commodore 64 computer for a time had a nearly 50% customer return rate."

    Ich denke als reaktion sind noch immer functionierende teile stark uberdimensioniert.


    Problem mit elecromigration ist das es nie aufhort, die ionen im material bleiben immer bei gebrauch langsahm weiter migriren,m wodurch wiederstand hoher wird, wordurch dan mehr local heitzung platsfindet. Bis es fehlt.

    Viel C64 chips sind ja normal schon uber 80C nach eine halbe stunde, also das macht electromigration viel mehr ein problem als bei CMOS. Bei CMOS sind es fast immer nur power-linien mit unerwarteten oder schlecht simulierten power-density oder local heating hotspots

    Electronmigration ja, auch schwerig dafur zu dimensionieren mit IC tools.

    Bei spateren chips wird bei die power-linien, weniger scharfe ecken (45 grat) gebraucht, oder wurden ecken in power-linien stark uberdimensioniert mit viele metal-layer und vias um es so lange wie moglich functioneren zu lassen.


    4797803600_1386367445_thumb.jpg

    Ja TTL, NMOS, HCMOS chips sind unglaublich uber-engineerd das sie jetzt noch immer functionieren. Das CBM-ziel war das den C64 nur einige jahren functionieren soll. Erst viel spater wurden die meisten chip fehler ursachen gut studiert und dann danach wurden consumer chips am meisten fur 10 jahre functionieren dimensioniert.


    Ich erinnere mich seht gut den IC-pin ESD-diode grosse discussion. ESD ist einer der meist vorkommende fehlerursache, und ESD dioden gebrachen sehr viel IC platz = geld. Also wurde damals in 90'r jahren sehr viel zeit genommen um aus zu finden wie klein man den ESD dioden unter jeden pin erstellen kann das den IC die gangingen ESD specification holt. Daneben, in ein ofen auf 200 C fur eine woche um so zeit-effecte zu emulieren. Alles nur um das beste compromis zwichen kosten (silicon area) und lebensdauer zu finden.


    Geht auch anders, altere Militar spec IC's und raumfahrt IC's sind eigentlich oft uberdimensioniert so das sie einzelfehler von transistoren uberleben konnen. Zum beispiel alte analog raumfahrt IC's hatten immer 4 transistors in ein schaltung so das diese 4 wie 1 transitor functioniert. Wenn 1 dieser 4 transistor in diese schaltung felht (entweder "offen" oder "geschlossen" fehler), bleiben die ubrige 3 noch immer functionieren wie 1 transistor. (Pioneer 10)


    Ich glaube mit C64 haben wir gluck das alles noch immer nach 40-50 jahren functioniert.

    Plastix ja ich kenne den systemloader nicht weiter, aber das tool kan ja nur den kernal-rom ersetzen mit C64 RAM.

    Also ich hatte das so eingeschatzt hier oben das die benutzer von systemloader die beschrankungen auch kennen.

    Nutzlich kan systemloader sein fur eigene C64 experimente, eigene kernal-mods mal ausprobieren, cross-compiler oder hardware checks aber naturlich wird systemloader nicht mit die meisten prg's compatibel sein. Um mit eigene experimente den KFF und systemloader zu gebrauchen sollen die alle auf ein D64 image stehen.


    Fur richtige soft-kernal support wie EasyFlash 3 hat, und wie skoe es in sein document beschrieben hat, braucht den KFF neue firmware. So wie ich hier oben geschrieben habe gibt es davon ein beta version, die wartet auf ein freiwilliger die das ausprobieren, messen kann. Danach kan es mit den gangigen firmware gemerged werden.

    @DerSchatten Es gibt schon ein betaversion von soft-kernal, die functioniert auf mein eigenes KFF-abgeleite prototype mit andere pinout.

    Diese soft-kernal wurde ich gerne zum merge mit den gangigen kff software vorbereiten, aber zuerst soll ein freiwilliger den soft-kernal version von KFF mal ausprobieren.


    Ich kann das nicht selbst weil ich kein original KFF besitz.


    Problem ist das es moglich ist dass den ST-chip GPIO pin fur EXROM und GAME auf meine version "normale" GPIO's sind und im standard KFF sind das "fast-normale" GPIO. Es kann sein das den timing von dieser pins etwas anders ist, und dadurch die ARM code etwas anders sein soll.


    Also wenn jemand dass versuchen will dan geht das schon. Auf eigene risiko naturlich - es gibt naturlich das risico das ich eine kleine fehler beim C programmieren gemacht habe fur den normal KFF version.


    Steht in meine github-fork

    Yeah 10k cycles is enough in any way I can think of. Its only used by KFF on firmware updates andwhen switching between larger than 64kB crt images.


    SDcards have similar cycle wear.


    For C64 hobby usage 10k cycles will last decades.

    Thanks merlintwa for your insights into the firmware. Interesting to know that there is a second timer to correct the first timer. I guess this is where the mcu becomes in sync with the C64. I have played witht the bluepill (stm32f103) and I noticed the latency jitter too. I think it might be because of the pipelines, they have to be emptied before branching on an interrupt. and then there is the flash cache prefetch thing also. I think.

    Hi bwack,


    The details of the STMF4 lacency is not made clear in the documentation, but I had to do quite a study of it while making the soft-kernal mode work to make an as short as possible jitter reduction code.

    Kim's approach is to read the running timer value at the start of the interrupt then copy it to a debug timer. The normal timer is on the APB bus and takes 5 cycles to access. The debug timer is part of the ARM core, sits right before the 3 bus muxes, and is around 3 cycles to access. Then Kim uses wait loops to wait for the debug timer to reach a value - so the remaining jitter is the max delay of one loop iteration, which is 7 cycles. Then the R/W, ROML, ROMH , IO1, IO2 are read and checked if there is an action to take. On a read, a second wait loop is used to hold data to the end of the cycle.


    The official ARM docs mention 12 cycles of latency plus a small amount of jitter depending on the currently executing instruction when the interrupt occurs. The doc is quite extensive on this part, and I can see from just the ARM doc that there can be 6 cycles of jitter just when the next interrupt is on the right cycle while leaving a previous interrupt (despite a lot of clever stuff in the CPU). But this ARM doc assumes all memory is zero-waitstate.


    However the peripherals on the ST busses have waitstates, some peripherals more than others. And the ARM has a write-buffer which I have measured will hold up a next instruction, and that next instruction will actually complete before the interrupt is taken. That is where I found 15 cycles of latency, it was because there is a write to a SD-card peripheral (which is put in the write buffer, and takes 7 cycles) followed by a jump to the start of the sd-card read loop (3 cycles) followed by an SD-card peripheral read (7 cycles). Somehow an interrupt occuring just when still executing that jump, will actually wait for the write-buffer to clear and then will fetch that read instruction (separate busses), then wait for both that write AND that read to complete before taking the interrupt.


    None of that is documented.


    In my soft-kernal mode code I found the 7 cycle jitter using a delay loop is too high so I use a 3 cycle delay loop instead. Also I had to re-code everything in assembly because the C compilation was too unstable (really minor changes causing radically different ordered code) for the soft-kernal mode. But it works!

    Hi bwack, its very close, timer is locked to counting the number of 168MHz cycles from the edge of PHI2, and an interrupt is generated (depending on NTSC or PAL) around 96-43 cycles after that edge. This is done using hardware features of the STM IC.

    Unfortunately, the ARM can have significant jitter (just like the 6510 with IRQ) on the start of the IRQ (I've measured 1-7 frequent and sometimes up to 15 cycles), so first another timer is used (which adds to the duration of the interrupt) to reduce the jitter of the start of the interrupt.

    Then, a cycle-accurate piece of code is run (which is compiled C but is quite sensitive to changes in C compiler settings or minor source code changes). After that completes, the ARM resumes background tasks.


    Some KungFuFlash cartridge-drivers have both a "normal" mode where there are some cycles left for background tasks

    Other cartridge drivers have "6510 + VICII" mode where the 6510 and the VIC both can access the cartridge for sprite data / char data for example. In this dual access mode, there are no spare ARM background cycles possible and the interrupt is active 100% of the time until the menu button forces a C64 reset.


    Even the "normal" mode driver can just make the interrupt timing when there are a lot of back-to-back accesses to the cartridge from the 6510. In such cases there are almost no background cycles left.


    But under normal cases, there are always some zero-page or ram accesses or wait cycles while running code from the cartridge every few cycles. When the Arm interrupt code detects there is no Cartridge access going on in the current cycle, it can exit the interrupt fairly early leaving sufficient background cycles to do things like SD-card access in D64 mode and USB in EAPI mode.

    Ich mag am liebsten die mindest-aufwendigen hardware losungen, also mit den mindensten IC count. FPGAs sind schon aber wenn es ohne kann find ich es schoner.


    UNO2IEC hat 1 IC und ist kleinsten PCB (Atmel, Arduino nano)

    KungFuFlash hat 1 IC (ST arm micro all-in-one)

    SD2IEC hat glaub ich 3 IC's, kann aber auch nur 1 haben (Atmel + 74xx sind optionel)

    Rest weiss ich nicht aber mehr als 3 glaub ich.

    Das ist doch (fast) ganz normal? Klar wird IPv4 UND IPv6 versucht (wenn der Server entsprechende DNS-Einträge hat und DNS überhaupt erreichbar war).

    Vielleicht, ist nicht meine erfahrung. IPv6 / IPv4 support ist in viel applications "best effort" und nicht so stabiel als nur IPv4 - wird also ofter ausconfiguriert in meine erfahrung weil alles stabieler wird.


    Bei ein hangenden WLAN treiber oder TCP stack, hilft doch oft um soviel moglich sockets force-closed zu machen. Das kann ein treiber ein "kick" geben. Zum beispiel weil es zufiel interne buffers offen sein, oder wenn intern auf ein mutex gewartet wird.

    Force close kann nur den application selbst machen. Der TCP stack warten bis ein socket timeout passiert + 2 minuten FIN_WAIT, und macht dan noch nicht immer ein gute cleanup.


    Noch so eine anekdote: Android 4 hatte damals ein apache-http-lib 1.0 im basis-OS-java set mitgeliefert. Diese lib hatte einen bug das den DNS timeout default nicht eingestellt war (also infinite timeout) und auch nicht extern vom API calls zu beeinflusen war. Das hatte viel arger bekommen, und viele app hangups verursacht genau wenn WLAN packet drops passieren bei DNS versuche.

    Damals war app size viel mehr ein issue als jetzt also wird fast immer diese built-in buggy library von apps verwendet.


    Mussten alle >1M user apps also die letzte version diesen library entweder selbst mitkomiplieren oder eine andere library gebrauchen.


    Naja damit will ich sagen, wenn es WLAN probleme auftreten - un in meine erfahrung passierst das bei sehr viele leute, sehr oft - dan sind basis-OS sachen nicht zureichend oder daueren viel zu lang (2+ minuten)


    Aber wenn ich deine berichte so lese gibt es keine WLAN dropouts in dein setup also das ist super!


    Fur meine eigene long-term SSH sessions gebrach ich X2Go. X2Go is sehr sensitive fur WLAN dropouts, hab ich bemerkt, aber das Linux GUI oberflach bleibt ja functionieren wenn die verbingung fehlt also sehr gut fur solche setups. Also ganz gut fur monat oder sogar jahren-lange linux sessions.

    Einge tage kann ich den ganzen tag ohne probleme mit X2Go eingelogd bleiben. Andere tage, 10 oder mehr dropouts pro tag.

    Im betriebs netzwerk wenn einer meine collega's ein Windows10 update downloadet, dan fehlt x2go jeden 15 minuten. Danach bleibt es 100% functionieren den ganzen tag. Wenn ich bekabeltes netzwerk im betriebsnetzwerk gebrauche dan functioniert x2go aber fast immer ohne probleme, auch wenn windows 10 updates platzfinden.

    Ok, meiner erfahrung ist anders, uber stabilitat von netwerk. Waran das exact liegt, weiss ich nicht.




    Fur mich ist SSH etwas wunderlich. Ich habe ein beispiel von ein 24/7 SSH - session zwichen zwei server in zwei rechencentrums in Afrika, wobei durch standige power verlust im land (auch bei den Telco) die routers ~10x pro tage restarten, und oft fur viele minuten sogar stunden down sind.


    Wenn ich nichts mache, keine berichte gesendet werden, bleibt SSH functionieren ohne probleme, weil mit TCP ja default *keine* keep-alives macht. Und wen ein router power-fehlt kommen auch keine TCP Reset-packets, also beide seiten von den SSH verbindung bemerken nichts davon. Komt power wider zuruck bevor ich eine taste beruht, bleibt alles functionieren.


    Stel ich aber TCP 30-sec keepalives ein, oder gibt es ein SSH mit log-file dump continue data, dan fuhrt jeden power-verlust langer als den TCP re-transmit timeout zum verlust von verbindung.


    Wie das exact so functioniert? Weiss ich nicht aber ich find das ganz Komisch.


    Also bei Browser, bemerk ich das bei netzwerk fehler viele sachen probiert werden, ich habe das interpretierts als:

    - Zuerst wird ein normalen TCP request gemacht. Normalen Nagle-algortime sachen dabei.

    - Komt dan innerhalb einige secunden kein antwort? Wird das nochmals versucht.

    - Kommen OS netzwerk fehler? Dan wird abhanging von fehlercodes:

    - In parallel, nochmals mit anderen source-IP versucht (ipv4/ipv6, aber auch local IPs LAN/WLAN/VPNs)

    - DNS auf neu probiert, *in parallel* von meherere DNS (wenn es meherere eingestellt sind)

    - HTTP-DNS versucht

    - Mit OS- functionen (strace) sockets force-closed und neu opened

    - Noch laufenden background requests force-closed

    - Ein error-meldung gezeigt an den user, aber sonstdem noch immer weiter im backgruond neu sockets versucht zu offnen, ips heraus zu finden, und expoinential-backoff retries

    - Http requests mit HTTP1.0 versucht stat 1.1


    Ja wie das alles und in welcher weise und was exact das OS selbst macht und was den browser exact sebst macht das hab ich nicht vollig studiert.

    Aber, normalen TCP/IP Linux/PC software ohne http libraries, bleibt oft bei ein einzelne gethostbyname anruf mit IPv4, ein ein einzige socket anruf, und das reicht fur 90% aller datacenter software. Bei ein TCP timeout wird entweder ein error gelogd und folgt kein retry, oder es folgt ein absturtz.