mboost-dp1
unknown
Nu bliver det spændene, har selv prøve 2.5.45 en gang og den var ok stabil og den del hurtiger. Så nu vil jeg hente denne ned og se hvad den siger. Mange nye ting, som er kommet med i denne her kernel. Godt arbejde. :)
#2:
2.5/2.6 er som sådan ikke specielt hurtigere, men der er fokuseret meget på at få desktopmaskiner til at FØLES hurtigere, ved at ændre scheduleren og sørge for lavere svartider(latency) på kerneniveau.
Alt dette kommer for slutbrugeren til at FØLES som om maskinen er langt hurtigere, men til ren rå beregning, vil det sandsynligvis koste lidt(den ER langsommere) :)
2.5/2.6 er som sådan ikke specielt hurtigere, men der er fokuseret meget på at få desktopmaskiner til at FØLES hurtigere, ved at ændre scheduleren og sørge for lavere svartider(latency) på kerneniveau.
Alt dette kommer for slutbrugeren til at FØLES som om maskinen er langt hurtigere, men til ren rå beregning, vil det sandsynligvis koste lidt(den ER langsommere) :)
#5
Det kommer an på hvad du mener med "rå bereginger". Ægte "rå" beregninger, som fx primtalsbestemmelse, tager ikke længere tid da det ikke bruger nogen systemkald (her ser vi bort fra at der skal udskrives en ganske lille mængde output)
Systemkald er det der virkelig er forskelligt i 2.2/2.4/2.6. I 2.6 er disse kald ca 3-6% langsommere (i gennemsnit) end 2.4. Til gengæld er en håndfuld kald der bruges ofto, op til 4 gange hurtigere! Eksempelvis koster det kun 50-60% af tiden i 2.4, at lave nye små filer (og slette dem), i 2.6.
IBM har lavet en test der viser dette:
http://www-124.ibm.com/developerworks/opensource/l...
Det omtalte eksempel med små filer er vist på side 13, men der er meget mere at komme efter.
Det kommer an på hvad du mener med "rå bereginger". Ægte "rå" beregninger, som fx primtalsbestemmelse, tager ikke længere tid da det ikke bruger nogen systemkald (her ser vi bort fra at der skal udskrives en ganske lille mængde output)
Systemkald er det der virkelig er forskelligt i 2.2/2.4/2.6. I 2.6 er disse kald ca 3-6% langsommere (i gennemsnit) end 2.4. Til gengæld er en håndfuld kald der bruges ofto, op til 4 gange hurtigere! Eksempelvis koster det kun 50-60% af tiden i 2.4, at lave nye små filer (og slette dem), i 2.6.
IBM har lavet en test der viser dette:
http://www-124.ibm.com/developerworks/opensource/l...
Det omtalte eksempel med små filer er vist på side 13, men der er meget mere at komme efter.
Er der nogen der ved hvad jeg gør galt?
Når jeg prøver at compile 2.6-test1 går det fint - ingen fejl, men da jeg skal til at installere modulerne, kommer den med en fejl om at nogle dependencies ikke er met...
Okay - jeg prøver alligevel, putter den i lilo.conf og kører lilo.
Fint nok - ingen fejl og rebooter computeren. Nu er det bare: når jeg vælger kernen loader den et øjeblik men så skifter skærmen til sort. Weird ... Dog ikke en kernel panic, men bare sort!
Btw: Jeg har IKKE framebuffer eller videomode selection slået til!
Når jeg prøver at compile 2.6-test1 går det fint - ingen fejl, men da jeg skal til at installere modulerne, kommer den med en fejl om at nogle dependencies ikke er met...
Okay - jeg prøver alligevel, putter den i lilo.conf og kører lilo.
Fint nok - ingen fejl og rebooter computeren. Nu er det bare: når jeg vælger kernen loader den et øjeblik men så skifter skærmen til sort. Weird ... Dog ikke en kernel panic, men bare sort!
Btw: Jeg har IKKE framebuffer eller videomode selection slået til!
Ahh - got it...
Skulle opdatere binutils (til version 2.12) og gcc skulle være version 2.9x i stedet for 3.x
Heh - happy compiling
Skulle opdatere binutils (til version 2.12) og gcc skulle være version 2.9x i stedet for 3.x
Heh - happy compiling
#12
Du aner ikke hvad du snakker om, tydeligvis. Hvis vi ser bort fra SCSI som transport, så bruges scsi-agtige kommandosæt i udstrakt grad af andre periferi typer som feks ATAPI. cdrecord snakker ikke SCSI, den snakker MMC kommandoer som ikke er SCSI specifikt. At Joerg så har lidt twisted opfattelse af hvad der er vigtigt idag er en anden ting.
Linux har heldigvis ikke begået samme fejl som visse andre OS med at behandle alt som SCSI som ikke er det. 2.6 har nu tilføjet generisk support for SG_IO ioctl som bruges af cdrecord, så det er muligt at brænde på ATAPI drev fuldstændig uden at blande SCSI laget ind i det. Så sparer du lige et helt SCSI lag på en desktop maskine, som sikkert ikke har SCSI devices alligevel. Og du sparer flere hops igennem kernen.
Du aner ikke hvad du snakker om, tydeligvis. Hvis vi ser bort fra SCSI som transport, så bruges scsi-agtige kommandosæt i udstrakt grad af andre periferi typer som feks ATAPI. cdrecord snakker ikke SCSI, den snakker MMC kommandoer som ikke er SCSI specifikt. At Joerg så har lidt twisted opfattelse af hvad der er vigtigt idag er en anden ting.
Linux har heldigvis ikke begået samme fejl som visse andre OS med at behandle alt som SCSI som ikke er det. 2.6 har nu tilføjet generisk support for SG_IO ioctl som bruges af cdrecord, så det er muligt at brænde på ATAPI drev fuldstændig uden at blande SCSI laget ind i det. Så sparer du lige et helt SCSI lag på en desktop maskine, som sikkert ikke har SCSI devices alligevel. Og du sparer flere hops igennem kernen.
#13
[Du aner ikke hvad du snakker om, tydeligvis. Hvis vi ser bort fra SCSI som transport, så bruges scsi-agtige kommandosæt i udstrakt grad af andre periferi typer som feks ATAPI.]
Muligvis.
Men alle brænderprogrammer på windows bruger tit en eller anden ASPI driver, som så vidt jeg har forstået er en SCSI wrapper?
[cdrecord snakker ikke SCSI, den snakker MMC kommandoer som ikke er SCSI specifikt. At Joerg så har lidt twisted opfattelse af hvad der er vigtigt idag er en anden ting.]
MMC kommandoer er givetvis ikke SCSI specifikke, men alle de programmer jeg har rodet med har enten kun kørt scsi eller gennem scsi emulering eller aspi laget.. ;)
[Linux har heldigvis ikke begået samme fejl som visse andre OS med at behandle alt som SCSI som ikke er det. 2.6 har nu tilføjet generisk support for SG_IO ioctl som bruges af cdrecord, så det er muligt at brænde på ATAPI drev fuldstændig uden at blande SCSI laget ind i det. Så sparer du lige et helt SCSI lag på en desktop maskine, som sikkert ikke har SCSI devices alligevel. Og du sparer flere hops igennem kernen.]
En af mange gode tiltag, som jeg har lagt mærke til.. :)
[Du aner ikke hvad du snakker om, tydeligvis. Hvis vi ser bort fra SCSI som transport, så bruges scsi-agtige kommandosæt i udstrakt grad af andre periferi typer som feks ATAPI.]
Muligvis.
Men alle brænderprogrammer på windows bruger tit en eller anden ASPI driver, som så vidt jeg har forstået er en SCSI wrapper?
[cdrecord snakker ikke SCSI, den snakker MMC kommandoer som ikke er SCSI specifikt. At Joerg så har lidt twisted opfattelse af hvad der er vigtigt idag er en anden ting.]
MMC kommandoer er givetvis ikke SCSI specifikke, men alle de programmer jeg har rodet med har enten kun kørt scsi eller gennem scsi emulering eller aspi laget.. ;)
[Linux har heldigvis ikke begået samme fejl som visse andre OS med at behandle alt som SCSI som ikke er det. 2.6 har nu tilføjet generisk support for SG_IO ioctl som bruges af cdrecord, så det er muligt at brænde på ATAPI drev fuldstændig uden at blande SCSI laget ind i det. Så sparer du lige et helt SCSI lag på en desktop maskine, som sikkert ikke har SCSI devices alligevel. Og du sparer flere hops igennem kernen.]
En af mange gode tiltag, som jeg har lagt mærke til.. :)
#14
ASPI er et programmerings interface til SCSI, det kan vel sammenlignes med API'et til brug af scsi generic i Linux.
At de programmer du har set bruger SCSI emulering i Linux er jo netop at det er den eneste måde de kan virke på, fordi der ikke var nogen andre fornuftige alternativer til at smider kommandoer til dem. Og så er vi faktisk tilbage ved kommentar #1, han har fuldstændig ret.
ASPI er et programmerings interface til SCSI, det kan vel sammenlignes med API'et til brug af scsi generic i Linux.
At de programmer du har set bruger SCSI emulering i Linux er jo netop at det er den eneste måde de kan virke på, fordi der ikke var nogen andre fornuftige alternativer til at smider kommandoer til dem. Og så er vi faktisk tilbage ved kommentar #1, han har fuldstændig ret.
#15
[ASPI er et programmerings interface til SCSI, det kan vel sammenlignes med API'et til brug af scsi generic i Linux.]
Jeps.
[At de programmer du har set bruger SCSI emulering i Linux er jo netop at det er den eneste måde de kan virke på, fordi der ikke var nogen andre fornuftige alternativer til at smider kommandoer til dem. Og så er vi faktisk tilbage ved kommentar #1, han har fuldstændig ret.]
Sådan som jeg læser det, vil det stadig være et scsi generic interface der kommunikeret med.
Så metoden er vel basalt set ens, omend en smule forenklet.
[ASPI er et programmerings interface til SCSI, det kan vel sammenlignes med API'et til brug af scsi generic i Linux.]
Jeps.
[At de programmer du har set bruger SCSI emulering i Linux er jo netop at det er den eneste måde de kan virke på, fordi der ikke var nogen andre fornuftige alternativer til at smider kommandoer til dem. Og så er vi faktisk tilbage ved kommentar #1, han har fuldstændig ret.]
Sådan som jeg læser det, vil det stadig være et scsi generic interface der kommunikeret med.
Så metoden er vel basalt set ens, omend en smule forenklet.
Jeg syntes at der er rart at de har deres mail addresser på så det er nemmere at finde ud af hvem der skal mail bombes :-)
Just kidding... :-|
Just kidding... :-|
#16
Ja det er stadig scsi generic der bruges, ellers skulle cdrecord (eller libscg) skrives om. Og det ville ikke være så sjovt. Før så kommando vejen således ud:
cdrecord -> sg -> scsi request -> ide-scsi -> ide
i 2.6 ser det således ud:
cdrecord -> block lags "sg" -> ide-cd
Metoden du snakker med drevet på fra user space er 100% ens, implementeringen i kernen er helt anderledes. Den er både hurtigere (færre hukommelses allokeringer, ingen kopiering af data fra user til kernen) og generisk i det nye 2.6 block lag. Det er simpelthen designet til at ikke kun kunne transportere læse/skrive requests fra filsystemer til block device drivere, men også generiske "scsi" kommandoer.
Derfor.
Ja det er stadig scsi generic der bruges, ellers skulle cdrecord (eller libscg) skrives om. Og det ville ikke være så sjovt. Før så kommando vejen således ud:
cdrecord -> sg -> scsi request -> ide-scsi -> ide
i 2.6 ser det således ud:
cdrecord -> block lags "sg" -> ide-cd
Metoden du snakker med drevet på fra user space er 100% ens, implementeringen i kernen er helt anderledes. Den er både hurtigere (færre hukommelses allokeringer, ingen kopiering af data fra user til kernen) og generisk i det nye 2.6 block lag. Det er simpelthen designet til at ikke kun kunne transportere læse/skrive requests fra filsystemer til block device drivere, men også generiske "scsi" kommandoer.
Derfor.
#18
Jens, xcdroast kommer med en kærd fejlmeddelelse om at jeg godt kan køre uden ide-scsi på min 2.4.20 kerne. Den siger dog at jeg får dårlig performance, men det virker fint og brænder med 16x.
(Den bruger sikkert ikke DMA, og laver tricks som root).
Har du forresten noget styr på brænding af DVD'er?
Jeg kan kun finde et properitært modul ProDVD, for at kunne brænde i Linux.
Jens, xcdroast kommer med en kærd fejlmeddelelse om at jeg godt kan køre uden ide-scsi på min 2.4.20 kerne. Den siger dog at jeg får dårlig performance, men det virker fint og brænder med 16x.
(Den bruger sikkert ikke DMA, og laver tricks som root).
Har du forresten noget styr på brænding af DVD'er?
Jeg kan kun finde et properitært modul ProDVD, for at kunne brænde i Linux.
#20
Da jeg lavede dvd support, introducerede jeg også en CDROM_SEND_PACKET ioctl som kan bruges til det samme (i teorien). Den er dog ikke designet til andet end småting, cdrecord folkene kastede sig bare over den som grippe fordi de nu endelig så noget som virkede generisk på atapi såvel som scsi cd-rw. Well faktisk er scsi jo totalt ligegyldigt når det kommer til brændere efterhånden, dem sælges der ikke mange af mere. Så det virker, men som du selv er inde på er performance elendig. Du kan prøve at holde øje med din system tid når du brænder (vmstat 1) og evt sammenligne med 2.6. Problemet er først rigtig stort, når der skal brændes hurtigere. Derfor jeg skriver i kommentar #10, at sg er den eneste "fornuftige" måde at brænde på.
Der findes forskellige cdrecord "forks" med dvd funktionalitet på nettet, jeg har selv været med til at lave en af dem. Har nu ikke holdt øje med det længe, den sidste jeg rodede med var den bero frigjorde var Joergs frygtelige build system. Prøv evt at søge på dvdrecord. Hvis du ikke kan finde noget, så send mig en mail og jeg skal prøve at grave lidt.
Da jeg lavede dvd support, introducerede jeg også en CDROM_SEND_PACKET ioctl som kan bruges til det samme (i teorien). Den er dog ikke designet til andet end småting, cdrecord folkene kastede sig bare over den som grippe fordi de nu endelig så noget som virkede generisk på atapi såvel som scsi cd-rw. Well faktisk er scsi jo totalt ligegyldigt når det kommer til brændere efterhånden, dem sælges der ikke mange af mere. Så det virker, men som du selv er inde på er performance elendig. Du kan prøve at holde øje med din system tid når du brænder (vmstat 1) og evt sammenligne med 2.6. Problemet er først rigtig stort, når der skal brændes hurtigere. Derfor jeg skriver i kommentar #10, at sg er den eneste "fornuftige" måde at brænde på.
Der findes forskellige cdrecord "forks" med dvd funktionalitet på nettet, jeg har selv været med til at lave en af dem. Har nu ikke holdt øje med det længe, den sidste jeg rodede med var den bero frigjorde var Joergs frygtelige build system. Prøv evt at søge på dvdrecord. Hvis du ikke kan finde noget, så send mig en mail og jeg skal prøve at grave lidt.
boooooring kunne de ikke udgive nogle flere programmer til linux istedetfor det er jo ligesom det der er problemet
H.E.R.O.
Nå jo, det hjælper nok helt vildt at alle der udvikler kernen sætter sig ned og begynder at skrive almindelige applikationer!
[Undre mig over hvorfor H.E.R.O. ikke er på min ignore liste]
Måske, hvis du tænker dig lidt om, så ville du nok indse at der også er et behov for at videreudvikle og forbedre kernen, istedet for at sætte sig ned og sige at det er det!
[Klikker på ignore ud for H.E.R.O.]
Nå jo, det hjælper nok helt vildt at alle der udvikler kernen sætter sig ned og begynder at skrive almindelige applikationer!
[Undre mig over hvorfor H.E.R.O. ikke er på min ignore liste]
Måske, hvis du tænker dig lidt om, så ville du nok indse at der også er et behov for at videreudvikle og forbedre kernen, istedet for at sætte sig ned og sige at det er det!
[Klikker på ignore ud for H.E.R.O.]
#23 H.E.R.O
[boooooring kunne de ikke udgive nogle flere programmer til linux istedetfor det er jo ligesom det der er problemet]
Vi har masser af software.
Hvis du bilder dig andet ind, så kigger du de forkerte steder.
Måske ikke særlig meget fra firmaer som Adobe, Macromedia, Autodesk og lignende men de skal nok komme af sig selv.
Vi i GNU/Linux samfundet kan bare gøre som vi hele tiden har gjort, så går det jo nok som det skal.
Vores brugerbase er så stor, at de fleste gange der er nogen der konstantere at der er noget vi ikke kan så går de igang med at gøre noget ved det.. :)
I münchen f.eks kan vi jo snart sige 'all your bases are belong to us' til Microsoft.. ;oD
[boooooring kunne de ikke udgive nogle flere programmer til linux istedetfor det er jo ligesom det der er problemet]
Vi har masser af software.
Hvis du bilder dig andet ind, så kigger du de forkerte steder.
Måske ikke særlig meget fra firmaer som Adobe, Macromedia, Autodesk og lignende men de skal nok komme af sig selv.
Vi i GNU/Linux samfundet kan bare gøre som vi hele tiden har gjort, så går det jo nok som det skal.
Vores brugerbase er så stor, at de fleste gange der er nogen der konstantere at der er noget vi ikke kan så går de igang med at gøre noget ved det.. :)
I münchen f.eks kan vi jo snart sige 'all your bases are belong to us' til Microsoft.. ;oD
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund