Nu tur iespējams kombinācija, jo SD kartes jau ar dažādas, ar dažādiem NAND moduļiem -> SLC, MLC utt, kur pārrakstāmo ciklu skaits var būt no 3 000 - 100 000 (atkarībā no tipa). Bet nu tas neatceļ faktu, ka neatkarīgi no tipa optimizēta rakstīšana cikla/riņkveida ierakstam var paildzināt kartes mūžu desmitiem reižu.   Viss jau atkarīgs cik intensīvi raksta. Ja kautkāds videoreģistrātors ar 3 kamerām (uz priekšu, kabīne un aizmugure) un teiksim katrs 4K video ar kautkādiem 20MB/s, tad jau pa pāris stundām pārraksta pat 1TB karti. Ja tas reģistrātors tiek izmantots kautkāda komercauto, kas brauc 8+ stundas dienā, tad kartei kirdik pa pāris mēnešiem vai pat ātrāk. A kautkāda 80+ MB/s ātruma karte tagad vismaz 200+ eiriki gabalā.   Nu ja raksta tik uz kustību, 1080p ar relatīvi zemu bitreitu, tad jau iet gadiem.   Teorētiski jau der, bet ne videoreģistrātoram, kam kurš var tikt atslēgts izslēdzot aizdedzi vai kautkādas avārijas gadījumā. Nepaspēji ierakstīt SD kartē, video kukūu.             

Man personīgi nav bijis vairāk par 985Mbps Speedtesta/ Steam dowlodā.. Bet man ir salinkojies uz 1.25gb.. kkad mēģinaju 2.5gbps bet RB4011 nepatika..    Es Teiktu ir jāmēģina dabūt vismaz 2.5gbps  link speed uz SFP+.. bet TET GPON OLT pusē domāju  ka visiem  privātajiem klientiem ir uzlikti cieti  1Gpbs un varbūt ieraudzīsi speedtestā maģisko 1Gbps.. .  Nav kā Jeņkos kur ir redzēti 1Gbps pieslēgumam 1.2Gbps kad ieliek GPON SFP+.    Te ir piemērs ko @hero saka   For example: OLT(config)#traffic-profile profile-id 10 profile-name test1 cir 128 pir 256 cbs 2000 pbs 3000 Here the parameters meaning: <CIR>: Committed Information Rate, range for 64-10240000, unit is kbps; <PIR>: Peek Information Rate, range for 64-10240000, unit is kbps; <CBS>: Committed Burst Size, range for 2000-10240000, unit is byte; <PBS>: Peek Burst Size, range for 2000-10240000, unit is byte;   Ja no Tet varētu uzzināt šis konkrētas vērtības tad būtu ļoti labi.. informatīvi    Autor, Te Kaspars cīnijas ar "lēto" Moduli https://kaspars.net/blog/setup-huawei-ma5671a   es pats lietoju ODI DFP-34X-2C2 un man tā nebija jāčakarējas..    Te Vēl info.. https://forum.lowyat.net/topic/4925452   Vēlāk no Twitter saliks screenshoot..    Vajadzētu saņemties un to Manuāli uzrakstīt ..     

Te mērķis nav uzzināt, te mērķis parunāties ar DI.

Neesmu kursā, bet laikam tāpēc dažu iekārtu OS, piemēram NAS, izmanto tehnoloģiju, kad  cache sīkfaili tiek uzkrāti RAMā līdz noteiktam apjomam un tad grūsti uz OS SDkarti. Šī tehnoloģija, iespējams, nederēs visos scenārijos. Man ar vienā vecā lētā ipkamerā ~5gadi, un SD lasās. nekādi paziņojumi nav bijuši.

Man ir pāris ķīniešu novērošanas kameras, kas raksta SD kartē, kad ir kustība, patiesībā laikam raksta visu laiku un saglabā, kad ir kustība, jo ierakstā ir kāda sekunde pirms objekta parādīšanās kadrā. Tad gan jau fragmentējas utt. Režīms ir kad karte pilna - raksta pa virsu. Kādu 5 gadu laikā bija pāris reizes, kad paziņoja, ka karte kirdik. Vienu izvilku un uztaisīju nevis quick, bet full format Win vidē un joprojām strādā, otra izbeidzās, nomainīju. Varbūt tas ir saistīts ar Andra teikto.

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