Små datamængder

der blandt andet skal gøre mobilbetalinger til en leg

De data der skal udveksles i forbindelse med en mobilbetaling er jo så begrænsede at lav reel dataoverførselshastighed ikke har nogen begrænsende effekt. Men det er naturligvis vigtigt at de korrekte data bliver overført jvnf. overhead der benyttes til netop at sikre dette.

Re: Små datamængder

Der er jo ingen som siger at NFC kun skal bruges til mobilbetalinger... ;-)

Re: Re: Små datamængder

Der er jo ingen som siger at NFC kun skal bruges til mobilbetalinger... ;-)

Joh - det vil jeg mene...eller dvs:

som den RFID-baserede teknologi hedder

RFID har aldrig været tænkt til at skulle benyttes til andet end ultrasmå datamængder såsom ID'ing eller udveksling af en betalingskode.

Overhead - uundgåeligt

99% overhead. Uha, det lyder vildt og voldsomt.

Men ja, det er ikke til at komme udenom at der er overhead i netværk. Prøv at tænke på ganske almindeligt kablet 100 mbit LAN; Jeg mener at kunne erindre at den anvendte CSMA/CD protokol medfører congestion-fænomener, begyndende ved cirka 35% udnyttelse af båndbredden. Hvilket så vil kunne 'oversættes' til uha-uha 65% procent overhead og en nyttehastighed på 35 mbit.
Heldigvis er tabet afhængig af trafiksammensætningen, så oftest ser man næsten den fulde båndbredde.

Eller hvad med netværk som glimrer ved 'latency-garanti' - altså at netværkets struktur garanterer levering af data inden for et specificeret tidsrum. Gøres typisk med timeslotting, og mht. reduktion af effektiv båndbredde findes der næppe nogen mere effektiv metode end lige netop timeslotting. For et givent net med f.eks 10 noder står max 10% af den rå bitrate til rådighed for hver node. Heldigvis anvendes net med latency-garanti typisk i fieldbus og industriel automation, hvor det netop gælder at datamængderne er små men vigtigheden af levering til tiden er høj.

Dette gør sig muligvis ikke gældende ifbm mobilbetalinger, men netop fordi der er tale om meget små datamængder, gør det nævnte overhead ingen skade.

Jeg mener at kunne spore en anelse 'sensationsjagt' i overskriftens udformning?

Re: Overhead - uundgåeligt

99% overhead. Uha, det lyder vildt og voldsomt.

Men ja, det er ikke til at komme udenom at der er overhead i netværk. Prøv at tænke på ganske almindeligt kablet 100 mbit LAN; Jeg mener at kunne erindre at den anvendte CSMA/CD protokol medfører congestion-fænomener, begyndende ved cirka 35% udnyttelse af båndbredden. Hvilket så vil kunne 'oversættes' til uha-uha 65% procent overhead og en nyttehastighed på 35 mbit.

Der er ingen (ok meget få) der i dag benytter CSMA/CD på kablede 100Mbps-netværk. Så din pointe med at det ikke er slemt med overhead går lidt tabt: I andre sammenhænge fjerner vi den slags overhead.

Re: Re: Overhead - uundgåeligt

Humlen i den bemeldte problematik er jo at man har et asyncront trådløst multi-peer netværk, så problemerne med pakkesammenstød (congestion) opstår helt nede på "første hardware niveau" - så at sige. De fysiske sammenstød/båndbredde problemer i et trådet netværk opstår lidt højere oppe i det elektriske hieraki.

ingen problem

Hvis det kun virker når man holder telefonen tæt på, kan det bruges til at aftale en anden kommunikation kanal. WIFI (aftal SSID og kode), Internet (aftal IP nummer og portnummer til at brude igennem NAT eller firewall). Bluetooth. Infrarød. Du kan udveksle kryptering nøgler eller bluetooth handshake koder. Så kan du bruge hvilken som helst "åben" kanal til sikkert dataudveksling. Hold laptoppen op imod hjemme routeren og den bliver indstillet til sikkert adgang på nettet. Fedt!

Strømforbrug

For RFID chips, kan overhead betyde noget. Et overhead, betyder større strømforbrug, og dermed at der skal bruges større stråling, for at aftaste kredsene.

Der er forskel på virkningen, afhægigt af om overhead er fra master til slave - eller fra slave til master. Da det er energien som overføres fra master til slave der giver slave enheden strøm, så vil normalt være nødvendigt at sende en del bits af denne vej. Det er ikke ualmindeligt, at der sendes en eller flere bit høj, inden data aflæses, for at sikre slave enheden har energi nok, til at retursende en bit. Hvis der eksempelvis må sendes en aktiv bit, for hver returneret bit, så giver det et overhead på 50%.

Herfra er dog langt, til 99% overhead...

Overhead betyder meget i de fleste RF sammenhæng, på grund af at bits koster strøm. Mange softwarefolk, er ikke helt klar over denne sammenhæng og ved ikke, at hvis de udvikler en protokol hvor der kun skal overføres en enkelt bit, at det så måske giver 100 gange lavere energiforbrug, og dermed levetid for et batteri på et trådløs produkt, som er over 100 gange større.

For at opnå, at der netop kun udsendes en enkelt bit, og at derved opnå et lavt strømforbrug, kan dog også vælges at give denne bit mange mulige bitpladser - f.eks. 1024 bitpladser. Det betyder, at 10 bits information, nu fylder 1024 bitpladser, og dermed en del mere i luften. Reelt bruges så kun 1% af båndbredden. Men, udfra et energimæssigt synspunkt, er det effektivt, fordi at alle pladser i rummet er tomme, og båndbredden faktisk ikke bruges på andet, end at opnå lavt forbrug.

Som regel, er det bedste et kompromiss, hvor man ikke ødsler pladsen væk i rummet - for dette optager også plads for andre, til at være på samtidigt.

Når der udvikles en protokol, er strømforbrug vigtigt. Skyldes det store overhead regulære tekniske overvejelser, kan det nemt være godt. Men, er det bare ødslen af bits og strømforbrug, står det naturligvis til fyringer.

Der er jo ingen der ønsker standarder, hvis hensigt er at gøre batteriet fladt på kort tid. Eller, hvor at brugeren udsættes for væsentligt mere stråling op i hovedet, end nødvendigt.

Mængden af stråling, har også stor sammenhæng med energiforbruget. Selvom der er afsat plads til mange bits, betyder det ikke nødvendigvis stor stråling, og stor strømforbrug, hvis protokollen sikres, at kun få bits er aktive. Det er kun de "tændte" bits, som giver anledning til strømforbrug og stråling. Anvendes FM eller PM modulation, er alle bits, uanset om de er nul eller et, altid tændte. Dog, giver mange FM modulationsstandarder også mulighed for slukkede bits, og så tæller de ikke nødvendigvis rigtigt med som et overhead. De fylder dog i luften.

En typisk standard, vil normalt bestå af et antal "interrupt bits", der vækker en sovende enhed. For telefoner, vil et interrupt gives, f.eks hvis der ringes til telefonen, hvis der sendes en besked, eller administrativ besked såsom opgrade. Man vælger hvor ofte der skal lyttes til sådanne beskeder, afhængig af hvor lang forsinkelse der accepteres fra interrupt til opvækning. Accepteres et halvt sekunds opvækningstid, vil typisk udsendes to bits per sekund til dette formål. Da der kan være mange enheder, ønsker vi ikke at alle skal vækkes, bare fordi at éen ringer. Vi vil derfor typisk have et større antal bits - f.eks. 1024 bits - og hvor telefonen så lytter på kun éen af disse bits. Det giver nu rask væk 2048 bits per sekund, alene til disse "vække bits". Vi kunne vælge et mindre antal, men risikoen for, at så blive falsk vækket, vil øges. Det koster lidt strøm at vækkes falsk, da vi når vi vækkes skal tjekke, om beskeden virkeligt er til os, og ellers skal vi hvile os igen. Dog koster det ikke lang tid, og vi kunne sikkert nøjes med et færre antal bits, uden det vil gå voldsomt ud over forbruget. Antages, at der kan være en million enheder, på samme sted, skal sendes 20 bits der lyttes til, når vi får et interrupt. At lytte til 20 bits, koster lidt strøm, men sker det kun ved 1/1024 af alle opkald/interrupts til telefonerne, så er det et utroligt begrænset forbrug, og vi kunne sikkert nemt nøjes med 256 positioner, der sendes to gange i sekundet til interrupts, uden at forbruget øges.

Udover interrupt, kan også være nødvendigt at lytte til en basestation, for at tjekke at den er der, og ikke er skiftet. Dette koster en enkelt ekstra bit, hvor der lyttes på en aktiv bit. Her skal så igen afsættes flere bits, så nærliggende stationer, ikke bruger samme bits. I nogle tilfælde, vil anvendes en negeret interrupt bit, så en manglende information, også indikerer basestationen mangler. Det giver dog et højt forbrug på basestationen, da den skal sende mange aktive bits uden grund. Og igen, giver det en del watt, og måske hovedpine, som kunne undgås.

Det jeg forsøger at vise, er at mange bits, som bruges fornuftigt, kan være en god investering. Meddens at ødsel af bits, der sker uden teknisk indsigt, og uden forståelse for konsekvenser for stråling og energiforbrug, oftest er uønsket, og at ekstra bit her kun giver store ulemper.

Derfor, er det altid vigtigt, at bruge få bits, men ikke færre bits end er godt.

Re: Strømforbrug

Humlen i den bemeldte problematik er jo at man har et asyncront trådløst multi-peer netværk, så problemerne med pakkesammenstød (congestion) opstår helt nede på "første hardware niveau" - så at sige. De fysiske sammenstød/båndbredde problemer i et trådet netværk opstår lidt højere oppe i det elektriske hieraki.

Et kollisionsbaseret trådløs netværk, smidder ikke nødvendigvis stor båndbredde på kolisioner. Antages, at 4 sender samtidigt - da vil ikke gå lang tid før at kollisonen detekteres. Det er muligt at sikre, at halvdelen kobles ud, så det anden gang kun sender to. Og næste gang, kobles også halvdelen ud, så der kun sendes éen - og uden kollision. Selvom der er 1024 samtidigt sendende, vil en unik få adgang, efter kun 10 sammenstød - og det svarer til omtrent 10 bits. Sendes en pakke på 16 bits, er det under 50% af kommunikationen. Der skal også sættes lidt af til pauser, men med mindre data sendes bytevis, og der er tusinder der sender samtidigt, vil ikke kunne opnås så dårlige tal, med mindre der er fejl i protokollen, f.eks. at der ikke sikres at halvdelen kobles af, for hver kollision.

Typisk løses det med pauser. Enten udfra en tilfældighedsgenerator, eller udfra et ID nummer, kobles halvdelen fra ved en kollision. Det fortsætter, indtil der er en større pause, når alle er koblet fra, og kun den sidste kom til. Så først, begynder de at kunne kolidere igen. Til at koble halvdelen ud, kan bruges en tilfældighedsgenerator, eller bits i nodenummeret. Der kan også anvendes priorit, eller indgå prioritet sammen med tilfældighed eller node nummer. Er nodenummer på 16 bits, kan højst opstå 15 kollisioner, inden man kommer til. Mangler denne del, medfører det totalt kaos og den ekspoenntielt aftagende fordeling udebliver.

Typisk, vil man lade dem der har fået data overført, kræve en længere pause, for at måtte komme til igen. Derved balanceres båndredden, så alle kommer ligeligt til. Er der 1024 første gang, er der dermed kun 1023 næste gang, da den der kom til ikke er med i løbet. Først, når alle har fået sendt data, deltager dem der har fået sendt i løbet igen, da at der opstår en ekstra stor pause. Hvis der ønskes ligeligt adgang, vil dette typisk bruges.

Som det gerne tydeligt skulle fremgå, så vil ikke ske det, at mange medfører de taler i munden på hinanden, og aldrig kommer til. Det er bare et spørgsmål om, at de overholder mødeprotokollen, og forstår betydningen af pauser. Er der mange, som skal på, accepterer halvdelen at de går ud af løbet, indtil der kommer en lidt større pause, og de får mulighed igen. Og ønskes ligeligt adgang, så accepteres, at når man først får et ord indført, ligger man i bunden og venter på ekstra lang pause, hvis at der ønskes ligeligt fordeling..

Re: Overhead - uundgåeligt

Der er ingen (ok meget få) der i dag benytter CSMA/CD på kablede 100Mbps-netværk. Så din pointe med at det ikke er slemt med overhead går lidt tabt: I andre sammenhænge fjerner vi den slags overhead.

100 mbps kablet netværk - er det ikke det vi kender som 'ethernet'?
Jævnfør http://www.net-faq.dk/faq.pl?g...sion benytter ethernet CSMA/CD, hvilket kolliderer (hehe) med din udtalelse. Hvad er det jeg misforstår her?

Re: Re: Overhead - uundgåeligt

Prøv at læse lidt på lektien.

Normalt bruge man 100 Mbit som punkt til punkt, dvs der er ingen at kollidere med... altså fra computer til en eller anden switch der så sørger for flowkontrol.

Det var (sådan lidt generaliseret)kun på gl 10 Mbit tyndt og tykt (det gule kabel) som var bus baserede - dvs multi drop - at man havde kollisionsmuligheder.

Der er masser at læse på wikipedia (den engelske udgave) om dette her