---

Hej NG

Jeg har nogen idéer til nogen open source projekter, som jeg selv synes
er geniale... Men jeg har ikke rigtigt tid til at programmere dem, og
måske er jeg lidt rusten i kerne- og systemprogrammering. Jeg har så
forsøgt at diskutere mine idéer med de folk der er ansvarlige for de
enkelte produkter, for at lokke dem til at implementere det, men det er
ikke lykkedes mig at få overtalt nogen. Men jeg har da fået kommentarer
tilbage på idéerne og det ser ud til at de er holdbare.

Jeg tænker så på om jeg kan få andre til at programmere tingene, evt
mod betaling, og hvordan jeg så slipper billigst fra det. Kan man få
nogen russere til at lave det, eller hvad? Hvordan gøres dette?

Jeg har nogen beskrivelser af hvad det er, fx:

1. filsystemer: mulighed for sikker genfinding af slettede filer, design
for ext3 foreligger som jeg har diskuteret med Dan T'so.

2. fordobling af batteritid (eller måske tredobling) for bærbare med
ACPI, ved at lukke helt ned for CPU.

3. forhindring af nogen bufferoverløbsexploits ved at flytte allokering
af funktionsdata til heapen.

4. opbygning af gratis trådløst meshnet, til global, sikker adgang

5. internettelefon

6. spejlet raid med striping på blot 2 fysiske diske.

altsammen open source, fx under GPL.

hilsen
keld

---

Keld Jørn Simonsen wrote:

> Hej NG
>
> Jeg har nogen idéer til nogen open source projekter, som jeg selv synes
> er geniale... Men jeg har ikke rigtigt tid til at programmere dem, og
> måske er jeg lidt rusten i kerne- og systemprogrammering. Jeg har så
> forsøgt at diskutere mine idéer med de folk der er ansvarlige for de
> enkelte produkter, for at lokke dem til at implementere det, men det er
> ikke lykkedes mig at få overtalt nogen. Men jeg har da fået kommentarer
> tilbage på idéerne og det ser ud til at de er holdbare.
>
> Jeg tænker så på om jeg kan få andre til at programmere tingene, evt
> mod betaling, og hvordan jeg så slipper billigst fra det. Kan man få
> nogen russere til at lave det, eller hvad? Hvordan gøres dette?
>
> Jeg har nogen beskrivelser af hvad det er, fx:
>
> 1. filsystemer: mulighed for sikker genfinding af slettede filer, design
> for ext3 foreligger som jeg har diskuteret med Dan T'so.

Kig på libtrash. Det virker med alle filsystemer.

> 2. fordobling af batteritid (eller måske tredobling) for bærbare med
> ACPI, ved at lukke helt ned for CPU.

Det må du lige forklare nærmere. Mener du om hibarnation? ACPI kan jo ikke
bare gøre hvad som helst :)

> 3. forhindring af nogen bufferoverløbsexploits ved at flytte allokering
> af funktionsdata til heapen.

Forklar nærmere? Har du en idé udover at omskrive N dele af M programmer?

> 4. opbygning af gratis trådløst meshnet, til global, sikker adgang

Den idé havde jeg også. Måske et godt bachelorprojekt. :)

> 5. internettelefon

Hvad betyder det?

> 6. spejlet raid med striping på blot 2 fysiske diske.

Kan allerede lade sig gøre. (I hvert fald med Linux, men sikkert også nogle
BSDer)

--
M.V.H
Christian Iversen

---

Hejsa

Christian Iversen wrote:
> Keld Jørn Simonsen wrote:

>>4. opbygning af gratis trådløst meshnet, til global, sikker adgang
> Den idé havde jeg også. Måske et godt bachelorprojekt. :)

Den ide ville jeg da gerne høre lidt mere om. Det er dog et kand.
speciale jeg skal finde en ide til (datalogi) :) :

Mesh net, hvad er det ?
Trådløs; hvilken teknologi ?
Hvilket niveau i ex. ISO-OSI netværksmodeller befinder vi os i ?

MVH
Søren

---

Soren Kuula <dongfang-remove_this@remove_this-bitplanet.net> writes:

> Hvilket niveau i ex. ISO-OSI netværksmodeller befinder vi os i ?

Hvis det er sådan et generelt spørgsmål er svaret vel 9?

--
Peter Makholm | Emacs is the only modern general-purpose
peter@makholm.net | operating system that doesn't multitask
http://hacking.dk |

---

Peter Makholm wrote:
>> Hvilket niveau i ex. ISO-OSI netværksmodeller befinder vi os i ?
>
> Hvis det er sådan et generelt spørgsmål er svaret vel 9?

HA HA :)

Har du også læst Dijkstra ? "...level x is the user (not implemented by us)"

Nej det var nu projektideen jeg mener.

MVH
Søren

---

Den Sun, 13 Jun 2004 12:07:01 +0200. skrev Soren Kuula:

> Hejsa
>
> Christian Iversen wrote:
>> Keld Jørn Simonsen wrote:
>
>>>4. opbygning af gratis trådløst meshnet, til global, sikker adgang
>> Den idé havde jeg også. Måske et godt bachelorprojekt. :)
>
> Den ide ville jeg da gerne høre lidt mere om. Det er dog et kand.
> speciale jeg skal finde en ide til (datalogi) :) :
>
> Mesh net, hvad er det ?

en teknologi hvor hvert trådløst netkort er base/relæ station, og
modtageområdet derfor udvides betydeligt.

> Trådløs; hvilken teknologi ?

Normal 802.11b/g. Min idé går på at lave meshnet der bare kan køre på
alles små trådløse netkort, uden nogen særlig opsætning.

> Hvilket niveau i ex. ISO-OSI netværksmodeller befinder vi os i ?

2-3 stykker.

hilsen
keld

---

Den Sat, 12 Jun 2004 13:31:01 +0200. skrev Christian Iversen:

> Keld Jørn Simonsen wrote:
>
>> Hej NG
>>
>> Jeg har nogen idéer til nogen open source projekter, som jeg selv synes
>> er geniale... Men jeg har ikke rigtigt tid til at programmere dem, og
>> måske er jeg lidt rusten i kerne- og systemprogrammering. Jeg har så
>> forsøgt at diskutere mine idéer med de folk der er ansvarlige for de
>> enkelte produkter, for at lokke dem til at implementere det, men det er
>> ikke lykkedes mig at få overtalt nogen. Men jeg har da fået kommentarer
>> tilbage på idéerne og det ser ud til at de er holdbare.
>>
>> Jeg tænker så på om jeg kan få andre til at programmere tingene, evt
>> mod betaling, og hvordan jeg så slipper billigst fra det. Kan man få
>> nogen russere til at lave det, eller hvad? Hvordan gøres dette?
>>
>> Jeg har nogen beskrivelser af hvad det er, fx:
>>
>> 1. filsystemer: mulighed for sikker genfinding af slettede filer, design
>> for ext3 foreligger som jeg har diskuteret med Dan T'so.
>
> Kig på libtrash. Det virker med alle filsystemer.

libtrash skal jo slås til først. Og det duer ikke hvis man evt er kommet
til lige at reformatere sin partition. Mit udkast til design løser dette.
Plus at det ikke tager (særligt meget) plads op.

>> 2. fordobling af batteritid (eller måske tredobling) for bærbare med
>> ACPI, ved at lukke helt ned for CPU.
>
> Det må du lige forklare nærmere. Mener du om hibarnation? ACPI kan jo
> ikke bare gøre hvad som helst :)

Min idé er at slukke for CPU-en helt, men lade skærm og tastatur køre.
På min bærbare bør jeg så kunne komme ned på et forbrug på 5 W,
istedet for ca 15 W. Dette burde kunne lade sig gøre på næsten alle
bærbare. CPU-en kan genstates fra død (ingen strøm) på 50 ms.
Jeg bør så kunne gå fra ca 3 timer til ca 10 timer på batteriet!

>> 3. forhindring af nogen bufferoverløbsexploits ved at flytte
>> allokering
>> af funktionsdata til heapen.
>
> Forklar nærmere? Har du en idé udover at omskrive N dele af M
> programmer?

Ja, idéen er at oversætteren generelt lægger funktionsdata ud på
heapen. dvs alle data liggere på heap eller i datasegmentet, og stakken
består kun af funktionskald og parametre. Da der ikke er adgang til
stakken kan funktionspegere i stakken ikke overskrives.

>> 4. opbygning af gratis trådløst meshnet, til global, sikker adgang
>
> Den idé havde jeg også. Måske et godt bachelorprojekt. :)
>
>> 5. internettelefon
>
> Hvad betyder det?

Noget udbygning af gnomemeeting med asteriks og noget organisering af det.
Måske noget tunnellering af H.323 så det altid kan komme igennem diverse
brandmure.

>> 6. spejlet raid med striping på blot 2 fysiske diske.
>
> Kan allerede lade sig gøre. (I hvert fald med Linux, men sikkert også
> nogle BSDer)

Det kan ikke lade sig gøre, så vidt jeg véd. Jeg har diskuteret det på
linux kerne raid listen, og de siger at det ikke kan lade sig gøre nu.
Eller har du en opskrift på hvordan det gøres?

Hilsen
keld

---

Keld Jørn Simonsen <keld@dkuug.dk> writes:

> Den Sat, 12 Jun 2004 13:31:01 +0200. skrev Christian Iversen:
>
> > Keld Jørn Simonsen wrote:

> >> 5. internettelefon
> >
> > Hvad betyder det?
>
> Noget udbygning af gnomemeeting med asteriks og noget organisering af det.
> Måske noget tunnellering af H.323 så det altid kan komme igennem diverse
> brandmure.

Har du kigget på SIP ? Det kan det meste.

Martin

--
Besøg http://www.adsltips.dk for guider til
ADSL og opsætning af Cisco/Zyxel routere.

---

Den Tue, 15 Jun 2004 18:44:36 +0200. skrev Martin Schultz:

> Keld Jørn Simonsen <keld@dkuug.dk> writes:
>
>> Den Sat, 12 Jun 2004 13:31:01 +0200. skrev Christian Iversen:
>>
>> > Keld Jørn Simonsen wrote:
>
>> >> 5. internettelefon
>> >
>> > Hvad betyder det?
>>
>> Noget udbygning af gnomemeeting med asteriks og noget organisering af det.
>> Måske noget tunnellering af H.323 så det altid kan komme igennem diverse
>> brandmure.
>
> Har du kigget på SIP ? Det kan det meste.

Ja, jeg har kigget på SIP. Det kan ikke lave konferencer, så vidt jeg
véd. Men jeg tror man skal understøtte både H.323 og SIP. Idéen er at få
VoIP til at blive brugt i stor skala.

Hilsen
keld

---

On 2004-06-15, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>>> 2. fordobling af batteritid (eller måske tredobling) for bærbare med
>>> ACPI, ved at lukke helt ned for CPU.
>>
>> Det må du lige forklare nærmere. Mener du om hibarnation? ACPI kan jo
>> ikke bare gøre hvad som helst :)
>
> Min idé er at slukke for CPU-en helt, men lade skærm og tastatur køre.

Hvad mener du med at slukke for cpuen helt? Kernen kører halt instruktionen
i idle tråden og ACPI lukker ned for delsystemer når de ikke bruges.

> På min bærbare bør jeg så kunne komme ned på et forbrug på 5 W,
> istedet for ca 15 W. Dette burde kunne lade sig gøre på næsten alle
> bærbare. CPU-en kan genstates fra død (ingen strøm) på 50 ms.
> Jeg bør så kunne gå fra ca 3 timer til ca 10 timer på batteriet!

Du ved godt at din kun cpu står for 25-30% af strømforbruget i en bærbar ikke?
Evt. gevinst ved at spare lidt strøm på cpuen bruger skærmen hurtigt.

.... hvilket også er grunden til at transmeta aldrig blev til noget stort.

Thomas

---

Den Tue, 15 Jun 2004 19:17:15 +0000. skrev Thomas S. Iversen:

> On 2004-06-15, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>>>> 2. fordobling af batteritid (eller måske tredobling) for bærbare med
>>>> ACPI, ved at lukke helt ned for CPU.
>>>
>>> Det må du lige forklare nærmere. Mener du om hibarnation? ACPI kan jo
>>> ikke bare gøre hvad som helst :)
>>
>> Min idé er at slukke for CPU-en helt, men lade skærm og tastatur køre.
>
> Hvad mener du med at slukke for cpuen helt? Kernen kører halt instruktionen
> i idle tråden og ACPI lukker ned for delsystemer når de ikke bruges.

I idle wait bruger min cpu 7,5 W, når den er slukket bruger den 0 W.
Det ser ikke ud til at ACPI lukker ned for alt der ikke bruges, jeg har
rodet med det i kerne 2.6.3 men ACPI er altså ikke så veldokumenteret.

>> På min bærbare bør jeg så kunne komme ned på et forbrug på 5 W,
>> istedet for ca 15 W. Dette burde kunne lade sig gøre på næsten alle
>> bærbare. CPU-en kan genstates fra død (ingen strøm) på 50 ms.
>> Jeg bør så kunne gå fra ca 3 timer til ca 10 timer på batteriet!
>
> Du ved godt at din kun cpu står for 25-30% af strømforbruget i en bærbar ikke?

Jeg mener at have god check på hvad der bruger hvor meget strøm i min
bærbare. Når den kører i idle wait går der altså 50 % til cpu, og noget
går til enheder der ikke behøver være aktive.

> Evt. gevinst ved at spare lidt strøm på cpuen bruger skærmen hurtigt.

Min skærm bruger ca 4 W hvis jeg har skruet helt ned for lysintensiteten.
(Kan spare ca 4 W der sammenlignet med normal intensitet.) Ialt bruges ca
14-15 W når den kører i idle wait. Og det gør den ca 97 % af tiden,
hvis jeg bare læser mail og besvarer ting. Altså kan jeg spare 7,5 W ved
at slukke for CPUen, mens jeg har skærmen tændt og så kan læse
forskellige ting.

Hilsen
keld

---

On 2004-06-15, Keld Jørn Simonsen <keld@dkuug.dk> wrote:

> I idle wait bruger min cpu 7,5 W, når den er slukket bruger den 0 W.
> Det ser ikke ud til at ACPI lukker ned for alt der ikke bruges, jeg har
> rodet med det i kerne 2.6.3 men ACPI er altså ikke så veldokumenteret.

Hvordan vil du lukke din cpu ned udover halt og ACPI?

> Min skærm bruger ca 4 W hvis jeg har skruet helt ned for lysintensiteten.
> (Kan spare ca 4 W der sammenlignet med normal intensitet.) Ialt bruges ca
> 14-15 W når den kører i idle wait. Og det gør den ca 97 % af tiden,

Jeg har endnu til gode at se en tft skærm køre på 4W, men jeg må jo bare
sige at du er en heldig mand.

Thomas

---

Den Tue, 15 Jun 2004 20:14:15 +0000. skrev Thomas S. Iversen:

> On 2004-06-15, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>
>> I idle wait bruger min cpu 7,5 W, når den er slukket bruger den 0 W.
>> Det ser ikke ud til at ACPI lukker ned for alt der ikke bruges, jeg har
>> rodet med det i kerne 2.6.3 men ACPI er altså ikke så veldokumenteret.
>
> Hvordan vil du lukke din cpu ned udover halt og ACPI?

med ACPI - sluk cpu. Der skal nok noget kernehakning til.

>> Min skærm bruger ca 4 W hvis jeg har skruet helt ned for lysintensiteten.
>> (Kan spare ca 4 W der sammenlignet med normal intensitet.) Ialt bruges ca
>> 14-15 W når den kører i idle wait. Og det gør den ca 97 % af tiden,
>
> Jeg har endnu til gode at se en tft skærm køre på 4W, men jeg må jo bare
> sige at du er en heldig mand.

4 W er forskellen mellen lavintensitet og slukket. Det er en Acer maskine.

Hilsen
Keld

---

On 2004-06-15, Keld Jørn Simonsen <keld@dkuug.dk> wrote:

> med ACPI - sluk cpu. Der skal nok noget kernehakning til.

ACPI supporten i linux supporterer alle S states og alle C states.
Se

/usr/src/linux-2.6.x/drivers/acpi/processor.c

Med mindre du kender en ny metode, så tror jeg ikke du skal regne med at få
lukket mere ned for cpuen. Eller har du noget specifikt i tankerne?

>>> Min skærm bruger ca 4 W hvis jeg har skruet helt ned for lysintensiteten.
>>> (Kan spare ca 4 W der sammenlignet med normal intensitet.) Ialt bruges ca
>>> 14-15 W når den kører i idle wait. Og det gør den ca 97 % af tiden,
>>
>> Jeg har endnu til gode at se en tft skærm køre på 4W, men jeg må jo bare
>> sige at du er en heldig mand.
>
> 4 W er forskellen mellen lavintensitet og slukket. Det er en Acer maskine.

Ja man du siger også samtidig at den bruger 4W hvis du skruer helt ned for
lyset. Vildt siger jeg bare. Min sluger 15W.

Thomas

---

Den Wed, 16 Jun 2004 00:38:30 +0000. skrev Thomas S. Iversen:

> On 2004-06-15, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>>> Jeg har endnu til gode at se en tft skærm køre på 4W, men jeg må jo
>> bare
>>> sige at du er en heldig mand.
>>
>> 4 W er forskellen mellen lavintensitet og slukket. Det er en Acer
>> maskine.
>
> Ja man du siger også samtidig at den bruger 4W hvis du skruer helt ned
> for lyset. Vildt siger jeg bare. Min sluger 15W.

Min bruger 8 W i normaltilstand. Tror du ikke du kan skrue ned for
lysintensiteten og spare noget strøm?

Hilsen
Keld

---

On 2004-06-16, Keld Jørn Simonsen <keld@dkuug.dk> wrote:

> Min bruger 8 W i normaltilstand. Tror du ikke du kan skrue ned for
> lysintensiteten og spare noget strøm?

Tja, tjo. Betyder ikke så meget. Jeg er fint tilfreds med de 3.5-4.0 timer
jeg får ved alm. surf/mail brug

Thomas

---

Keld Jørn Simonsen wrote:

> Den Sat, 12 Jun 2004 13:31:01 +0200. skrev Christian Iversen:
>
>> Keld Jørn Simonsen wrote:
>>
>>> Hej NG
>>>
>>> Jeg har nogen idéer til nogen open source projekter, som jeg selv synes
>>> er geniale... Men jeg har ikke rigtigt tid til at programmere dem, og
>>> måske er jeg lidt rusten i kerne- og systemprogrammering. Jeg har så
>>> forsøgt at diskutere mine idéer med de folk der er ansvarlige for de
>>> enkelte produkter, for at lokke dem til at implementere det, men det er
>>> ikke lykkedes mig at få overtalt nogen. Men jeg har da fået kommentarer
>>> tilbage på idéerne og det ser ud til at de er holdbare.
>>>
>>> Jeg tænker så på om jeg kan få andre til at programmere tingene, evt
>>> mod betaling, og hvordan jeg så slipper billigst fra det. Kan man få
>>> nogen russere til at lave det, eller hvad? Hvordan gøres dette?
>>>
>>> Jeg har nogen beskrivelser af hvad det er, fx:
>>>
>>> 1. filsystemer: mulighed for sikker genfinding af slettede filer, design
>>> for ext3 foreligger som jeg har diskuteret med Dan T'so.
>>
>> Kig på libtrash. Det virker med alle filsystemer.
>
> libtrash skal jo slås til først. Og det duer ikke hvis man evt er kommet
> til lige at reformatere sin partition. Mit udkast til design løser dette.
> Plus at det ikke tager (særligt meget) plads op.

Det må du lige forklare så. Mener du at man kan have eksempelvis en
reiserfs-partition på /dev/hda1 og så "komme til" at køre mke2fs /dev/hda1,
og derefter nemt redde data?

>>> 2. fordobling af batteritid (eller måske tredobling) for bærbare med
>>> ACPI, ved at lukke helt ned for CPU.
>>
>> Det må du lige forklare nærmere. Mener du om hibarnation? ACPI kan jo
>> ikke bare gøre hvad som helst :)
>
> Min idé er at slukke for CPU-en helt, men lade skærm og tastatur køre.
> På min bærbare bør jeg så kunne komme ned på et forbrug på 5 W,
> istedet for ca 15 W. Dette burde kunne lade sig gøre på næsten alle
> bærbare. CPU-en kan genstates fra død (ingen strøm) på 50 ms.
> Jeg bør så kunne gå fra ca 3 timer til ca 10 timer på batteriet!

Hvordan vil du bære dig ad med at slukke for CPUen? Som andre har nævnt er
det ikke trivielt / muligt overhovedet.

>>> 3. forhindring af nogen bufferoverløbsexploits ved at flytte
>>> allokering
>>> af funktionsdata til heapen.
>>
>> Forklar nærmere? Har du en idé udover at omskrive N dele af M
>> programmer?
>
> Ja, idéen er at oversætteren generelt lægger funktionsdata ud på
> heapen. dvs alle data liggere på heap eller i datasegmentet, og stakken
> består kun af funktionskald og parametre. Da der ikke er adgang til
> stakken kan funktionspegere i stakken ikke overskrives.

Nogle programmer bruger stakken som en slags malloc(). De skal så omskrives.
Det er ikke kønt, men det er noget hurtigere. Dog burde de nok kunne
allokere med malloc() i større blokke før de skal bruge pladsen, men det
ville tage et stykke tid at finde ud af, for alle programmer der gør dette.

>>> 5. internettelefon
>>
>> Hvad betyder det?
>
> Noget udbygning af gnomemeeting med asteriks og noget organisering af det.
> Måske noget tunnellering af H.323 så det altid kan komme igennem diverse
> brandmure.

Ja H.323 er godt nok ikke rart at prøve presse igennem fx NAT.

>>> 6. spejlet raid med striping på blot 2 fysiske diske.
>>
>> Kan allerede lade sig gøre. (I hvert fald med Linux, men sikkert også
>> nogle BSDer)
>
> Det kan ikke lade sig gøre, så vidt jeg véd. Jeg har diskuteret det på
> linux kerne raid listen, og de siger at det ikke kan lade sig gøre nu.
> Eller har du en opskrift på hvordan det gøres?

Du laver 2 partitioner på hver disk - halv størrelse. Lad os sige det bliver
4x20GB på 2x40GB diske. Disse partitioner kaldes A1, A2, B1, B2.

Du spejler A1, B1 => S1 og A2, B2 => S2. Så striper du S1+S2. Hvis disk A
forsvinder, bliver S1 og S2 holdt oppe af B1 og B2 (og omvendt).

Problemet med denne metode er at du kan risikere store søgetider hvis kernen
ikke kan gennemskue at fordele IO-operationerne godt. Idet S1 er første
halvdel af diskene og S2 anden halvdel, vil en S1-S2 striping altid læse
lidt fra første halvdel af en disk, og lidt fra anden halvdel. Den eneste
effektive måde at gøre dette på er at lade første halvdel blive behandlet
af den ene disk, og anden halvdel af den anden. (det er dét jeg ikke ved om
kernen er god til) Det er dog stadig problematisk med skrivninger, hvor
læsehovederne skal flyttes.

Jeg foreslår derfor følgende metode:

Du spejler A1, B2 => S1 og B1, A2 => S2. Så striper du S1+S2. Nu bliver
læse-operationer stripet mellem de to første halvdele eller de to sidste,
men aldrig på kryds. Skriveoperationer bliver ligeledes effektive (så godt
som RAID-1 nu tillader det). Hvis disk A forsvinder, har du B2 som S1 og B1
som S2. (og omvendt).

Jeg har ikke afprøvet ovenstående i praksis, så der er måske noget jeg har
overset.

--
M.V.H
Christian Iversen

---

Den Wed, 16 Jun 2004 12:59:46 +0200. skrev Christian Iversen:

> Keld Jørn Simonsen wrote:
>
>> Den Sat, 12 Jun 2004 13:31:01 +0200. skrev Christian Iversen:
>>
>>> Keld Jørn Simonsen wrote:
>>>
>>>> Hej NG
>>>>
>>>> Jeg har nogen idéer til nogen open source projekter, som jeg selv synes
>>>> er geniale... Men jeg har ikke rigtigt tid til at programmere dem, og
>>>> måske er jeg lidt rusten i kerne- og systemprogrammering. Jeg har så
>>>> forsøgt at diskutere mine idéer med de folk der er ansvarlige for de
>>>> enkelte produkter, for at lokke dem til at implementere det, men det er
>>>> ikke lykkedes mig at få overtalt nogen. Men jeg har da fået kommentarer
>>>> tilbage på idéerne og det ser ud til at de er holdbare.
>>>>
>>>> Jeg tænker så på om jeg kan få andre til at programmere tingene, evt
>>>> mod betaling, og hvordan jeg så slipper billigst fra det. Kan man få
>>>> nogen russere til at lave det, eller hvad? Hvordan gøres dette?
>>>>
>>>> Jeg har nogen beskrivelser af hvad det er, fx:
>>>>
>>>> 1. filsystemer: mulighed for sikker genfinding af slettede filer, design
>>>> for ext3 foreligger som jeg har diskuteret med Dan T'so.
>>>
>>> Kig på libtrash. Det virker med alle filsystemer.
>>
>> libtrash skal jo slås til først. Og det duer ikke hvis man evt er kommet
>> til lige at reformatere sin partition. Mit udkast til design løser dette.
>> Plus at det ikke tager (særligt meget) plads op.
>
> Det må du lige forklare så. Mener du at man kan have eksempelvis en
> reiserfs-partition på /dev/hda1 og så "komme til" at køre mke2fs /dev/hda1,
> og derefter nemt redde data?

Ja, det jeg har diskuteret er dog ext3.

>>>> 2. fordobling af batteritid (eller måske tredobling) for bærbare med
>>>> ACPI, ved at lukke helt ned for CPU.
>>>
>>> Det må du lige forklare nærmere. Mener du om hibarnation? ACPI kan jo
>>> ikke bare gøre hvad som helst :)
>>
>> Min idé er at slukke for CPU-en helt, men lade skærm og tastatur køre.
>> På min bærbare bør jeg så kunne komme ned på et forbrug på 5 W,
>> istedet for ca 15 W. Dette burde kunne lade sig gøre på næsten alle
>> bærbare. CPU-en kan genstates fra død (ingen strøm) på 50 ms.
>> Jeg bør så kunne gå fra ca 3 timer til ca 10 timer på batteriet!
>
> Hvordan vil du bære dig ad med at slukke for CPUen? Som andre har nævnt er
> det ikke trivielt / muligt overhovedet.

Tjoe, véd det ikke. Men hvorfor skulle det ikke kunne lade sig gøre?
Det ser ud til at man virkelig kan spare strøm på det.

Mere diskussion i anden tråd.

>>>> 3. forhindring af nogen bufferoverløbsexploits ved at flytte
>>>> allokering
>>>> af funktionsdata til heapen.
>>>
>>> Forklar nærmere? Har du en idé udover at omskrive N dele af M
>>> programmer?
>>
>> Ja, idéen er at oversætteren generelt lægger funktionsdata ud på
>> heapen. dvs alle data liggere på heap eller i datasegmentet, og stakken
>> består kun af funktionskald og parametre. Da der ikke er adgang til
>> stakken kan funktionspegere i stakken ikke overskrives.
>
> Nogle programmer bruger stakken som en slags malloc(). De skal så omskrives.
> Det er ikke kønt, men det er noget hurtigere. Dog burde de nok kunne
> allokere med malloc() i større blokke før de skal bruge pladsen, men det
> ville tage et stykke tid at finde ud af, for alle programmer der gør dette.

Hvordan bruger programmerne stakken som malloc? Og hvorfor kan de ikke
gøre det på heapen i stedet - automatisk, idet nye funktionsdata
allokeres på heapen?

>>>> 6. spejlet raid med striping på blot 2 fysiske diske.
>>>
>>> Kan allerede lade sig gøre. (I hvert fald med Linux, men sikkert
>>> også nogle BSDer)
>>
>> Det kan ikke lade sig gøre, så vidt jeg véd. Jeg har diskuteret det
>> på linux kerne raid listen, og de siger at det ikke kan lade sig gøre
>> nu. Eller har du en opskrift på hvordan det gøres?
>
> Du laver 2 partitioner på hver disk - halv størrelse. Lad os sige det
> bliver 4x20GB på 2x40GB diske. Disse partitioner kaldes A1, A2, B1, B2.
>
> Du spejler A1, B1 => S1 og A2, B2 => S2. Så striper du S1+S2. Hvis disk
> A forsvinder, bliver S1 og S2 holdt oppe af B1 og B2 (og omvendt).

Ja, jeg har prøvet dette under kerne 2.4 det virkede ikke godt.

> Problemet med denne metode er at du kan risikere store søgetider hvis
> kernen ikke kan gennemskue at fordele IO-operationerne godt. Idet S1 er
> første halvdel af diskene og S2 anden halvdel, vil en S1-S2 striping
> altid læse lidt fra første halvdel af en disk, og lidt fra anden
> halvdel. Den eneste effektive måde at gøre dette på er at lade
> første halvdel blive behandlet af den ene disk, og anden halvdel af den
> anden. (det er dét jeg ikke ved om kernen er god til) Det er dog stadig
> problematisk med skrivninger, hvor læsehovederne skal flyttes.
>
> Jeg foreslår derfor følgende metode:
>
> Du spejler A1, B2 => S1 og B1, A2 => S2. Så striper du S1+S2. Nu bliver
> læse-operationer stripet mellem de to første halvdele eller de to
> sidste, men aldrig på kryds. Skriveoperationer bliver ligeledes
> effektive (så godt som RAID-1 nu tillader det). Hvis disk A forsvinder,
> har du B2 som S1 og B1 som S2. (og omvendt).
>
> Jeg har ikke afprøvet ovenstående i praksis, så der er måske noget
> jeg har overset.

Jeg har prøvet det i praksis. Det performer ikke. Det er bedre at lave en
raid personality der er beregnet til det. Neil Brown som er en af
vedligeholderne af raid til Linux har leget lidt med det, og jeg har lavet
lidt design.

Hilsen
keld

---

Keld Jørn Simonsen wrote:
> Den Wed, 16 Jun 2004 12:59:46 +0200. skrev Christian Iversen:

>>Nogle programmer bruger stakken som en slags malloc(). De skal så omskrives.
>>Det er ikke kønt, men det er noget hurtigere. Dog burde de nok kunne
>>allokere med malloc() i større blokke før de skal bruge pladsen, men det
>>ville tage et stykke tid at finde ud af, for alle programmer der gør dette.
>
> Hvordan bruger programmerne stakken som malloc? Og hvorfor kan de ikke
> gøre det på heapen i stedet - automatisk, idet nye funktionsdata
> allokeres på heapen?

Der tænkes nok på alloca(3) som er BSD-udvidelse af libc til at allokere
plads på kalderens stak. Kaldet udføres direkte af oversætteren (GCC),
og som jeg ser det, er der ikke noget til hinder for at oversætteren
tager pladsen fra et andet sted, for eksempel fra samme alternative stak
som du vil lægge automatiske variable på.

---

Byrial Jensen wrote:

> Keld Jørn Simonsen wrote:
>> Den Wed, 16 Jun 2004 12:59:46 +0200. skrev Christian Iversen:
>
>>>Nogle programmer bruger stakken som en slags malloc(). De skal så
>>>omskrives. Det er ikke kønt, men det er noget hurtigere. Dog burde de nok
>>>kunne allokere med malloc() i større blokke før de skal bruge pladsen,
>>>men det ville tage et stykke tid at finde ud af, for alle programmer der
>>>gør dette.
>>
>> Hvordan bruger programmerne stakken som malloc? Og hvorfor kan de ikke
>> gøre det på heapen i stedet - automatisk, idet nye funktionsdata
>> allokeres på heapen?
>
> Der tænkes nok på alloca(3) som er BSD-udvidelse af libc til at allokere
> plads på kalderens stak. Kaldet udføres direkte af oversætteren (GCC),

Netop den, ja.

(og pointen med alloca() var at den er noget hurtigere end malloc(), men kun
fungerer i én funktion)

> og som jeg ser det, er der ikke noget til hinder for at oversætteren
> tager pladsen fra et andet sted, for eksempel fra samme alternative stak
> som du vil lægge automatiske variable på.

Jo det skulle være muligt.

--
M.V.H
Christian Iversen

---

Keld Jørn Simonsen <keld@dkuug.dk> writes:

>> Hvordan vil du lukke din cpu ned udover halt og ACPI?
>
> med ACPI - sluk cpu. Der skal nok noget kernehakning til.

Ja, og hardware. Når en x86 CPU får strøm på, er den sat til at
eksekvere kode i 16bit med en adressepeger på det sted, IBM engang
vedtog at BIOS'ens start ligger.

Inden den blev slukket, kørte den 32bit (hvis vi stadig snakke x86) og
havde en adressepeger på det sted i hukommelsen, hvor Linux lige nu
var nået til.

Idet CPU'en slukkes, tømmes alle registre for informationer og er ikke
tilgængelige, når strømmen kommer tilbage.

Alt i alt: Efter en slukning er CPU'en i en markant anden tilstand end
før. Der er forsvundet mange vitale registre, idet der er slukket for
CPU'ens vitale kredsløb. Adressepegeren peger på BIOS og ikke på det
rette sted i Linux.

Linux har i denne tilstand ingen chance for at køre. Maskinen vil
simpelthen boote BIOS'ens kode i stedet.

Er du sikker på, du ikke bare leder efter suspend-to-disk? Der gemmes
statusregistre, kerneparametre og en masse andet information og
indlæses fra disk ved genstart.

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
He has his own opinions
- just like the others.
- Burnin' Red Ivanhoe
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

Den Wed, 16 Jun 2004 02:43:26 +0200. skrev Rasmus Bøg Hansen:

> Keld Jørn Simonsen <keld@dkuug.dk> writes:
>
>>> Hvordan vil du lukke din cpu ned udover halt og ACPI?
>>
>> med ACPI - sluk cpu. Der skal nok noget kernehakning til.
>
> Ja, og hardware. Når en x86 CPU får strøm på, er den sat til at
> eksekvere kode i 16bit med en adressepeger på det sted, IBM engang
> vedtog at BIOS'ens start ligger.
>
> Inden den blev slukket, kørte den 32bit (hvis vi stadig snakke x86) og
> havde en adressepeger på det sted i hukommelsen, hvor Linux lige nu
> var nået til.
>
> Idet CPU'en slukkes, tømmes alle registre for informationer og er ikke
> tilgængelige, når strømmen kommer tilbage.
>
> Alt i alt: Efter en slukning er CPU'en i en markant anden tilstand end
> før. Der er forsvundet mange vitale registre, idet der er slukket for
> CPU'ens vitale kredsløb. Adressepegeren peger på BIOS og ikke på det
> rette sted i Linux.
>
> Linux har i denne tilstand ingen chance for at køre. Maskinen vil
> simpelthen boote BIOS'ens kode i stedet.
>
> Er du sikker på, du ikke bare leder efter suspend-to-disk? Der gemmes
> statusregistre, kerneparametre og en masse andet information og
> indlæses fra disk ved genstart.

Det jeg tænker på er suspend-to-ram, hvor jeg blot også holder skærmen
tændt, og også tastatur tændt. Det må da kunne lade sig gøre.

Hilsen
keld

---

On 2004-06-16, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>> Er du sikker på, du ikke bare leder efter suspend-to-disk? Der gemmes
>> statusregistre, kerneparametre og en masse andet information og
>> indlæses fra disk ved genstart.
>
> Det jeg tænker på er suspend-to-ram, hvor jeg blot også holder skærmen
> tændt, og også tastatur tændt. Det må da kunne lade sig gøre.

Du vil altså prøve at kombinere ACPI S3 og samtidig holde liv i nordbroen og
grafikkortet.

Det tvivler jeg _meget_ kraftigt på kan lade sig gøre.

1) S3 er implementeret i BIOS, idet det kun er BIOSen de ved hvad hardwaren
er i stand til og ikke i stand til. Derfor er S3 enten/eller.

2) Selv _hvis_ du koder din egen S3, _specifikt_ til din bærbar, så
tvivler jeg på at nordbroen kan være autonom og styre sig selv uden
cpu hjælp. Og hvis du ikke har en nordbro har du ikke pci, og hvis du
ikke har pci, har du ikke gfx og uden gfx, blank skærm.

Men jeg vil da godt undersøge det for dig for .5k i timen

Thomas

---

Den Wed, 16 Jun 2004 08:00:31 +0000. skrev Thomas S. Iversen:

> On 2004-06-16, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>>> Er du sikker på, du ikke bare leder efter suspend-to-disk? Der gemmes
>>> statusregistre, kerneparametre og en masse andet information og
>>> indlæses fra disk ved genstart.
>>
>> Det jeg tænker på er suspend-to-ram, hvor jeg blot også holder skærmen
>> tændt, og også tastatur tændt. Det må da kunne lade sig gøre.
>
> Du vil altså prøve at kombinere ACPI S3 og samtidig holde liv i nordbroen og
> grafikkortet.
>
> Det tvivler jeg _meget_ kraftigt på kan lade sig gøre.
>
> 1) S3 er implementeret i BIOS, idet det kun er BIOSen de ved hvad hardwaren
> er i stand til og ikke i stand til. Derfor er S3 enten/eller.
>
> 2) Selv _hvis_ du koder din egen S3, _specifikt_ til din bærbar, så
> tvivler jeg på at nordbroen kan være autonom og styre sig selv uden
> cpu hjælp. Og hvis du ikke har en nordbro har du ikke pci, og hvis du
> ikke har pci, har du ikke gfx og uden gfx, blank skærm.

Det jeg ville var blot at holde skærmen tændt hele tiden, og så modtage
et event på mus eller tastatur, som så ville starte cpuen op.
Det ville koste 50 msek.

Hvorfor kan man ikke holde skærmen tændt, når man kan holde rammen
tændt, med slukket cpu, som man gør i suspend-to-ram? Skærmen skal ikke
lave noget aktivt. Jeg kan godt se at den nok skal igennem noget nordbro
med grafikkort på pci. Men det kunne man vel også have tændt.

> Men jeg vil da godt undersøge det for dig for .5k i timen

Hele min idé med at poste her var at finde nogen personer der var
billigere, og hvor man kunne finde dem.

Hilsen
Keld

---

Keld Jørn Simonsen wrote:

> Det jeg ville var blot at holde skærmen tændt hele tiden, og så modtage
> et event på mus eller tastatur, som så ville starte cpuen op.
> Det ville koste 50 msek.

Bare en tanke.. hvis man så har uret vist på desktoppen, skal
processoren selv vågne op og opdatere skærmen hvert minut, eller hvem
skal vække den der? Eller markøren i det brev du er ved at skrive.

--
Anders Lund - spam2004@andersonline.dk

---

Den Wed, 16 Jun 2004 21:38:14 +0200. skrev Anders Lund:

> Keld Jørn Simonsen wrote:
>
>> Det jeg ville var blot at holde skærmen tændt hele tiden, og så modtage
>> et event på mus eller tastatur, som så ville starte cpuen op.
>> Det ville koste 50 msek.
>
> Bare en tanke.. hvis man så har uret vist på desktoppen, skal
> processoren selv vågne op og opdatere skærmen hvert minut, eller hvem
> skal vække den der? Eller markøren i det brev du er ved at skrive.

Tjoe, det ville være fint, men ikke noget jeg absolut ville kræve.
Er der ikke et separat ur på en maskine, der går uafhængigt af om
CPU-en er tændt?

Hilsen
keld

---

Keld Jørn Simonsen wrote:

> Den Wed, 16 Jun 2004 21:38:14 +0200. skrev Anders Lund:
>
>> Keld Jørn Simonsen wrote:
>>
>>> Det jeg ville var blot at holde skærmen tændt hele tiden, og så modtage
>>> et event på mus eller tastatur, som så ville starte cpuen op.
>>> Det ville koste 50 msek.
>>
>> Bare en tanke.. hvis man så har uret vist på desktoppen, skal
>> processoren selv vågne op og opdatere skærmen hvert minut, eller hvem
>> skal vække den der? Eller markøren i det brev du er ved at skrive.
>
> Tjoe, det ville være fint, men ikke noget jeg absolut ville kræve.
> Er der ikke et separat ur på en maskine, der går uafhængigt af om
> CPU-en er tændt?

Jo, men hvordan ville du opdatere skærmen?

--
M.V.H
Christian Iversen

---

Den Thu, 17 Jun 2004 08:01:40 +0200. skrev Christian Iversen:

> Keld Jørn Simonsen wrote:
>
>> Den Wed, 16 Jun 2004 21:38:14 +0200. skrev Anders Lund:
>>
>>> Keld Jørn Simonsen wrote:
>>>
>>>> Det jeg ville var blot at holde skærmen tændt hele tiden, og så modtage
>>>> et event på mus eller tastatur, som så ville starte cpuen op.
>>>> Det ville koste 50 msek.
>>>
>>> Bare en tanke.. hvis man så har uret vist på desktoppen, skal
>>> processoren selv vågne op og opdatere skærmen hvert minut, eller hvem
>>> skal vække den der? Eller markøren i det brev du er ved at skrive.
>>
>> Tjoe, det ville være fint, men ikke noget jeg absolut ville kræve.
>> Er der ikke et separat ur på en maskine, der går uafhængigt af om
>> CPU-en er tændt?
>
> Jo, men hvordan ville du opdatere skærmen?

Ved at starte cpuen, når man får et klokkeinterrupt. Jeg tror at man kan
uret til at lave et interrupt programmeret.

Hilsen
Keld

---

Keld Jørn Simonsen wrote:

> Den Thu, 17 Jun 2004 08:01:40 +0200. skrev Christian Iversen:
>
>> Keld Jørn Simonsen wrote:
>>
>>> Den Wed, 16 Jun 2004 21:38:14 +0200. skrev Anders Lund:
>>>
>>>> Keld Jørn Simonsen wrote:
>>>>
>>>>> Det jeg ville var blot at holde skærmen tændt hele tiden, og så
>>>>> modtage et event på mus eller tastatur, som så ville starte cpuen op.
>>>>> Det ville koste 50 msek.
>>>>
>>>> Bare en tanke.. hvis man så har uret vist på desktoppen, skal
>>>> processoren selv vågne op og opdatere skærmen hvert minut, eller hvem
>>>> skal vække den der? Eller markøren i det brev du er ved at skrive.
>>>
>>> Tjoe, det ville være fint, men ikke noget jeg absolut ville kræve.
>>> Er der ikke et separat ur på en maskine, der går uafhængigt af om
>>> CPU-en er tændt?
>>
>> Jo, men hvordan ville du opdatere skærmen?
>
> Ved at starte cpuen, når man får et klokkeinterrupt. Jeg tror at man kan
> uret til at lave et interrupt programmeret.

Ja - normalt sker dette mange gang i sekundet (fx 1024). Kernen reagerer på
dette, og derved bliver det program kørt der opdaterer skærmen. Der er 2
problemer med dit forslag:

1) Det ville kræve store omskrivninger af mange dele af kernekoden.
2) Kernen kører i forvejen en idle-process der enter kører instruktionen HLT
(halt) der stopper CPUen, eller en særligt strømbesparende APM/ACPI
kommando. Fordelen er altså ikke særligt stor, og da slet ikke i forhold
til det arbejde der ville gå med det.

--
M.V.H
Christian Iversen

---

Den Thu, 17 Jun 2004 17:45:10 +0200. skrev Christian Iversen:

> Keld Jørn Simonsen wrote:
>
>> Den Thu, 17 Jun 2004 08:01:40 +0200. skrev Christian Iversen:
>>
>>> Keld Jørn Simonsen wrote:
>>>
>>>> Den Wed, 16 Jun 2004 21:38:14 +0200. skrev Anders Lund:
>>>>
>>>>> Keld Jørn Simonsen wrote:
>>>>>
>>>>>> Det jeg ville var blot at holde skærmen tændt hele tiden, og så
>>>>>> modtage et event på mus eller tastatur, som så ville starte cpuen op.
>>>>>> Det ville koste 50 msek.
>>>>>
>>>>> Bare en tanke.. hvis man så har uret vist på desktoppen, skal
>>>>> processoren selv vågne op og opdatere skærmen hvert minut, eller hvem
>>>>> skal vække den der? Eller markøren i det brev du er ved at skrive.
>>>>
>>>> Tjoe, det ville være fint, men ikke noget jeg absolut ville kræve.
>>>> Er der ikke et separat ur på en maskine, der går uafhængigt af om
>>>> CPU-en er tændt?
>>>
>>> Jo, men hvordan ville du opdatere skærmen?
>>
>> Ved at starte cpuen, når man får et klokkeinterrupt. Jeg tror at man kan
>> uret til at lave et interrupt programmeret.
>
> Ja - normalt sker dette mange gang i sekundet (fx 1024). Kernen reagerer på
> dette, og derved bliver det program kørt der opdaterer skærmen. Der er 2
> problemer med dit forslag:
>
> 1) Det ville kræve store omskrivninger af mange dele af kernekoden.

Hvorfor det? uret kan vel sættes til at generere et langt interrupt når
man har fundet ud af at man vil slukke cpu'en. Dette skal vel kun gøres
ét sted.

> 2) Kernen kører i forvejen en idle-process der enter kører instruktionen HLT
> (halt) der stopper CPUen, eller en særligt strømbesparende APM/ACPI
> kommando. Fordelen er altså ikke særligt stor, og da slet ikke i forhold
> til det arbejde der ville gå med det.

Ja, kernen kører et idle loop. Der bruges måske 7,5 W på dette i stedet
for 30 W i aktiv tilstand. Jeg kan spare 7,5 W, hvilket er ganske meget ud
af det samlede forbrug på 15 W (tal fra min Acer). Dobbelt så lang
batteritid!

Hilsen
Keld

---

On 2004-06-16, Keld Jørn Simonsen <keld@dkuug.dk> wrote:

> Det jeg ville var blot at holde skærmen tændt hele tiden, og så modtage
> et event på mus eller tastatur, som så ville starte cpuen op.

En lille tur rundt med google har vist at bus disconnect tilsyneladende
kun er implementeret i AMDs athlon serie og der er det ofte slået fra
da det giver problemer.

> Hvorfor kan man ikke holde skærmen tændt, når man kan holde rammen
> tændt, med slukket cpu, som man gør i suspend-to-ram? Skærmen skal ikke
> lave noget aktivt. Jeg kan godt se at den nok skal igennem noget nordbro
> med grafikkort på pci. Men det kunne man vel også have tændt.

Du kan også godt holde skærmen tændt, men det kommer ikke til at foregå via
ACPI. ACPI S3 er et specifikt bios kald der, på _supporteret hardware_
gemmer OS state og power enhederne og sig selv ned --- som du rigtigt har fat
i.

Det kan åbenbart godt lade sig gøre at disconnecte cpuen fra PCI broen
(havde jeg ikke troet), men der er store problemer forbundet med det.

Dit skærmkort arbejder jo på fuldt tryk selvom der ikke "sker" noget på
skærmen. Specielt er RAMdac'en på arbejde. En gfx chip med ACPI support vil
selv lukke de units ned den ikke bruger via C modes. Jeg tror ikke du kan
gøre det bedre end hvad der er support for via dine ACPI tabller i biosen,
under antagelse af, at du har en nyere bærbar.

>> Men jeg vil da godt undersøge det for dig for .5k i timen
>
> Hele min idé med at poste her var at finde nogen personer der var
> billigere, og hvor man kunne finde dem.

..5k er da ikke vildt. Som privat person måske, men da ellers ikke.

Thomas

---

Den Wed, 16 Jun 2004 21:37:04 +0000. skrev Thomas S. Iversen:

> On 2004-06-16, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>
>> Det jeg ville var blot at holde skærmen tændt hele tiden, og så modtage
>> et event på mus eller tastatur, som så ville starte cpuen op.
>
> En lille tur rundt med google har vist at bus disconnect tilsyneladende
> kun er implementeret i AMDs athlon serie og der er det ofte slået fra
> da det giver problemer.

Hvad er bus disconnect?

>> Hvorfor kan man ikke holde skærmen tændt, når man kan holde rammen
>> tændt, med slukket cpu, som man gør i suspend-to-ram? Skærmen skal ikke
>> lave noget aktivt. Jeg kan godt se at den nok skal igennem noget nordbro
>> med grafikkort på pci. Men det kunne man vel også have tændt.
>
> Du kan også godt holde skærmen tændt, men det kommer ikke til at foregå via
> ACPI. ACPI S3 er et specifikt bios kald der, på _supporteret hardware_
> gemmer OS state og power enhederne og sig selv ned --- som du rigtigt har fat
> i.

Jeg havde ellers hørt at Linux ikke bruger BIOS, men det gør det
måske til ACPI?

Det jeg tænker på er nærmere S2 hvor man individuelt kan bestemme
hvad der er tændt og slukket.

Jeg mente at hver Linux driver kunne tænde og slukke den enhed de
bestyrer. De ikke-brugte enheder skulle derfor sættes i tilstand D3.

> Det kan åbenbart godt lade sig gøre at disconnecte cpuen fra PCI broen
> (havde jeg ikke troet), men der er store problemer forbundet med det.

Hvad er problemerne? Idéen er at der ikke sker noget nogen steder, og
cpu-en derfor er slukket. Så snart der sker noget, betragtes dette som en
hændelse der vækker CPU'en (tænder CPU'en), og systemet kører så
normalt.

> Dit skærmkort arbejder jo på fuldt tryk selvom der ikke "sker" noget
> på skærmen. Specielt er RAMdac'en på arbejde. En gfx chip med ACPI
> support vil selv lukke de units ned den ikke bruger via C modes. Jeg
> tror ikke du kan gøre det bedre end hvad der er support for via dine
> ACPI tabller i biosen, under antagelse af, at du har en nyere bærbar.

Ja, den arbejder og derfor bruger den strøm. Men den skal vel ikke bruge
CPU'en til noget. Skærmen viser vel bare hvad der er i dens skærmlager.

>>> Men jeg vil da godt undersøge det for dig for .5k i timen
>>
>> Hele min idé med at poste her var at finde nogen personer der var
>> billigere, og hvor man kunne finde dem.
>
> .5k er da ikke vildt. Som privat person måske, men da ellers ikke.

Næh, det var ikke vildt for dansk arbejdskraft. Men jeg tænkte på
russisk eller indisk arbejdskraft - eller lignende. Det er mine egne penge
det drejer sig om.

Hilsen
keld

---

On 2004-06-16, Keld Jørn Simonsen <keld@dkuug.dk> wrote:

> Hvad er bus disconnect?

At cpuen er disconnected fra PCI bussen (og derfor har lov til at stoppe med
at snakke med nordbroen => den kan falde i "søvn" hvis den vil).

> Jeg havde ellers hørt at Linux ikke bruger BIOS, men det gør det
> måske til ACPI?

Linux bruger skam BIOS. Jeg har ikke lige fulgt med hvor god PCI
implementeringen i 2.6.x er blevet, men i tidligere versioner havde man brug
for bios til at sætte PCI enhederne ordenligt op. Det kan man nok klare selv
nu. Man har dog brug for ACPI tabellerne for at kunne tilgå hardwaren på
eksotiske måder. Herunder powersave og suspend/sleep.

> Jeg mente at hver Linux driver kunne tænde og slukke den enhed de
> bestyrer. De ikke-brugte enheder skulle derfor sættes i tilstand D3.

Det kan de I princippet også godt. Problemet er bare, at det foregår via
ACPI. Motherboard fabrikanterne laver jo forskellige motherboards og trækker
"ledningerne" forskelligt på disse, så man bliver nødt til at tilgå
hardwaren gennem et interface i mange tilfælde. I andre kan man gøre som man
vil direkte.

>> Det kan åbenbart godt lade sig gøre at disconnecte cpuen fra PCI broen
>> (havde jeg ikke troet), men der er store problemer forbundet med det.
>
> Hvad er problemerne? Idéen er at der ikke sker noget nogen steder, og
> cpu-en derfor er slukket. Så snart der sker noget, betragtes dette som en
> hændelse der vækker CPU'en (tænder CPU'en), og systemet kører så
> normalt.

Der er to problemer:

* Timing. I en perfekt verden virker alt som det bør. I en ikke perfekt
verden kan PCI enheder (herunder broer) ikke klare at der ikke bliver svaret
fra cpuen i lang tid. De er ikke bygget til at være autonome. Lyd og Video
har specielt problemer lader det til.

* Når du slukker og tænder for din cpu flere hundre gange i sekundet
belaster du dine spændingsregulatorer på bundkortet (går fra ingen strøm til
meget, til ingen, til meget, osv.). Det slider. Specielt athlon processoren
er kendt for at trække en stor start strøm. For at gøre systemet mere
stabilt er der en del mb fabrikanter der har disablet den feature i bios.
Den kan slås til igen (med strømbesparelse til følge), men der er en grund
til at det er slået fra, fra start af.

> Ja, den arbejder og derfor bruger den strøm. Men den skal vel ikke bruge
> CPU'en til noget. Skærmen viser vel bare hvad der er i dens skærmlager.

Ja det har du ret i. I teorien. Det kræver at dit gfx chipset kan
"programmeres" til at arbejde på den måde, og kan klare at cpuen
er lang tid om at svare på IRQs når de kommer.

Thomas

---

Den Wed, 16 Jun 2004 22:46:31 +0000. skrev Thomas S. Iversen:

> On 2004-06-16, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>
>> Hvad er bus disconnect?
>
> At cpuen er disconnected fra PCI bussen (og derfor har lov til at stoppe med
> at snakke med nordbroen => den kan falde i "søvn" hvis den vil).
>
>> Jeg havde ellers hørt at Linux ikke bruger BIOS, men det gør det
>> måske til ACPI?
>
> Linux bruger skam BIOS. Jeg har ikke lige fulgt med hvor god PCI
> implementeringen i 2.6.x er blevet, men i tidligere versioner havde man brug
> for bios til at sætte PCI enhederne ordenligt op. Det kan man nok klare selv
> nu. Man har dog brug for ACPI tabellerne for at kunne tilgå hardwaren på
> eksotiske måder. Herunder powersave og suspend/sleep.
>
>> Jeg mente at hver Linux driver kunne tænde og slukke den enhed de
>> bestyrer. De ikke-brugte enheder skulle derfor sættes i tilstand D3.
>
> Det kan de I princippet også godt. Problemet er bare, at det foregår via
> ACPI. Motherboard fabrikanterne laver jo forskellige motherboards og trækker
> "ledningerne" forskelligt på disse, så man bliver nødt til at tilgå
> hardwaren gennem et interface i mange tilfælde. I andre kan man gøre som man
> vil direkte.

Det er vel OK at drivere kan bruge bios'en i forskellige tilfælde, det er
vel ikke noget som ændrer på strategien i min idé.

>>> Det kan åbenbart godt lade sig gøre at disconnecte cpuen fra PCI
>>> broen (havde jeg ikke troet), men der er store problemer forbundet med
>>> det.
>>
>> Hvad er problemerne? Idéen er at der ikke sker noget nogen steder, og
>> cpu-en derfor er slukket. Så snart der sker noget, betragtes dette som
>> en hændelse der vækker CPU'en (tænder CPU'en), og systemet kører
>> så normalt.
>
> Der er to problemer:
>
> * Timing. I en perfekt verden virker alt som det bør. I en ikke perfekt
> verden kan PCI enheder (herunder broer) ikke klare at der ikke bliver
> svaret fra cpuen i lang tid. De er ikke bygget til at være autonome.
> Lyd og Video har specielt problemer lader det til.

Hvis der kører lyd eller video, skal man ikke sætte maskinen i S2.
Så kører systemet.

> * Når du slukker og tænder for din cpu flere hundre gange i sekundet
> belaster du dine spændingsregulatorer på bundkortet (går fra ingen
> strøm til meget, til ingen, til meget, osv.). Det slider. Specielt
> athlon processoren er kendt for at trække en stor start strøm. For at
> gøre systemet mere stabilt er der en del mb fabrikanter der har
> disablet den feature i bios. Den kan slås til igen (med
> strømbesparelse til følge), men der er en grund til at det er slået
> fra, fra start af.

Ja, det kunne godt bekymre mig. Men er det anderledes end at disken bruger
strøm når den læser? Det siges at cpu'en ikke tager skade af at blive
slukket og tændt mange gange. Faktisk siger de at jo mindre strøm der er
på den, des bedre - dvs den lever længere jo koldere den er. Hvor meget
bruges der til opstart af CPU? og hvor længe? Det skulle jo gerne være
sådan at gevinsten ved at holde cpu'en slukket var højere end ved at
starte den op igen. Og hvor stort er sliddet på bundkortet?

Det kan godt være at der slides noget, men så kan det være at man kun
sjældent har brug for denne specielle strømbesparende tilstand. Jeg har
fx nok selv kun brug for den når jeg er ude at flyve.

>> Ja, den arbejder og derfor bruger den strøm. Men den skal vel ikke
>> bruge CPU'en til noget. Skærmen viser vel bare hvad der er i dens
>> skærmlager.
>
> Ja det har du ret i. I teorien. Det kræver at dit gfx chipset kan
> "programmeres" til at arbejde på den måde, og kan klare at cpuen er
> lang tid om at svare på IRQs når de kommer.

Hvad er det for nogen IRQ's der kommer hvis maskinen ikke laver noget?
Der skulle komme IRq's fra mus og tastatur, og måske fra klokken,
men ikke andre steder fra. Hvis der kommer IRQ's andre steder fra kan man
vælge at ignorere dem. Der kunne typisk komme input på ethernet eller
modemporten.

Hilsen
keld

---

On 2004-06-17, Keld Jørn Simonsen <keld@dkuug.dk> wrote:

> Hvis der kører lyd eller video, skal man ikke sætte maskinen i S2.

Ja, men at halte cpuen er ikke en sort/hvid ting. Du halter den måske kun
i 95/100 af tiden, men det bliver jo også til mange
opvågningerne/nedlukninger i sekundet.

Pointen er, at nogle enheder har det meget dårligt med at cpuen forlader dem
i længere tid ad gangen. Ærgeligt, men sådan er det nu engang.

> Ja, det kunne godt bekymre mig. Men er det anderledes end at disken bruger

Din hdd bruger 1W, en nyere Athlon/P4 mobile cpu 25W i fuldbelastning. Det
er ikke af "økonomiske" hensyn at jeg siger det. Kondensatorer har bedst af
ikke at blive op/afladet med stor strøm hele tiden. Det aftager deres
levetid betragteligt af.

> starte den op igen. Og hvor stort er sliddet på bundkortet?

Afhænger af dine kondensatorer og kvaliteten af designet omkring din VRM.

> Hvad er det for nogen IRQ's der kommer hvis maskinen ikke laver noget?

Jeg tror også den laver noget. Jeg tror at gfx kortet med givne intervaller
får lavet et interrupt som cpuen _må_ besvare såfremt du vil blive ved med
at have noget på skærmen. Men det er bare min formodning.

Thomas

---

Den Thu, 17 Jun 2004 10:50:06 +0000. skrev Thomas S. Iversen:

> On 2004-06-17, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>
>> Hvis der kører lyd eller video, skal man ikke sætte maskinen i S2.
>
> Ja, men at halte cpuen er ikke en sort/hvid ting. Du halter den måske kun
> i 95/100 af tiden, men det bliver jo også til mange
> opvågningerne/nedlukninger i sekundet.

Jeg tror ikke man bare skal slukke for cpu, i stedet for idle loop.
Man skal nok først slukke efter at der er kørt i idle loop et stykke
tid, måske 100 ms. Det udelukker at man slukker hvis der fx kører lyd
eller video, eller hvis man bevæger musen. Spørgsmålet er om man skal
slukke for hvert tastetryk på tastaturet. Hvor hurtigt taster man?
Tog lige tid på det: 200 til 500 ms for hvert tryk, og jeg er ikke hurtig.

Så jeg tror ikke det bliver mange opvågninger/slukninger i sekundet.
Men det er vel noget man kan eksperimentere sig frem til, og evt regulere.
Man kunne sætte en parameter for hvor lnag tid maskinen skal køre i idle
loop før man slukker. En kernevariabel, målt i msek.

> Pointen er, at nogle enheder har det meget dårligt med at cpuen
> forlader dem i længere tid ad gangen. Ærgeligt, men sådan er det nu
> engang.

Har de også problemer hvis de ikke laver noget?

>> Ja, det kunne godt bekymre mig. Men er det anderledes end at disken
>> bruger
>
> Din hdd bruger 1W, en nyere Athlon/P4 mobile cpu 25W i fuldbelastning.
> Det er ikke af "økonomiske" hensyn at jeg siger det. Kondensatorer har
> bedst af ikke at blive op/afladet med stor strøm hele tiden. Det
> aftager deres levetid betragteligt af.

jeg tror at bærbares diske typisk tager ca 5 - 7 W at starte op, og
ca 2 - 3 W ved læsning/skrivning. Men det er da en del mindre end hvad
CPU-en kræver i opstart/kørsel. Hmm, er det ikke det samme der sker,
når cpuen går fra idle loop til aktiv? Der går min cpu fra ca 7 W til
30 W. Det må efter hvad du siger også slide på kondensatorerne. Og det
er noget den gør hele tiden. Hvis det er rigtigt tror jeg altså ikke at
slukning er et større problem.

>> Hvad er det for nogen IRQ's der kommer hvis maskinen ikke laver noget?
>
> Jeg tror også den laver noget. Jeg tror at gfx kortet med givne
> intervaller får lavet et interrupt som cpuen _må_ besvare såfremt du
> vil blive ved med at have noget på skærmen. Men det er bare min
> formodning.

Ja, der er meget her der er teori, men spørgsmålet er hvordan det virker
i praksis, og også om det overhovedet kan lade sig gøre. Jeg kunne godt
tænke mig at få det implementeret og prøvet af.

Hilsen
keld

---

On 2004-06-17, Keld Jørn Simonsen <keld@dkuug.dk> wrote:

> Har de også problemer hvis de ikke laver noget?

Nej, men din gfx chip laver jo noget, konstant. Det er jo det du gerne vil
have.

> jeg tror at bærbares diske typisk tager ca 5 - 7 W at starte op, og

Min disk tager 1-2W i drift

> når cpuen går fra idle loop til aktiv? Der går min cpu fra ca 7 W til
> 30 W. Det må efter hvad du siger også slide på kondensatorerne. Og det

Ja, men der skifter du jo heller ikke saerlig tit. Problemerne opstaar naar
du har en masse "spidser" i stroemforbruget. Det tror jeg du vil have hvis
du lukker helt ned. Jeg tvivler paa at du kan faa slukket helt i flere
sekunder/minutter ad gangen. Men som sagt, saa maa du finde en billig
kineser der kan proeve det for dig!

Thomas

---

Den Thu, 17 Jun 2004 11:52:48 +0000. skrev Thomas S. Iversen:

> On 2004-06-17, Keld Jørn Simonsen <keld@dkuug.dk> wrote:

>> når cpuen går fra idle loop til aktiv? Der går min cpu fra ca 7 W til
>> 30 W. Det må efter hvad du siger også slide på kondensatorerne. Og det
>
> Ja, men der skifter du jo heller ikke saerlig tit.

Det sker da hele tiden. Fx hvis jeg skriver. Det tager måske 1 ms at
processere et tasteanslag, så går der 300 ms før der kommer et nyt. I
de 299 ms kører processoren i idle loop. Det er iøvrigt de samme skift
der skal ske iflg. min idé, men i stedet for at køre i idle loop, så
slukker CPUen efter et bestemt antal ms.

> Problemerne opstaar naar
> du har en masse "spidser" i stroemforbruget. Det tror jeg du vil have hvis
> du lukker helt ned. Jeg tvivler paa at du kan faa slukket helt i flere
> sekunder/minutter ad gangen. Men som sagt, saa maa du finde en billig
> kineser der kan proeve det for dig!

Jo, og hvor finder jeg så ham kineseren?

Noget andet er at jeg kunne udløve 3 flasker god rødvin og hædrende
omtale til dem der implementerer de idéer jeg har beskrevet. Det kunne
også ske i etaper.

Hilsen
keld

---

On 2004-06-17, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
> Den Thu, 17 Jun 2004 11:52:48 +0000. skrev Thomas S. Iversen:
>
>> On 2004-06-17, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>
>>> når cpuen går fra idle loop til aktiv? Der går min cpu fra ca 7 W til
>>> 30 W. Det må efter hvad du siger også slide på kondensatorerne. Og det
>>
>> Ja, men der skifter du jo heller ikke saerlig tit.
>
> Det sker da hele tiden. Fx hvis jeg skriver. Det tager måske 1 ms at

Nej du bruger ikke 30W paa at processere tasteanslag. Der bruger du de 7W.
De 30W er hvis du f.eks. spiller (bruger FPUen) eller oversaetter et eller
andet.

> Jo, og hvor finder jeg så ham kineseren?

Jeg vil raade dig til at skrive til ham der er ansvarlig for ACPI systemet i
linux og hoere om din ide er realiserbar. Han vil med garanti vide det.

Ioevrigt sad jeg og spekulerede paa hvad du vil bruge et statisk billede til
i 8 timer i et fly?

Thomas

---

Den Thu, 17 Jun 2004 13:30:32 +0000. skrev Thomas S. Iversen:

> On 2004-06-17, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>> Den Thu, 17 Jun 2004 11:52:48 +0000. skrev Thomas S. Iversen:
>>
>>> On 2004-06-17, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>>
>>>> når cpuen går fra idle loop til aktiv? Der går min cpu fra ca 7 W til
>>>> 30 W. Det må efter hvad du siger også slide på kondensatorerne. Og det
>>>
>>> Ja, men der skifter du jo heller ikke saerlig tit.
>>
>> Det sker da hele tiden. Fx hvis jeg skriver. Det tager måske 1 ms at
>
> Nej du bruger ikke 30W paa at processere tasteanslag. Der bruger du de 7W.
> De 30W er hvis du f.eks. spiller (bruger FPUen) eller oversaetter et eller
> andet.

Min CPU er ikke centrino, men alm celeron. Den koster 30 W når den
processerer og 7,5 W i idle loop. Det kan godt være at den ikke bruger
FPU'en, men det gør den vel sjældent. Eller hvad véd jeg. Måske bruger
X FPU'en - det kan godt tænkes. Men under alle omstændigheder bruger den
meget mere end 7,5 W når den udfører almindelige instruktioner. Faktisk,
hvis den ikke laver noget, og ikke kører i idle loop, som fx hvis man er
i debug mode i bios'en, så bruger den 30 W. Og hvis jeg kommer tilbage
efter en S3 suspend-to ram, så kommer den af en eller anden grund ikke i
idle loop, og så bruger CPU'en også 30 W selvom den ikke laver noget som
helst. Dette er nok en ACPI-fejl (kerne 2.6.3).

>> Jo, og hvor finder jeg så ham kineseren?
>
> Jeg vil raade dig til at skrive til ham der er ansvarlig for ACPI systemet i
> linux og hoere om din ide er realiserbar. Han vil med garanti vide det.

Jeg har skrevet et par gange på acpi-kernelisten, uden at få respons.

> Ioevrigt sad jeg og spekulerede paa hvad du vil bruge et statisk billede til
> i 8 timer i et fly?

Jammen det er kun de 7 timer at billedet er statisk. 1 time - måske -
laver maskinen noget, resten af tiden kigger jeg på en uforandret skærm.

Hilsen
Keld

---

Keld Jørn Simonsen wrote:

> Den Thu, 17 Jun 2004 10:50:06 +0000. skrev Thomas S. Iversen:
>
>> On 2004-06-17, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>>
>>> Hvis der kører lyd eller video, skal man ikke sætte maskinen i S2.
>>
>> Ja, men at halte cpuen er ikke en sort/hvid ting. Du halter den måske kun
>> i 95/100 af tiden, men det bliver jo også til mange
>> opvågningerne/nedlukninger i sekundet.
>
> Jeg tror ikke man bare skal slukke for cpu, i stedet for idle loop.
> Man skal nok først slukke efter at der er kørt i idle loop et stykke
> tid, måske 100 ms. Det udelukker at man slukker hvis der fx kører lyd
> eller video, eller hvis man bevæger musen. Spørgsmålet er om man skal
> slukke for hvert tastetryk på tastaturet. Hvor hurtigt taster man?
> Tog lige tid på det: 200 til 500 ms for hvert tryk, og jeg er ikke hurtig.
>
> Så jeg tror ikke det bliver mange opvågninger/slukninger i sekundet.
> Men det er vel noget man kan eksperimentere sig frem til, og evt regulere.
> Man kunne sætte en parameter for hvor lnag tid maskinen skal køre i idle
> loop før man slukker. En kernevariabel, målt i msek.

Linux understøtter allerede dette (med tiden 333ms som default).

--
M.V.H
Christian Iversen

---

Her skriver Christian at Linux allerede kan det omkring at slukke for
CPU-en. Hvad er det den gør efter 333 ms?

Er der nogen link til en beskrivelse?

Hilsen Keld


Den Thu, 17 Jun 2004 17:49:43 +0200. skrev Christian Iversen:

> Keld Jørn Simonsen wrote:
>
>> Den Thu, 17 Jun 2004 10:50:06 +0000. skrev Thomas S. Iversen:
>>
>>> On 2004-06-17, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>>>
>>>> Hvis der kører lyd eller video, skal man ikke sætte maskinen i S2.
>>>
>>> Ja, men at halte cpuen er ikke en sort/hvid ting. Du halter den måske kun
>>> i 95/100 af tiden, men det bliver jo også til mange
>>> opvågningerne/nedlukninger i sekundet.
>>
>> Jeg tror ikke man bare skal slukke for cpu, i stedet for idle loop.
>> Man skal nok først slukke efter at der er kørt i idle loop et stykke
>> tid, måske 100 ms. Det udelukker at man slukker hvis der fx kører lyd
>> eller video, eller hvis man bevæger musen. Spørgsmålet er om man skal
>> slukke for hvert tastetryk på tastaturet. Hvor hurtigt taster man?
>> Tog lige tid på det: 200 til 500 ms for hvert tryk, og jeg er ikke hurtig.
>>
>> Så jeg tror ikke det bliver mange opvågninger/slukninger i sekundet.
>> Men det er vel noget man kan eksperimentere sig frem til, og evt regulere.
>> Man kunne sætte en parameter for hvor lnag tid maskinen skal køre i idle
>> loop før man slukker. En kernevariabel, målt i msek.
>
> Linux understøtter allerede dette (med tiden 333ms som default).

---

Keld Jørn Simonsen wrote:

> Her skriver Christian at Linux allerede kan det omkring at slukke for
> CPU-en. Hvad er det den gør efter 333 ms?

Du må undskylde formuleringen - strømmen er ikke taget 100% efter de 333ms.
Det kommer an på APM-implementationen. (men betyder at processorer/systemer
der implementerer bedre strømbesparelse automatisk kan benytte denne
funktionalitet efter 1/3 sekund). Det er dog samme grundidé.

"make menuconfig"-menuen fra linux-kernekonfigurationen har følgende at
sige:

CONFIG_APM_CPU_IDLE:
Enable calls to APM CPU Idle/CPU Busy inside the kernel's idle loop.
On some machines, this can activate improved power savings, such as
a slowed CPU clock rate, when the machine is idle. These idle calls
are made after the idle loop has run for some length of time (e.g.,
333 mS). On some machines, this will cause a hang at boot time or
whenever the CPU becomes idle. (On machines with more than one CPU,
this option does nothing.)


--
M.V.H
Christian Iversen

---

Keld Jørn Simonsen <keld@dkuug.dk> writes:

>> Det kan de I princippet også godt. Problemet er bare, at det foregår via
>> ACPI. Motherboard fabrikanterne laver jo forskellige motherboards og trækker
>> "ledningerne" forskelligt på disse, så man bliver nødt til at tilgå
>> hardwaren gennem et interface i mange tilfælde. I andre kan man gøre som man
>> vil direkte.
>
> Det er vel OK at drivere kan bruge bios'en i forskellige tilfælde, det er
> vel ikke noget som ændrer på strategien i min idé.

Næh, men det hjælper jo ikke noget, når ingen bios'er har
understøttelse for dine ideer?

>> * Timing. I en perfekt verden virker alt som det bør. I en ikke perfekt
>> verden kan PCI enheder (herunder broer) ikke klare at der ikke bliver
>> svaret fra cpuen i lang tid. De er ikke bygget til at være autonome.
>> Lyd og Video har specielt problemer lader det til.
>
> Hvis der kører lyd eller video, skal man ikke sætte maskinen i S2.

Du siger at du vil lade skærmen være tændt. Så kører grafikken jo også
og du kan ikke slukke CPU'en.

> strøm når den læser? Det siges at cpu'en ikke tager skade af at blive
> slukket og tændt mange gange. Faktisk siger de at jo mindre strøm der er
> på den, des bedre - dvs den lever længere jo koldere den er. Hvor meget

Når du slukker og tænder den, er der skiftevis strøm og ikke strøm
på. Når der er strøm på den udvikler den varme og kredsløbene udvider
sig. Når den er slukket, falder temperaturen og kredsløbene trækker
sig sammen. Dvs. at du får mange udvidelser og sammentrækninger af
kredsløbene, og det slider på CPU'en. Jeg ved ikke hvor meget, men det
er da også væsentligt at tage højde for.

> Det kan godt være at der slides noget, men så kan det være at man kun
> sjældent har brug for denne specielle strømbesparende tilstand. Jeg har
> fx nok selv kun brug for den når jeg er ude at flyve.

Og der er 4 timers batteritid - som der er på de fleste moderne
bærbare - ikke nok?

> Hvad er det for nogen IRQ's der kommer hvis maskinen ikke laver noget?
> Der skulle komme IRq's fra mus og tastatur, og måske fra klokken,
> men ikke andre steder fra. Hvis der kommer IRQ's andre steder fra kan man
> vælge at ignorere dem. Der kunne typisk komme input på ethernet eller
> modemporten.

clock (kan velsagtens slås fra, hvis man ved, hvorledes dette gøres på
det enkelte bundkort), grafikkort (medmindre dette kan slukkes - men
så slukker du formentlig også skærmen), USB, tastatur, mus, netkort,
modem, lydkort. Nogle af disse enheder vil nok kunne deaktiveres i
denne tilstand, men næppe alle. Og f. eks. musen er ret nem at komme
til at skubbe til (nok ikke mindst i et fly, hvor der er så lidt
plads).

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
We're here to *HACK* boxes not to Patch them!
-- Hack4Life
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

Den Thu, 17 Jun 2004 13:04:31 +0200. skrev Rasmus Bøg Hansen:

> Keld Jørn Simonsen <keld@dkuug.dk> writes:
>
>>> Det kan de I princippet også godt. Problemet er bare, at det foregår via
>>> ACPI. Motherboard fabrikanterne laver jo forskellige motherboards og trækker
>>> "ledningerne" forskelligt på disse, så man bliver nødt til at tilgå
>>> hardwaren gennem et interface i mange tilfælde. I andre kan man gøre som man
>>> vil direkte.
>>
>> Det er vel OK at drivere kan bruge bios'en i forskellige tilfælde, det er
>> vel ikke noget som ændrer på strategien i min idé.
>
> Næh, men det hjælper jo ikke noget, når ingen bios'er har
> understøttelse for dine ideer?

De fleste nyere bios'er har undestøttelse for S2. Og det er nok ikke alt
ACPI i kerne 2.6 der bruger bios'en. Kernen i min idé er at kunne slukke
for CPU'en. Jeg tror det meste her ikke behandles af BIOS allerede, men er
specifik ACPI 2.6 kerne drivere. Men det jeg skriver er teori, og det kan
da godt være det ikke kan lade sig gøre. Jeg mener bare min idé er
sund, og hvis man virkelig kan have 3 gange så lang batteritid, så burde
nogle flere interessere sig for det (IMHO).

Jeg ser det som en killerfeature for linux - hvis linux kan køre 3 gange
så lang tid på bærbare på linux ifht windows, og det bare er at køre
den nye knoppix, så er der nok mange der vil prøve det.

>>> * Timing. I en perfekt verden virker alt som det bør. I en ikke perfekt
>>> verden kan PCI enheder (herunder broer) ikke klare at der ikke bliver
>>> svaret fra cpuen i lang tid. De er ikke bygget til at være autonome.
>>> Lyd og Video har specielt problemer lader det til.
>>
>> Hvis der kører lyd eller video, skal man ikke sætte maskinen i S2.
>
> Du siger at du vil lade skærmen være tændt. Så kører grafikken jo også
> og du kan ikke slukke CPU'en.

Hvorfor ikke? Grafikkredslæbet skal bare displaye hvad der er i
grafiklageret. Der er ingen ændringer som cpu'en skal lave.

>> strøm når den læser? Det siges at cpu'en ikke tager skade af at
>> blive slukket og tændt mange gange. Faktisk siger de at jo mindre
>> strøm der er på den, des bedre - dvs den lever længere jo koldere
>> den er. Hvor meget
>
> Når du slukker og tænder den, er der skiftevis strøm og ikke strøm
> på. Når der er strøm på den udvikler den varme og kredsløbene
> udvider sig. Når den er slukket, falder temperaturen og kredsløbene
> trækker sig sammen. Dvs. at du får mange udvidelser og
> sammentrækninger af kredsløbene, og det slider på CPU'en. Jeg ved
> ikke hvor meget, men det er da også væsentligt at tage højde for.

Ja, men det gør CPU'en i forvejen, når den skifter mellem idle loop og
aktiv, for mig er det et skift mellem 7,5 W og 30 W. Dette skift er
processoren og maskinen i øvrigt bygget til at klare.

>> Det kan godt være at der slides noget, men så kan det være at man
>> kun sjældent har brug for denne specielle strømbesparende tilstand.
>> Jeg har fx nok selv kun brug for den når jeg er ude at flyve.
>
> Og der er 4 timers batteritid - som der er på de fleste moderne
> bærbare - ikke nok?

Næh, ikke når man flyver til USA eller Japan.

>> Hvad er det for nogen IRQ's der kommer hvis maskinen ikke laver noget?
>> Der skulle komme IRq's fra mus og tastatur, og måske fra klokken, men
>> ikke andre steder fra. Hvis der kommer IRQ's andre steder fra kan man
>> vælge at ignorere dem. Der kunne typisk komme input på ethernet eller
>> modemporten.
>
> clock (kan velsagtens slås fra, hvis man ved, hvorledes dette gøres
> på det enkelte bundkort), grafikkort (medmindre dette kan slukkes - men
> så slukker du formentlig også skærmen), USB, tastatur, mus, netkort,
> modem, lydkort. Nogle af disse enheder vil nok kunne deaktiveres i denne
> tilstand, men næppe alle. Og f. eks. musen er ret nem at komme til at
> skubbe til (nok ikke mindst i et fly, hvor der er så lidt plads).

Hvis der sker noget på disse enheder, så må man betragte det som en
hændelse i ACPI forstand, som vækker systemet til live.

Hilsen
keld

---

Due some reason Keld Jørn Simonsen <keld@dkuug.dk> happened to write:

>>> Det er vel OK at drivere kan bruge bios'en i forskellige tilfælde, det er
>>> vel ikke noget som ændrer på strategien i min idé.
>>
>> Næh, men det hjælper jo ikke noget, når ingen bios'er har
>> understøttelse for dine ideer?
>
> De fleste nyere bios'er har undestøttelse for S2. Og det er nok ikke alt
> ACPI i kerne 2.6 der bruger bios'en. Kernen i min idé er at kunne slukke

Men hvis BIOS'ens ACPI-implementation ikke beskriver, hvordan du
slukker for CPU'en i S2, har du ingen chance for at kunne gøre det vha
ACPI.

> for CPU'en. Jeg tror det meste her ikke behandles af BIOS allerede, men er
> specifik ACPI 2.6 kerne drivere. Men det jeg skriver er teori, og det kan

Du er klar over, hvordan ACPI fungerer? BIOS har nogle ACPI-tabeller,
som kernen indlæser ved boot. Disse tabeller beskriver, hvordan man
håndterer forskellige tilstande, operationer mm. på *netop denne*
hardware.

Herefter kan kernen implementere disse funktioner; evt. via
BIOS-kald. Normalt vil dette dog gøres direkte i kernen og BIOS så
vidt muligt undgås.

Nu er "sluk CPU" mig bekendt ikke defineret i ACPI-standarden. Altså
kan du ikke slukke for CPU'en via ACPI. Heller ikke i S2 - for BIOS's
ACPI-tabeller beskriver ikke, hvorledes dette gøres.

>> Du siger at du vil lade skærmen være tændt. Så kører grafikken jo også
>> og du kan ikke slukke CPU'en.
>
> Hvorfor ikke? Grafikkredslæbet skal bare displaye hvad der er i
> grafiklageret. Der er ingen ændringer som cpu'en skal lave.

Sådan fungerer det ikke. GPU'en læser indholdet af grafikhukommelsen
og konverterer dette til et VGA-signal (eller TV/DVI). GPU'en (eller i
hvert fald dele af den) kører altså hele tiden, når du har signal på
skærmen. Jeg tror ikke, du kan få GPU'en til at køre uden at kunne
signalere CPU'en at de kører.

>> Når du slukker og tænder den, er der skiftevis strøm og ikke strøm
>> på. Når der er strøm på den udvikler den varme og kredsløbene
>> udvider sig. Når den er slukket, falder temperaturen og kredsløbene
>> trækker sig sammen. Dvs. at du får mange udvidelser og
>> sammentrækninger af kredsløbene, og det slider på CPU'en. Jeg ved
>> ikke hvor meget, men det er da også væsentligt at tage højde for.
>
> Ja, men det gør CPU'en i forvejen, når den skifter mellem idle loop og
> aktiv, for mig er det et skift mellem 7,5 W og 30 W. Dette skift er
> processoren og maskinen i øvrigt bygget til at klare.

Som nævnt slider dette på maskinen, ligesom op- og afladning af
kondensatorer gør. Jeg ved ikke hvor meget, men det er muligvis værd
at overveje.

>> Og der er 4 timers batteritid - som der er på de fleste moderne
>> bærbare - ikke nok?
>
> Næh, ikke når man flyver til USA eller Japan.

Tja, jeg havde nok bare sat den til side en del af tiden, så den ikke
stod i vejen - men der er vi sikkert bare forskellige.

>> clock (kan velsagtens slås fra, hvis man ved, hvorledes dette gøres
>> på det enkelte bundkort), grafikkort (medmindre dette kan slukkes - men
>> så slukker du formentlig også skærmen), USB, tastatur, mus, netkort,
>> modem, lydkort. Nogle af disse enheder vil nok kunne deaktiveres i denne
>> tilstand, men næppe alle. Og f. eks. musen er ret nem at komme til at
>> skubbe til (nok ikke mindst i et fly, hvor der er så lidt plads).
>
> Hvis der sker noget på disse enheder, så må man betragte det som en
> hændelse i ACPI forstand, som vækker systemet til live.

Ja. Så skal du have implementeret i samtlige drivere, at der kan
slukkes for CPU'en, så de holder op med at sende interrupts. Forudsat
at de i hardwareimplementationen kan klare dette.

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
The logical thing to do with an egg is cook it and eat it, but throwing
it at someone is much more fun.
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

Den Thu, 17 Jun 2004 19:07:16 +0200. skrev Rasmus Bøg Hansen:

> Due some reason Keld Jørn Simonsen <keld@dkuug.dk> happened to write:
>
>>>> Det er vel OK at drivere kan bruge bios'en i forskellige tilfælde, det er
>>>> vel ikke noget som ændrer på strategien i min idé.
>>>
>>> Næh, men det hjælper jo ikke noget, når ingen bios'er har
>>> understøttelse for dine ideer?
>>
>> De fleste nyere bios'er har undestøttelse for S2. Og det er nok ikke alt
>> ACPI i kerne 2.6 der bruger bios'en. Kernen i min idé er at kunne slukke
>
> Men hvis BIOS'ens ACPI-implementation ikke beskriver, hvordan du
> slukker for CPU'en i S2, har du ingen chance for at kunne gøre det vha
> ACPI.

Nåh, jeg har skrevet om mine idéer til Len Brown, som er en af
hovedmændene bag Linux ACPI. Det kan da være du har ret.

>>> Du siger at du vil lade skærmen være tændt. Så kører grafikken jo
>>> også og du kan ikke slukke CPU'en.
>>
>> Hvorfor ikke? Grafikkredslæbet skal bare displaye hvad der er i
>> grafiklageret. Der er ingen ændringer som cpu'en skal lave.
>
> Sådan fungerer det ikke. GPU'en læser indholdet af grafikhukommelsen
> og konverterer dette til et VGA-signal (eller TV/DVI). GPU'en (eller i
> hvert fald dele af den) kører altså hele tiden, når du har signal på
> skærmen. Jeg tror ikke, du kan få GPU'en til at køre uden at kunne
> signalere CPU'en at de kører.

Det er muligt. Men jeg har været ude for at gå i suspend-to-ram (S3) og
så var skærmen alligevel tændt... Det var jo en fejl, men kendt.
Og skærmen viste det rigtige indhold. Så teknisk er det muligt at have
skærmen tændt og CPU'en slukket.

>>> clock (kan velsagtens slås fra, hvis man ved, hvorledes dette gøres
>>> på det enkelte bundkort), grafikkort (medmindre dette kan slukkes -
>>> men så slukker du formentlig også skærmen), USB, tastatur, mus,
>>> netkort, modem, lydkort. Nogle af disse enheder vil nok kunne
>>> deaktiveres i denne tilstand, men næppe alle. Og f. eks. musen er ret
>>> nem at komme til at skubbe til (nok ikke mindst i et fly, hvor der er
>>> så lidt plads).
>>
>> Hvis der sker noget på disse enheder, så må man betragte det som en
>> hændelse i ACPI forstand, som vækker systemet til live.
>
> Ja. Så skal du have implementeret i samtlige drivere, at der kan
> slukkes for CPU'en, så de holder op med at sende interrupts. Forudsat
> at de i hardwareimplementationen kan klare dette.

Njae, interrupts kan vel bare ignoreres. Det kan man tillade sig fordi man
véd at der ikke foregår noget. Eller man kan have slukket for næsten
alt, så mængden af interrupts er begrænset og kontrollerbart - dvs de
enkelte drivere der er i luften kan ændres til at tage hånd om disse
interrupts - hvilket i al væsentlighed vil sige bare at generere en
ACPI-hændelse der vækker CPU'en.

Hilsen
keld

---

On 2004-06-17, Keld Jørn Simonsen <keld@dkuug.dk> wrote:

> Det er muligt. Men jeg har været ude for at gå i suspend-to-ram (S3) og
> så var skærmen alligevel tændt... Det var jo en fejl, men kendt.
> Og skærmen viste det rigtige indhold. Så teknisk er det muligt at have
> skærmen tændt og CPU'en slukket.

Jeps. Men du kom aldrig ud af den suspend
Du kom heller ikke tilsigtet ind i den!

Jeg ved ikke. Måske kan du, men som sagt, så bliver det i bedste fald et
hack til kernen der passer til lige præcis din blærbare :-/

Thomas

---

Due some reason asjo@koldfront.dk (Adam Sjøgren) happened to write:

> On Thu, 17 Jun 2004 13:04:31 +0200, Rasmus wrote:
>
>>> Det kan godt være at der slides noget, men så kan det være at man
>>> kun sjældent har brug for denne specielle strømbesparende tilstand.
>>> Jeg har fx nok selv kun brug for den når jeg er ude at flyve.
>
>> Og der er 4 timers batteritid - som der er på de fleste moderne
>> bærbare - ikke nok?
>
> (Uden at vide noget som helst, eller tage stilling til, resten af
> diskussionen:) Nej, 4 timer er slet ikke nok.

Nå nej - nu ville jeg næppe sidde i et fly foran en computer hele
vejen. Hvis jeg endelig skulle have brug for det, havde jeg nok købt
et ekstra batteri. Der er jeg nok bare anderledes end andre :)

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
A computer without Windows, is like a fish without a bicycle.
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

On 2004-06-17, Rasmus Bøg Hansen <spam@amagerkollegiet.dk> wrote:

> Nå nej - nu ville jeg næppe sidde i et fly foran en computer hele
> vejen. Hvis jeg endelig skulle have brug for det, havde jeg nok købt
> et ekstra batteri. Der er jeg nok bare anderledes end andre :)

Saa er du ikke alene om at vaere anderledes

Thomas

---

Due some reason asjo@koldfront.dk (Adam Sjøgren) happened to write:

> Jo mere man skal slæbe rundt på, jo mindre tiltalende er en bærbar
> computer, synes jeg.

Enig.

> Og lige så snart batteriet er løbet tørt, så er _al_ vægten dødvægt
>

Dét er der noget om!

> Jeg synes en ordentlig batterilevetid ville være noget i stil med hvad
> mobiltelefoner efterhånden kan, et par dage.

Ja, det ville være rart (sagde jeg, der slet ikke har en bærbar).

Jeg tror nok, jeg fik misforstået mig selv ;)
Jeg tvivler også på, at Jørns ide vil give særlig meget ekstra
batteritid og at den ekstra smule næppe gør til eller fra i forhold
til lange flyveture. At jeg så ikke skrev det direkte, er vist min
fejl ;)

At jeg så nok ikke tager min computer med ud i naturen, er en anden
side - men helt så bogstaveligt skulle det næppe tages

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
Eat right, exercise regularly, die anyway.
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

Due some reason spam@amagerkollegiet.dk (Rasmus Bøg Hansen) happened to write:

> Jeg tvivler også på, at Jørns ide vil give særlig meget ekstra

Ups! Jeg mente selvfølgelig Keld (selvom Jørn også i en vis forstand
synes at være korrekt)

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
There is no insanity, just different perceptions of reality.
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

On Thu, 17 Jun 2004 13:04:31 +0200, Rasmus wrote:

>> Det kan godt være at der slides noget, men så kan det være at man
>> kun sjældent har brug for denne specielle strømbesparende tilstand.
>> Jeg har fx nok selv kun brug for den når jeg er ude at flyve.

> Og der er 4 timers batteritid - som der er på de fleste moderne
> bærbare - ikke nok?

(Uden at vide noget som helst, eller tage stilling til, resten af
diskussionen:) Nej, 4 timer er slet ikke nok.


Mvh.

--
"Thanks to my lobbying, Internet mail messages are now Adam Sjøgren
allowed to have 5-digit years." -djb asjo@koldfront.dk
"Thank you, Internet mail repair main!" -kas

---

Keld J?rn Simonsen <keld@dkuug.dk> wrote:

Du er jo en gammel raev i det her felt. Saa se nu hvad en ung raev synes
om de her ideer:

> 1. filsystemer: mulighed for sikker genfinding af slettede filer, design
> for ext3 foreligger som jeg har diskuteret med Dan T'so.

Det tror jeg ikke paa.

; ext3 betyder at det skal skubbes til kernen. Der vil du ikke have noget
der oeger kompleksiteten.

; CVS/Subversion/Arch/Darcs/RCS etc yder en ganske god beskyttelse mod
sletning og lader dig endvidere styre revisioner af det du har med at
goere. Det er overlegent i forhold til et 2-lags system som det du har
i tankerne.

; En generalisation er file-system snapshots. Det har FreeBSD 5.x og Net-
samt OpenBSD kunne nemt faa det ogsaa.

> 2. fordobling af batteritid (eller m?ske tredobling) for b?rbare med
> ACPI, ved at lukke helt ned for CPU.

Hvis saa bare at ACPI var noget man kunne stole paa naar man kodede
computere.

; ACPI er en standard med det formaal at de dovne udviklere kan skubbe
mere arbejde op i operativsystemet i stedet for at lave det i hardware.
Det er smart, fordi hardware er besvaerligt at lave aendringer i efter
det er sendt paa markedet (taenk flash-rom).

; ACPI skal som regel overrides, fordi udviklerne ikke kan finde ud af at
foelge standarden.

; ACPI er gaven til Microsoft, specielt hvis man kan faa sparket APM ud af
laptops.

; Stroemforbrug skal loeses af hardware. Pentium-M vil altid klare sig bedre
end andre CPU'er paa markedet i dag, uanset dine hacks i operativsystemet.

; Det er tvivlsomt hvor meget det vil hjaelpe saa vidt jeg kan se, hvis det
kan lade sig goere overhovedet.

> 3. forhindring af nogen bufferoverl?bsexploits ved at flytte allokering
> af funktionsdata til heapen.

Sindsygt. Det eneste rigtige at goere er en eller flere af foelgende:

; Map stakken non-executeable, map heapen non-executeable, map text-segmentet
non-writeable, osv. I OpenBSD hedder det W^X (Write XOR Execute). I Linux
hedder patches vistnok PAX. I windows kalder de det NX. Det er nemmere at
lave hvis man har en execute-bit per page i sin MMU, saa det har alle nyere
chips (amd64, intels kommende 64-bit arkitektur etc).

; Koer med propolice. Beskyt pointere paa stakken ved at ligge dem efter
allokerede buffere (arrays). Indsaet en canary i funktionsepilogen
foer $RA registeret med en random-value og check at denne er intakt i
funktionsprologen. Goer det meget svaerer at overskrive returadressen.

; Vaelg et ordentligt programmeringssprog der, hvis compileren ikke kan
garantere at der ikke sker bufferoverloeb, indsaetter et out-of-bounds
check. Der er masser af sprog at vaelge imellem og udvikling af standard
programmel i C er hjernedoedt alligevel. Selv Gnome-folkene er paa vej
vaek fra det (hint: det tager for lang tid at rette bugs i)

> 4. opbygning af gratis tr?dl?st meshnet, til global, sikker adgang

Den skal jeg ikke sige noget om. Det aner jeg intet om.

> 5. internettelefon

Hvordan loeser du QoS problemet?

> 6. spejlet raid med striping p? blot 2 fysiske diske.

Det faar man jo ikke noget ud af.

--
j.

---

Jesper Louis Andersen wrote:
>
> ; Vaelg et ordentligt programmeringssprog der, hvis compileren ikke kan
> garantere at der ikke sker bufferoverloeb, indsaetter et out-of-bounds
> check. Der er masser af sprog at vaelge imellem og udvikling af standard
> programmel i C er hjernedoedt alligevel. Selv Gnome-folkene er paa vej
> vaek fra det (hint: det tager for lang tid at rette bugs i)

Der er intet til hinder for at have index-tjekning i C. Jeg fatter ikke
helt hvorfor man ikke indfører det i GCC. Der har været uofficielle
pathes til GCC til det i næsten 10 år. (Se
http://web.inter.nl.net/hcc/Haj.Ten.Brugge/ for de nyeste versioner).

---

Byrial Jensen <bjensen@nospam.dk> wrote:

> Der er intet til hinder for at have index-tjekning i C. Jeg fatter ikke
> helt hvorfor man ikke indf?rer det i GCC. Der har v?ret uofficielle
> pathes til GCC til det i n?sten 10 ?r. (Se
> http://web.inter.nl.net/hcc/Haj.Ten.Brugge/ for de nyeste versioner).

Se, det goer jeg heller ikke. Problemet med C er i dette tilfaelde dog
nok naermere mangel paa garbage-collection og nogle mere effektive
primitive datatyper (saasom string, hehe).

--
j.

---

Den Thu, 17 Jun 2004 20:06:05 +0200 skrev Jesper Louis Andersen:
> Keld J?rn Simonsen <keld@dkuug.dk> wrote:
>
> ; Map stakken non-executeable, map heapen non-executeable, map text-segmentet
> non-writeable, osv. I OpenBSD hedder det W^X (Write XOR Execute). I Linux
> hedder patches vistnok PAX. I windows kalder de det NX. Det er nemmere at
> lave hvis man har en execute-bit per page i sin MMU, saa det har alle nyere
> chips (amd64, intels kommende 64-bit arkitektur etc).

Ikke helt korrekt. AMD kalder bit'en NX, og Intel har SVJH kopieret navnet
med da de kopierede bit'en. Windows bibeholder naturligvis navnet, men
da Linux og OpenBSD har haft funktionaliteten længe inden AMD og Intel
"opfandt" den (Sparc har haft den i årevis), har de naturligvis deres
eget navn til den.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis <nospam@nospam.invalid> wrote:
>
> Ikke helt korrekt. AMD kalder bit'en NX, og Intel har SVJH kopieret navnet
> med da de kopierede bit'en.

Ah.

Sparc, Alpha, HPPA og lignende ordentlige CPU-designs har haft det i mange
aar. Tricket er at man kun adresserer via eksempeltvist 42 bits og benytter
de overskydende bit til saadan nogle smaa krumspring som NX-bits, eller
hvad man nu kalder dem. Det vaesentlige er at man har en per page. Saa
bliver det nemlig nemt.

--
j.

---

Den Thu, 17 Jun 2004 20:06:05 +0200. skrev Jesper Louis Andersen:

> Keld J?rn Simonsen <keld@dkuug.dk> wrote:
>
> Du er jo en gammel raev i det her felt. Saa se nu hvad en ung raev synes
> om de her ideer:
>
>> 1. filsystemer: mulighed for sikker genfinding af slettede filer, design
>> for ext3 foreligger som jeg har diskuteret med Ted T'so.
>
> Det tror jeg ikke paa.

Nåh, jeg kan da fremsende det jeg har skrevet sammen.
Se http://www.dkuug.dk/keld/lazy3.txt
Ted mente det nok kunne lade sig gøre.


> ; ext3 betyder at det skal skubbes til kernen. Der vil du ikke have noget
> der oeger kompleksiteten.

Ja, det er vel ikke ligetil. Men hvis flere siger god for det kan man da
nok få noget ind. Der er så vidt jeg kan se ikke så meget der skal
skrives. Måske 50 linjer.

> ; CVS/Subversion/Arch/Darcs/RCS etc yder en ganske god beskyttelse mod
> sletning og lader dig endvidere styre revisioner af det du har med at
> goere. Det er overlegent i forhold til et 2-lags system som det du har
> i tankerne.

Jeg tror det er forskellige ting der opnås.

> ; En generalisation er file-system snapshots. Det har FreeBSD 5.x og
> Net-
> samt OpenBSD kunne nemt faa det ogsaa.

Jeg mener at mine idéer også nemt kan overføres til andre filsystemer
end ext3. Men nu mødte jeg Ted og snakkede med ham, og det var et ext3
filsystem jeg havde fået ødelagt, ved en mkfs på en forkert partition


>> 2. fordobling af batteritid (eller m?ske tredobling) for b?rbare med
>> ACPI, ved at lukke helt ned for CPU.
>
> ; Stroemforbrug skal loeses af hardware. Pentium-M vil altid klare sig
> bedre
> end andre CPU'er paa markedet i dag, uanset dine hacks i
> operativsystemet.

Jeg synes det er rart at man kan styre hvilke enheder man slukker for.
De bios'er jeg har set har været begrænset i fleksibiliteten.

> ; Det er tvivlsomt hvor meget det vil hjaelpe saa vidt jeg kan se, hvis
> det
> kan lade sig goere overhovedet.

Dobbelt op på batteritid synes jeg er OK

>> 3. forhindring af nogen bufferoverl?bsexploits ved at flytte allokering
>> af funktionsdata til heapen.
>
> Sindsygt. Det eneste rigtige at goere er en eller flere af foelgende:
>
> ; Map stakken non-executeable, map heapen non-executeable, map
> text-segmentet
> non-writeable, osv. I OpenBSD hedder det W^X (Write XOR Execute). I
> Linux hedder patches vistnok PAX. I windows kalder de det NX. Det er
> nemmere at lave hvis man har en execute-bit per page i sin MMU, saa
> det har alle nyere chips (amd64, intels kommende 64-bit arkitektur
> etc).

Ja, W^X er også fint, og man kan vel kombinere tingene.

> ; Koer med propolice. Beskyt pointere paa stakken ved at ligge dem efter
> allokerede buffere (arrays). Indsaet en canary i funktionsepilogen
> foer $RA registeret med en random-value og check at denne er intakt i
> funktionsprologen. Goer det meget svaerer at overskrive returadressen.

Ja, også en kendt teknologi. Men det beskytter ikke mod at overskrive
stakken, det gør mit forslag.

> ; Vaelg et ordentligt programmeringssprog der, hvis compileren ikke kan
> garantere at der ikke sker bufferoverloeb, indsaetter et out-of-bounds
> check. Der er masser af sprog at vaelge imellem og udvikling af
> standard programmel i C er hjernedoedt alligevel. Selv Gnome-folkene
> er paa vej vaek fra det (hint: det tager for lang tid at rette bugs i)

Kan ikke lade sig gøre i praksis. Jeg taler om at indbygge dette i
compilerne, fx gcc og så genoversætte hele distroen - alle pakker.
Jeg anser det for umuligt at omskrive alle pakker der er skervet i C eller
C++ til et andet programmeringssprog.

>> 5. internettelefon
>
> Hvordan loeser du QoS problemet?

Véd det ikke,

>> 6. spejlet raid med striping p? blot 2 fysiske diske.
>
> Det faar man jo ikke noget ud af.

Joda, dobbelt hastighed ved sekventiel læsning ifht raid-1.
Se http://www.dkuug.dk/keld/stripemirror.txt

Hilsen
keld

---

Keld J?rn Simonsen <keld@dkuug.dk> wrote:

>> ; ext3 betyder at det skal skubbes til kernen. Der vil du ikke have noget
>> der oeger kompleksiteten.
>
> Ja, det er vel ikke ligetil. Men hvis flere siger god for det kan man da
> nok f? noget ind. Der er s? vidt jeg kan se ikke s? meget der skal
> skrives. M?ske 50 linjer.

Fordi mange mennesker siger god for noget er det ikke noedvendigvis godt.
Jeg kan ikke se hvad det konkret skal benyttes til ud over hvis man har
skudt sig selv i foden.

> Jeg mener at mine id?er ogs? nemt kan overf?res til andre filsystemer
> end ext3. Men nu m?dte jeg Ted og snakkede med ham, og det var et ext3
> filsystem jeg havde f?et ?delagt, ved en mkfs p? en forkert partition
>

Det er saa der man har backups. Det at lave noget der kan redde det,
hvor rart det end er, lyder paa mig som en lappeloesning for dem der
ikke har styr paa et ordentligt backup-system.

> Jeg synes det er rart at man kan styre hvilke enheder man slukker for.
> De bios'er jeg har set har v?ret begr?nset i fleksibiliteten.

BIOS er ikke nogen koen ting. Det har det stort set aldrig vaeret. Det
jeg ikke kan lide er at ACPI standarden er stor, kedelig og utilgaengelig.
Det kunne have vaeret lavet meget simplere og meget smartere med mindre
hovedpine for programmoererne.

Og ioevrigt lader det til at det ikke er teknisk muligt at goere det du
foreslaar.

> Dobbelt op p? batteritid synes jeg er OK

Er du sikker paa at du kan faa det i praksis? En del enheder kraever
CPUens vaagen over dem for ikke at ryge i en kedelig tilstand.

[Propolice]
>
> Ja, ogs? en kendt teknologi. Men det beskytter ikke mod at overskrive
> stakken, det g?r mit forslag.

Jeg antager at det du vil er at flytte arrays af data til hoben i stedet
for at have dem paa stakken. Vi kan yderligere antage at malloc() ikke
indeholder fejl. Overheadet for allokation paa stakken er en operation,
der alligevel skal udfoeres, nemlig en manipulation af en stakpeger.

Skal det allokeres paa hoben skal vi foerst have plads til det. At kalde
malloc() kan loese det problem, men saa snakker vi potentielt om mange
instruktioner, saa det er naeppe en smart loesning, fordi funktionen
potentielt set kan kaldes mange gange i loebet af et programs udfoersel.

Vi kunne ogsaa oprette et scratch-areal vi benytter til at allokere arrays
i. Det har nogenlunde den samme cache-locality som at allokere paa stakken
og vi render derfor ikke ind i cache-miss performanceproblemer samtidig med
at vi ikke laengere kan overskrive data paa stakken. Da det kun giver
mening at vi ikke ogsaa maa kunne overskrive andre arrays, maa vi guarde
hvert array vi har med en non-executeable page foer og efter vores array.
Vi ender igen med betragteligt flere operationer end en stakpegermanipulation.

Og hvorfor er det saa at det er ligegyldigt?

; Det er udefineret hvad der sker naar vi laver noget out-of-bounds. Saa
hvis vi overskriver store dele af stakken og roder videre i vores
funktion, saa vil vi potentielt set have et program der kan goere
hvad som helst. Loesningen med guard-pages ville naturligvis fange
mange problemer af denne type naar de opstaar og vi vil kunne fylde
noget volapyk af data til en fil/database whatever.

Dette er dog forudsat at vi ikke laver nogen form for validering af
de data vi faar. Det problem er logisk og det kan vi ikke loese ved
smarte compilertricks.

Det vi godt vil have er at en angriber ikke kan komme til at udfoere
kode paa maskinen, og det kan han ikke med propolice, overskrevet stak
eller ej.

Konklusion: En angriber kan lave sabotage hvis funktionen og
programmet er skrevet dumt, men vil aldrig kunne overtage maskinen.
Givet at vi godt vil beskytte os selv mod sabotage af data saa kan det
vaere et udmaerket forslag, men konsekvenserne er langt mindre og jeg
mener ikke at der er grund til at goere noget ved det.

>> ; Vaelg et ordentligt programmeringssprog der, hvis compileren ikke kan
>> garantere at der ikke sker bufferoverloeb, indsaetter et out-of-bounds
>> check. Der er masser af sprog at vaelge imellem og udvikling af
>> standard programmel i C er hjernedoedt alligevel. Selv Gnome-folkene
>> er paa vej vaek fra det (hint: det tager for lang tid at rette bugs i)
>
> Kan ikke lade sig g?re i praksis. Jeg taler om at indbygge dette i
> compilerne, fx gcc og s? genovers?tte hele distroen - alle pakker.
> Jeg anser det for umuligt at omskrive alle pakker der er skervet i C eller
> C++ til et andet programmeringssprog.

Du kan sagtens checke out-of-bounds paa C-programmer. Og i praksis
lader det til at faerre og faerre programmer skrives i C++ eller C,
men at der i stedet anvendes mere fornuftige vaerktoejer.

>>> 6. spejlet raid med striping p? blot 2 fysiske diske.
>>
>> Det faar man jo ikke noget ud af.
>
> Joda, dobbelt hastighed ved sekventiel l?sning ifht raid-1.
> Se http://www.dkuug.dk/keld/stripemirror.txt

Og en rigtig uheldig situation naar den ene disk staar af. Da vil
dine laesninger ligge med praecist en halv disks afstand til
hinanden og med 8ms gennemsnitssoegetid saa bliver performance
ret daarling. Endvidere slider det temmeligt meget paa disken og
min erfaring siger mig at hvis den ene disk i et mirror staar af,
saa goer den anden ogsaa ret hurtigt derefter. At belaste disken
paa den maade er set med det lys i oejnene nok ikke saa smart.

Resten af det med at opbygge et saadant mirror lader dog til at
kunne lade sig goere. Maaske det er en opgave for noget LVM?

--
j.

---

Den Fri, 18 Jun 2004 01:59:52 +0200. skrev Jesper Louis Andersen:

> Keld J?rn Simonsen <keld@dkuug.dk> wrote:
>
>>> ; ext3 betyder at det skal skubbes til kernen. Der vil du ikke have noget
>>> der oeger kompleksiteten.
>>
>> Ja, det er vel ikke ligetil. Men hvis flere siger god for det kan man da
>> nok f? noget ind. Der er s? vidt jeg kan se ikke s? meget der skal
>> skrives. M?ske 50 linjer.
>
> Fordi mange mennesker siger god for noget er det ikke noedvendigvis godt.
> Jeg kan ikke se hvad det konkret skal benyttes til ud over hvis man har
> skudt sig selv i foden.

Det med at skyde sig selv i foden, ja, det er altså sket for mig nogen
gange. Og også for andre.

> Og ioevrigt lader det til at det ikke er teknisk muligt at goere det du
> foreslaar.

Jeg véd det ikke endnu. Men Len Brown siger det allerede er lavet, og der
var også en anden her i NG der skrev noget tilsvarende (med en
idle tid på var det 333 msek). Jeg vil se om det virker.

> [Propolice]
>>
>> Ja, ogs? en kendt teknologi. Men det beskytter ikke mod at overskrive
>> stakken, det g?r mit forslag.
>
> Jeg antager at det du vil er at flytte arrays af data til hoben i stedet
> for at have dem paa stakken. Vi kan yderligere antage at malloc() ikke
> indeholder fejl. Overheadet for allokation paa stakken er en operation,
> der alligevel skal udfoeres, nemlig en manipulation af en stakpeger.
>
> Skal det allokeres paa hoben skal vi foerst have plads til det. At kalde
> malloc() kan loese det problem, men saa snakker vi potentielt om mange
> instruktioner, saa det er naeppe en smart loesning, fordi funktionen
> potentielt set kan kaldes mange gange i loebet af et programs udfoersel.

Der skal også malloc'es på stakken. Det er ca lige mange mallocs. Men
det er rigtigt at det giver lidt ekstra overhead. I stedet for kun at
allokere på stakken, skal der allokeres både på stakken og på heapen.
Men så får man også noget mere sikkerhed ud af det. Og man kan måske
undlade nogen checks med canaries, etc.

> Vi kunne ogsaa oprette et scratch-areal vi benytter til at allokere
> arrays i. Det har nogenlunde den samme cache-locality som at allokere
> paa stakken og vi render derfor ikke ind i cache-miss
> performanceproblemer samtidig med at vi ikke laengere kan overskrive
> data paa stakken. Da det kun giver mening at vi ikke ogsaa maa kunne
> overskrive andre arrays, maa vi guarde hvert array vi har med en
> non-executeable page foer og efter vores array. Vi ender igen med
> betragteligt flere operationer end en stakpegermanipulation.

Det er vel ca det samme som at allokere på stakken eller heapen,
performancemæssigt.

> Og hvorfor er det saa at det er ligegyldigt?
>
> ; Det er udefineret hvad der sker naar vi laver noget out-of-bounds. Saa
> hvis vi overskriver store dele af stakken og roder videre i vores
> funktion, saa vil vi potentielt set have et program der kan goere hvad
> som helst. Loesningen med guard-pages ville naturligvis fange mange
> problemer af denne type naar de opstaar og vi vil kunne fylde noget
> volapyk af data til en fil/database whatever.
>
> Dette er dog forudsat at vi ikke laver nogen form for validering af de
> data vi faar. Det problem er logisk og det kan vi ikke loese ved
> smarte compilertricks.

Ja, den bedste løsning er selvfølgelig at rette alle fejl. Men det er
nok uoverkommeligt.

> Det vi godt vil have er at en angriber ikke kan komme til at udfoere
> kode paa maskinen, og det kan han ikke med propolice, overskrevet stak
> eller ej.
>
> Konklusion: En angriber kan lave sabotage hvis funktionen og
> programmet er skrevet dumt, men vil aldrig kunne overtage maskinen.
> Givet at vi godt vil beskytte os selv mod sabotage af data saa kan det
> vaere et udmaerket forslag, men konsekvenserne er langt mindre og jeg
> mener ikke at der er grund til at goere noget ved det.

Det kan godt være at propolice, stackguard mm løser det samme problem,
og mit forslag ikke giver noget ekstra. Jeg tror dog der er noget i det.

>>> ; Vaelg et ordentligt programmeringssprog der, hvis compileren ikke
>>> kan
>>> garantere at der ikke sker bufferoverloeb, indsaetter et
>>> out-of-bounds check. Der er masser af sprog at vaelge imellem og
>>> udvikling af standard programmel i C er hjernedoedt alligevel. Selv
>>> Gnome-folkene er paa vej vaek fra det (hint: det tager for lang tid
>>> at rette bugs i)
>>
>> Kan ikke lade sig g?re i praksis. Jeg taler om at indbygge dette i
>> compilerne, fx gcc og s? genovers?tte hele distroen - alle pakker. Jeg
>> anser det for umuligt at omskrive alle pakker der er skervet i C eller
>> C++ til et andet programmeringssprog.
>
> Du kan sagtens checke out-of-bounds paa C-programmer. Og i praksis lader
> det til at faerre og faerre programmer skrives i C++ eller C, men at der
> i stedet anvendes mere fornuftige vaerktoejer.

Det kan være du har ret med nyskrivning, men der er en hulens masse kode
i Linux der allerede er skrevet i C/C++. og som kører basale funktioner i
systemet.


>>>> 6. spejlet raid med striping p? blot 2 fysiske diske.
>>>
>>> Det faar man jo ikke noget ud af.
>>
>> Joda, dobbelt hastighed ved sekventiel l?sning ifht raid-1. Se
>> http://www.dkuug.dk/keld/stripemirror.txt
>
> Og en rigtig uheldig situation naar den ene disk staar af. Da vil dine
> laesninger ligge med praecist en halv disks afstand til hinanden og med
> 8ms gennemsnitssoegetid saa bliver performance ret daarling. Endvidere
> slider det temmeligt meget paa disken og min erfaring siger mig at hvis
> den ene disk i et mirror staar af, saa goer den anden ogsaa ret hurtigt
> derefter. At belaste disken paa den maade er set med det lys i oejnene
> nok ikke saa smart.

Ja, performance bliver dårlig hvis den ene disk går ned.
men så må man få ordnet dette. Sliddet er vel kun hvis den ene disk er
stået af? Det er altså en undtagelsessituation.

> Resten af det med at opbygge et saadant mirror lader dog til at kunne
> lade sig goere. Maaske det er en opgave for noget LVM?

Neil Brown - RAID ankermand - har lavet lidt kode på det, han ser det som
en ny personality i RAID. Koden er ikke færdig.

Jeg bemærker at en del af folkene i denne tråd ikke bruger danske
bogstaver som æøå. Er det fordi jeg har fat i
programmører/systemprogrammører?

Hilsen
keld

---

On 2004-06-18, Keld Jørn Simonsen <keld@dkuug.dk> wrote:

> Jeg véd det ikke endnu. Men Len Brown siger det allerede er lavet, og der
> var også en anden her i NG der skrev noget tilsvarende (med en
> idle tid på var det 333 msek). Jeg vil se om det virker.

Har du et link?

> Jeg bemærker at en del af folkene i denne tråd ikke bruger danske
> bogstaver som æøå. Er det fordi jeg har fat i
> programmører/systemprogrammører?

For mit vedkommende afhænger det af den forbindelse jeg sidder på. Om den er
sat op til æøå eller ej.

Thomas

---

Den Fri, 18 Jun 2004 11:04:44 +0000. skrev Thomas S. Iversen:

> On 2004-06-18, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>
>> Jeg véd det ikke endnu. Men Len Brown siger det allerede er lavet, og der
>> var også en anden her i NG der skrev noget tilsvarende (med en
>> idle tid på var det 333 msek). Jeg vil se om det virker.
>
> Har du et link?

Det var Christian Iversen der skrev noget om det. Jeg har lige citeret
den, det kan være ham mente noget andet med det.

Len Brown: det var privat email, og jeg har spurgt ham yderligere
om hvordan. Og så har jeg downloaded kerne 2.6.7...

Hilsen
keld

---

On 2004-06-18, Keld Jørn Simonsen <keld@dkuug.dk> wrote:

> Len Brown: det var privat email, og jeg har spurgt ham yderligere
> om hvordan. Og så har jeg downloaded kerne 2.6.7...

Hmm, interessant hvis Len Brown har lavet support for at slukke for alt
andet end gfx chippen. Jeg har ikke støt på det endnu, og tror først på det
når jeg ser det

Thomas

---

Den Fri, 18 Jun 2004 14:08:12 +0000. skrev Thomas S. Iversen:

> On 2004-06-18, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>
>> Len Brown: det var privat email, og jeg har spurgt ham yderligere
>> om hvordan. Og så har jeg downloaded kerne 2.6.7...
>
> Hmm, interessant hvis Len Brown har lavet support for at slukke for alt
> andet end gfx chippen. Jeg har ikke støt på det endnu, og tror først på det
> når jeg ser det

Jeg véd ikke om det er Len Brown der lavet det, men han er da en af dem
der indleverer ACPI rettelser til Linux.

Men der er jo en strømbesparende tilstand der hedder throttling, som
betyder at man helt slukker for cpu-en for at spare på strømmen. Mens
resten af maskinen er tændt. Så det kan da lade sig gøre, så vidt jeg
kan forstå.

Hilsen
Keld

---

On 2004-06-18, Keld Jørn Simonsen <keld@dkuug.dk> wrote:

> Men der er jo en strømbesparende tilstand der hedder throttling, som

Er de ikke cpufreq modulet du tænker på? Altså at du kan ændre på den
frekvens og spænding cpuen kører med og derved opnå ret lavt strømrforbrug?

Der er f.eks. en P3-tualatin der kan bringes til at sluge 2W ved 300Mhz og
så kan den selvfølgelig bringes til at køre sine normale 1200Mhz hvis der er
behov for det.

~2 W (0.13 µm @ 300 MHz 512 KB L2 @ 0.95V)

sandpile.org/impl/p3.htm

Thomas

---

Den Fri, 18 Jun 2004 21:07:40 +0000. skrev Thomas S. Iversen:

> On 2004-06-18, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>
>> Men der er jo en strømbesparende tilstand der hedder throttling, som
>
> Er de ikke cpufreq modulet du tænker på? Altså at du kan ændre på den
> frekvens og spænding cpuen kører med og derved opnå ret lavt strømrforbrug?

Nej, cpufreq og throttling er noget forskelligt.
cpufreq regulerer frekvensen, throttling stopper cpuen.

hilsen
keld

---

On 2004-06-18, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
> Den Fri, 18 Jun 2004 21:07:40 +0000. skrev Thomas S. Iversen:
>
>> On 2004-06-18, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>>
>>> Men der er jo en strømbesparende tilstand der hedder throttling, som
>>
>> Er de ikke cpufreq modulet du tænker på? Altså at du kan ændre på den
>> frekvens og spænding cpuen kører med og derved opnå ret lavt strømrforbrug?
>
> Nej, cpufreq og throttling er noget forskelligt.
> cpufreq regulerer frekvensen, throttling stopper cpuen.

http://acpi.sourceforge.net/documentation/processor.html

Du kan jo prøve:

cat /proc/acpi/processor/CPU0/throttling

for at se hvad din processer kan throttles til

Hvis der er en der hedder 100%, så bremses cpuen 100%. Læg mærke til
hvilken state det foregår i. Skriv derefter

echo -n "nummer" > /proc/acpi/processor/CPU0/throttling.

Held og lykke.

Thomas

---

Keld J?rn Simonsen <keld@dkuug.dk> wrote:

> Der skal ogs? malloc'es p? stakken. Det er ca lige mange mallocs. Men
> det er rigtigt at det giver lidt ekstra overhead. I stedet for kun at
> allokere p? stakken, skal der allokeres b?de p? stakken og p? heapen.
> Men s? f?r man ogs? noget mere sikkerhed ud af det. Og man kan m?ske
> undlade nogen checks med canaries, etc.

Nej! Det der er det fede ved en stak er netop at allokering af plads er
hamrende hurtigt. Du skal bare flytte en stakpeger. Det er alt. En
allokering via hoben kraever et kald til malloc(), der igen kan risikere
at lave systemkald (sbrk(), mmap()). Der er saa ogsaa nogen problemer med
allokering paa en stak. Naar funktionen returnerer bliver den allokerede
plads fjernet. Det betyder at hvis data skal kunne returneres og er
mere avanceret end hvad der kan repraesenteres i nogle returvaerdier,
saa skal det ned i hoben. Man vil gerne undgaa allokering paa hoben saa
vidt muligt.

Det er ioevrigt ogsaa derfor at garbage collection kan goeres hurtigt.
Er det lavet rigtigt, saa er det som regel ogsaa bare et flyt af en pointer
for at allokere plads.

Det er praecis 1 stakpegerflyt, fordi compileren kan lave noget akkumulation
af den plads der er behov for. Hvis du i din loesning laver det samme, saa
opnaar du ikke den sikkerhed som din loesning kan give ud over hvad propolice
giver. Du skal lave 1 malloc() (eller lignende) + n+1 mprotect() kald hvor
n er antallet af arrays. Saa vidt jeg kan se.

mht canaries, saa kan du undgaa dem. Men det er ikke sikkert at der er saa
meget at vinde. I din loesning vil du pludselig have en stakpeger og en
peger ned hoben. Paa en elendig arkitektur som x86 har du ikke lyst til
at spilde et register med det. Det betyder potentielt spill af registre
og saa bliver det foerst rigtigt dyrt. Propolice koster vist omkring 3%.
Det er overkommeligt.

[Scratch areal]

Well, der skal ogsaa allokeres i scratch-arealet, men du undgaar et kald til
malloc(), og det vil du gerne. Der er eksempeltvist grunde til at man siger
til programoerrer at de skal holde sig fra at allokere for meget med malloc()
new, eller lignende.

> Det kan godt v?re at propolice, stackguard mm l?ser det samme problem,
> og mit forslag ikke giver noget ekstra. Jeg tror dog der er noget i det.

Som jeg saa det kan du med din loesning garantere at at et overloeb i et array
ikke loeber over i et andet array og fylder det med junk. Givet at du
smider guardpages udenom. Hvis du ikke smider guardpages udenom, saa
aabner du i den grad muligheden for et heap-overflow. Og saa har du ikke
vundet noget.

> Ja, performance bliver d?rlig hvis den ene disk g?r ned.
> men s? m? man f? ordnet dette. Sliddet er vel kun hvis den ene disk er
> st?et af? Det er alts? en undtagelsessituation.

Jeg argumenterer for at du i den situation helst ikke vil have oeget slid
paa den aden disk. det er en undtagelse ja, hvor du gerne vil have
gendannet disken saa hurtigt som muligt. Jeg er bare kynisk og siger at
det altid er nemesis der kommer forbi naar den ene disk er staaet af og den
anden udsaettes for oeget slid.

> Neil Brown - RAID ankermand - har lavet lidt kode p? det, han ser det som
> en ny personality i RAID. Koden er ikke f?rdig.

Jeg er ikke sikker, men mon ikke du handler noget random-read performance
for det? Den eneste fornuftige queueing algoritme jeg kunne finde kan
hypotetisk set hyles ud af den.

> Jeg bem?rker at en del af folkene i denne tr?d ikke bruger danske
> bogstaver som ???. Er det fordi jeg har fat i
> programm?rer/systemprogramm?rer?

Jeg er medlem af foreningen mod unicode... Nej, det er fordi jeg skriver
med dvorak-tastatur og skriver mere engelsk end dansk og programmerer
mere paa engelsk, saa det er en fordel for mig at have et tastatur der
goer det nemmere. Og nej, jeg gider ikke at skifte ;)

--
j.

---

Den Fri, 18 Jun 2004 17:11:30 +0200. skrev Jesper Louis Andersen:

> Keld J?rn Simonsen <keld@dkuug.dk> wrote:
>
>> Der skal ogs? malloc'es p? stakken. Det er ca lige mange mallocs. Men
>> det er rigtigt at det giver lidt ekstra overhead. I stedet for kun at
>> allokere p? stakken, skal der allokeres b?de p? stakken og p? heapen.
>> Men s? f?r man ogs? noget mere sikkerhed ud af det. Og man kan m?ske
>> undlade nogen checks med canaries, etc.
>
> Nej! Det der er det fede ved en stak er netop at allokering af plads er
> hamrende hurtigt. Du skal bare flytte en stakpeger. Det er alt. En
> allokering via hoben kraever et kald til malloc(), der igen kan risikere
> at lave systemkald (sbrk(), mmap()). Der er saa ogsaa nogen problemer med
> allokering paa en stak. Naar funktionen returnerer bliver den allokerede
> plads fjernet. Det betyder at hvis data skal kunne returneres og er
> mere avanceret end hvad der kan repraesenteres i nogle returvaerdier,
> saa skal det ned i hoben. Man vil gerne undgaa allokering paa hoben saa
> vidt muligt.

Du kan vel også risikere at der ikke er plads på stakken. Men det kan
vel så løses ved et page interrupt, hvilket vel er det samme som du
laver når malloc løber tør for plads. Jeg har også tænkt på at der
kunne være 2 stakke, men det er der vel arkitekturer der ikke
understøter.

> Det er ioevrigt ogsaa derfor at garbage collection kan goeres hurtigt.
> Er det lavet rigtigt, saa er det som regel ogsaa bare et flyt af en
> pointer for at allokere plads.

Lyder underligt iflg hvad jeg har lært. Det er vel forskelligt hvad der
slettes og skal frigives, så man kan da ikke bare klare oprydning med at
flytte en peger.


>> Det kan godt v?re at propolice, stackguard mm l?ser det samme problem,
>> og mit forslag ikke giver noget ekstra. Jeg tror dog der er noget i
>> det.
>
> Som jeg saa det kan du med din loesning garantere at at et overloeb i et
> array ikke loeber over i et andet array og fylder det med junk. Givet at
> du smider guardpages udenom. Hvis du ikke smider guardpages udenom, saa
> aabner du i den grad muligheden for et heap-overflow. Og saa har du ikke
> vundet noget.

Idéen var at indtrængeren aldrig kunne komme til at få kontrollen over
maskinen, fordi han ikke kunne komme til at ødelægge funktionspegere på
stakken.

>> Ja, performance bliver d?rlig hvis den ene disk g?r ned. men s? m? man
>> f? ordnet dette. Sliddet er vel kun hvis den ene disk er st?et af? Det
>> er alts? en undtagelsessituation.
>
> Jeg argumenterer for at du i den situation helst ikke vil have oeget
> slid paa den aden disk. det er en undtagelse ja, hvor du gerne vil have
> gendannet disken saa hurtigt som muligt. Jeg er bare kynisk og siger at
> det altid er nemesis der kommer forbi naar den ene disk er staaet af og
> den anden udsaettes for oeget slid.

Ideen var mest beregnet til billig raid, hvor du kan få øget sikkerhed
og ydelse af blot at have 2 diske. Typisk en hjemme-pc. Der er sliddet
ikke stort (ud fra egne erfaringer).


>> Neil Brown - RAID ankermand - har lavet lidt kode p? det, han ser det
>> som en ny personality i RAID. Koden er ikke f?rdig.
>
> Jeg er ikke sikker, men mon ikke du handler noget random-read
> performance for det? Den eneste fornuftige queueing algoritme jeg kunne
> finde kan hypotetisk set hyles ud af den.

Du kan vel både have striping og random read. Men striping er godt til
sekventiel læsning, og meget almidelig aktivitet er sekventiel læsning.

Hilsen
keld

---

Jesper Louis Andersen wrote:

> Nej! Det der er det fede ved en stak er netop at allokering af plads er
> hamrende hurtigt. Du skal bare flytte en stakpeger. Det er alt. En
> allokering via hoben kraever et kald til malloc(), der igen kan risikere
> at lave systemkald (sbrk(), mmap()). Der er saa ogsaa nogen problemer med
> allokering paa en stak. Naar funktionen returnerer bliver den allokerede
> plads fjernet. Det betyder at hvis data skal kunne returneres og er
> mere avanceret end hvad der kan repraesenteres i nogle returvaerdier,
> saa skal det ned i hoben. Man vil gerne undgaa allokering paa hoben saa
> vidt muligt.

Som jeg forstår det vil Keld undgå at blande returadresser og øvrige
data på samme stak for at forhindre at eventuelle bufferoverløb kan
overskrive returadresser.

I så fald er det vel bedst at have 2 stakke i steden for én: 1 til
returadresser, og 1 til returværdier, funktionsargumenter, automatiske
variable og alloca()-allokeringer.

Prisen vil i bedste fald være at 2 registre skal afsættes til
stakoperationer i steden for kun 1, hvor det 2. register på nogle
arkitekturer vil have dårligere hardware-understøttelse end det første
register.

Men jeg synes at det ville smartere at bruge krafterne og resurserne på
at undgå bufferoverløb ved at bruge C- og C++-implementationer med
indeks-tjekning ved brug af arrays og pointere.

---

Jesper Louis Andersen <jlouis@miracle.mongers.org> writes:

>> Jeg bem?rker at en del af folkene i denne tr?d ikke bruger danske
>> bogstaver som ???. Er det fordi jeg har fat i
>> programm?rer/systemprogramm?rer?
>
> Jeg er medlem af foreningen mod unicode... Nej, det er fordi jeg
> skriver med dvorak-tastatur og skriver mere engelsk end dansk og
> programmerer mere paa engelsk, saa det er en fordel for mig at have
> et tastatur der goer det nemmere. Og nej, jeg gider ikke at skifte
> ;)

Fint nok, men kunne du i det mindste ikke lade være med at smadre
danske tegn i den tekst du citerer? ae aa oe osv. generer mig ikke,
men det er ret irriterende at æøå bliver erstattet med ? når du
citerer.

--
Jesper Harder <http://purl.org/harder/>

---

On Thu, 17 Jun 2004 19:08:56 +0200, Rasmus wrote:

>> Nej, 4 timer er slet ikke nok.

> Nå nej - nu ville jeg næppe sidde i et fly foran en computer hele
> vejen.

Jeg kan sagtens finde på andre situationer hvor det ville være rart
med batteri på computeren i lang tid - hvis man er ude i naturen langt
væk fra stik-kontakter f.eks.

(Jeg forestiller mig ikke at man sætter sig i grøftekanten i otte
timer i træk, men en time her, en time der, i løbet af nogle dage hvor
man ikke har adgang til strøm).

> Hvis jeg endelig skulle have brug for det, havde jeg nok købt et
> ekstra batteri. Der er jeg nok bare anderledes end andre :)

Jo mere man skal slæbe rundt på, jo mindre tiltalende er en bærbar
computer, synes jeg.

Og lige så snart batteriet er løbet tørt, så er _al_ vægten dødvægt


Jeg synes en ordentlig batterilevetid ville være noget i stil med hvad
mobiltelefoner efterhånden kan, et par dage.


Nå, det var vist et sidespor, og bare en kæphest.


Mvh.

--
"Alla sammanträffande med verkligheten är helt Adam Sjøgren
slumpmässiga, alla melodier är påhittade." asjo@koldfront.dk

---

On 2004-06-18, Adam Sjøgren <asjo@koldfront.dk> wrote:

> Jeg kan sagtens finde på andre situationer hvor det ville være rart
> med batteri på computeren i lang tid - hvis man er ude i naturen langt
> væk fra stik-kontakter f.eks.

Hvis du aligevel er ude i det store blå rum(tm) så nyd udsigten

> Jo mere man skal slæbe rundt på, jo mindre tiltalende er en bærbar
> computer, synes jeg.

Jeg kan ikke være mere enig. Problemet er bare, at der ikke
er nogle evolutionære løsninger på længden af batterilevetid en bærbar har.
Vi skal over i noget radikalt nyt. Og det nytter ikke at begrænse
strømforbruget i en selvstændig komponent. Hvis det var tilfældet var
transmeta for længst blevet rigtig mange penge værd. Det er de ikke.

Vi snakker brændselsceller eller noget nyere før vi kan blive rigtig bærbare


> Jeg synes en ordentlig batterilevetid ville være noget i stil med hvad
> mobiltelefoner efterhånden kan, et par dage.

Personligt kunne jeg godt leve med en langsom cpu, masser af ram, ingen
disk, boot fra cf og så et sort hvidt LCD display. Det burde kunne give
noget, men der er ikke marked for sådanne computere

> Nå, det var vist et sidespor, og bare en kæphest.

Det var mit vist også.

Thomas

---

Hejsa

Lige den dumme kommentar til alt det strømspareri.

Hvad med Solceller, en lille vindmølle man kan puste til, det der
rysteenergi (kinesisk eller kinetisk) eller ligesom ham den levende
computer, der trak strøm fra sig selv?

Mvh Leif

---

Den Mon, 05 Jul 2004 21:12:32 +0200. skrev Leif Poulsen:

> Hvad med Solceller, en lille vindmølle man kan puste til, det der
> rysteenergi (kinesisk eller kinetisk) eller ligesom ham den levende
> computer, der trak strøm fra sig selv?

Ja, det har jeg overvejet, og det nærmeste jeg har fundet er en lille
håndgenerator, der når man klemmer på den (ud og ind) skulle kunne
generere op mod 7 W. Det bør være nok til at holde systemet i luften!
- givet de andre strømbesparelsesidéer kan implementeres.

Jeg er gået i luften med en præmie på 1000 USD til den der kan lave en
implementation af min idé med strømbesparelse - som kører på min
maskine. Annonceret på ACPI-devel listen. Nogen mener det ikke kan lade
sig gøre hardwaremæssigt. Men jeg har ikke givet op endnu.

Hilsen
keld