Svenska ElektronikForumet

Nerre skrev:Med tcp/ip måste datat delas upp i paket så det ryms inom MTU, så där behöver man nog kunna dividera.

Intressant att du ändå säger "nog"

MVH/Roger

Det verkar alltså som om man tom kan koppla upp sig mot internet utan MUL/DIV.

Jag tänker då på nån primitiv uppkoppling (utan https som tydligen innebär krypteringsberäkningar för att hålla det säkert).

Men om vi backar lite.

Hur uppstod internet?

Såvitt jag kan förstå så var det typ ett universitet som tyckte att "vi borde dela på den här informationen".

Och jag tvivlar på att dom ens hade lösenord utan dom slog bara på datorn när dom kom till skolan och hade därmed direkt och utan omsvep tillgång till alla kollegors ihopsamlade information.

Så allt detta säkerhetstänk som får applikationerna att mutera var och varannan vecka tycker jag helt enkelt inte om.

Det som däremot hade varit intressant är om applikationerna (typ FF) hade fått förbli sig lika och att dom BARA siktade in sig på buggar och säkerhetsbrister.

MVH/Roger
PS
"Varsågod, gå en guidad tur i nya käcka finesser"...

Det är hanteringen av pengar som sabbar hela internet-konceptet, tycker jag.

Vill bara säga det att ditt trevliga snack är lååååångt över min kompetensnivå

Hmm, Ja, det gäller andra trådar också.

Jag instämmer

Men vad ska man göra när man är passionerat intresserad av nåt man inte förstår?

Jag har läst väldigt mycket.

Men vet du vad?

Jag tror att det "bästa" sättet att försöka förändra nåt är att försöka "uppfinna hjulet på nytt"

Är du med

MVH/Roger

Nä, uppfinna hjulet på nytt är tämligen kontraproduktivt och meningslöst, hjulet är ju ultimat, så det behöver inga förbättringar.

Fan Tomas, är du också ensam?

I min värld suger det!

Nåväl, du inser säkert hur fel du har.

Om man ska kunna förändra nåt gäller det att tänka i nya banor.

Man kan emellertid förlita sig på litteratur därmed bli matad med det sättet saker och ting började och hur det sedan på ett "naturligt sätt" utvecklade sig.

Men detta är inte detsamma som att tänka i nya banor dvs "uppfinna hjulet på nytt".

Samtidigt, vem tror jag att lilla jag är

MVH/Roger
PS
Undrar om detta nånsin kommer mynna ut i nåt användbart

Ensam, varför skulle jag vara det?

Nä, jag har aldrig fel.
Jag tänker alltid i ny banor, och de är rätt många, tro mig.

Med risk för att jag minns fel:

Man sänder väl så mycket som ryms i en MTU (om man ens har så mycket data), och sedan får resten av datat vänta. Eftersom TCP är strömmar och inte överföring av någon slags fasta block så behöver man aldrig i förväg ange antal "block" eller liknande, utan man skickar bara på fler och fler paket som är en MTU stora vardera. Men visst, man måste ge dem löpnummer och hålla reda på vilket block som är vilket, och om man vill ha mer än ett block "ute i etern" samtidigt så måste man väl kunna räkna ut vad som eventuellt behöver sändas om, och då kan väl MUL/DIV antagligen vara händigt.

rogerk8 skrev: Rätta mig gärna om jag har fel men säg att din hårddisk är på moderna 100 GB.

Jag tvivlar starkt på att antalet block är större än 100.

Dvs varje block är på maximalt 1GB.

Nu är du helt ute och cyklar. En fil på lagringsenhet tar alltid upp ett helt antal block, om varje block vore 1 GB så skulle en fil med ett tecken ta upp 1 GB på disken...

http://sv.wikipedia.org/wiki/Allokeringsenhet

För en hårddisk är den minsta del som hårdvaran kan läsa eller skriva en sektor. Traditionellt har en sektor varit på 512 byte, men på moderna hårddiskar kan storleken vara en annan, beroende på konfiguration. Typiska klusterstorlekar kan variera från 1 till 128 sektorer. Det totala möjliga antalet kluster varierar beroende på typ av filsystem. FAT16 tillåter till exempel totalt 65.524 (2^16-12) kluster, FAT32 2^28 (268.435.456) kluster och NTFS 2^64 stycken.

Genom att läsa din trevligt bifogade länk har jag fattat följande:

Ett allokeringsminne/kluster/block är en gäng spårsektorer (där skivan är indelad i skivsektorer och spår).

Ett sådant block är alltså den minsta minnesmängd som går åt redan vid skrivning av en fil med ett enda tecken.

Mycket intressant för jag har alltid fattat nada om hårddiskar (speciellt intresserad av den elektromekaniska biten dock).

Börjar förstå begreppet fragmentering nu

Lite flummigt funderar jag då på om det inte får plats större minnesmängd längst ut än längst in (i samma skivsektor)?

Fast med tanke på att periferihastigheten är större längst ut (samtidigt som spårsektorn är längre) och R/W-tiden säkerligen densamma så är nog minnesmängden konstant.

Dock förlorar en radiellt pendlande läsarm accesstid...

Samtidigt, varför kan inte data läggas "vinkel-sekvensiellt" och radiellt kluster för kluster?

Hur nära sanningen (om defragmentering) är jag?

MVH/Roger

xxargs skrev:Ett 'litet' fel infann sig i en av MS C-libbar av en viss version med felaktiga avrundningsregler (det finns flera att välja mellan även på en matteprocessor) vilket gjorde att mp3-uppspelare och kodare som kompilerades på den plattformen fungerade inte alls utan gav bara oljud och brus, tydligen var det en liten flagga fel till matteprocessorn så att det avrundades efter ekonomiska avrundningsregler som default och inte enligt det som används inom naturvetenskap - det räckte...

Kan du förklara skillnaden mellan ekonomiska och naturvetenskapliga avrundningsregler?

MVH/Roger

MiaM skrev:Med risk för att jag minns fel:

Man sänder väl så mycket som ryms i en MTU (om man ens har så mycket data), och sedan får resten av datat vänta. Eftersom TCP är strömmar och inte överföring av någon slags fasta block så behöver man aldrig i förväg ange antal "block" eller liknande, utan man skickar bara på fler och fler paket som är en MTU stora vardera. Men visst, man måste ge dem löpnummer och hålla reda på vilket block som är vilket, och om man vill ha mer än ett block "ute i etern" samtidigt så måste man väl kunna räkna ut vad som eventuellt behöver sändas om, och då kan väl MUL/DIV antagligen vara händigt.

Här kan man alltså eventuellt dra slutsatsen att om man har en normal mängd data så klarar Folkdatorn att tom koppla upp sig mot internet

Vet du hur mycket det ryms i en MTU?

MVH/Roger

Enligt engelsk Wikipedia är dock det vanligaste MTU (Maximum Transmitted Unit) på 1500 byte.

Det var inte mycket

Men för textmässig kommunikation duger det väl?

Man borde ju tom kunna skicka över en olinjär formel för beräkning på detta sättet.

Nerladdning av större filer ser jag heller inte som nåt problem. Bara ta emot och skifta in, liksom

Att skicka större filer kan dock bli ett problem. Men om man leker med tanken att man först har hela filen. Man bestämmer sig för att skicka den med arslet först. Man börjar på högsta adressen. Skickar 1500 byte. Räknar ner adresspekaren 1500 byte och skickar ytterligare ett paket samt håller på så tills allt är skickat.

Ser fortfarande ingen nytta för MUL/DIV

MVH/Roger

Jag har dock ett litet problem.
Den kan inte MUL/DIV.

Då ska du inte använda den.

Hur enkel man än vill göra en processor så är väl ändå minimikravet att sen ska klara av de fyra räknesätten. Om den bara har en ALU som kan hantera addition, subtraktion och bitshift - med carrybit - så har man grunden. Det är dessutom extremt enkelt att ordna med enkel logik, så det borde inte vara något man behöver undvika.

Klarar den inte det tror jag inte att den duger att bygga något av. Så hela tråden tycker jag bygger på ett feltänk från början.

Nu är ju det så fantastiskt skapat att MTU'n även innehåller diverse checksummor, headers osv, så payloaden i ett IP-paket är faktiskt mindre. Det är dock inte riktigt så enkelt att man bara kan skicka iväg ett stycke text i ett paket och tro att det dyker upp på mottagarens skärm.
Om det är epost, så skall det naturligtvis med en massa headers osv, förutom själva meddelandet, är det ett kodat epostmeddelande, så måste också headern tala om hur det är kodat (base64 etc).
Är det en Websida så måste hela HTML-headern vara med, och naturligtvis måste ju texten vara formaterad i enlighet med HTML, annars begriper inte webb-läsaren det, osv.

Alla paket har ett nummer, och mottagaren sätter samman paketen i rätt nummerordning, sändaren skickar om paketet om den inte får en ACK inom en viss tid.