Tulee mieleen tunne että ajassa on siirrytty ainakin 20 vuotta taaksepäin.
VAPAAN MARKKINATALOUDEN PERUSTEET: (rautapuolellakin)
1. Voiton maksimointi.
2. Tutkimus ja tuotekehittely.
3. Loppukäyttäjien minimitarpeiden kartoitus (asiakaslähtöisyys).
4. Mitään "lopullista" standardia ei saa muodostua. (juoksutetaan)
MarkkinatalousNoin se menee, on se nähty. 1. on tärkein. Kohta 2. tulee vain silloin esille kun kilpailijat tai kohta 3. pakottavat siihen. Nimimerkillä, niin monta kertaa turhautunut siitä, että joku asia on tehty todella välttävästi ja tiedän miten sitä voisi parantaa. Mutta kun korjausta ei ole "pakko" tehdä, niin sitä ei tietenkään haluta tehdä, koska korjaamisesta muodostuu kuluja jotka siten verottaisivat kohtaa 1.
Eli vaikka monesti sanotaan että vapaa markkinatalous ja ammattilaiset tekevät hyviä ohjelmia. Mä sanoisin lähinnä, että ne tekevät niin HUONOJA ohjelmia, kuin markkinat sallivat niiden tehdä. Mitään mielenkiintoa hyvien ohjelmien tekemiseen ei oikeasti ole. Näin se vaan tuntuu menevän, vaikka joskus nuorempana "idealistina" joskus haaveilinkin siitä että jotain tehtäisiin kunnolla. Microsoftin toiminnassahan tämän huomaa myös hyvin, strategia on juuri samanlainen.
Mutta mitä tulee tuohon levy I/O ongelmaan.Testaisin vielä uudestaan ja varsinkin suuret yksittäiset tiedostot muodostavat isoimman ongelman. Eli syystä tai toisesta kaikki pienemmän levy I/O tehtävät jäävät "tolkuttoman pitkään jonoon" ja toteutuvat vasta kymmenien sekuntien perästä. Kun monet ohjelmat sitten tekvät peräkkäisiä I/O operaatioita, niin aika moninkertaistuu. Edelleen esimerkki tolkuttomasta latenssista ja liian isosta RWIN:istä pätee tähän hyvin.
Kysymys onkin, että voiko tuota levy I/O prioriteettia säätää jotenkin? Haluaisin itse laskea tuota lohkokokoa jolla operaatioita käsitellään. Silloin saisin pienempien tehtävien jonotusajan paljon pienemmäksi.
Outoa että näin radikaaliin ongelmaan ei ole kiinnitetty huomiota, vaikka nimen omaan kernelin CPU schedulerin fairness ja priority inversion ongelmiin on varmasti käytetty tolkuttomasti aikaa. Ehkä se ongelma juuri onkin siinä, että molemmat tehtävät, tuo suuri ja pieni tehtävä ovat samalla prioriteetilla. Mutta silti fairness ei missään nimessä mielestäni toteudu. Tehtävien jako tuntuu enemmänkin tapahtuvan operaatio kuin tavu tasolla.
Historian havinaa ja turhaa tarinaaEi millään pahalla, mutta tämä muistuttaa oikein lämpimästi minua DOS, Windos 3.11 ja DeskView ajoista. OS/2:ssa tätä ongelmaa ei muistaakseni ollut.
Paras karhunpalvelus tuolloin oli se, että kun oli yksi serveri joka käytti DV:tä, niin alkoi kopioimaan kahdelta CD:ltä jotka oli CD-swapperissa tavaraa kiintolevylle. Hölmömpikin arvaa miten siinä kävi. Koska levy I/O:t meni ilman optimointia tapahtuma kohtaisina ja synkronisina lopputulos oli tämä.
1. Vaihdetaan CD1 asemaan, luetaan sieltä N kiloa (buffers)
2. Vaihdetaan CD2 asemaan, luetaan sieltä N kiloa (buffers)
3. Kirjoitetaan data 1
4. Kirjoitetaan data 2
5. Suoritetaan muiden käyttäjien operaatioita
6. palataan kohtaan 1.
Ongelmahan ei sinänsä ole suuri. Paitsi tuo taikasana vaihdetaan cdX asemaan. Joka kulutti aikaa noin 5 sekuntia. Näin ollen pelkästään terminaalikäytössä se että käyttäjä sai echon siitä mitä kirjoitti, niin kesti helposti 10-15 sekuntia.
Kokä järjestelmä oli siis teknisesti täysin jumissa, vaikka se toimikin. Synkronisella I/O:lla tuo levyjen vaihto oli aika killeriä. Heh heh.
Tuo taitaisi siis toimia ubuntullakin kokemani valossa.
Aihe: Levy I/O vetää koneen täysin jumiin, Linux ominaisuus? (Luettu 7469 kertaa)
