Vispār jau lielākā interese ir kādam ir jābūt fragmentācijas līmenim, lai tas kautkādā veidā sāktu ietekmēt SD kartes teorētisko caurlaidību.   Tipiski lai rakstītu tos pašus 90MB/s izmantojos SD kartes CMD25 komandu (Multi-Block Write): Ja fails ir vienā nepārtauktā blokā, tad visa rakstīšana pa lielam ir ar vienu komandu.   Host SD Card | | |── CMD25 (start address) ──────────>| |<─ R1 response ────────────────────| | | |── [Data Block 0] ────────────────>| |── [Data Block 1] ────────────────>| ← continuous stream |── [Data Block 2] ────────────────>| |── [Data Block N] ────────────────>| |── CMD12 (stop) ──────────────────>| ← or predefined count |<─ R1b (busy until flushed) ───────|   Bet ja ir ntie fragmenti: Host SD Card | | | === Fragment 1: addr 0x001000 === | | | |── CMD25 (addr=0x001000) ─────────────>| |<─ R1 (ready) ────────────────────────| |── [Data Block 0] ───────────────────>| |── [Data Block 1] ───────────────────>| |── CMD12 (stop) ─────────────────────>| |<─ R1b (busy ~200µs) ────────────────| ← card flushes write buffer | | | === Fragment 2: addr 0x036A00 === | ← address jumps, new fragment | | |── CMD25 (addr=0x036A00) ────────────>| |<─ R1 (ready) ────────────────────────| |── [Data Block 0] ───────────────────>| |── [Data Block 1] ───────────────────>| |── [Data Block 2] ───────────────────>| |── CMD12 (stop) ─────────────────────>| |<─ R1b (busy ~350µs) ────────────────| ← card flushes write buffer | | | === Fragment 3: addr 0x1C2000 === | ← address jumps again | | |── CMD25 (addr=0x1C2000) ────────────>| |<─ R1 (ready) ────────────────────────| |── [Data Block 0] ───────────────────>| |── [Data Block 1] ───────────────────>| |── [Data Block 2] ───────────────────>| |── [Data Block 3] ───────────────────>| |── CMD12 (stop) ─────────────────────>| |<─ R1b (busy ~200µs) ────────────────| ← done | |   (nu tas viss teorētiski)  

ieej google mi režīmā un uzzināsi ātrāk nekā forumā

Enefit abos reģionos ir pārstāvji.

Plus/mīnus. (pa lielam tas pats ar lielākām kartēm vai mazākiem failiem)   DJI acīmredzot izmanto mazliet citu stratēģiju. Sadala SD kartes vietu 'slotos' (teiksim tajos 1.6GB uz failu), un vienmēr raksta katru jaunu failu no slota sākuma un tādā veidā rotē.   Pirmā izmanto standarta stratēģiju, kur atrod pirmo brīvo vietu (kautvai vienu klāsteri) un raksta tur, kad aizpilda, meklē nākamo.

Nu blēē 🤭,tā jau  būs otra bezizeja!!!  Nu pie vellna,lai pati perās ar savu enefitu 

Līdzēs, ka jau pats raksti, ja kundzīte būs paradīzē vai ellē deklarējusies.😀

Vai DJI action kamerai ir bijuši tikpat sarežģīti apstākļi ar ierakstīto/dzēsto video skaitu un izmēriem kā pirmajam piemēram?

Itkā ja vairs neslēdz līgumu ar  tēmā minēto  Pašvaldības īpasumā esošo dzīvoki, vai tad,tad arī nav jaanulējās  tā dzivokļa skaitītājam, es tiešām nezinu....  Nu ko piezvanīs,parasti  vis vienkārši notiek  ja līgumā slēdzējs ir nosprādzis!    Jeb Pašvaldība  pati visas tās lietas  sakarto?! Jeb līdzēs  tas kad Kundzīte  būs citur deklarējusies?!

Bet nopietni, nezvani, neraksti tirgotājam, jo tas var zināt labāk kā forums kā tev tur būs ar to izbeiKšanu.

Cik zināms,parasti bija tā... Ja uzradās  cilvēks kurš pārņem  tā dzivokļa skaitītāju uz savu vārdu,ta  iepriekšējais maksātājs anulējās.Jaunais īrnieks ķipa  ņem uz sava  varda ar saviem pribambasiem-piemējasm  biržas  beztermiņa līgumu,bet tam arī ir kirdika kamēr kāds  cits nepārņem -jeb šis mierīgi var pārtraukt,izbeikt saistības  atiecībā uz tā skaitītāja!?    Midzenis takš Pašvaldības īpašums-par uzturēšanu tak atbild pašvaldība!?    

Protams ne aiz neko darīt. Bet lai salīdzinātu cik labi ar problēmu tiek galā dažādi daškamu (aka videoreģistrātoru) ražotāji 😂

Brrr. Tīri aiz neko darīt.

Ko tur saprast vai nesaprast?    Teiksim ja tu paņem SD karti un noformatē kā FAT vai exFAT, vai jebkuru citu no tās famīlijas (nekādas būtiskas atšķirības starp variācijām nav). Failu sistēma sadalīs to SD karti 'virtuālos' klāsteros, tipiski izmēros no 32kb līdz 128kb, kā nu kurai OS labāk patīk. FAT princīpā ir ļoti primitīva failu sistēma, kur SD kartes (vai jebkura cita diska) sākumā viņa rezervēs pāris megabaitus 'Failu Tabulas' vajadzībām (atkarībā no diska/klasteru izmēra). Failu tabulā katram failam vienkārši būs atzīmēts pirmais klāsters, kur tas fails sākas. Tas vienkārši ir LinkedList (programētāji sapratīs) ar klasteru adresēm. Tapēc arī ļoti vienkārši var atjaunot itkā izdzēstus failus. Seko tikai klāsteru ķēdītei un pārkopē.   Problēma tāda ka nepārtraukti dzēšot tie klāsteri vairs nav pēc kārtas, jo pa vidam bij kāds cits fails, kur pirmstam izdzēsts. Nu tas tākā jebkuram kas atcerās Windows defragmentācijas tūļa laikus vajadzētu būt skaidram. Kā tas redzms tam 86MB failam. Fails sadalīts 30 fragmentos, citi mazliet lielāki, citi mazāki.    Principā jau tas nekādā veidā neietekmē ikdienas lietošanu. Bet ja tā teiksim ir videokamera, kas izmanto SD kartes ātrumu pilnībā, tad pēc laika rodas problēma. - Jo vairāk tie fragmenti izkliedētāki un jo vairāk to fragmentu, jo vairāk IO operācijas. Attiecīgi kamera vairs nespēj ierakstīt vajadzīgo apjomu. - Jo vairāk tie fragmenti izkliedētāki un jo vairāk to fragmentu, jo vairāk izdēs/ieraksti cikli. SD karte nevar ierakstīt teiksim 1kb. Atkarībā no izmēra tie ir 1 - 4MB. Tātad katru reizi kad vajag ierakstīt to nelielo pāris klāsteru fragmentu, nākas idzēst 4MB bloku un pārrakstīt pa jaunam. Attiecīgi SD karte nolietojas ļoti ātri.   Tapēc arī itkā pat industriālas SD kartes ļoti ātri nobeidzas dažādos videoreģistrātoros, pat pašos dārgākajos.   Tai problēmai nevajadzētu būt problēmai, ja FAT drivers ir optimizēts konkrētajai vajadzībai, kā tas ir DJI gadījumā, kur viens fails ir viens garš fragments.   Tūlis vienkārši palīdz ātri vizualizēt fragmentācijas pakāpi. Tīri debuggošanai.   

Kā ,ja tu vairs nevari īrēt, elektrībai ar jaizbeidzās!!!

Ar to izbeiKšanu būs kā būs 

Es par to ar aizdomājos!😁 

Nekādā gadījumā un ne pie kādiem apstākļiem nezvanīt vai nerakstīt esošajam tirgotājam. 

Ja vien būtu kāds vesels velo…  Katrs velo citādāks, attiecīgi arī rati un spieķi atšķiras. It kā jau katram velo ir 2 rati, bet priekšējais ir "simetrisks".   Nu protams, ka jo mazāka izkliede, jo labāk. Jautājums jau bija, kādi ir tie knifi, lai dabūtu mazāku izkliedi. Park Tool tutoriāļos par to nerunā (vismaz ne tajos, kurus noskatījos), kaut kādos citos vispār nepieminēja ne spieķu nospriegojumu, ne "radiālo taisnošanu" (nav ne jausmas, kā to latviski sauc; "radial truing"), ne par centrēšanu… Vienīgais, ko tajos video iesaka - sameklēt "nelīdzeno vietu" un pieregulēt vai nu 1, vai 3 spieķus (kā kurā video).   Sākumā bija sanācis kaut kā šādi (bilde zemāk). Te bija tas variants, kur puse rata ideāla, puse - "amerikāņu kalniņi". Nu nepatika man tā "neglītā puse", mēģināju piedzīt tuvāk tiem "vidējajiem papagaiļiem" (16 kreisā puse, 20 labā puse), beigās panācu vien to, ka visu bija jāsāk no sākuma.     Otrajā piegājienā tā "ideālā puse" vairs nav ne tuvu tik ideāla. Bet nu pēc vienas pilnas dienas un divām "trešdaļdienām" vairs nav vēlmes turpināt. Tāpat jau tā rata dēļ brīvdienās (un vispār jau pāris nedēļas) nācās iztikt bez velobraucieniem…

Situācija sekojoša. Dzīoklis kurā ir slēgts līgums  ar enefit ir Valsts īpašums un kundze īrniece... Kundzītei līgums ar Enefit uz 6gadiem...četri ir pagājuši,līgumsoda laiks ar pagājis! Jautājums. Kundzītei vajag atkratīties no tā enefit,bet nejau pārejot pie kāda  cita vai kā savādāk! Viņai jaunajā dzīvesvietā būs haļavā elektrība! Ieejot tai  viņas  Enefit lapā,nav tādas funkcijas ,izbeikt saistības....  Pametiet ieteikumus, kās jadar?  Kundzīte baidās ka jaunie īrnieki esošājā vietā  sēdēs uz viņas reiķina!

Vajadzētu man te kaut ko ierakstīt, lai foruma biedri trīs dienas pērtos kā mušas pa tūtu, bet es no šitā neko nesaprotu, pieļauju, ka pārējie arī. Piedod, Andri